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

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

Mark,

Another implementation option which wasn't mentioned is to
designate a tunnel pseudo-interface that acts as a "lid" on
the can-of-worms consisting of all active tunnels configured
on the endpoint. The lid would present a consistent MTU
(e.g., 9180 bytes) to upper layers, e.g., for setting the
TCP MSS, but there may be instances of locally-generated
ICMPv6 "packet too big" messages coming from tunnels inside
the can. Again, this seems outside the scope of the
specification - do you concur?

Fred
fred.l.templin@boeing.com   

> -----Original Message-----
> From: Templin, Fred L 
> Sent: Friday, August 19, 2005 8:17 AM
> To: Mark Smith
> Cc: v6ops@ops.ietf.org
> Subject: RE: New draft: "Link Adaptation for IPv6-in-IPv4 Tunnels"
> 
> 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.
> > 
> 
>