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

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

I agree. The main issues we saw are not related to "bad IP stacks", but to something inside the networks (mainly firewalls) that cannot be controlled. Many times, we needed to change the MSS to get Teredo, ISATAP, 6in4 or 6to4 working. It is just a fact (or maybe a dream) that we have to accept that any stacks should support the broken PMTUs. 

My 2 cents,
  Vincent

Christian Huitema wrote:


I am just saying that ICMP black holes are frequent enough, because of
firewalls. The level of support in various stacks may vary. I would not
be surprised if it was be pretty simplistic in some cases. But stacks do
indeed have to be able to deal with the issue. 
-----Original Message-----
From: Matt Mathis [mailto:mathis@psc.edu] Sent: Thursday, October 06, 2005 2:55 PM 
To: Christian Huitema
Cc: Templin, Fred L; Fred Baker; v6ops@ops.ietf.org
Subject: RE: Requirements for IP-in-IP Tunnel MTU Assurance

This strategy is only obvious if all important stacks already have
robust mechanisms to deal with ICMP black holes.

Christian, are you asserting that this is true?   Would you care to
define "all
important stacks"?

Thanks,
--MM--

On Thu, 6 Oct 2005, Christian Huitema wrote:


There is an obvious strategy: tunnel servers should set the "don't
fragment" bit when forwarding a packet larger than the "guaranteed

MTU",

and allow fragmentation for smaller packets, e.g. smaller than 1280

for

IPv6. Then, they should just ignore any ICMP message. That should make
the tunnel behavior equivalent to sending through a firewall,

something

that transport protocols are expected to handle.

-----Original Message-----
From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On
Behalf Of Templin, Fred L
Sent: Wednesday, October 05, 2005 2:06 PM
To: Fred Baker
Cc: v6ops@ops.ietf.org; Matt Mathis
Subject: RE: Requirements for IP-in-IP Tunnel MTU Assurance

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