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

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 18 Aug 2005 10:20:01 -0700

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.

The text of these two paragraphs is intentionally worded to allow
implementations some freedom in how they configure the initial tunnel
MTU, e.g. an implementation might wish to ratchet up the initial MTU
by sending a series of IPv6 ND messages using different values for
SEGSIZE to determine a larger IPv4 segment size for the path before
setting the tunnel MTU.

Fred
[email-masked]

> -----Original Message-----
> From: Mark Smith 
> [mailto:[email-masked]] 
> Sent: Wednesday, August 17, 2005 8:30 PM
> To: Templin, Fred L
> Cc: [email-masked]
> Subject: Re: New draft: "Link Adaptation for IPv6-in-IPv4 Tunnels"
> 
> Hi Fred,
> 
> On Wed, 17 Aug 2005 14:55:14 -0700
> "Templin, Fred L" <[email-masked]> wrote:
> 
> > A new draft of possible interest to v6ops is available
> > that anticipates MTU-related performance issues for
> > tunnels and proposes a solution. Document location
> > and abstract appear below. Comments?
> > 
> 
> I've had a quick read through.
> 
> I'm a bit confused by this text :
> 
> "  Implementations MUST configure a minimum per-tunnel 
> interface LinkMTU
>    of 1280 bytes and SHOULD provide a configuration knob to set larger
>    values.  A maximum LinkMTU of 9180 bytes (i.e., the same as defined
>    in [RFC1626]) is RECOMMENDED for normal use cases, since 
> it is large
>    enough to encode 8KB network filesystem blocks and take 
> advantage of
>    Gigabit Ethernet Jumbo Frames, yet not so large as to diminsh the
>    effectiveness of 32-bit link layer CRCs [GIGE].  
> Implementations MAY
>    set even larger LinkMTU values, but are advised that this 
> may lead to
>    unacceptable levels of undetected errors unless all 
> physical segments
>    in the path can provide assured error-free deliverey for large
>    packets."
> 
> I read it as saying that the initial tunnel MTU, by default, should
> always be 1280 bytes. However, I think the first part of the next
> sentence,
> 
> "A maximum LinkMTU of 9180 bytes (i.e., the same as defined
>    in [RFC1626]) is RECOMMENDED for normal use cases"
> 
> could possibly be taken to be a statement that for "normal use cases"
> (which is commonly the "default"), the initial tunnel MTU 
> should be 9180
> bytes.
> 
> The reason that I ask is that if I understand the tunnel MTU probing
> mechanism in this ID, it relies on the upper layer protocol generating
> TPDUs that are larger than the current tunnel MTU value. If the upper
> layer protocol was TCP, it would set it's MSS option to be the current
> tunnel MTU minus the IPv6 header size. If the initial tunnel 
> MTU is 1280
> bytes, as per the first sentence in the above text, and the TCP end
> points were on the same nodes as the tunnel end points (for 
> example), the
> MSS value for each end point would be set to 1280 minus 40 
> bytes for the
> IPv6 header or 1240 bytes.
> 
> From that point onwards, the TCP end points would never send a segment
> larger than the MSS, and therefore never generate a IPv6 packet larger
> than 1280 bytes or a IPv4 packet larger than 1300 bytes. If the IPv4
> path MTU between the two tunnel end points was 1500 bytes, 
> which I think
> is probably the case for most of the Internet, I don't think the probe
> mechanism in this ID would ever discover that and then be able to
> utilise it. TCP or other transport layer protocols would never
> indirectly attempt to push the tunnel MTU above what the local tunnel
> interface MTU is set to, and if that is initially 1280 bytes, then I
> think the tunnel MTU would never increase beyond that value.
> 
> Rather than the initial MTU being set to 1280 bytes, maybe it 
> should be
> set to a value that is derived from the common IPv4 path MTUs in the
> Internet e.g 1500 - 20 bytes or 1480 bytes. This would allow today's
> common IPv4 path MTU to be taken advantage of by this ID, yet 
> avoid the
> amount of fragmentation an initial tunnel MTU of 9180 bytes 
> would cause
> and the associated time it would take for PMTUD to resolve down to
> today's common IPv4 path MTU. PMTUD and the mechanisms in this draft
> would cope with IPv4 paths between tunnel end points that 
> have a smaller
> MTU than the assumed, common, 1500 bytes.
> 
> If this common IPv4 path MTU figure changes in the future, 
> then the RFC
> could be updated by a later RFC with an increased initial tunnel MTU
> recommendation.
> 
> HTH,
> Mark.
>

---

From: Mark Smith <[email-masked]>
Date: Fri, 19 Aug 2005 17:07:31 +0930

Hi Fred,

On Thu, 18 Aug 2005 10:20:01 -0700

> 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.

---

From: Mark Smith <[email-masked]>
Date: Fri, 19 Aug 2005 17:43:09 +0930

On Fri, 19 Aug 2005 17:07:31 +0930

> probe for anything larger, because it would never send a segment to Node

Oops, that should be 1500 - 20 (IPv4) or a path MTU of 1480 bytes.