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

From: "Attila Bader (ETH)" <[email-masked]>
Date: Wed, 18 Jun 2003 16:02:45 +0200

Hi All,

I agree that NTLP has to have responsibility for fragmentation generally. However, the cost of 'do not fragment' is 1 bit, which makes it possible that an NSLP that do not want fragmentation in underlying layers get an error message and do fragmentation itself or do something else to solve the problem. I would not exclude this option, so I propose to include DF bit.

Best regards,  Attila

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Wednesday, June 18, 2003 1:40 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [NSIS] yet another attempted summary of fragmentation
> discussion
> 
> 
> 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

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

---

From: "Cheng Hong" <[email-masked]>
Date: Thu, 19 Jun 2003 10:54:55 +0800

Hi Attila,

If there are NSLPs that really really don't want its messages be fragmented
by the lower layer, due to whatever reason, the "do not fragment" flag could
be justified. However, this has nothing to do with the performance
consideration being discussed in this thread. Probably it should be looked
at in the layer split section.

BR

Cheng

> Attila Bader (ETH)
> Sent: Wednesday, June 18, 2003 10:03 PM
> To: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> I agree that NTLP has to have responsibility for fragmentation
> generally. However, the cost of 'do not fragment' is 1 bit, which
> makes it possible that an NSLP that do not want fragmentation in
> underlying layers get an error message and do fragmentation
> itself or do something else to solve the problem. I would not
> exclude this option, so I propose to include DF bit.
>
> Best regards,  Attila
>
>
>