Subject: Re: [dtn] FW: New Version Notification for draft-dtnwg-bp-00.txt

From: Elwyn Davies <[email-masked]>
Date: Tue, 21 Jul 2015 18:39:37 +0200

Hi.

Somewhat belated comments on the draft:  IMO there is an awful lot to 
clear up in this draft (which the authors probably know).   I am 
particularly concerned that the piece on forwarding of bundles is a sort 
of half hearted lecture on routing.  If we aren't going to consider 
routing in the draft (as it says early on) then all of the stuff in 
s5.4r needs serious reworking. At least part of this is (IMO) due to 
excessive consideration of prioritisation.

Identifier:  Has this draft been formally adopted by the WG?   I 
couldn't see anything in the minutes or mailing list.   If so it should 
be draft-ietf-dtnwg-bp-00; otherwise it should be 
draft-burleigh-dtnwg-bp-00.

Scope (para after figure 1): It describes the protocol and the 
processing of bundles in the nodes (BPA)

"The bundle route computation algorithm.": Better "The process used to 
determine how and when bundles should be forwarded to nodes that might 
be connected to this node."

"Mechanisms for populating the routing or forwarding information bases 
of bundle nodes."  RIBs and FIBS are not defined in this document.  If 
the previous statement is true, there is no guarantee that a node will 
have either (even if we knew what they were).

> Bundle payload - A bundle payload (or simply "payload") is the
>     application data whose conveyance to the bundle's destination is the
>     purpose for the transmission of a given bundle.
No.  In administrative bundles the data in bundles is internal admin 
data and nothing to do with the application  data.

>   The
>     nominal payload for a bundle forwarded in response to reception of
>     that bundle is the payload of the received bundle.
Not if it gets fragmented.

> either a nominal
>     payload or a fragmentary payload -- of length M, such that 0 < N <
>     M.
Are we sticking with the idea that every bundle has to have a non-empty 
payload?

>     In the most familiar case, a bundle node is instantiated as a single
>     process running on a general-purpose computer, but in general the
>     definition is meant to be broader: a bundle node might alternatively
>     be a thread, an object in an object-oriented operating system, a
>     special-purpose hardware device, etc.
Not necessary.

> The manner in which it does so is
>     wholly an implementation matter. For example, BPA functionality
>     might be coded into each node individually; it might be implemented
>     as a shared library that is used in common by any number of bundle
>     nodes on a single computer; it might be implemented as a daemon
>     whose services are invoked via inter-process or network
>     communication by any number of bundle nodes on one or more
>     computers; it might be implemented in hardware.
Not necessary.  Adding speculation on implementation is unwise.  We are 
describing the protocol and the associated processes that have to be 
carried out when a bundle is received from or dispatched to a 
convergence layer adapter at the 'bottom' and an application (agent) at 
the 'top'.

Convergence Layer Adaptors:
s/functionally/potentially/
> it may offer additional CL-specific functionality.
In that case there had better be an interface through which the BPA (and 
AA) find out what CL specific functionality is available and allow it to 
be presented to applications.  This could be considered as a layer 
violation.  OTOH e.g. LTP needs to be told which part of the data is RED 
and which GREEN.

Bundle Endpoints:
The concept of Minimum Reception Group (MRG) from RFC 4838 has (to the 
best of my knowledge) never been implemented in its full glory. We have 
done unicast and what one might describe as "ad hoc anycast" where the 
bundle is delivered to any node that it happens to encounter that has 
registered the EndPoint ID on the bundle.  Given an (opportunistic) DTN 
one has no good way of determining how many nodes have registered the 
EndPointID - the idea of having a central registry doesn't look good .  
It is also very unclear how a nodes would be able to determine that the 
MRG transmission requirement had been satisfied - and how one might 
adjust one's transmission efforts depending on how many copies have been 
delivered -   the notifications will be potentially a long time coming 
and might never arrive.  What use case is a MRG of multiplicity > 1 
addressing? And does anybody understand how it would be implemented in 
an opportunistic network (it is possible something might be done in a 
CGR network - but that would all be centrally controlled and amounts to 
multiple unicasts).  OTOH unspecified and unmanaged delivery to any 
number of endpoints that express a particular address looks entirely 
sensible.

Consequently the whole concept of 'transmission'  is overblown.

