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

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

Hi Fred,

On Wed, 17 Aug 2005 14:55:14 -0700
"Templin, Fred L" <Fred.L.Templin@boeing.com> 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.