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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]