Subject: RE: [NSIS] yet another attempted summary of fragmentation discussion

From: [email-masked]
Date: Wed, 18 Jun 2003 14:39:34 +0300

Hi All,

I am in favor of Robert's point 2:

	2. Do it only in the NTLP

I think it is the cleanest, most general proposal.  I believe that
there are a number of mechanisms available, and would note that there
are a number of mechanisms for doing PMTU discover (for example, see 
the end of message).

As far as Georgios' concern, my feeling that inside a controlled
environment (like 3G RAN), a NSLP could use configuration data
to ensure that PMTU is not needed and that all NSLP packets are
within the PMTU.  However, this is to be handled in the NTLP
spec.  I think that, as a general rule, saying that the NTLP
has ultimate responsibility for handling fragmentation is a 
reasonable thing for the Framework document to say.  

I also get the feeling that there is consensus on the mailing
list to support this position.

John
======================================================

A new IETF working group has been proposed in the Transport Area.
The IESG has not made any determination as yet. The following description
was submitted, ans is provided for informational purposes only:

 Path Maximum Transmission Unit Discovery (pmutd)
 ------------------------------------------------

 Current Status: Proposed Working Group

 Chair(s):

 Matt Mathis <[email-masked]>
 TBD

 Transport Area Directors(s):

 Allison Mankin <[email-masked]>
 Jon Peterson <[email-masked]>

 Transport Area Advisor:

 Allison Mankin <[email-masked]>

 Mailing List (temporary):

 General Discussion: [email-masked]
 Subscribe: [email-masked] with "subscribe mtu" in the body
 Archive: http://www.psc.edu/~mathis/MTU/mbox.txt

 (This is to be moved to the IETF as soon as chartered).

 Description of Working Group:

 The goal of the PMTUD working group is to specify a robust method for
 determining the IP Maximum Transmission Unit supported over an
 end-to-end path. This new method is expected to update most uses of
 RFC1191 and RFC1981, the current standards track protocols for this
 purpose. Various weakness in the current methods are documented in
 RFC2923, and have proven to be a chronic impediment to the deployment
 of new technologies that alter the path MTU, such as tunnels and new
 types of link layers.

 The proposed new method does not rely on ICMP or other messages from
 the network. It finds the proper MTU by starting a connection using
 relatively small packets (e.g. TCP segments) and searching upwards by
 probing with progressively larger test packets (containing application
 data). If a probe packet is successfully delivered, then the path MTU
 is raised. The isolated loss of a probe packet (with or without an
 ICMP can't fragment message) is treated as an indication of a MTU
 limit, and not a congestion indicator.
 
 The working group will specify the method for use in TCP, SCTP, and
 will outline what is necessary to support the method in transports
 such as DCCP. It will particularly describe the precise conditions
 under which lost packets are not treated as congestion indications.
 The work will pay particular attention to details that affect
 robustness and security.

 Path MTU discovery has the potential to interact with many other parts
 of the Internet, including all link, transport, encapsulation and
 tunnel protocols. Thereforethis working group will particularly
 encourage input from a wide cross section of the IETF to help to
 maximize the robustness of path MTU discovery in the presence of
 pathological behaviors from other components.

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

---

From: "Thanh Tra LUU" <[email-masked]>
Date: Wed, 18 Jun 2003 16:01:32 +0200

Hi Georgios,

Sorry, I did a mistake.

I think ( I take RSVP as an exemple), NSLP_RSVP send message PATH from
A to B, NTLP has the right to fragment the message. When A receive the
message RSVP from B, NSLP of A know the MTU of a packet A to B (end to end).
              ^^^^^^
              RESV

If A send a another message to B and the length of message is smaller than
MTU, it can set the bit "Don't Fragment" and the NTLP on the intermediate
nodes won't do fragmentation anymore. If we do it, there is a problem that
if the route changes and the MTU is not correct anymore, we must have some
messages for errors.

Nary Tra
ENST, Paris.

---

From: Bob Braden <[email-masked]>
Date: Fri, 20 Jun 2003 09:32:54 -0700 (PDT)

Georgios,

Thank you for the explanation, but unfortunately it does not seem
to relate to my question.

Bob Braden