[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Requirements for IP-in-IP Tunnel MTU Assurance

that's true. That said, fragmentation and reassembly are rather a big deal, big enough that RFC 1812 (which I edited but I didn't write - this text was agreed on by a large number of folks) comments in the discussion of section 5.2.6 Fragmentation and Reassembly: RFC-791 Section 3.2 

      A few people have suggested that there might be some topologies
      where reassembly of transit datagrams by routers might improve
      performance.  The fact that fragments may take different paths to
      the destination precludes safe use of such a feature.
The use of tunnels in the network is a case in which the router acts (from a certain perspective) as a host: it takes a payload, embeds it into an IP datagram (and might fragment it), transmits that across an IP network (where the receiving system might reassemble it), and then operates on that payload (in this case, sending it as an IP datagram somewhere else). However, this host also forwards traffic, obviously.
The reason that fragmentation in the network, as done in IPv4, was removed from IPv6 and made a host function was that fragmentation in the network is truly a last resort, and something many administrations disable entirely. So I find myself wondering (participant hat) why that applies in the general case and not in the specific case we are discussing.
BTW, I also wonder why it is specific to IP/IP encapsulation, as opposed to being considered also for tunnel-mode VPNs, GRE tunnels (used in Mobile IP), and so on. But I digress.
If we want to remove fragmentation from the network, then it seems to me that the approach of choice would be to figure out not the MTU for the tunnel, but the path MTU end to end. That is the direction of my question. Why is it proper to fragment at a tunnel endpoint and not in the general case? Why would this be preferable to finding the path MTU? 

On Oct 7, 2005, at 8:21 AM, Templin, Fred L wrote:


Fred,

I couldn't tell whether you were asking a question here or
not, but I don't see the tunnel MTU assurance requirement
as being at-odds with the end-to-end principles. The tunnel
is simply a link that occurs somewhere on the path and, like
any other link, needs to present an assured MTU to layer 3.
Link adaptation within the tunnel (i.e., below layer 3) is
really no different than for ordinary links that need to do
link-layer segmentation/reassembly to present an assured MTU
to layer 3 (e.g., 802.11, 802.15).

Fred
fred.l.templin@boeing.com



-----Original Message-----
From: Fred Baker [mailto:fred@cisco.com]
Sent: Thursday, October 06, 2005 2:29 PM
To: Templin, Fred L
Cc: v6ops@ops.ietf.org; Matt Mathis
Subject: Re: Requirements for IP-in-IP Tunnel MTU Assurance

hmm.

dumb question, wearing "participant" hat...

fragmentation is done end to end in IPv6; the network doesn't
fragment. Ultimately, the question for the application is
what packet
size will work to get its data end to end, of which the tunnel is
just a part of the path. The big difference in doing this end to end
and on the tunnel is that on the tunnel a packet-too-large ICMP goes
to the tunnel endpoint and not the originator of the message,
so that
a per-potential-destination route MTU could be maintained, but that
only goes to the actual originator when the originator fires off a
message.

It seems to me more practical to advise applications to (a) respond
to ICMP packet-too-huge by reducing their MSS, and to provide some
tool that would measure goodput rates such that if goodput is zero
but ICMP is not getting back to follow a heuristic to Matt's pmtud.
that has several effects. First, it is consistent with the end2end
principal, which suggests that one should not implement at a lower
layer something that already has to be supplied end to end; doing
this in the tunnel is a duplicative mechanism. Second, it
generalizes; on any path, there is a least MTU en route and
tyerefore
a packet size that will work. It is IMHO up to the
application, if it
wants its transmissions to work, to find that packet size
among other
things.

On Oct 6, 2005, at 8:46 AM, Templin, Fred L wrote:


Fred,

I'm not sure I exactly understand your question, but the
requirement is for a path MTU assurance mechanism that is employed
*within* the tunnel to ensure that packets no larger than the
tunnel MTU make it through to the other side of the tunnel, i.e.,
the mechanism would act only on one hop of what may be


multiple hop


path. The path MTU method outlined in Matt Mathis' draft is
employed at packetization layers *above* the tunnel to determine
the MTU of the path that may extend many hops beyond the


other side


of the tunnel, and I agree that the algorithm could be used for
protocols other than TCP.

The algorithm used by the tunnel MTU assurance mechanism might be
quite similar to that described in Matt's draft, but the use case
and implementation are different. In fact, it could happen that
implementations of Matt's packetization layer path MTU


scheme and a


tunnel MTU assurance mechanism would occur in the same


physical box


and would act at independently of each other.

Fred
fred.l.templin@boeing.com



-----Original Message-----
From: Fred Baker [mailto:fred@cisco.com]
Sent: Wednesday, October 05, 2005 5:37 PM
To: Templin, Fred L
Cc: v6ops@ops.ietf.org; Matt Mathis
Subject: Re: Requirements for IP-in-IP Tunnel MTU Assurance

ah. ok.

so, dumb question of the month. are you looking for a simple
protocol that can be run over such a tunnel (including not


only ip/


ip, but

GRE, IPSEC, etc) to determine the pmt of the tunnel? If so, would
something along the lines of pmtu accomplish it? As in, it seems
to me that the algrorithm is funcdamentally useful for things
other than TCP.

