randomizing lease renewal?

[Simon Hobson]

Scott Helms wrote:

>  > If a client starts downloading a large file that takes 8 hours to
>>  download, but they are forced to change their IP every 4 hours, then
>>  they will never be able to download the whole file.  Their client will
>>  keep retrying (restarting from the beginning if the client or the
>>  protocol doesn't support resume functionality) causing unnecessary
>>  load on the server.  This is pretty bad for the Internet.
>
>Now, bear in mind that my point of view is entirely based around
>Internet access and not LAN administration.  Having said that, the
>concept of an 8 hour download is pretty far fetched and one that can't
>be managed by a download manager is even less likely.

To put this in perspective, we've had requests on this list in the 
past for 2 hours (that I can remember), and downloads lasting 2 hours 
are quite feasible - not only that, but you have to consider that the 
user doesn't wait until just after an address change to hit download 
so you can affect downloads after any subset of the max lease time. 
As to download managers, taking your previous comments, I think you 
have to assume that the average level of 'cluelessness' is going to 
be far worse in your user base as a whole than amongst those with 
enough ability to run a server - and hence I think you can safely 
assume that few of your users will be running anything but the 
default software, and few will think to use any resume function 
instead of just clicking the 'download' link again.

>   Again, I ask the
>question, how is forcing a client to acquire a new IP address any more
>harmful than having a cable, DSL, or wireless connection drop offline?

How badly engineered is your cable network ? I would suggest that if 
a cable modem can't keep it's link up for at least days at a time 
then there's something wrong. That's a lot different to deliberately 
engineering a broken network - like forcing all cable modems to 
disconnect every few hours.

>In short, I think the argument that says a network administrator
>shouldn't have a tool because some network admins might not use it in an
>intelligent fashion is pretty weak given that the same admin can use (or
>misuses) other tools to create the same inefficiency.  Again, I don't
>write ISC and I don't intend to slight the people that do, I'm simply
>expressing my opinion.

I don't think the authors have said that, what has been said is that 
the tool was written to the rfc and to change it would require more 
than trivial modification to core bits of the code. The demand is not 
high and there are plenty of other things (like IPv6) to do. I'm sure 
that if someone were to produce sensible modifications (including 
documentation changes that address the "are you being stupid here ?" 
aspect), then they would be considered. This would not be the first 
non-rfc-compliant element as I understand that a future version will 
allow the administrator to change the key selection from it's current 
(RFC compliant) 'match first (client-id, hardware)' implementation to 
work around two common issues (one of them down to a specific vendors 
client implementation).

>I think that OSS loses when we decide that a
>feature isn't "moral" to include since closed source vendors don't have
>the same compunction, especially given that I don't think this exclusion
>actually accomplishes anything other than forcing people to other
>solutions.

I don't think that's been said either - at least not in those terms. 
It would have helped greatly if you had said WHY you wanted this 
function in the first place, because without it we have to guess, and 
based on past experience we assume that it's because the poster wants 
to do something stupid (or more correctly has been ordered to do 
something stupid by management). I've been on this list for a few 
years, and I think the question comes up several times a year - yours 
is only the second time (that I can remember) when it wasn't asked 
for as a 'stupid switch' !