Registration:
The whole concept of registration rather moved on after 4838 and 5050 
were published.  Applications should be the causative agent in getting 
registrations established.  The DTN2 system (apart from the wonderfully 
insecure script execution on delivery capability) makes a lot of sense, 
providing a mechanism for multiplexing and demultiplexing within  a 
single endpoint.  I think the AA should be handling the registrations 
with support form the BPA.

I would delete s3.2 - implementation is out of scope.

s4, Bundle Format: Are empty payloads allowed? The one byte restriction 
was irritating sometimes.

s4.1 - can't we refer to the SDNV RFC6256?

s4.2 - One needs to define what 'critical' means and how best efforts 
forwarding differs from reliable.  Also why do we have bits 6-8 AND the 
class of service bits?  Can't they be combined (assuming one can 
convince oneself they are useful)? [The usefulness of CoS bits has been 
close to zero in most networks - the only case that I know of thet has 
been truly successful is flagging routing control traffic in IP networks 
where it is the network owner that expedities his/her own traffic for 
good reason.  Customers are almost invariably confused by offering CoS - 
and having to pay for it.]  I am not sure why one bothers to leave blank 
bits when using an SDNV. It just may make the SDNV bigger.

s4.2:
> If the bundle's source endpoint is the null
>     endpoint (see below), then the bundle is not uniquely identifiable
>     and all bundle protocol features that rely on bundle identity must
>     therefore be disabled: the bundle's custody transfer requested flag
>     must be zero, the "Bundle must not be fragmented" flag must be 1,
>     and all status report request flags must be zero.
This might also be true if the source endpoint is not a singleton 
endpoint - should always use the node admin endpoint?

  s4.4.1:
>   Scheme identifier zero is reserved for the null endpoint ID.
The null endpoint id is referred to as dtn:none elsewhere.

Figure 5: Duplicating the payload block format (being the same as the 
canonical format) (and postponing the description till after the 
canonical block defn is confusing).

Lifetime:  It be better to be honest and call it 'Expiry Time' sice it 
is an absolute time (still).

s5.4, step 2:  This attempts to sort of tell me how to do routing, 
except it is only a small part of the story and does not consider (among 
other things) whether it is wise to continue replicating (as forwarding 
implies replication according to your earlier definition).  Also 
contraindication is in s5.4.1 and not Figure 12.

s5.4 throughout but especially step 6:  The concept of connections 
varying in time is not considered.

Ordering of extension blocks:  Can extension blocks be on either side of 
payload?  What about fragmentation?

/Elwyn

On 22/06/2015 16:47, Burleigh, Scott C (312B) wrote:
> Hi.  Yesterday I posted a new Bundle Protocol specification as an Internet Draft; it's at https://www.ietf.org/internet-drafts/draft-dtnwg-bp-00.txt, authored by Ed Birrane, Kevin Fall, and me.  We started with the draft I'd posted last December, removed a bunch of things on which we clearly didn't have consensus, and inserted some new material on which I believe we do have consensus.   There's a section toward the end that very briefly summarizes the ways in which this spec significantly differs from RFC 5050, followed by a longer section listing the technical issues on which we have yet to come to agreement.  Plenty of material to discuss at IETF 93 and on the mailing list between now and then.
>
> Scott
> _______________________________________________
> dtn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtn
>

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Tue, 21 Jul 2015 21:14:25 +0000

Thanks for these, Elwyn.  At this point I guess we will mainly trying to resolve them after the meeting rather than prior to it, but I'll offer a few initial thoughts, in-line below (>>).

Scott
________________________________________
From: dtn [[email-masked]] on behalf of Elwyn Davies [[email-masked]]
Sent: Tuesday, July 21, 2015 9:39 AM
To: [email-masked]
Subject: Re: [dtn] FW: New Version Notification for draft-dtnwg-bp-00.txt

Hi.

s5.4r needs serious reworking.

>>  Can you explain why this is true?  I think this section draws a clear distinction between routing (that is, the procedure by which you decide which proximate node(s) to copy the bundle to in order to advance it toward its destination) and forwarding (the procedure by which you copy the bundle to the selected node(s)).  The formerly is explicitly out of scope and is not addressed at all; the latter is defined in some detail in section 5.4.

At least part of this is (IMO) due to
excessive consideration of prioritisation.

>>  Really?  There is one sentence in section 5.4 that refers to bundle priority.

>>  Okay.

>>  Not an improvement.

>>  But this is not what is meant.  What is meant is what is written: the algorithm used to compute the route.  The process by which bundles are forwarded to nodes is addressed in this specification.

