Subject: RE: IPv6 Path MTU Discovery process ...

From: Bernie Volz <[email-masked]>
Date: Tue, 23 May 2000 18:00:42 -0400

Seems like a reasonable idea ... some comments follow:

I like the idea of having the destination respond with the MTU. It's cleaner
since it avoids a lot of responses and figuring out when to stop waiting for
a responses (since the destination might be down - so you'd get no response)
if you allow potentially all intermediate nodes to response as well.

An interesting question to consider is the cost of doing this ...
intermediate routers now have to be capable of generating these "shell
packets" and end nodes (routers too) would need to understand the "shell
packets" and respond accordingly. How well do the characteristics of this
"shell packet" need to match the original packet? For example, it is always
possible that different types of traffic take different paths.

I think from IPv4 experience, while this idea would be an optimization, I
doubt that there are many MTU drops that typically occur (at least on todays
networks). The value is usually found reasonably fast (with one or two MTU
drops) [I don't have any hard data to back this up, it is just a gut
feeling!].

I do believe the IPv4 system, on which the IPv6 was likely built, was a
"upgrade" and therefore had to work with the existing hardware/software. 

It is probably a bit late to require IPv6 systems to support this revised
technique. But ...

- Bernie Volz

-----Original Message-----
From: John Spence [mailto:[email-masked]]
Sent: Tuesday, May 23, 2000 4:29 PM
To: [email-masked]
Subject: IPv6 Path MTU Discovery process ...

Hello;

I sent an eMail to Jack McGann asking a question about IPv6 Path MTU
Discovery.  I had a question about how it was described, and thought I had
an idea for a better solution.  Mr. McGann answered saying that he didn't
know if that had been considered, and suggested I distribute it in this
forum.

Here is the eMail I sent Mr. McGann - please feel free to contact me for
questions and to let me know what you think.

Best regards;

John Spence

---------------------
Hello Mr. McCann;
I have read with interest "IPv6 Clearly Explained", by Pete Loshin. I read
about the Path MTU Discovery process and I had a question. I went to the
IETF site and researched the RFC, and I have a thought.
The book, and the RFC, describe the process is described as the source node
sending the largest packet permissible on it's own network - essentially the
first hop. If any intervening link cannot handle packets that large, it
discards the packet and sends a ICMPv6 "packet too big" message to the
source. The source node drops the size of the packet to within that reported
limit, and send the packet again. Perhaps it makes the final destination,
perhaps another node requires even a smaller packet size, and generates
another "packet too big" message for the source. This could go on for
awhile.
My question is this. Why not have each node in the path that supports only a
smaller MTU than the source node send the "packet too big" message, but
still forward a "shell packet" on towards the destination, where the "shell
package" contains the minimum MTU so far along that path. Since the goal is
to send a packet all the way to the destination, that information may well
be needed, and it would reduce latency in a scenario where there was a
"stepping down" of the MTU size allowed by intervening links as the packets
approached the destination.
The source node would simply wait, collecting whatever "packet still too
big" ICMP messages it received from the intervening nodes (a node that could
accommodate the current MTU would simply forward the shell packet forward,
but would not reply to the source node), until it received a confirmation
from the true destination that the packet had finally arrives. Looking over
the ICMP "packet too big" messages the source had received, it could now
choose the best possible MTU and proceed with confidence.
Heck - we could even have the "shell packet" continue all the way to the
destination node, being adjusted downward by each link along the way (if
needed) - without generating any ICMP "packet too big" messages - and then
make the true destination node send a message back to the source saying "a
2785byte MTU is cleared all the way through", at which time the real data
transmission would begin. You would probably want the very first node that
determined it needed a smaller packet generate the ICMP "packet too big"
message for the source, just to let the source know it wasn't going to be
clear sailing. It could mark the "shell packet" it sent forward to
downstream nodes so they knew they weren't the first to demand a smaller
MTU.
What do you think? Good idea? I'll bet you guys thought of this - just
trying to help. You at the IETF are doing a great job.
----------------------------------------------------------------------------
-----
John E Spence                    ZAMA NETWORKS, INC.
Senior UNIX Systems Engineer
12101 International Boulevard, Seattle WA 98168-2569
wk 206.352.9262  NEXTEL 206.571.9792 fx 206.352.3918
[email-masked] || http://www.zama.net
-------------------------------------------------------------------------

---

From: Zachary Amsden <[email-masked]>
Date: Tue, 23 May 2000 17:42:51 -0700

> drops) [I don't have any hard data to back this up, it is just a gut

Yes, but how do you know when you have an MTU drop?  There are plenty of 
black-holing routers out there that won't give you an ICMP_UNCREACH/NEEDFRAG.

-- 
Zachary Amsden  [email-masked]  3-6919  31-2-510  Core Protocols

---

From: Alan Cox <[email-masked]>
Date: Wed, 24 May 2000 01:31:54 +0100 (BST)

> possible that different types of traffic take different paths.

Also you have to checksum it if you want to trust it - thats more overhead
that people just got off routers on the whole

> drops) [I don't have any hard data to back this up, it is just a gut

MTU drops can make a mess on lossy wireless links and very slow stuff, but
even then I see no material problems