Subject: [dtn-interest] some comments on draft-zinky-dtnrg-erasure-coding-extension

From: "Fall, Kevin" <[email-masked]>
Date: Fri, 9 Nov 2012 17:33:54 +0000

I was reading this over yesterday.  Here are some notes I made...

        this document really defines a new, different architecture that seems
        to use DTN as a sort of transport mechanism underneath

        yet it also seems to liberally make changes in a variety of bits and
        pieces of the existing structure, protocols and even architecture

        I initially expected the EC framework to be at a CL.  The document
        needs a layering diagram in any case.

        I have concerns about the idea of typed data transfer (requiring IANA)
        in addition to Handling Instructions (due to complexity)

        specific to EC:

        What about ALC (RFC5775) and LCT (RFC5651)?  or FLUTE (RFC6726)?
        ALC combines
                Layered Coding Transport (LCT) building block [RFC5651]
                FEC building block [RFC5052]
                multiple rate congestion control building block [RFC2357]

       while those are sort of IP-specific, can't their frameworks be re-used here?

        why change the name of source symbol to Chunk?
        why change FEC Payload ID to "Encoding Vector"
        saying the encoding data is the "same length as the chuks": same as
                they ARE the chunks?
        Encoding set: why does it have to be a set of LINEAR equations?  What if you have some other type of code?
        "some informtaion is put in the bundle primary block, such as the Data Object
        Transfer Specification"

        "Handling specification" - does this conflict with priority?

        I find 3.1 sort of backward.  It says you have:

        data object -> encodings -> bundles

        I'd have expected this framework as a CL as thus:

        data object -> bundles -> encoded bundles

        Requirements in 3.1: divide into equal sized blocks, and assign UUID
        (ordering is required! -> what does this really imply)

        "The transfer spec cross cuts multiple layers by adding parameters to the
        bundle header, extension blocks and Data Object's internal metadata".. uh ho.

        There is a new (big) concept of typed data (data objects and transfer
        specifications)

        Feedback messages - are these more general?

        "Early research suggests" (sect 6.4) - reference?

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 9 Nov 2012 13:53:08 -0800

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
[email-masked]

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.

---

From: Simon Perreault <[email-masked]>
Date: Sat, 10 Nov 2012 17:13:39 +0100

+1

Simon

Le 2012-11-09 22:53, Templin, Fred L a écrit :
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> 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