Hi Richard & Thomas I'd just like to indicate that we have seen the delay for router advertisement to be a significant delay in MIPv6 handovers, since there is no DAD in the case where a mobile node moves back to a previously visited network.
In this case, the RS/RA delay is the biggest factor in the L3 handover time (dwarfing signalling since we use HMIPv6). Even in the case of fast handovers for MIPv6, any delay before the receipt of an RA can cause performance degradation, because a node cannot determine if it is on the correct access network until it receives this advertisement (and thus cannot finalize its address acquisition and signalling). Each of the delays in the handover are discrete issues, related to the design of the original protocols (which are good, but not tuned for mobility). There may be an integrated solution, which gets around most of these issues, but there are also several simple modifications which I think should be considered to DAD and neighbour discovery (where the delays occur). Since they may be deployed without harm to other systems, nor complicated reliances on Link-layer technologies. I think that a co-ordinated approach to these issues is needed, rather than a single integrated solution. Greg Daley Richard Nelson wrote: > ----- Original Message ----- > From: "Thomas Narten" <[EMAIL PROTECTED]> > >>Stepping back for a minute. MAX_RA_DELAY_TIME is .5 seconds. A router >>delays a random amount of time between 0 and .5 seconds before >>responding. So, on average, .25 seconds. That's not a terribly long >>delay. What exactly is the application that can't deal with this kind >>of a delay? > > > Plenty, voice particularly, but it might also kill your TCP transfer. Also > saying average .25 sec fudges the issue, 10% of the time it will be greater > than .45 sec so users will normally see near the worst case some of the > time. > >>Then there is more to getting link connectivity than just finding a >>router. You may have to generate an address, and then invoke DAD. But >>DAD (on an Ethernet) requires a 1 second delay. That's a much bigger >>factor than the RS delay. Is this not also an issue? I.e., what is so >>critical about getting an immediate RS but that doesn't also have an >>issue with some of the other ND/addrconf/DAD constants. > > > Yep it is a big issue, but there are solutions to that as well. > > Will > >>addressing the RS delay alone *really* solve the problem here, and if >>not, shouldn't we be thinking about the more general problem and >>working on finding a solution that deals with all the potential delay >>spots? > > > Well the general solution is fast handovers and that is being worked on. > But without fast handovers, if you use fast RAs and HMIP and get rid of DAD > somehow, the MIPv6 handover can be a few 10s of milliseconds. If you have a > fast L2 handover (A big if as it turns out) it is possible that MIPv6 > handovers could be really useful even with real time traffic. > > > Richard. > > >>Thomas >>-------------------------------------------------------------------- >>IETF IPng Working Group Mailing List >>IPng Home Page: http://playground.sun.com/ipng >>FTP archive: ftp://playground.sun.com/pub/ipng >>Direct all administrative requests to [EMAIL PROTECTED] >>-------------------------------------------------------------------- >> > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to [EMAIL PROTECTED] > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
