RE: New draft: "Link Adaptation for IPv6-in-IPv4 Tunnels"

["Templin, Fred L" <Fred.L.Templin@boeing.com>]

Mark,

Understand your point about setting TCP MSS, but regardless of
whether the tunnel occurs on the same node as one of the TCPs
or somewhere along the path the key point is whether/not the
implementation takes the SHOULD and configures the largest
possible MTU during tunnel setup time. This might require some
pre-probing of SEGSIZE, e.g., when sending IPv6 ND messages
during tunnel setup.

Alternatively, the tunnel could optimistically set a larger MTU
and return locally-generated ICMPv6 "packet too big" messages
in case it gets ICMPv4 "fragmentation needed" messages back
from the network. But, this method is susceptible to path
MTU-related black-holes when the network fails to deliver
accurate ICMPv4s.

The best implementations might do some kind of fusion of the
two approaches, e.g., optimistically set a larger initial MTU
and actively probe the tunnel segment size in the early going
while watching for ICMPv4's. So, the degree of sophistication
here is really up to the implementation rather than being
mandated by the spec.

Thanks - Fred
fred.l.templin@boeing.com
      

> -----Original Message-----
> From: Mark Smith 
> [mailto:ipng@69706e6720323030352d30312d31340a.nosense.org] 
> Sent: Friday, August 19, 2005 12:38 AM
> To: Templin, Fred L
> Cc: v6ops@ops.ietf.org
> Subject: Re: New draft: "Link Adaptation for IPv6-in-IPv4 Tunnels"
> 
> Hi Fred,
> 
> On Thu, 18 Aug 2005 10:20:01 -0700
> "Templin, Fred L" <Fred.L.Templin@boeing.com> wrote:
> 
> > Mark,
> > 
> > Thanks for the comments. The paragraph you cited needs to be read in
> > conjunction with the one that immediately follows, however, i.e.:
> > 
> >    Since LinkMTU values larger than 1280 bytes may result 
> in [ICMPv6]
> >    "packet too big" messages due to temporary segmentation 
> restrictions
> >    (see: section 3.3), ULPs SHOULD employ a probing 
> strategy that begins
> >    with a smaller payload size (on the order of 1KB) and 
> probes upward
> >    [PMTUD].  (Note that this may not be possible for some ULPs.)
> > 
> > This says that ULPs (like TCP) can do their own probing if they want
> > to discover larger MTUs beyond what the initial tunnel interface MTU
> > allows independent of the tunnel segment size probing. BTW, 
> this is true
> > also for the case of no tunnel interfaces in the path, 
> e.g., a TCP could
> > start out on a path with a small MTU and re-routed to an 
> all-GIGE path.
> > 
> 
> Is this based on the assumption that the tunnel is a link within the
> path, rather than possibly at one end of it ?
> 
> The reason I ask is that I was looking at this issue in the context of
> one end of the TCP connection being on the same node as the tunnel end
> point, which happens to be how I'm currently running IPv6 - this PC is
> both a tunnel end point and the node where my TCP connections 
> originate.
> 
> For example, say Node A is both the tunnel end point and one 
> of the TCP
> connection end points. Node A starts the 3 way TCP hand shake 
> with remote
> node B, which is sitting behind, rather than on, the remote tunnel
> end-point. In that case, Node A would set it's announced MSS value to
> something derived from the initial tunnel MTU i.e. 1280 
> bytes, or a MSS
> value of 1220. The other end might set MSS to 1440, because it is
> attached to a 1500 byte MTU ethernet.
> 
> Even though there might be a larger possible path MTU between 
> Node A and
> B, including the tunnel within that path, e.g., 1500 - 20 (IPv4) - 40
> (IPv6) or a path MTU of 1460, Node B would never attempt to or cause a
> probe for anything larger, because it would never send a 
> segment to Node
> A that was larger than Node A's initial MSS value. 
> 
> I'm not sure if TCP adapts to a larger local interface MTU if 
> it changes
> during the connection. If it does, Node A could send segments larger
> than the initial MTU (minus IPv6 and TCP hdrs) to Node B if the local
> MTU increases, up to the maximum segment size that Node B 
> announced. If
> TCP doesn't behave that way, then Node A would also never 
> send a larger
> than it's original MTU derived segment to Node B, also never 
> causing the
> tunnel MTU to increase. That would mean that in both directions of the
> path, the MTU would never be increased beyond the initial tunnel MTU
> value.
> 
> My thoughts were that setting the initial tunnel MTU to a 
> value derived
> from todays common Internet path MTU, rather than IPv6's minimum
> required MTU value, might overcome this problem in this scenario where
> the TCP and tunnel end points are on the same node, without 
> it being too
> detrimental to any other cases, such as when the tunnel is 
> within the path,
> rather than at one of the ends of it.
> 
> HTH,
> Mark.
>