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

From: Greg Daley <[email-masked]>
Date: Mon, 14 Mar 2005 18:37:04 +0000 (GMT)

Hi Erik, 

Thanks for helping to work through this.

----- Original Message -----
From: Erik Nordmark <[email-masked]>
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

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 14 Mar 2005 11:21:11 -0800

> of them not being on a wired segment 

Having the routers float around in some wireless L2 mesh is ok as long 
as the packet loss rate is not too much higher for multicast than unicast.
And if the packet loss rate is much higher for multicast than unicast 
then I think we have more issues are ND (NS/NA address resolution, DAD, 
and router discovery all use multicast).
But this seems to have little to do with DNA.

FWIW A long time ago I did a partial sketch on a ND variant which could 
be used to minimize multicast by having hosts register their IP->L2 
mappings with some agents on the link (and the agents could be the 
routers) and then do implicit or explicit unicast queries of these 
agents instead of using multicast DAD and NS.
In such a scheme multicast would only be needed when no agent addresses 
are known on the link.

> prejudice itself just from the RS.

Is this a standard, or just something some 802,11 device drivers do?

> more unreliable than unicast?

FWIW It isn't clear to me whether the "router side document" is a BCP 
for the operational folks (who can control which routers advertise which 
prefixes etc) or the folks that implement routers (who can change the 
routers to unicast more and multicast less).

Shouldn't the latter (the "recommendations for those that modify the 
router code") be to implement the DNA solution?

In any case, I think the DNA solution should be done so that solicited 
RAs are unicast in most cases (but if there are 100 RSs per second, then 
it might make sense to respond with a single multicast RA).
Unicasting the RAs in the solution is rather natural since we want to 
make the RA delivery be fast.

> the STALE flag.  The question is whether we need

Ah.

> not may a statement on the issue...

Presumably we want a DNA solution that after the RS/RA exchange, the 
router which responded (with a unicast) is marked as reachable. That 
doesn't mean it was the same as any previous router on the link, but it 
provides more NUD information to the host at no additional cost.

ok

> draft, we can see where the text best fits.

It isn't going to be perfect, but I started the edits to the framework 
draft on Friday so hopefully I'll have something to send out in a few days.

ok

    Erik