Re: [dtn-interest] comments on draft-irtf-dtnrg-ecos

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

Brad, there's a reason that the term "reliability" does not appear in the discussion of the "streaming" flag in the ECOS I-D: the feature is not intended as a reliability control (although in practice it would result in the selection of CL protocols that are colloquially characterized as "reliable" or "unreliable").

The purpose of the "streaming" flag is strictly and precisely to suppress retransmission, exactly as noted in the specification, nothing more.  The reason for it is the requirement -- identified at JPL, if nowhere else -- to support the transmission of real-time "streaming" data over DTN; the rationale is briefly discussed in the I-D.  It *does not* describe reliability in general terms or provide a general "hint" about reliability.  It *does not* describe (or even refer to) reliability in any way.  "Streaming" is exactly and explicitly what it is all about.

It would be a mistake to puff up this humble little flag, serving a very limited, constrained purpose for which there is a well-defined need, into a general "reliability" control, especially when we're evidently months or years away from reaching consensus on what "reliability" means and how best to express that in protocol.

But sure, there may well also be a requirement for some sort of Reliability control in the ECOS block, and perhaps also some sort of Discardability control (though there's got to be a better word for it).

How about this?  Let's define two additional flags in the Flags byte of the ECOS block:

-	The 0x08 bit, if True, indicates that the "flow label" in this ECOS block (if present; otherwise, the "ordinal" byte) is followed by a numeric "reliability code" in SDNV representation.

-	The 0x10 bit, if True, indicates that the "reliability code" in this ECOS block (if present; otherwise, the "flow label" if present; otherwise, the "ordinal" byte) is followed by a numeric "discardability code" in SDNV representation.

Using SDNVs here gives us plenty of expressive power, so the encoding of the "reliability" and "discardability" control specifications can be as rich as you like.  Implementations that want to use these features can do so, and those that don't yet see a need for them can omit them at no cost in bandwidth, just by leaving the flags unset.  So we'll be using the BP extensions mechanism as a way to explore the utility of these features in practical operation, exactly as it was designed to do.

If you can give me some text defining the reliability and discardability codes you'd like to use, I will happily add them to the ECOS I-D and post a new version.  Or, if you'd prefer to spend some more time on that coding, I can handle them for now in the same way as "flow label" is handled in the text.

Scott

-----Original Message-----
From: Moore, Brad [mailto:[e-mail]] 
Sent: Friday, November 26, 2010 10:10 AM
To: [e-mail]; Burleigh, Scott C (313B); [e-mail]
Subject: RE: [dtn-interest] comments on draft-irtf-dtnrg-ecos

Lloyd Wood wrote:
> Reliable delivery or reliable as in error-free? The concepts are
> confused

I agree that there are multiple sub-properties that fall under the
"reliability" heading.
For example, error-free as in error-detecting, or error-correcting?

One approach would be to define specific flags for each of these
sub-attributes
so that a CL, such as the Saratoga CL (from what you describe), could
take advantage
of its richer feature set and address these attributes with precise
control.

Another approach, (the one that seems to be taken with the ecos draft)
is to
provide a very minimal set of flags that describe reliability in very
general terms,
and it is up to the CL, and the configuration of a Bundle Agent, to
determine how best to
interpret the general hint, and map to specific features of the CL.

I am not sure which of these two approaches is more appealing to me, but
in my opinion the
second approach needs more than just a single flag to represent a
reasonable set of semantics.
Some middle ground is needed.

The more control flags are added to the second approach, the more that
approach starts to
look like the first approach. My position right now is that adding one
more flag to the ecos
proposal is probably good enough to satisfy most needs, though I could
be convinced more towards the
first approach.

I agree that the terminology can be improved though. In fact, I think
"Streaming" can be misleading as well. I foresee the Streaming
flag being used in cases where the associated bundles are not
really part of a stream. Similarly, there can be cases there
streaming is occurring (possibly over TCP as you mention) 
where the Streaming flag may be undesirable.

First, what are the semantic attributes that might be associated with
setting the streaming flag?

 Setting the streaming flag might imply and affect some or all of the
following;
  1. Higher Speed - Lighter weight protocol sends data more quickly
  2. Lower bandwidth usage - Less data being sent 
  3. Lower delivery reliability - less or no resends
  4. Less error detection
  5. Less error correction
  6. Higher discardability - drop bundle if queue build up occurs, 
                             possibly forward only, instead of store and
forward
  7. Less persistence (possibly store in volatile memory rather than on
disk)

I see congestion control between the sender and the receiver 
(communicating round trip times for example) as being a configuration
of the CL as a function of the system contraints independent of the
setting of the streaming flag). Local congestion control (what I call
discardability)
however is more a function of the bundle agent than the CL.

If we set a reliability flag (or if we stuck with only the streaming
flag and this flag was not set), I see that would imply some or all of
the following;

  1. Lower Speed - Heavier weight protocol sends data at a slower rate
  2. Higher bandwidth usage - more data being sent 
  3. Higher delivery reliability - Resends >= 1
  4. More error detection (checksum?)
  5. More error correction (FEC?)
  6. Lower discardability - Avoid dropping bundle if at all possible
  7. More persistence Store on disk or non-volatile memory.

Note that these flags (both streaming, and reliability) can affect more
than just the selection
of CL. It may also affect queue management within the bundle agent for
example.

It's difficult to come up with a label for a single flag that describes
all of these effects.

Having two flags can make this easier, provided that the labels for the
flags are not
the boolean negation of each other. (eg. Streaming vs non-streaming, or
reliable vs non-reliable)

I think if the flags were labeled "Speed" (instead of "Streaming"), and
"Accuracy" (instead of "reliable"), then this would better capture the
semantics.

(Speed=> true, Accuracy=> false) seems to capture the effects associated
with the current streaming flag quite well.

Whereas;

(Speed=> false, Accuracy=> true) conversly seems to capture the effects
assocated with the other end of the spectrum.

As in real life, one cannot generally have both speed and accuracy
unless as some sort of compromise,
So;
(Speed=> true, Accuracy=> true) would be interpretted as being an
interest in both properties and represented as some middle ground
between the two, based on the available CL's, and their capabilities.

(Speed=> false, Accuracy=> false) indicates that neither of these
properties are of interest, and any decisions for the handling of a
bundle should be left to the default behaviours of the bundle agent and
CL.

Brad Moore


The information contained in this e-mail message is PRIVATE. It may contain confidential information and may be legally privileged. It is intended for the exclusive use of the addressee(s). If you are not the intended recipient, you are hereby notified that any dissemination, distribution or reproduction of this communication is strictly prohibited. If the intended recipient(s) cannot be reached or if a transmission problem has occurred, please notify the sender immediately by return e-mail and destroy all copies of this message. 
Thank you.