Subject: [pmtud] draft PMTUD minutes from IETF64

From: Matthew J Zekauskas <[email-masked]>
Date: Fri, 09 Dec 2005 01:51:52 -0500

Draft minutes from the PMTUD meeting at IETF64 are attached.

These minutes and the presentations are all on the IETF64
meeting materials site:
<https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=64>

If anyone has any comments, please send them to either the list
or directly to the chairs.

--Matt

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

---

From: Florian Lohoff <[email-masked]>
Date: Fri, 9 Dec 2005 09:02:15 +0100

On Fri, Dec 09, 2005 at 01:51:52AM -0500, Matthew J Zekauskas wrote:
> Matt Mathis started a discussion around one of the open technical issues
> in the draft: how often should you probe to see if the MTU has been raised
> along a path.   The draft currently says five minutes, but that value
> was somewhat arbitrary.  Matt wondered if anyone has insights into
> existing precedent or a rational way of picking a number.
> Michael Richardson thought 5 minutes sounded about right, and in
> any case it should be greater than the 2 minute TCP timeout; he
> also thought it should not be larger than the typical damping interval
> for BGP.  John Heffner commented that ten minutes is commonly used for
> values in route caches.  Fernando Gont suggested a strategy being considered
> for OpenBSD: base the probe interval based on the current MTU size.  If the
> size is small, probe more frequently; if the value is large (and still
> working) use a larger timeout.  Matt asked if Fernando considered 1500
> large or small.  Fernando thought "small", and a "large" value might
> be something greater than 6000 right now; a value of 10 to 15 minutes
> might be appropriate there.  Dave Thalor noted that since the draft
> is an extension of "PMTUD classic" right now, RFC 1981 says 10 minutes,
> so that's a value that you would not have to defend.

What about specifying a bitrate by considering all probes lost. So
PMTUd-new shouldnt sent out more than 100 bit/s additional traffic.
Which makes it 2 Minutes for 1500 byte probes. (1500 * 8 / 120)

Flo
-- 
Florian Lohoff                  [email-masked]             +49-171-2280134
                        Heisenberg may have been here.
_______________________________________________
pmtud mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pmtud

---

From: Fernando Gont <[email-masked]>
Date: Fri, 09 Dec 2005 04:05:57 -0800

Matt,

A comment on the minutes:

>Fernando noted that if TCP (or any other packetization protocol) would
>have to know the complete size of packets, and with some
>implementations that would be difficult.  However, he felt in many
>implementations it would be easy.

Actually, in the meeting I got the feeling that it was considered 
"difficult" to know the complete size of packets. What I tried to point out 
in the meeting is that, at least in BSD-derived ones, it isn't.

Kindest regards,

--
Fernando Gont
e-mail: [email-masked] || [email-masked]

---

From: Matthew J Zekauskas <[email-masked]>
Date: Fri, 09 Dec 2005 09:52:31 -0500

Thanks!  I'll clarify.  --Matt

--On Friday, December 09, 2005 4:05 AM -0800 Fernando Gont <[email-masked]> wrote:

> Actually, in the meeting I got the feeling that it was considered "difficult" to know the
> complete size of packets. What I tried to point out in the meeting is that, at least in
> BSD-derived ones, it isn't.
>
> Kindest regards,
>
> --
> Fernando Gont