Fwd: Rapid DHCP

[Dan Williams]

On Sat, 2011-07-30 at 19:41 -0400, Nathaniel McCallum wrote:
> Dan, that works on wireless networks. On wired networks the ARP
> technique determines *which* of the valid leases you should attempt to
> restore. So on a wired network you:

Right, which is why I noted a couple of times about wifi specifically,
but perhaps not as clearly as I should have.  Obviously NM doesn't yet
know which network you're on for wired, and ARP can help there.

> 1. ARP the known DHCP server IPs to discover the subnet.
> 2. ARP the IP from the valid lease on that subnet to avoid collision.
> 3. Restore the ifconfig from the still valid lease.
> 4. Renew the lease.
> 
> This should be pretty sane and gives large speedups to resuming on
> wired (which people with docks do a lot).

Yup, though on wired the impact is a lot lower since medium is a lot
more reliable than wifi, and DHCP tends to happen a lot more quickly.
The problem with wired is that broadcast and multicast frames often end
up getting dropped because they aren't necessarily re-transmitted when
there's interference or channel contention.  That usually doesn't happen
on wired networks.  But yes, it can help speed things up on wired, and
it can help determine what connection we should be associating with the
link as you describe.

Dan

> Nathaniel
> 
> On Jul 30, 2011 6:45 PM, "Dan Williams" <dcbw at redhat.com> wrote:
> > On Sat, 2011-07-30 at 11:46 -0400, Genes MailLists wrote:
> >> On 07/30/2011 10:37 AM, Lennart Poettering wrote:
> >> > On Sat, 30.07.11 10:31, Genes MailLists (lists at sapience.com)
> wrote:
> >> > 
> >> >>>> http://cafbit.com/entry/rapid_dhcp_or_how_do
> >> >>>
> >> 
> >> > 
> >> > IIRC connman (i.e. NM's competition) can do the ARP magic, too.
> >> > 
> >> > Lennart
> >> > 
> >> 
> >> 
> >> Seems like a pretty reasonable thing to do - surely better than
> just
> >> waiting for a timeout to decide if the server is not there ... are
> you
> >> aware of any gotcha's ?
> > 
> > NM already keeps DHCP information around based on the network you're
> > connecting to, so we don't need to ARP a bunch of servers just to
> > determine whether the DHCP server we wanted is still there. dhclient
> is
> > smart enough to attempt to reclaim the lease if it's not already
> > expired. Note that the Mac attempts to ARP a number of different
> DHCP
> > servers (192.168.2.1, 192.168.4.1, 192.168.1.1) which would be
> pointless
> > with NetworkManager, because it's extremely unlikely that the DHCP
> > server on your wifi network has changed; NM would simply know that
> the
> > last DHCP server used *on that wifi network* was 192.168.1.1 and not
> > bother to try talking to other ones like Mac OS X appears to do.
> > 
> > NM could use the same method of ARPing multiple DHCP servers that
> Mac OS
> > X does, but it wouldn't provide much additional benefit, if any, at
> > least on WiFi networks. It could be used on wired networks to (a)
> > determine which wired network you're connected to, and (b) do rapid
> > DHCP. Again, NM already knows what DHCP server and what lease was
> last
> > used on the specific wifi network you just connected to, and it
> won't
> > bother doing a DISCOVER, it'll just jump to RENEW if your lease is
> still
> > valid.
> > 
> > What's unique about the method described there is that the Mac
> > configures the interface with the same IP address it previously had
> if
> > the lease is still valid, while NetworkManager waits for the DHCP
> server
> > confirm the lease. So we could presumptuously configure the
> interface
> > with the previous address from the lease and then only tear it down
> if
> > the DHCP server fails or rejects the renewal.
> > 
> > Of course, none of this helps if your DHCP leases are short, but it
> > certainly helps if you put your laptop to sleep a lot and wake it up
> in
> > the same location.
> > 
> > Dan
> > 
> > -- 
> > devel mailing list
> > devel at lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/devel
>