Re: [DNA] High-level overview of DNA, take 2

[Erik Nordmark <erik.nordmark@sun.com>]

Bernard Aboba wrote:
>> But there is no middle point: sending the RS to all-routers in 
>> parallel with the unicast NS doesn't reduce the multicast traffic.
> 
> I don't think the issue is multicast traffic reduction per se.  The 
> issue is the *timing* of multicast traffic.  To avoid multicast storms 
> it is necessary for multicast to involve delays and backoffs. Sending 
> both NS and RS in parallel would remove potential ambiguities while not 
> requiring that multicast RS be sent *immediately* as has been proposed, 
> which would create severe scaling problems in the event of a power failure.

Are you assuming that some event would cause N stations to try to 
multicast at the same time? (Recall, this is a single multicast packet 
and not somebody streaming UDP video over multicast.)

How does DNAv4 handle this? The draft says to do the ARP validation and 
DHCPREQUEST in parallel, and explicitly says to broadcast the 
DHCPREQUEST. Seems like DNAv4 as specified has as much of a problem with 
broadcast/multicast load...

>> But that approach optimizes only for the case of non-movement. We need 
>> a balance that also optimizes for the case of movement.
> 
> Actually, I'd argue that the important thing is to make sure that 
> performance is not impacted negatively in any scenario.  Since DNA is an 
> optimization, it is not useful unless it actually improves performance.

But in the above case you are saying that we can detect non-movement in 
a roundtrip time (the NS/NA exchange), but that detecting movement 
requires some random delay (how much? how much will VoIP cope with?) 
plus a RS/RA exchange.

I don't think such an approach satisfies the DNA goals (RFC 4135). FWIW 
that document does not say that we should avoid using multicast; if 
multicast is so evil we should have had that discussion from the start 
instead of in the 11th hour. And as I said elsewhere, there is plenty of 
network technology where multicast is expensive (.15.4 .16) but is 
expensive even for the RS when the device boots. So the multicast 
avoidance issue isn't specific to DNA.

>> Seriously, it is hard to optimize for the case of flaky infrastructure 
>> (like IETF on Monday morning), and at the same time also optimize for 
>> non-movement as well as movement.
> 
> I believe that the effects we see at the IETF are real and occur 
> regularly in high density 802.11 environments.  They are not anomalies, 
> since they show up in test environments regardless of the equipment that 
> was being used.

Yes, but *Monday morning* at IETF is a bit special, since it is often in 
a place that hasn't seen that density deployment before. Thus it is 
quite a bit different ramp-up than some hotspot that sees a lot of 
traffic, because of the arrival rate in a completely new infrastructure.

The rest of the week is more normal, with the usual plethora of 
operating systems that try to be too helpful to automagically switching 
to ad-hoc mode (and in some cases using the same ESSID as before they 
lost the AP. ;-)

    Erik