>>  Good point.  This sentence could certainly be deleted.

>>  Not so: the administration of the nodes is an application, served by an application-layer protocol (the administrative records) that is layered on top of BP in the same way that SNMP is layered on top of IP.

>>  Right, that's what "nominal" means here.  The off-nominal procedure is fragmentation.

>>  Yes, unless someone wants to argue otherwise.

Not necessary.

>>  True.  This sentence is meant to be informational, for the benefit of the reader who may be approaching the specification with a different concept in mind.

>>  Again, you are right, this is not necessary.  It's intended to be a kindness to the reader.

>>  "Functionally" is what is meant here.  But the adverb doesn't add much clarity and could certainly be dropped.

>>  But specification of that interface isn't necessary for interoperation.  I think it can be left as an implementation matter.

Bundle Endpoints:

>>  Actually a pretty full-featured specification for reliable DTN multicast was posted as an I-D a couple of years ago and has been implemented in ION about the same length of time.  It's not centrally controlled, but it does depend on effective forwarding; extending CGR to opportunistic routing may or may not make it more broadly usable, the jury's still out on that.  However, it does provide an existence proof of the viability of MRG > 1.

>>  I don't see how that follows.

Registration:

>>  I don't follow your reasoning at all here, Elwyn.  I think this needs some discussion.

>>  I'm not altogether opposed.  This again is text that is meant to be illustrative and informative; it's certainly not normative.

>>  Can you say more about when and why you'd want to send a bundle with no payload?

>>  Sure.  This again is meant as a kindness to the reader, saving an extra Web query.

s4.2 - One needs to define what 'critical' means and how best efforts
forwarding differs from reliable..

>>  Yes, this is identified in 13.11 as an open issue.

Also why do we have bits 6-8 AND the

>>  Bits 6-8 address the character of transmission, not the order of transmission.  Some applications require reliable delivery, while others actually require that forwarding *not* be slowed by retransmission.  In the Internet we offer the application a choice of UDP or TCP; bits 6-8 offer the equivalent range of options in BP.  (No, custody transfer is not even remotely equivalent to TCP.)

>>  Another open issue: since we have never defined procedures by which a set of nodes can transmit a bundle, it's unclear how the source endpoint can ever be anything other than a singleton endpoint. 

>>  Correct.  Here we are talking about the "encoded", over-the-wire representation of the EID, not the human-readable representation.

>>  Sure, we should fix this.

>>  No, it isn't.  It's the interval of time which, when added to the bundle's creation time, yields the Expiry Time. The distinction is important if we want to support the Bundle Age option.

>>  Not at all.  It explicitly says it is *not* going to tell you how to do routing.

except it is only a small part of the story and does not consider (among
other things) whether it is wise to continue replicating (as forwarding
implies replication according to your earlier definition).

>>  Correct.  It doesn't consider such questions because they are matters of routing, which is out of scope.

Also

>>  The procedure is defined in 5.4.1; the reasons are identified in Figure 12.

>>  What would that consideration be, and why is it needed?

>>  Good question.  13.8 talks a little about the proposal to require the payload block always to be the last block of the bundle, which I think is a good idea.

/Elwyn

---

From: Tomek Mrugalski <[email-masked]>
Date: Wed, 22 Jul 2015 09:59:51 +0200

> draft-burleigh-dtnwg-bp-00.
The DTN wg designation is -dtn-, not -dtnwg-, so the draft name should
be draft-burleigh-dtn-bp-XX while in its individual phase and
draft-ietf-dtn-bp-XX once adopted. There's a very good reason to adhere
to this notation: datatracker doesn't show misnamed drafts. See here:

https://datatracker.ietf.org/wg/dtn/documents/

It seems as if there was only a single individual submission related to
this WG. That obviously is not true.

Tomek

---

From: "Marc Blanchet" <[email-masked]>
Date: Wed, 22 Jul 2015 10:08:42 +0200

On 22 Jul 2015, at 9:59, Tomek Mrugalski wrote:

>> Identifier:  Has this draft been formally adopted by the WG?

no. no document has been adopted by the WG yet.

>> I

Right, however, we also are not declining any draft that does not follow 
this bcp.

Marc.

---

From: Elwyn Davies <[email-masked]>
Date: Wed, 22 Jul 2015 14:07:30 +0200

>> https://datatracker.ietf.org/wg/dtn/documents/
Sorry... I haven't got over my dtnrg addiction yet :-)
/E