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

["Moore, Brad" <[e-mail]>]

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.