Re: [dtn-interest] DTN protocol suite, FEC as an example of cross cutting traditional network layering.

["Burleigh, Scott C (313B)" <[e-mail]>]

In the unlikely event that anyone is confused by this posting:

Bundle protocol is an overlay network protocol.  In an Internet environment it runs over the Internet, treating Internet connections as links.  In an environment where there is no Internet it treats the available R/F (or whatever) links as links.  As we are all well aware, BP does indeed do routing, spanning Internet and non-Internet environments.

It's not unreasonable to observe that "this new application service is the TCP to the bundle protocol's IP".  This layered structure may or may not be very different from what is used outside CCSDS, depending on how people want to deploy the protocols.

Scott

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Sunday, September 09, 2012 6:30 AM
To: [e-mail]
Subject: Re: [dtn-interest] DTN protocol suite, FEC as an example of cross cutting traditional network layering.

I am very puzzled by this. And my puzzlement comes back to thinking about layering and the bundle protocol.

The bundle protocol isn't a network protocol. It only has endpoints IDs, after all - not network IDs. It has little truck with network addressing or routing.

And yet, the bundle protocol is not really a transport protocol. It doesn't provide reliable delivery, custody transfer doesn't work. The EIDs can be overloaded to distinguish different applications, and provide stream separation at the endpoints.

In the above-convergence-layer world where you have a reliable transport protocol (TCP) under the bundle protocol, the bundle protocol becomes a data format, or arguably, a slim session layer. This is the analogy of old with email.

In the CCSDS world, where you have a link layer and that's pretty much it (because running CFDP over bundling or vice versa would be redundant), the bundle protocol, which isn't networking or transport, becomes really just the equivalent of a datagram over that link layer. Which, I think, is why CCSDS bundles are relatively small, and why this 'end-to-end bundle application service' -- or transport protocol - is now being built for the bundle protocol. This new application service is the TCP to the bundle protocol's IP, and this layered structure will be very different to what is used outside CCSDS.

We can debate the layering model and whether it applies endlessly. But a more interesting question is whether we are seeing the development of two different layering models, articulating two very different views of what the bundle protocol is and what it is for. And if there are transports both above and below the bundle protocol, what value does the bundle protocol add?

Lloyd Wood
http://sat-net.com/L.Wood/

who suspects that bundle FEC fails because you can't FEC or even checksum the headers....


________________________________________
From: [e-mail] [[e-mail]] On Behalf Of Burleigh, Scott C (313B) [[e-mail]]
Sent: 06 September 2012 17:39
To: John Zinky; [e-mail]
Subject: Re: [dtn-interest] DTN protocol suite, FEC as an example of cross cutting traditional network layering.

John, thanks for an interesting message.  I need to get back into your I-D and re-read it in more detail to be able to discuss the specifics of some of these points, but a general observation occurs to me.  Most -- perhaps all -- of the service adaptations you speak of resemble features of an end-to-end bundle application service layer called "Delay-Tolerant Payload Conditioning" that we've been developing within NASA, to address some requirements identified by the European Space Agency and others that were identified in the course of a tactical communications project that JPL worked on for DARPA.

Unfortunately we haven't got an Internet Draft on DTPC whipped into publishable shape quite yet.  If we had, I think you'd recognize in it some things that closely resemble your "Data Object Format", "Data Object UUID", end-to-end feedback messages, and even some handling specifications such as "latest available data".  In fact, we've even discussed including an erasure coding option in DTPC.

I think the key point here is that, at least for the purposes of all the requirements we've identified, these features matter only at the ends of the path; they're not relevant at the forwarding points within the network, and in some cases it's not even feasible to support them at those interim forwarding points.  DTPC is conceived as a strictly end-to-end service based on a protocol that is layered above BP, which enables it to take full advantage of whatever routing, security, and CoS capabilities are provided by BP and its convergence-layer protocols without diving into the combinatoric complexity that I think would result from trying to infuse all those features into BP itself.  DTPC can be fully specified without introducing a lot of new dependencies, and the relatively simple core of BP is preserved without modification.

