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

["Templin, Fred L" <[e-mail]>]

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
[e-mail]

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.