Subject: Re: [pmtud] draft-welzl-pmtud-options-00.txt

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

Dear Sean,

> In this particular case I'm concerned about how well the algorithm is
> likely to work in a mixed deployment of new and old equipment.  The MTU
> will most likely be limited by the older equipment which will not
> understand the new IP option used for probing the path MTU.  Since
> the algorithm only ratchets downwards toward smaller MTU sizes, it will
> consistently overestimate the MTU in this type of environment.  Does this
> mean we must discard the results of a probe if any router along the path did
> not properly process the option?

This is specified in the draft:

the result of the probe is interpreted as an upper limit
for PMTUD (be it the old or new variant), no matter how
many routers supported it.

Old variant: you start with the MTU from the probe.
New variant: you end with the MTU from the probe.

In any case, you avoid loss.

Best regards,
Michael

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

---

From: "Sean McCreary" <[email-masked]>
Date: Thu, 04 Mar 2004 07:01:22 -0700

Michael Welzl <[email-masked]> wrote:
> "Sean McCreary" <[email-masked]> wrote:
>> the algorithm [...] will

Thank you for explaining this in more detail.  If I understand correctly,
the PMTU-Options probe could be integrated with the PLPMTUD algorithm as
an initial phase occurring just before the search phase of section 5.1.1
of draft-ietf-pmtud-method-01.txt.  The result of the probe is then useful
in making an educated guess about the initial MTU to use for subsequent
probing, but isn't sufficient by itself to specify what MTU should be used.

Have you considered how to specify the timeout value for lost probe
packets, and what kind of retransmission scheme would be required?  Given
that packets with IP options are quite frequently dropped by current
routing equipment, we should expect the loss rate for probe packets to
be high.  Also, if any of the application data is sent with IP header
options this may produce as much or more packet loss than the PLPMTUD
process itself.
--
Sean McCreary                                              [email-masked]

---

From: Michael Welzl <[email-masked]>
Date: 04 Mar 2004 15:33:51 +0100

> probing, but isn't sufficient by itself to specify what MTU should be used.

Exactly! But I guess you mean 5.5.1.
Also, I would include it in the monitor state (5.5.2) - just
before re-probing the most recent failed MTU.

> packets, and what kind of retransmission scheme would be required?  Given

Not yet - but I think that it ought to be similar to what
happens when a packet is dropped because the MTU limit
was exceeded with "normal" PLPMTUD.

> options this may produce as much or more packet loss than the PLPMTUD

I agree that this is a problem - it is these issues (along
with the potential router overload if everybody did this
for all new connections) that make it an experimental
suggestion for special scenarios only.

One such scenario is a tunnel, where you might know that the
routers within the traversed cloud generally do not drop
packets because of IP options. Another special scenario
(at least that's how I refer to it in the draft) is the
combination with the monitor phase.

In the monitor phase, chances are generally high that the
first normal probe will fail right away because you are still
on the same path. If you know that your first
PMTUD-OPTIONS-probe (the one you sent before the search
phase) made it, chances are high that it will make it again,
thereby avoiding a lost packet each time.

Best regards,
Michael

---

From: "Sean McCreary" <[email-masked]>
Date: Thu, 04 Mar 2004 01:07:30 -0700

Eddie Kohler <[email-masked]> wrote:
[...]
>On the one hand, most people probably think that anything involving IP
>options will not happen in practice. On the other hand, this seems like a
>perfectly reasonable/appropriate way to get precise MTU information
>quickly.