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

[Greg Daley <Greg.Daley@eng.monash.edu.au>]

Hi Erik, 


Thanks for helping to work through this.


----- Original Message -----
From: Erik Nordmark <erik.nordmark@sun.com>
Date: Monday, March 14, 2005 6:12 pm
Subject: Re: [DNA] Comments on draft-narayan-dna-hosts-bcp

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

Agreed. 

I'm starting to think that the possibility
of them not being on a wired segment 
is increasing with time.


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

Agreed.  I think that there are ways of forcing
other reachability checks (such as sending RS
without a source address). I'm beginning to think
that it's a different problem though (not explicitly
DNA's problem).

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

Oh Well, at least with optimistic DAD, there's
no need to drop out of optimistic/tentative
state unless you need to send an NS...
	
With regard to optimizations, 802.11 itself
treats Router Solicitations as Unicast, when going 
to the DS (wired side).  So the host won't
prejudice itself just from the RS.

It's the router's response relying on unicast or
multicast which may affect it.  That's not for this
document though, and doesn't have to do with
bidirectional reachability, rather the success
rate of DNA signaling.
 
> Thus I don't see where sending a unicast packet to the old router 
> would 
> help at all.


Agreed.

Should we put some consideration for the
router side document to indicate that
in some situations downstream multicast is
more unreliable than unicast?

This would allow routers to prefer unicast
in those networks.
 
> > 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?


No, it's already being done with RA setting
the STALE flag.  The question is whether we need
to do anything more.

The STALE flag causes at least 5 seconds delay.
If that's OK for this rare case then we may or may
not may a statement on the issue...
 
> > 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.

Let's get an issues list made up based on your
review and the discussion here (am in Atlanta,
so it may be a bit tardy).

Then when we get a new version of the framework
draft, we can see where the text best fits.

Does this sound like a plan?

Thanks again.

Greg