Subject: [pmtud] New pmtu method draft

From: Matt Mathis <[email-masked]>
Date: Thu, 12 Feb 2004 17:16:20 -0500 (EST)

I have an updated pmtud method draft that I plan to submit to the ID editor on 
Sunday.

This draft is substantially improved from the prior draft.  You can get a copy
from http://www.psc.edu/~mathis/draft/draft-ietf-pmtud-method-XX.txt   If you 
have any suggestions, etc and include text before Sunday I will attempt to 
to incorporate the changes in the ID before it gets submitted.

We are on the IETF agenda for Thursday afternoon.

Thanks,
--MM--
-------------------------------------------
Matt Mathis      http://www.psc.edu/~mathis
Work:412.268.3319    Home/Cell:412.654.7529
-------------------------------------------
A good plan today is better than a perfect plan tomorrow.
	- Gen Patton

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

---

From: Fred Templin <[email-masked]>
Date: Tue, 17 Feb 2004 11:24:21 -0800

Matt,

As you know, I have been favorably impressed by PLPMTUD
due to its elegant approach and its non-requirement for ICMPs.
I have a number of concerns, however:

  1)  raising the MTU always involves redundant data and/or
      data loss, hence there will always be an efficiency penalty.
      (This is especially problematic for short-lived sessions, and
      not useful at all, e.g., for sending a single large UDP packet.)
  2) detecting and reacting to path MTU reductions (e.g., due
      to connections being re-routed) takes too long; again, with
      negative efficiency implications.
  3)  the duration of the verification phase limits the ability
      to quickly increase probe sizes while searching.
  4)  the PLPMTUD mechanism itself is too complicated,
      and not well specified for transports other than TCP.

Over the past year, I have put a great deal of time and effort
into designing and evaluating schemes for dynamic path
MTU determination, and PLPMTUD is perhaps one of the
more promising I have encountered. But, with these seemingly
insurmountable drawbacks (among others), I have come to
the realization that the problem of generalized dynamic
path MTU discovery is simply intractable.

Instead, I believe there are two simple tenets that  nodes can
confidently observe in all cases:

  1) If the destination  is connected to the same link (and, the
      same contiguous segment on the same link) send packets
      up to the size of attached link's MTU.

  2) Otherwise, only send packets that are known to be no
      larger than the smallest restricting link/segment in
      the path.

As to tenet 2), it is commonly said that the practical physical
cell size in today's Internet is 1500bytes, with L2 encapsulations
that can reduce the size to something on the order of the IPv6
minimum MTU of 1280 bytes. The minimum link MTU for
IPv4 is only 68 bytes, however, so to be absolutely certain there
would be no fragmentation, nodes would need to send IPv4
packets no larger than 68 bytes.

68 bytes is astonishingly close to  the size of an ATM cell!
Since ATM has proven that good performance can be realized
with such a small cell size, how unrealistic would it be to
assume that we could get decent performance out of the
existing Internet infrastructure if all nodes suddenly started
to limit the size of the IPv4 packets they send to something
between 68 - 1280 bytes? (I.e., something closer to 68 bytes
to avoid all fragmentation, and something closer to 1280
bytes  if some fragmentation can be tolerated?)

Thanks - Fred
[email-masked]