Hi Allison,
Thanks for the review. Appreciate it. Please see inline.
On Wed, 20 Feb 2008, Allison Mankin wrote:
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(_at_)ietf(_dot_)org 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.
One clarification w.r.t the encapsulation modes. The supported
encapsulation modes for the tunnel between the LMA and the MAG, as per
this specification, is IPv6-in-IPv6 [RFC-2473]. The other modes of
IPv6 over IPv4 transport (IPv6 over IPv4 or IPv6 over IPv4-UDP) are
enabled in the companion document which is still under WG review.
http://www.ietf.org/internet-drafts/draft-ietf-netlmm-pmip6-ipv4-support-02.txt
The document briefly talked about the other two modes for the sake
of completeness in the context of Proxy Mobile IPv6 protocol scope
and the supported transports.
This essentially leaves just one mode, IPv6-in-IPv6. All though, the
comment on PMTU changes due to various encap modes in the access networks
is a very good comment and needs more attention in the IPv4 support
document, as that is the enabler for varying encap modes. However, as
per this document, we have a fixed encap type in a given Proxy Mobile IPv6
domain, if this makes it bit better.
As a side note, not trying to argue about this issue at all. In Mobile
IPv4, per 3344 and in combination with the NAT traversal spec [RFC-3519],
when a mobile node operating in FA-CoA mode registers to the home agent,
the encap mode for the tunnel between the FA and HA could be either,
IP-in-IP, IP-GRE-IP or IP-UDP-MIPHDR-IP. The MTU issues in both the cases
(when IPv4 support is enabled for PMIP6) are just identical. Trying to
draw a relation to understand the issue and see what solution that
spec adopted.
In a scenario, when a mobile moves from MAG1 to MAG2 and if the PMTU on
the path between MAG2 and the LMA is lower than the PMTU between MAG1
and LMA, the RA advertising the mobile node's home network prefix can
contain a MTU option with a lower MTU value reflecting the PMTU between
the MAG and the LMA. In any case, the MAG is required to complete the
signaling with the LMA before it can send the RA on the access link. If
the mobile after an handoff, receives a RA with a lower MTU, the TCP
streams originating from the host should adopt to this change. This is
one way to address the PMTU change issue after an handoff. We can suggest
on the need to add the MTU option in the RA's sent by the MAG, generally
reflecting the pre-configured PMTU between the MAG and LMA.
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?
The LMA-MAG tunnel is a layer-3 ( IPv6-in-IPv6) tunnel, per RFC-2473. We
are bound by that spec w.r.t ECN management. I assume 2473 based tunnel
implementation must support Limited-funcitonality ECN option and not sure
if this spec can say any thing beyond that and specially in the absence of
negotiation protocol in 2473, w.r.t ECN capability exchange. We can
certainly suggest copying the ECN codepoint from the outer header to the
inner header, prior depcap. But, not sure if that is in scope of this
document which leverages standard tunneling modes.
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.
These are separate considerations. The processing flow in 5.3.1, bullet
13, determines the flow.
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
We had some discussions on this. The LMA has received a dereg from the
prev MAG, LMA accepts the dereg, but keeps the BCE for transient amount
of time, to allow the MN to handoff to a new MAG and let that MAG
update the binding before the binding is deleted. Earlier versions of
the document did recommend that the LMA should continue to forward the
traffic to the prev MAG. But, the comment from the WG was that, the
party is no longer interested and hence we should not forward the
traffic during that wait time.
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.
Typically, LMAs can serve potentially 3 to 5 million bindings. Buffering
requirements might be too high, also SDO architectures do handle this in
the manner that suits that architecture, resources ..etc. So, buffering
was considered out of scope for this work.
Thanks for the detailed review. Appreciate it.
Regards
Sri
Allison Mankin / Transport Directorate
Allison Mankin
Division of Computer and Network Systems
National Science Foundation (US)
------- End of Forwarded Message
_______________________________________________
netlmm mailing list
netlmm(_at_)ietf(_dot_)org
http://www.ietf.org/mailman/listinfo/netlmm
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
http://www.ietf.org/mailman/listinfo/ietf