Re: [dtn-interest] Argument in favor of a data format field for groups of bundles

Vint,
There are two questions that need to be addressed concerning a next protocol field in DTN.

1) Is a "next protocol" or "Data Object format" field needed in the bundle protocol suite?
Erasure Coding needs such a field

2) Where should the next protocol field be located?
The right place seems to be an extension block, but which extension block?

At the heart of the "Erasure Coding as an example End-to-End service discussion" is a more fundamental question about the architecture for a DTN protocol suite. 

The Erasure Coding has its own private extension block, some would call this a stove pipe. But looking in detail, the EC extension block contains fields that are needed in other contexts, such as
 1) Handling Specs: which addresses Forwarding Policies as the ECOS draft
http://tools.ietf.org/html/draft-irtf-dtnrg-ecos-03

 2) Group ID: which is similar to the Content ID in the BPQ draft
http://tools.ietf.org/html/draft-farrell-dtnrg-bpq-00

It is easy to imagine an end-to-end application that needs all three services, Erasure Coding, Forwarding policies, Content Query.

Imagine a large content object that is Erasure Encoded and  pieces disseminated throughout the DTN network. A Query based on the Content Object ID is sent out into the network and Erasure coded bundles are sent back to the requester. But the default First-Come-First-Serve Forwarding Policy will not work because duplicate encodings (the one that was sent first) will be returned first which are guaranteed to be redundant. 

Currently all three services have their own stovepipe internet draft.
If we start to design a non-layered DTN protocol suite, how do we partition functionality to the extension blocks?  And how do the services, such as Erasure Coding, Forwarding policies, Content Query use these extension blocks and not step on each other?

On Dec 6, 2012, at 7:50 PM, Vint Cerf <vint@google.com> wrote:

> is there some reason that extension header would not work?
> 
> v
> 
> 
> On Thu, Dec 6, 2012 at 3:22 PM, John Zinky <jzinky@bbn.com> wrote:
> 
> On Nov 9, 2012, at 12:33 PM, "Fall, Kevin" <kfall@qti.qualcomm.com> wrote:
> > I have concerns about the idea of typed data transfer (requiring IANA)
> 
> Erasure Coding adds one SDNV field to store a format type number in the extension block. A field is necessary to distinguish a "File" Data Object, from a "Big Bundle" Data Object
> 
> RFC 5050 does not have a next protocol field like IP.
> 
> Alternative solutions to a Data Object format type field would be:
> 1) Append a Object format type in the Destination EID. This would take a least one byte, which is the same overhead as an SDNV. Hairing up the EID has no advantage.
> 
> 2) Gleam format from the Data Object itself. But the Erasure Coding does not require the whole Data Object be delivered, e.g. a layer video stream encoding or situation awareness updates. The Data object could have gaps, there is no place in the data object that is guaranteed to be delivered, hence no place to actually define the format.
> 
> 3) Add a payload header to every payload, hence every bundle. But if we ignore layering, then this payload header becomes an extension block.
> 
> So in the case of the Data Object being spread over multiple bundles, the easiest mechanism is to add a "Next Encapsulated Protocol" field. Having this field in the EC header, means that it does not have overhead for small (non grouped) bundles.
> 
> _______________________________________________
> dtn-interest mailing list
> dtn-interest@irtf.org
> https://www.irtf.org/mailman/listinfo/dtn-interest
> 