On Oct 5, 2005, at 2:05 PM, Templin, Fred L wrote:


Fred,

Yes, I know about Matt Mathis' work on Packetization Layer Path
MTU Discovery (PLPMTUD) but that work covers


packetization layers


above layer 3 and is independent of the requirement to


provide an


assured MTU below layer 3 for IP/IP tunnels.

To your question, the requirement is for an assured MTU


for IP/IP


tunnels, i.e., when the tunnel MTU is X bytes then upper layer
protocols can be assured that packets no larger than X will
traverse the tunnel under normal circumstances or a layer 3
"packet too big" message will be returned that informs upper
layers of a smaller MTU. For tunnels over IPv4, if no other
mechanism were provided then the only assured MTU that could be
offered would be 68 bytes since RFC 791 specifies that as the
minimum link MTU for IPv4. But, IPv6 needs to see an assured MTU
of 1280 bytes so some form of MTU assurance for tunnels is needed.

Fred
fred.l.templin@boeing.com



-----Original Message-----
From: Fred Baker [mailto:fred@cisco.com]
Sent: Wednesday, October 05, 2005 1:34 PM
To: Templin, Fred L
Cc: v6ops@ops.ietf.org; Matt Mathis
Subject: Re: Requirements for IP-in-IP Tunnel MTU Assurance

I imagine you have read http://www.psc.edu/~mathis/MTU/pmtud/
draft- mathis-pmtud-method-00.txt. The fundamental algorithm is
that the sending TCP starts from the negotiated MSS (or should
transmission suddenly stop being successful, potentially due to
a route change that reduces the real path MTU from the current
message size it is sending) and reduces its segment size until
succeeds in getting a packet through, and then periodically
attempts to increase the message size in order to take


advantage


of capacity that might become available as routes shift. It
seems that this fundamental approach would address your issues.
Does it?

As to the efficiency of file transfer, yes, if the header
overhead is of fixed size, carrying more payload will increase
efficiency. ie, if the IPv6 header is 40 bytes and the TCP
header is 20, and the IPv6 MTU is 1500 bytes, the maximum
payload we can carry is 1440 bytes, or 96%, and being able to
switch that to a 9180 byte IPv6 MTU would change the efficiency
to 99.3% and reduce the interrupt load an the two hosts by a
factor of about 9180/1500. Changing from 1280 to 1500 bytes,
however, is a change from 95.3% to 96% efficiency, which seems
relatively minor, and switching from 1280 to 1380 bytes of
payload seems even more trivial.

The principal value of getting the pmtu right, it seems to me,
is to first get an estimated pmtu that in fact works at all
(downsize it from the negotiated MSS to a packet size


that works


regardless of what hiccups lie en route), and second to


that, it


would be really nice to minimize the interrupt load on the
sending and receiving hosts in order to balance the goals of
maximizing throughput and minimizing the impact on the hosts
themselves. ie, if the sender and receiver are on 10/100
Ethernets and there is an IP/IP tunnel on the path, carrying a
1280 byte payload is better than carrying a 1440 byte payload
because the former works and the latter doesn't, and it


would be


nice to be able to figure out that a 1380 byte payload would
also work and be a .35% improvement in efficiency.

So, question (and yes, this is a question): are you chasing a
problem I don't see? What is the objective here?

On Oct 5, 2005, at 9:16 AM, Templin, Fred L wrote:


Fred,

Please see the following draft which documents operational
issues relevant to v6ops and calls for a solution: http://
www.ietf.org/internet-drafts/draft-templin-mtuassurance-00.txt

Please note that this obsoletes a previos draft called:
"Requirements for Link Adaptation over IP-in-IPv4 Tunnels".

Fred
fred.l.templin@boeing.com



-----Original Message-----
From: Templin, Fred L
Sent: Friday, September 30, 2005 3:40 PM
To: Fred Baker
Cc: v6ops@ops.ietf.org
Subject: Requirements for Link Adaptation over IP-in-IPv4
Tunnels (was RE: Link Adaptation for IPv6-in-IPv4 Tunnels)

Fred - please see:

http://www.ietf.org/internet-drafts/draft-templin-linkadapt-
reqts-00.txt

Fred
fred.l.templin@boeing.com



-----Original Message-----
From: Fred Baker [mailto:fred@cisco.com]
Sent: Friday, September 23, 2005 9:24 AM
To: Templin, Fred L
Cc: v6ops@ops.ietf.org
Subject: Re: Link Adaptation for IPv6-in-IPv4 Tunnels

Does it still propose a protocol or protocol change?

I don't know offhand whether the charter of v6ops then
precluded protocol work, and won't go into whether it was
proper for [MECH] to be done in v6ops. Given the present
charter, I can treat it as a requirements document that may
be asking for something like the work you are proposing. But
my read of the document you pointed to is that it is still
proposing an incompatible change (as in "unchanged equipment
will not perform the function and once the message is
segmented in this fashion it must be reassembled in this
fashion.

I think that has to be done in a WG chartered to do non-
backward-compatible changes to IPv4.

On Sep 23, 2005, at 9:04 AM, Templin, Fred L wrote:


Can this work be contributed as an extension to [MECH]?