Subject: [pmtud] draft-welzl-pmtud-options-01.txt

From: Michael Welzl <[email-masked]>
Date: 04 Mar 2004 09:06:39 +0100

Dear all,

I have just been told that the PMTUD session is over and
that my draft draft-welzl-pmtud-options-01.txt was
discussed; I am very sorry that I could not personally
attend the meeting and add my comments!!!

This is probably too late, but I thought I'd say a
few words here anyway:

For those of you who didn't read the draft and didn't
know what it is about - in one sentence, the idea
is to make ptmud converge faster without necessarily
losing a packet (which usually leads to an extra icmp packet
being generated) at the cost of having a packet delayed
via an IP option; I think that this may be useful in
certain special cases (e.g. with tunnels), so that's what
it was designed for.

I have been told that Joe Touch said that it would
be more useful to have a mechanism like that INCREASE
the MTU rather than impose a limit. This is a very
interesting idea, and I agree that this would be useful;
just like the present spec., it could make PMTUD converge
faster - in this case, in the presence of very large MTU
values.

I think that this idea could be nicely interwoven with
the rest of the draft; a combination of "please give
me a large MTU that I can use right away" and "please
give me an upper limit so I don't exceed it" would
make a lot of sense to me. The general goal of the
draft would remain:

Make PMTUD converge faster in special scenarios.

What do you all think of the following proposal:

1. I create this mixture of Joe's + my idea.

2. We discuss it on the list.

3. I'll be present at the next meeting, to discuss
   whether it can be taken up as a work group item.

?

Best regards,
Michael

_______________________________________________
pmtud mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pmtud

---

From: Michael Welzl <[email-masked]>
Date: 25 Mar 2004 14:53:39 +0100

Dear PMTU'ers,

> faster - in this case, in the presence of very large MTU

I don't know what struck me when I wrote this; I actually
forgot that this paragraph is already in the spec:

   If the value of TTL-Diff in the reply packet is equal to the stored
   value of TTL-Diff, all routers along the path supported the option.
   This means that the MTU value in the reply packet is not an upper
   limit for the PMTU but the actual end result; this fact SHOULD be
   communicated to the local PMTUD or PLPMTUD instance, which MAY then
   terminate immediately using the value from the packet carrying the
   MTU feedback.

This is exactly what the idea is about, isn't it?

I will give this a much more prominent part in the next
draft update (introduction, ..)!

Also, I would like to enquire about the state of
implementations. I have an enthusiastic student here
who is willing to 1) implement PMTU-Options as
a patch to standard PMTUD in the Linux kernel, and 2)
implement PLPMTUD with and without PMTU-Options.

Best regards,
Michael