Reject delay fractional value

Eugene Grosbein fr at grosbein.net
Wed Oct 29 21:42:57 CET 2014


On Wed, Oct 29, 2014 at 10:15:19AM -0400, Alan DeKok wrote:

> > OTOH, why have you prohibited fraction delays in between 0 and 1?
>   Because sub-second delays make much, much less sense.  You have to
> draw a limit somewhere.  I put it at one second, at least in part
> because that was the previous limit.
> 
> > I can think of usefulness of 0.5 or 0.9 values too.
> 
>   Which you don't explain here.  Nice.
> 
>   "I can think of reasons why we can do X.  But... I won't tell you"

I can explain but that will take more words and
English is not my native language, but let's try.

DHCP has some similarities with PPPoE. To get an IP address,
a client sends a broadcast packet first: PADI or DHCPDISCOVER.
Suppose, there is a farm of PPPoE or DHCP relays/servers in the vlan,
so the client will get a bunch of replies: PADOs or DHCPOFFERs.
Generally, the client chooses first (most quick) access server
and may send a unicast request to it: PADR or DHCPREQUEST
(I know that DHCPREQUEST may be broadcasted too, but leave this for now).

It is possible to manage server's load with very small delays
in a response to initial broadcast. For example, Cisco has a command
"pado delay <miliseconds>" to conditionally insert such delay
before PADO in sent (PPPoE Smart Server Selection feature,
http://www.cisco.com/c/en/us/td/docs/ios/bbdsl/configuration/guide/bba_pppoe_sss.pdf ).

So, we can preferably serve some users from one part of server farm
and other users from another part but still have a backup in case
of long failure of "first part" without noticable delay before answer.

The same applies to the farm of FreeRAIDUS servers acting as DHCP servers.
But artifical limitation for 1 second as minimum delay length would
be noticable for no good reason.

This is only one of use cases for small delays.
It's local system administrator responsibility for selecting sane
delay values and IMHO server software should not impose artifical
limitations. You can never know in advance, what use cases may
field practice present to an administrator, can you?

Eugene Grosbein


More information about the Freeradius-Users mailing list