Subject: [dhcwg] Re: Simplification of DNAv4 specification

From: Bernard Aboba <[email-masked]>
Date: Tue, 4 Oct 2005 10:05:09 -0700 (PDT)

The scenario we need to be concerned about is a power failure on 
a densely populated 802.11b network (e.g. an IETF meeting).  Here you 
might have 1000+ hosts attempting to obtain configuration at roughly the 
same time.  80211b offers only 1-2 Mbps bandwidth for broadcast/multicast 
traffic and up to 11 Mbps for unicast traffic.  One advantage to using 
unicast ARP instead of broadcast (the change introduced in -15) is the 
greater bandwidth availability for unicast traffic in 802.11. 

To prevent overload in a powerfail scenario, the major concern is 
limitation in the total traffic.  It's not just how many parallel attempts 
are made, it's the spacing between attempts, the synchronization of attempts, 
and the number of attempts. 

It might be ok for an implementation to try more configurations in 
parallel, as long as the jitter interval was larger, so that they were 
spaced out over a longer period. 

For example, 1000 packets of 50B each is 50KB.  If spread out over 
100ms, this represents 4 Mbps, enough to saturate an 802.11b network with 
a substantial number of stations running at 5.5 Mbps rate.  If spread over 
200ms, this is 2 Mbps, and at 400ms, it is 1 Mbps.  

Barr Hibbs said:

I basically agree with rewording DNAv4 to permit multiple
parallel efforts to configure the client.  We are rapidly
entering an era when network bandwidth is sufficient to all
but eliminate the concern about extra traffic.

Would it be appropriate to add a guideline such as: "clients
on a 10 or 11 Mbit/s network SHOULD NOT attempt more than
two (2) parallel reachability attempts (DHCPv4 and link
local), clients on a 54 or 100 Mbit/s network SHOULD NOT
attempt more than five (5), and clients operating on
networks above 500 Mbits/s MAY attempt as many as they
wish?"  The idea being to suggest a bit of self-restraint
without mandating an inflexible limit.

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Barr Hibbs" <[email-masked]>
Date: Fri, 7 Oct 2005 10:17:26 -0700

Bernard,

this is the sort of excellent discussion that might be very
useful as an addendum or appendix to the RFC, providing
implementors with guidelines for constructing clients, but
without burdening the RFC with cast-in-concrete
requirements.

If the advancement of DNAv4 would NOT be held up by such an
inclusion, I would suggest doing so, otherwise perhaps a
draft for a BCP would be useful?

--Barr

> -----Original Message-----
> From: Bernard Aboba
> Sent: Tuesday, October 04, 2005 10:05
>
>