Are there ways in which this general approach wouldn't work for the FEC service you've proposed?

Scott

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of John Zinky
Sent: Tuesday, September 04, 2012 9:16 AM
To: [e-mail]
Subject: [dtn-interest] DTN protocol suite, FEC as an example of cross cutting traditional network layering.

The Erasure Coding specification exposes many protocol design issues that are intrinsic to disruption tolerant networks (DTNs). Specifically, that DTN services tend to crosscut traditional network layering.

Forward Error correction in IP networks is a property of the link layer to remove physical channel errors or end-to-end drops then the transport layer. The forward error correction scheme can be tailored to the channel error characteristics, and there is a wide continuum of solutions that can trade off end station processing against channel overhead. The choice of the FEC can be dynamically determined at runtime, based on real-time measurements.

But DTNs have extreme channel characteristics, with high drop rates, reordering, duplicates, and long delays. Basically, the DTN network is running open loop with very little or no end-to-end feedback.

The result was that for even a strait forward service, such as FEC, the service design touched many layers in the DTN protocol suite. The design had to specify how to set the primary block parameters, added an extension block, and even specify the format of the payload.
  http://tools.ietf.org/html/draft-irtf-dtnrg-zinky-erasure-coding-extension-00

The open question for discussion is, if DTNs services do not layer nicely and each service needs to use and set parameters across multiple layers. How should DTN services be defined?

For FEC, we created an extension block with several aspects that really can be used by other services.

Data Object Format: The format of the payload is not specified in 5050. For FEC, the combined payload over multiple bundles needs to be specified. The solution we chose was to make an explicit next protocol field that is part of the Erasure Coding Extension Block. But how does this interact with the "Application-layer", where the payload format is implicitly specified in the Destination EID. Should "Next Protocol" be pulled out into is own extension block?

Data Object UUID: FEC works over a group of bundles that encode the same data object. FEC needs a field that indicates the data object that is associated with an encoding bundle. But, grouping bundles could be a service in its own right. Should "Session ID" be pulled out into its own extension block?

Handling Specification: Because the DTN transfer is basically open loop, the sender has to make use of an oracle to predict the channel characteristics across the DTN. These channel characteristic assumptions can be specified in a "Handling Specification" for the encoding bundles. For FEC, how an individual bundle is forwarded between routers is not as important as how the whole group of FEC bundles is treated. For example, the order of encoding bundles being sent between contacts between quickly moving BPAs, should not be First Come First Serve, i.e. only the first Bundles of a group will be forwarded. Other application bundle streams also want specialized handling, such as Situational Awareness wants to send the most recent status update (Last In First Out). Should the "Handling Spec" be pulled out into its own extension block?

End-to-end Feedback Messages: FEC is more efficient with more feedback from neighbors and from the destination(s).
The 5050 notifications are about specific bundles and not about groups of bundles. Should notification for groups of bundles, be encoded in extension blocks or the payload? Also, how should feedback about a group of bundles be aggregated?

Concluding Remark:
DTN is an opportunity to address the Quality of Service issues that have plagued TCP/IP networks, because of its explicit/fixed layers in the IP protocol suite. QoS issues crosscut the traditional layers, so the DTN protocol suite could have a different layering decomposition or it could embrace the notion of crosscutting and create a set of extensions that can be composed into multiple services, i.e. mixed and matched. I would like to see other examples of DTN network services and how they interact, such as encryption, compression, aggregation, situation awareness, pub-sub service (e.g DDS), multicast, geo-loc/role based routing, content dissemination, etc.


_______________________________________________
dtn-interest mailing list
[e-mail]
https://www.irtf.org/mailman/listinfo/dtn-interest
_______________________________________________
dtn-interest mailing list
[e-mail]
https://www.irtf.org/mailman/listinfo/dtn-interest
_______________________________________________
dtn-interest mailing list
[e-mail]
https://www.irtf.org/mailman/listinfo/dtn-interest