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

[Bernard Aboba <bernard_aboba@hotmail.com>]

>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.

>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.

>I thought it was the 802.11 associate frames that were problematic on 
>Monday's at the IETF ;-)

Actually, IETF 802.11 usage shows evidence of congestive collapse due to 
inappropriate rate negotiation behavior.  That kind of problem can be made 
considerably worse by multicast traffic without appropriate jittering and 
backoff.

>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.