-----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-re
qts-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]?