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

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 5 Oct 2005 09:16:21 -0700

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: Jeroen Massar <[email-masked]>
Date: Wed, 05 Oct 2005 18:31:43 +0200

> "Requirements for Link Adaptation over IP-in-IPv4 Tunnels".

Are there implementations/prototypes of this protocol (publically)
available? eg Linux/BSD? It sounds really good and would replace quite a
number of manual knobs, especially as MTU's of endusers (eg dsl) have
been going up and using 1280m,unless manually changed, is thus not very
efficient.

Greets,
 Jeroen

---

From: Fred Baker <[email-masked]>
Date: Wed, 5 Oct 2005 13:33:55 -0700

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?