Allison, Thank you for the review. These seem valid issues that we need to talk about and/or resolve. Jari Allison Mankin kirjoitti: > I've reviewed this document as part of the transport area > directorate's ongoing effort to review key IETF documents. These > comments were written primarily for the transport area directors, but > are copied to the document's authors for their information and to > allow them to address any issues raised. The authors should consider > this review together with any other last-call comments they > receive. Please always CC tsv-dir@xxxxxxxx if you reply to or forward > this review. > > Overview - > The specification is written clearly and the elements of the proxy IPv6 > mobility design strike me as pretty coherent at this point. > > The design raises a number of issues for transport sessions on the > mobile node. These need to be addressed in some way. As suggested > above, correspondence with the transport directorate (tsv-dir) and me is > welcome for clarification or to discuss these points. > > 1. MTU - the mobile node (MN) receives its traffic through a tunnel. > The local mobile anchor to mobile access gateway encapsulations are > varied (Section 6.10.2: v6-in-v6, v6-in-v4, v6-in-v4-udp). While > tunnels lead to a generic problem for MTUs (RFC 4459), the problems > are intensified in this design because the MN's moves may result in > successive differently encapsulated tunnels, at short enough > intervals that transport sessions survive across them and end up > transmitting data with problematic MTUs. > > Please discuss the MTU issue. Suggestion - recommend the state of > the art initial MTU detection, PLMTUD (RFC 4821), which also allows > connections that can't start new probes to learn of MTU changes from > other connections with more recent probe information. > > 2. Tunnel and Explicit Congestion Notification (ECN) - with transport traffic > that uses ECN (RFC 3168) - most transports - provision is made for tunnels > by transferring ECN information between the outer and inner IP(v#) headers at > the tunnel endpoints. Something like this procedure is also provided for > maintaining the ECN signal through an MPLS network. I suggest that this > document should call for applying the ECN for tunnels procedure from RFC 3168 > on behalf of the MN and its correspondent nodes. More motivation: far from > having no congestion in the highly engineered wireless/wireline deployments, > measurements often find serious pressure on resources such as the wireline > backhaul. Good to make sure the congestion avoidance system is well in place. > > Please get ECN into the local mobility anchor to mobility access > gateway tunnel if possible Question: it's clear that forming a new tunnel > requires ECN to zero out and start over and only the local mobility anchor > knows this. Doable? > > 3. Data during Binding Changes - > > Section 5.3.4 describes the action at the local mobile anchor when a new mobile > anchor gateway has sent a binding update for the MN, in other words, when there has > been a handoff. Section 5.3.5 describes the signaling action at the local > mobile anchor before the handoff, when a mobile anchor gateway has sent a > the binding de-registration. A binding de-registration might not be followed > by a handoff. > > From a data transport point of view, it is unclear why the working group chose > to flush any pending data in the binding de-registration: > > During this wait period, the local mobility anchor SHOULD drop the mobile > node's data traffic > > The mobile anchor gateway has a timer prior to deleting the binding state. Isn't > the transparency of mobility and of handoffs best served by holding the pending data > and then providing it as early as possible during handoff? I'd like to understand > the reasoning. A technical counter is that a large data loss is a signal for > all IETF data transports to enter major congestion avoidance. Non-response > will lead to other problems with transports' performance. > > Please consider holding the pending data - the parameter MinDelayBeforeBCEDelete > is a small amount of time, but perhaps the data hold could be recommended to be > for half of it as a buffer implementation consideration. > > If the pending data is held, then Section 5.3.4 needs to discuss the pending data > too. > > > Allison Mankin / Transport Directorate > > Allison Mankin > Division of Computer and Network Systems > National Science Foundation (US) > > > > > > > _______________________________________________ IETF mailing list IETF@xxxxxxxx http://www.ietf.org/mailman/listinfo/ietf