Re: [dtn-interest] MTU considerations for 'draft-irtf-dtnrg-dgram-clayer-00'

+1

Simon

Le 2012-11-09 22:53, Templin, Fred L a écrit :
> At the DTNRG meeting yesterday, I mentioned MTU considerations for
> UDP and DCCP convergence layers. Here are my suggestions for updates
> to the document:
>
> Thanks - Fred
> fred.l.templin@boeing.com
>
> 1) Section 3.1, rewrite as follows:
>
>    "The Bundle Protocol allows bundles with sizes limited only by node
>     resource constraints. In IPv4, the maximum size of a UDP datagram is
>     nearly 64KB. In IPv6, when using jumbograms [RFC2675], UDP datagrams
>     can be up to 4GB in size [RFC2147]. It is well understood that
>     sending large IP datagrams that must be fragmented by the network has
>     enormous efficiency penalties [Kent88]. Recent studies have also shown
>     that undetected data corruption can result from sending IP fragments
>     at high data rates [RFC4963], and that IP fragments are sometimes
>     unconditionally discarded by the network [Attacks].
>
>     The Bundle Protocol specification provides a bundle fragmentation
>     concept [RFC5050] that allows a large bundle to be divided into bundle
>     fragments. If the Bundle Protocol is being encapsulated in DCCP or UDP,
>     it therefore SHOULD create each fragment of sufficiently small size
>     that it can then be encapsulated into a datagram that will not need
>     to be fragmented at the IP layer."
>
> 2) Add a new Section 3.1.3 as follows:
>
>    "3.1.3. Path MTU Determination for DCCP and UDP
>
>     IP Path MTU Discovery [RFC1191][RFC1981] depends on the deterministic
>     delivery of ICMP Packet Too Big (PTB) messages from routers in the
>     network. However, studies have shown that these messages are frequently
>     discarded by the network resulting in a condition known as a black hole
>     [RFC2923][WAND][SIGCOMM]. A new means of path MTU determination that can
>     operate in the absence of PTB messages has therefore been specified
>     [RFC4821].
>
>     The UDP and DCCP bundle protocol CLs can determine an appropriate MTU
>     by employing the positive feedback probing method specified in [RFC4821].
>     In this process, the CL selects an initial segment size that is certain
>     to traverse the path without loss due to an MTU restriction (e.g., 512
>     bytes for IPv4 or (1280-(UDP and IP header sizes)) bytes for IPv6). The
>     CL can thereafter send probe messages of larger sizes (e.g., 1500 bytes,
>     4K bytes, 8K bytes, etc.) to elicit a response from the CL destination.
>     If the CL receives a response, it can advance its segment size to the
>     largest successful probe size. If the CL subsequently receives an ICMP
>     PTB message, or if the path to the destination appears to be failing,
>     it can again reduce the segment size.
>
>     In this process, the CL MUST set the Don't Fragment flag in the IPv4
>     header to 1."
>
> 3) Add the following citations:
>
>     [Attacks]  Atlasis, A., "Attacking IPv6 Implementation Using
>                Fragmentation", March 2012.
>
>     [WAND]     Luckie, M., Cho, K., and B. Owens, "Inferring and
>                Debugging Path MTU Discovery Failures", October 2005
>
>     [SIGCOMM]  Luckie, M. and B. Stasiewicz, "Measuring Path MTU
>                Discovery Behavior", November 2010.
>
> _______________________________________________
> dtn-interest mailing list
> dtn-interest@irtf.org
> https://www.irtf.org/mailman/listinfo/dtn-interest
>


-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca