Subject: RE: Requirements for IP-in-IP Tunnel MTU Assurance

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 6 Oct 2005 08:46:59 -0700

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
[email-masked]

> -----Original Message-----
> From: Fred Baker [mailto:[email-masked]] 
> Sent: Wednesday, October 05, 2005 5:37 PM
> To: Templin, Fred L
> Cc: [email-masked]; 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
> > [email-masked]
> >
> >
> >> -----Original Message-----
> >> From: Fred Baker [mailto:[email-masked]]
> >> Sent: Wednesday, October 05, 2005 1:34 PM
> >> To: Templin, Fred L
> >> Cc: [email-masked]; 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
> >>> [email-masked]
> >>>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Templin, Fred L
> >>>> Sent: Friday, September 30, 2005 3:40 PM
> >>>> To: Fred Baker
> >>>> Cc: [email-masked]
> >>>> 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-re
> >>>> qts-00.txt
> >>>>
> >>>> Fred
> >>>> [email-masked]
> >>>>
> >>>>
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Fred Baker [mailto:[email-masked]]
> >>>>> Sent: Friday, September 23, 2005 9:24 AM
> >>>>> To: Templin, Fred L
> >>>>> Cc: [email-masked]
> >>>>> 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]?
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >
> 
>

---

From: Fred Baker <[email-masked]>
Date: Thu, 6 Oct 2005 14:29:19 -0700

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.
>
> 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
>> protocol that can be run over such a tunnel (including not only ip/ 
>> ip, but
>>
>> 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.
>>
>>> 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
>>>> 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?
>>>>
>>>> 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  
>>>> problem I don't see? What is the objective here?
>>>>
>>>>> 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
>>>>>
>>>>>> http://www.ietf.org/internet-drafts/draft-templin-linkadapt- 
>>>>>> reqts-00.txt
>>>>>>
>>>>>> Fred
>>>>>>> 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.
>>>>>>>