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

[Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org>]

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.