Re: [DNA] Confirming today's face-to-face meeting decisions

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

Hi Sathya,

----- Original Message -----
From: Sathya Narayanan <sathya@research.panasonic.com>
Date: Friday, November 12, 2004 2:24 am
Subject: Re: [DNA] Confirming today's face-to-face meeting decisions

> <snip> 
> > > 2) Whether immediate change is detected in link-scoped 
> > identifier is actually not clear - this is primarily because of 
> > the non-dependency of the method on L2 trigger (and that is 
> > arguably a good thing), so the average gain in the detection time 
> > for link-scoped identifier approach MAY not be very high. Again, 
> > we need some analysis.
> > 
> > I think this is a separate problem.  The point is in being able 
> to 
> > makea correct decision based on the reception of a single RA.  
> How 
> > you get that RA is a separate problem.
> Yes. It is a separate problem, but when we are talking (comparing) 
> the quickness of link-change-detection we need to look at the 
> complete picture. If the link-scoped approach has the property of 
> link-change-detection when a unsolicited RA is received (which is a 
> good thing about it), but how useful is it if you need the RS 
> message to initiate it for rapid-detection is a valid point to 
> consider in terms of the cost. If the link-scoped approach depends 
> on a RS message, than host-scoped approach is (arguably) as good as 
> the link-scoped approach with less out-of-band cost.
> 

L2 Trigger isn't needed, if in MIPv6 the RA rate is 20/second.
In this case, the only issue is establishment of trust with the router,
which is a problem in both cases.
 
> > > 3) I am not recommending timeout as the only change detection - 
> > if you think about the mechanism proposed in RRD, when the 
> > 'landmark still exists?' question is asked, if you receive a 
> 'this 
> > NEW landmark exists' answer thats an indication of link change. 
> > Ofcourse, you need to authenticate this response - but in most 
> > cases the router that responded is likely to be the router you 
> are 
> > going to use as default router and you need to authenticate it 
> anyway.> 
> > I can't remember the details of RRD - are you saying that there 
> is 
> > a way
> > for an RA with a prefix that you haven't seen before indicates a 
> link> change as oposed to a new router on the same link?
> Yes - if we can design a mechnism that with a high probability can 
> ensure that the confirmation of current landmark (from current AR) 
> is likely to happen before any other router responds. Thats what I 
> am trying to achieve with my MaxDelayForCurrRouter and 
> MinDelayForOtherRouters variables. If these two variables are equal 
> to zero, the probability is 1 - packet loss probability and the 
> time window involved can be few milli-seconds (this needs to be 
> confirmed using simulations, ofcourse).

There's a reliance on Positive Ack here in the case where there's
no negotiation amongst peers.

Packet loss is obviously a considerable factor, but it's not clear
without simulation whether the false positive movement in this case
causes more work or harm than the cost of explicitly changed LinkIDs.

Where there is any trust or knowledge of the prefixes or router id's
on a link, this has exactly the same issue as Link Identification 
in establishing trust between routers as Link ID.

These approaches Explicit LinkID and Landmarks are still likely to be
required in backwards compatability for non LinkID routers on the
same or different link.

For hosts which need landmarks it's possibly worthwhile working along
the lines of confidence intervals somewhat like CPL.

If we're confident that the landmarks are representative of the link 
(Link ID stored for a while across RS/RA, routerids stored), 
then any response which doesn't match the stored landmarks may be acted
upon immediately.

If we're not sure, but have an indication throgh reception of a non
matching landmark, then we should check the reachability of the landmark
explicitly (possibly with hysteresis). 
This may require a further test or waiting for a timeout...

Greg