James, Thanks. I will ask our folks to do the same and see if we see the same. Will take me some time.
/jim -----Original Message----- From: James Kempf [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 10:41 AM To: Bound, Jim; Brett Pentland; Thomas Narten Cc: [EMAIL PROTECTED] Subject: Re: Changing RS Reply Timing for Mobile IPv6 Jim, We have numbers for standard MIPv6 v.s. optimized MIPv6, where optimized uses the 802.11 reassociate for a link up trigger to cause the RS. There is a substantial decrease in packet loss, on the order of the router beacon. This requires us to set MAX_RTR_SOLICITATION_DELAY and MAX_RA_DELAY_TIME to zero. We have not implemented the optimization described in the draft yet. jak ----- Original Message ----- From: "Bound, Jim" <[EMAIL PROTECTED]> To: "James Kempf" <[EMAIL PROTECTED]>; "Brett Pentland" <[EMAIL PROTECTED]>; "Thomas Narten" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, October 16, 2002 8:19 AM Subject: RE: Changing RS Reply Timing for Mobile IPv6 > James, > > Have you actually tested this with implementation? Or is this > theoretical debate? > > Thanks > /jim > > -----Original Message----- > From: James Kempf [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, October 15, 2002 5:40 PM > To: Brett Pentland; Thomas Narten > Cc: [EMAIL PROTECTED] > Subject: Re: Changing RS Reply Timing for Mobile IPv6 > > > Thomas, > > > Seems to me then that this document is a bit narrowly scoped and may > > even miss the point. Don't we need to look at the overall problem > > and then see what can be done to address the overall problem > > adequately? In general, I don't know that its all that useful to > > focus on a narrow > > > part of a bigger problem unless the bigger problem is sufficiently > > understood that the point solution is understood to be an important > > and useful component of it. How do we know that this change will > > make > > > any significant difference in practice given the general problem? > > > > You are right that this document is fairly narrowly scoped. To solve > the full problem, it requires other parts of the ND process, > specifically DAD, to be accelerated as well. Additionally, as was > brought up on the list, the MN must also decrease > MAX_RTR_SOLICITATION_DELAY to zero. As was also brought up on the > list, this can lead to congestion when mobile nodes move in concert, > or when an access point crashes. > > The FMIPv6 work is certainly a more comprehensive solution, however, > the currently understanding of how FMIPv6 would work together with > 802.11 is not encouraging. There is, of course, an argument about how > much the IETF should modify its specifications to be implementable on > a specific link layer. However, for 802.11 to work well with FMIP, > there would either need to be a major change in the current firmware > implementations for anticipated handover, or an additional protocol > would be needed between the AP and the AR for conveying the > reassociation link up trigger to the AR, or some special kind of > security association would be required between the old AR and the MN > in order to do unsolicited FBU signaling from the AR to the MN. The > IETF can do some work on the last two of these but the first one is > entirely controlled by the IEEE and, worse, by card manufacturers who > may or may not implement given that IEEE has no standard. > > So the deployment alternative with ND as defined in RFC 2461 and the > base FMIPv6 document if one wants faster 802.11 handovers is to set > MAX_RTR_SOLICITATION_DELAY to zero and set MAX_RA_DELAY_TIME to zero. > Near term, this is likely to be what people do. With this deployment, > not only could the above two problems with congestion occur, but the > router is now subject to DoS attacks. The advantage of the proposal in > draft-khalil-ipng-fastra-00.txt is that the authors believe it would > reduce the potential for DoS attacks. > > Whether or not this is enough of an improvement over the RS reply > algorithm as defined by RFC 2461 to standardize, is something for WG > and the IESG to decide. > > jak > > -------------------------------------------------------------------- > 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] --------------------------------------------------------------------
