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

[John Zinky <[e-mail]>]

Kevin,

Thanks for reviewing the Erasure Coding drafts. You bring up several issues which I would like to split into four threads, Comments about the Erasure Coding internet-drafts, DTN architecture issues to handle Huge Bundles, Bundle Forwarding issues for groups of bundles, and Typed Data

This first email deals with specific comments, subsequent emails deal with the other issues, hopefully, prompting some discussion. 


1) What about ALC (RFC5775) and LCT (RFC5651)? ALC combines Layered Coding Transport (LCT) building block [RFC5651] FEC building block [RFC5052] multiple rate congestion control building block [RFC2357] and File Delivery over Unidirectional Transport (FLUTE) (RFC6726). While those are sort of IP-specific, can't their frameworks be re-used here?

The intent of the ALC protocol suite is also trying to send large data objects, but many of the details are different. ALC really is designed for IP multicast, with reasonable error-rates. The DTN Erasure Coding has to deal with the case of extreme bundle loss, when contact times are short relative to the transmission time of the object. The way DTN Erasure coding deals with this problem is to basically make every bundle a "repair symbol" and to flood redundant, but not duplicate, repair symbols into the DTN in hopes that a enough get through in time. The key to this case is that no Encoding Bundle carries unique information, all the bundles have to be completely interchangeable. 

Note that Erasure Coding spec can also be configured for the case of a stream of source symbol bundles, with a few block parity bundles added in for redundancy.

I think the EC drafts could use some of the higher level features of the ALC suite, such as using the "File Delivery Table" entry format for metadata (or MIME) instead of the arbitrary file header format described in the Eraser Coding Object internet draft.


2) 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 chunks": same as they ARE the chunks?

During development, we found this terminology more intuitive for those not immersed in Forward Error Correcting Code literature. We could replace these terms with the FEC terms if that is desirable.

3) Encoding set: why does it have to be a set of LINEAR equations?  What if you have some other type of code?

Other FEC kinds of code are easily handled by changing the code FEC Scheme Type field.
The Erasure Coding Random Binary FEC Scheme draft deals with a specific linear code.


4)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

The Erasure Coding suite is an end-to-end FEC scheme and not a CLA Link layer FEC. For FEC at the CLA layer, MITRE developed a NORM-CLA based on Negative-ACKnowledgment (NACK) Oriented Reliable Multicast (NORM) (RFC 5740) protocol.


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

All this says is that a source data object is an order string of bits and 
the data object has a UUID. Note that the UUID is universal and not relative to the source. This is necessary because intermediate recoders need to use their own source EID in order to generate a signature. At decode time, Encoding Bundles from many sources maybe merged based on the UUID.


6) Feedback messages - are these more general?

Feedback messages are out of scope of these internet drafts. This section just tries to enumerate the different types. We are still experimenting with the usefulness of each type, but the usefulness is highly dependent on the end-to-end channel characteristics.


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

Angela Hennessy, Alex Gladd, and Brenton Walker "Nullspace-based Stopping Conditions for Network-Coded Transmissions in DTNs" CHANTS, 2012. 

8) The document needs a layering diagram.

Which diagrams do you recommend based on the limitation of ascii art.
Example diagrams can be found in the EC slideshow. 
https://dist-systems.bbn.com/papers/2011/Zinky/ErasureCodingExtBlockSpec-IRTF-2011-07-25-Rev1-2-2.pdf

Will Ivancic suggests:
Slide 8 for section 3.3.3
Slide 13 for section 4.2
Slide 30 for the Bundle Data Object description.