Re: Problem of blocking ICMP packets

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, 9 May 2004, Masataka Ohta wrote:
> Back to the original problem, PMTUD depends on the capabilities
> of intermediate systems on a path to generate certain ICMP,
> generation of which is as complex as fragmentation itself,
> that it is not very end to end.
> 
> That is, PMTUD is a broken concept.

This is the whole point of reopening the original pmtud working group.
http://www.ietf.org/html.charters/pmtud-charter.html

See draft-ietf-pmtud-method-01.txt   I quote:

   This document describes a robust new method for Path MTU Discovery
   that relies on TCP or other Packetization Layer to probe an Internet
   path with progressively larger packets.  This method is described as
   an extension to RFC 1191 and RFC 1981.
   ...
   The general strategy of the new algorithm is to start with a small
   MTU and probe upward, testing successively larger MTUs by probing
   with single packets.  If the probe is successfully delivered, then
   the MTU is raised.  If the probe is lost, it is treated as an MTU
   limitation and not as a congestion signal.


This does not require any messages from the network, and works just fine with 
arbitrary middleboxes that either toss over-sized frames or ICMP 
messages.

Comments, suggestions and additions to the text are welcome.  The document is 
not well baked, but there is running code.   There is some (slightly out of 
date) background info at http://www.psc.edu/~mathis/MTU/#pmtud

Thanks,
--MM--
-------------------------------------------
Matt Mathis      http://www.psc.edu/~mathis
Work:412.268.3319    Home/Cell:412.654.7529
-------------------------------------------


_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]