[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: New draft: "Link Adaptation for IPv6-in-IPv4 Tunnels"
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
fred.l.templin@boeing.com
> -----Original Message-----
> From: Mark Smith
> [mailto:ipng@69706e6720323030352d30312d31340a.nosense.org]
> Sent: Wednesday, August 17, 2005 8:30 PM
> To: Templin, Fred L
> Cc: v6ops@ops.ietf.org
> 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" <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.
>