Re: [DNA] Comments on draft-narayan-dna-hosts-bcp

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

Greg Daley wrote:

> regarding different reachability for unicast and
> multicast: 
> 
> I think that there may be a situation where 
> a device only uses unicast signaling to associate
> with an AP, and multicast is broken because of
> the motion of the node.  This isn't only related
> to Link-Re/Establishment events, but also may 
> occur if the node experiences changes within a 
> wireless cell.

It's true that the L2 packet loss might be higher for multicast than for 
unicast, but in any L2 with L2 connections/associations, I don't see 
this making a difference when the routers are attached to a wired 
network. Either the multicast packet makes it to the AP or not, and if 
it makes it to the AP then all the routers will see it (because the 
wired part of the network works well.)
Of course, if the routers are not on a wired segment then things are 
different; there would be an increase probability that one router sees a 
RS but not the other router.

But this still doesn't make a case for verifying (unicast) bidirectional 
reachability with the old router, since unicast works well.


The discrepancy between multicast and unicast packet loss rate does hint 
at a possible optimization. At high multicast loss rate it can be 
significantly faster to send a unicast packet to the old router and 
receive a unicast response, they trying to get a multicast RS to one router.
But it only helps in the case when you are on the same link. And I would 
assume that a DNA host has the status-quo assumption i.e. unless it can 
determine that it has moved it continues to use the information for the 
(old) link. Thus sending unicasts would help speedup the DNA procedure 
when on the same link, but without any unicast the host will assume it 
is on the same link so the time it takes to verify this doesn't matter.
The only difference I can see is how long time the host will be in DAD 
optimistic mode (but DAD doesn't work well with high multicast loss rate 
so this is a bit of a rat hole).

Thus I don't see where sending a unicast packet to the old router would 
help at all.

> Perhaps this is something worth treating later
> (in a different document) if there's a
> demonstrated need.

It sure makes sense understanding the motivation and the tradeoffs better.

> The 802.11 network wasn't specifically my focus
> either.  There will be networks where a node
> discovers or is instructed to take a cell using
> network side messages.
> 
> Where there isn't explicit acknowledgement of 
> 'toward network' frames at the MAC layer, then
> upper layer confirmation from Layer 3 should be
> used.

I'm having a hard time understanding what this means. We have NUD in all 
cases, thus sooner or later the host will detect if one of the default 
routers isn't working. Are you saying that such information should be 
"exported" to L2 so that L2 can use it to make handover decisions?


> I think there was a section describing using 
> previous knowledge, including recently visited
> networks.
> 
> Perhaps we can revisit the text to make it more
> explicit.

ok

> There are timing relationships with other layers
> for example MLD, which needs to be run before 
> _and_ after change detection, based on the DAD
> state, and the results of the detection.
> 
> Is this the sort of thing we should describe?

Yes.
FWIW I think there is some text about this in the solutions framework doc.

    Erik