Subject: re: Last Call: draft-ietf-netlmm-proxymip6-10.txt to Proposed Standard

From: Allison Mankin <[email-masked]>
Date: Wed, 20 Feb 2008 21:23:24 -0800

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 [email-masked] 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)

------- End of Forwarded Message

_______________________________________________
IETF mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ietf

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 21 Feb 2008 21:35:37 -0800 (PST)

Hi Allison,

Thanks for the review. Appreciate it. Please see inline.

>   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.

>   requires ECN to zero out and start over and only the local mobility anchor

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.

>   the binding de-registration.  A binding de-registration might not be followed

These are separate considerations. The processing flow in 5.3.1, bullet
13, determines the flow.

>       During this wait period, the local mobility anchor SHOULD drop the mobile

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.

>   If the pending data is held, then Section 5.3.4 needs to discuss the pending data

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

> netlmm mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/netlmm
>