Subject: Re: [netlmm] Last Call: draft-ietf-netlmm-proxymip6-10.txt to Proposed Standard

From: Jari Arkko <[email-masked]>
Date: Wed, 20 Feb 2008 21:50:50 -0800

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 [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)
>
>
>
>
>
>
>   

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

---

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

Overview -

   

Allison Mankin