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