randomizing lease renewal?
dhcp1 at thehobsons.co.uk
Fri Mar 30 18:56:01 UTC 2007
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
>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
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' !
More information about the dhcp-users