Subject: Re: [dtn] CBAR

From: Keith Scott <[email-masked]>
Date: Tue, 18 Aug 2015 13:11:02 -0400

Scott,

I wonder if the (albeit slight) mistake here is that you said earlier
that you thought adopting CBOR on the wire wouldn't accelerate the
development of bundle protocol *implementations*.  I think what you
meant was that using CBOR on the wire wouldn't affect (one way or the
other, really) the adoption of BP and/or BP *applications* (?)

    --keith

Stephen, I don't see what you're disagreeing with.  You're absolutely
right, most developers don't have time to implement codecs.  They
shouldn't have to.  You only need to develop a codec when you're
developing a protocol implementation, which most developers don't need
to do.  All they need to do is develop applications that utilize
well-supported implementations of protocols.

Sure, JSON or S/MIME might be a great way to encode the payloads of
bundles, which applications are going to read and write, and which
(therefore) lots of developers can benefit from.

But there's no reason for application developers to be developing
implementations of BP itself, in the same way that there's no reason
for application developers to be developing their own implementations
of TCP.  These are two entirely different development communities.

Scott
________________________________________
From: Stephen Farrell [stephen.farrell at cs.tcd.ie]
Sent: Tuesday, August 18, 2015 9:10 AM
To: Burleigh, Scott C (312B); Jeremy.Mayer at dlr.de;
kapaleeswaran.viswanathan at boeing.com; dtn at ietf.org
Subject: Re: [dtn] CBAR?

Hi Scott,

On 18/08/15 17:05, Burleigh, Scott C (312B) wrote:
> Using JSON or CBOR (or whatever) as as basis for the on-the-wire
> representation of bundle information would not significantly
> accelerate the development of bundle protocol implementations.

I really don't agree.

Most developers will not be implementing a general purpose
bundle router.

Most developers do not have enough time to implement 5050 or
any similar home-grown codec.

The above are sufficient reasons for real-world developers to
not use 5050 and to re-invent delay-tolerance at the application
layer over and over IMO. (There may be others but I'm convinced
of the above. )

Cheers,
S.

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Tue, 18 Aug 2015 21:42:12 +0000

Good point, but I did mean to say that the advantage for implementation developers was insignificant. The advantage for application developers is zero, because applications are not going to form bundles; only BP implementations are going to do that.

If BP were just another way to package data for transmission over TCP/IP, JSON would make loads of sense.  But it's not.

Sent from my Verizon 4G LTE Smartphone

------ Original message------

From: Keith Scott

Date: Tue, Aug 18, 2015 1:55 PM

To: [email-masked];

Cc:

Subject:Re: [dtn] CBAR

Scott,

I wonder if the (albeit slight) mistake here is that you said earlier that you thought adopting CBOR on the wire wouldn't accelerate the development of bundle protocol *implementations*.  I think what you meant was that using CBOR on the wire wouldn't affect (one way or the other, really) the adoption of BP and/or BP *applications* (?)

    --keith

Stephen, I don't see what you're disagreeing with.  You're absolutely right, most developers don't have time to implement codecs.  They shouldn't have to.  You only need to develop a codec when you're developing a protocol implementation, which most developers don't need to do.  All they need to do is develop applications that utilize well-supported implementations of protocols.

Sure, JSON or S/MIME might be a great way to encode the payloads of bundles, which applications are going to read and write, and which (therefore) lots of developers can benefit from.

But there's no reason for application developers to be developing implementations of BP itself, in the same way that there's no reason for application developers to be developing their own implementations of TCP.  These are two entirely different development communities.

Scott
________________________________________
From: Stephen Farrell [stephen.farrell at cs.tcd.ie<http://cs.tcd.ie>]
Sent: Tuesday, August 18, 2015 9:10 AM
To: Burleigh, Scott C (312B); Jeremy.Mayer at dlr.de<http://dlr.de>; kapaleeswaran.viswanathan at boeing.com<http://boeing.com>; dtn at ietf.org<http://ietf.org>
Subject: Re: [dtn] CBAR?

Hi Scott,

I really don't agree.

Cheers,
S.

---

From: <[email-masked]>
Date: Wed, 19 Aug 2015 04:12:27 +0000

> If BP were just another way to package data for transmission over TCP/IP, JSON would make loads of sense.  But it's not.

Over 90% of bundles are sent over TCP/IP. And only TCP/IP.

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

________________________________
From: dtn <[email-masked]> on behalf of Burleigh, Scott C (312B) <[email-masked]>
Sent: Wednesday, 19 August 2015 7:42 AM
To: Keith Scott; [email-masked]
Subject: Re: [dtn] CBAR

------ Original message------

From: Keith Scott

To: [email-masked];

Cc:

Subject:Re: [dtn] CBAR

Scott,

    --keith

Scott

Hi Scott,

I really don't agree.

Cheers,
S.

---

From: "I-Viswanathan, Kapaleeswaran" <[email-masked]>
Date: Wed, 19 Aug 2015 10:03:54 +0000

Hi Lloyd.

>> Over 90% of bundles are sent over TCP/IP. And only TCP/IP.

Are you suggesting that we ignore the under 10% irrespective of the importance of those bundles?

Many thanks.

Best regards
Kapali

From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, August 19, 2015 9:42 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [dtn] CBAR

Lloyd Wood

________________________________
From: dtn <[email-masked]<mailto:[email-masked]>> on behalf of Burleigh, Scott C (312B) <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, 19 August 2015 7:42 AM
To: Keith Scott; [email-masked]<mailto:[email-masked]>
Subject: Re: [dtn] CBAR

------ Original message------

From: Keith Scott

To: [email-masked]<mailto:[email-masked]>;

Cc:

Subject:Re: [dtn] CBAR

Scott,

    --keith

Scott

Subject: Re: [dtn] CBAR?

Hi Scott,

I really don't agree.

bundle router.

of the above. )

Cheers,

S.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 19 Aug 2015 11:54:17 +0100

> Are you suggesting that we ignore the under 10% irrespective of the importance of those bundles?

The 90:10 thing isn't a measurement, but I'd say it's
not too far off either so I would not suggest that we
ignore the 10%, but we definitely do not want to ignore
the 90%! (For whom ease of development/deployment are
gigantically more important than saving a bit or two
in the encoding.)

RFC4838 has the concept of a convergence layer. [1] So
using something web friendly for the 90% and something
mappable to/from that (e.g. map from JSON to CBOR) for
the 10% would seem entirely sensible to me.

Cheers,
S.

[1] https://tools.ietf.org/html/rfc4838#section-6

---

From: "I-Viswanathan, Kapaleeswaran" <[email-masked]>
Date: Wed, 19 Aug 2015 11:55:21 +0000

JSON/REST/HTTP was great for PC-era client-server computing. We are in the post-PC era mobile and cloud computing while staring at an impending era for Internet-of-Things including very small devices -- as opposed to fat PCs and even fatter servers. The constraint on the client device side is finite battery power while that on the server device side is electricity bill for infinite electricity supply. There are better options other than JSON and XML. 

1. With the advent of binary transport technologies such as Google Protocol Buffer and Apache/Facebook Thrift, even services on the Internet have commenced movement away from JSON. The reason for this move is demand for ultra-low latency in communication and ultra-low cost of serializing and deserializing data structures due to the advent of (battery powered) mobile computing. On the server side, there is an implication between decoding and energy bills that can run to millions of dollars when we are talking about Internet-scale services. 
http://blog.codeclimate.com/blog/2014/06/05/choose-protocol-buffers/ 
http://dl.acm.org/citation.cfm?id=2184810 

http://stackoverflow.com/questions/14703627/websockets-protocol-vs-http
https://en.wikipedia.org/wiki/SPDY 

2. The world of programming may have commenced its steady move away from REST (usually implemented over HTTP) towards Reactor Pattern and Event Loop Programming, which are closer to event-driven programming. The rise of Websockets is another evidence for the trend.
http://www.programmableweb.com/news/rest-losing-its-flair-rest-api-alternatives/analysis/2013/12/19

My past work, while at HP Labs, for a group collaboration platform using mobile-cloud computing  provided solid insights for moving away from REST and text-based channels such as (JSON and XML) especially when we need to transport text, image, audio, video, and other binary data on a regular basis. 

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Wednesday, August 19, 2015 4:24 PM
To: I-Viswanathan, Kapaleeswaran; [email-masked]
Subject: Re: [dtn] CBAR

> Are you suggesting that we ignore the under 10% irrespective of the importance of those bundles?

The 90:10 thing isn't a measurement, but I'd say it's not too far off either so I would not suggest that we ignore the 10%, but we definitely do not want to ignore the 90%! (For whom ease of development/deployment are gigantically more important than saving a bit or two in the encoding.)

RFC4838 has the concept of a convergence layer. [1] So using something web friendly for the 90% and something mappable to/from that (e.g. map from JSON to CBOR) for the 10% would seem entirely sensible to me.

Cheers,
S.

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Wed, 19 Aug 2015 12:03:23 +0000

Except this presupposes that the constrained-environment use cases don't really matter, so it's fine for them to do all that mapping and unmapping and remapping at every network node, because they've got cycles to burn.

How about an approach that allocates the processing to the nodes that can afford to do it?  Let's define a DtnDAV that operates as an end-to-end ("application") layer on top of BP, that provides the familiar all-text environment that Web developers expect and maps to underlying bit-efficient BP.

Scott
________________________________________
From: dtn [[email-masked]] on behalf of Stephen Farrell [[email-masked]]
Sent: Wednesday, August 19, 2015 3:54 AM
To: I-Viswanathan, Kapaleeswaran; [email-masked]
Subject: Re: [dtn] CBAR

Cheers,
S.

_______________________________________________
dtn mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dtn

---

From: "I-Viswanathan, Kapaleeswaran" <[email-masked]>
Date: Wed, 19 Aug 2015 12:08:26 +0000

This is actually for DTNRG and a nice idea. Makes a nice graduate student project. 

If we can interface BP with something like Node.JS, you can have bit-efficiency on the wire and efficient but user-friendly non-blocking Web programming. This is similar to what I suggested in a response to Rick's email on this mailing list a few minutes ago. 

Best regards
Kapali 

-----Original Message-----
From: Burleigh, Scott C (312B) [mailto:[email-masked]] 
Sent: Wednesday, August 19, 2015 5:33 PM
To: Stephen Farrell; I-Viswanathan, Kapaleeswaran; [email-masked]
Subject: RE: [dtn] CBAR

Scott

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 19 Aug 2015 13:09:27 +0100

Hiya,

Two points:

- I don't think JSON is wonderful, and I agree that fashions in
that respect change about every 5 years or so. But JSON does have
wide-spread, deployed support now and will for the forseeable, so
is I think a better choice compared to somewhat more fashionable
things like protocol buffers etc. Of the currently fashionable
things, I do think I'd prefer CBOR for DTN as it happens, and
Carsten I know has done that analysis of CBOR vs. others though
not with DTN at the top of the list that I know. Anyway my
preference here is to not be at the height of fashion for the
TCPCL situations at least. Having other CLs that are more
fashionable is a fine thing, and other CLs that use CBOR would
make fine sense.

- I've not suggested we try be RESTful. That might or might not
be worth thinking about for a specific CL (basically an HTTPs CL
I guess using ALPN), but that'd be CL-specific I think and not
an e2e DTN thing.

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 19 Aug 2015 13:11:34 +0100

Hiya,

On 19/08/15 13:03, Burleigh, Scott C (312B) wrote:
> Except this presupposes that the constrained-environment use cases
> don't really matter,

I don't think that's a fair criticism.

What I'd assume is that the last non-constrained router would
be the first one to start using the CL that works for the 10%.
I don't see any problems doing so and I do think that allocates
processing where it can be best done (or allows one to).

S.

---

From: "Sheehe, Charles J. (GRC-LCA0)" <[email-masked]>
Date: Wed, 19 Aug 2015 12:16:12 +0000

Hi
I have been reading your exchanges, very interesting.

If the environment is so constrained on the flight node side why is DTN trying to implement Security.
Why would we not leave security at the ground and the end application?  

We cannot protect the network without incurring resource hits, let the end nodes decide the security they desire.
Even protected network get DOS ed.
 
http://www.networkworld.com/article/2959547/security/black-hat-2015-hacker-shows-how-to-alter-messages-on-satellite-network.html

Thanks
Chuck

Charles J. Sheehe III
Electronics Engineer
System Architectures and Networks Branch
21000 Brookpark Rd
Cleveland, OH 44135
[email-masked]
Office: 216-433-5179

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of Burleigh, Scott C (312B)
Sent: Wednesday, August 19, 2015 8:03 AM
To: Stephen Farrell; I-Viswanathan, Kapaleeswaran; [email-masked]
Subject: Re: [dtn] CBAR

Scott

Cheers,
S.

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Wed, 19 Aug 2015 12:16:53 +0000

Of course it's a fair criticism.  If the definition of BP protocol traffic is all based on text and it only becomes binary at the convergence layer, then everything gets mapped to binary every time it is transmitted over a constrained link and unmapped as soon as it is received, at every node.  If the entire network is constrained nodes, then it happens at every single node, on every hop, for every bundle transmitted from every node to every other node.  All wasted.

If the mapping/unmapping happens at the layer above BP, then it's done at the ends, where the applications live who want it.

Scott
________________________________________
From: Stephen Farrell [[email-masked]]
Sent: Wednesday, August 19, 2015 5:11 AM
To: Burleigh, Scott C (312B); I-Viswanathan, Kapaleeswaran; [email-masked]
Subject: Re: [dtn] CBAR

Hiya,

S.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 19 Aug 2015 13:29:13 +0100

On 19/08/15 13:16, Burleigh, Scott C (312B) wrote:
> Of course it's a fair criticism. 

No. As I read it, you claimed that my argument means that I
don't care about constrained environment use-cases. I do. I
just also care about other things as well:-)

> If the definition of BP protocol
> traffic is all based on text and it only becomes binary at the
> convergence layer, then everything gets mapped to binary every time
> it is transmitted over a constrained link and unmapped as soon as it
> is received, at every node.  If the entire network is constrained
> nodes, then it happens at every single node, on every hop, for every
> bundle transmitted from every node to every other node.  All wasted.

That's where your and my views of this as just a protocol or
as an entire service cause a difference. For me, it's just
fine if a node that knows it'll (possibly or certainly) use
the same CL on ingress and egress decides to not mess with
the encoding. For you, I guess you want the exact same treatment
to happen internally regardless of which CLs are available,
which I agree could lead to waste. (But it'd not have to either
if one is smart about it.)

Cheers,
S.

> 
> If the mapping/unmapping happens at the layer above BP, then it's
> done at the ends, where the applications live who want it.
> 
> Scott ________________________________________ From: Stephen Farrell
> [[email-masked]] Sent: Wednesday, August 19, 2015 5:11 AM 
> To: Burleigh, Scott C (312B); I-Viswanathan, Kapaleeswaran;
> [email-masked] Subject: Re: [dtn] CBAR
> 
> Hiya,
> 
> What I'd assume is that the last non-constrained router would be the
> first one to start using the CL that works for the 10%. I don't see
> any problems doing so and I do think that allocates processing where
> it can be best done (or allows one to).
> 
> S.
>

---

From: Rick Taylor <[email-masked]>
Date: Wed, 19 Aug 2015 12:55:07 +0000

> If we can interface BP with something like Node.JS, you can have bit-efficiency on the wire and efficient but user-friendly non-blocking Web programming. This is similar to what I suggested in a re…

I think you may be confusing the HOW with the WHAT here:

WHAT is: "What does a DTN forwarding agent require in a bundle in order 
to correctly deliver it to an endpoint?"

HOW is: "How shall I write this code: event-driven javascript or 
fork-and-accept blocking IO in C89?"  (or any other cool technology for 
a given definition of 'cool')

The WG can only focus on the WHAT.

With that in mind, I believe that describing the WHAT using JSON has 
some benefits, as long as nothing in the protocol prevents a node from 
deciding to transform the JSON into something more suitable for 
communicating over its links, such as CBOR or SDNV.

An extension of that point is that even if the core DTN protocol is 
defined entirely in JSON, there is nothing to stop an implementation 
using an entirely different data representation internally and never 
actually formatting anything as JSON if the CLs in use do not use JSON.

Cheers,

Rick

---

From: "I-Viswanathan, Kapaleeswaran" <[email-masked]>
Date: Wed, 19 Aug 2015 13:13:23 +0000

Hi Rick

I agree that standards only need to specify whats and hows. 

>> With that in mind, I believe that describing the WHAT using JSON has some benefits, as long as nothing in the protocol prevents a node from deciding to transform the JSON into something more suitable for communicating over its links, such as CBOR or SDNV.

This would imply that double encoding and double decoding are standardized. 

If it is known that binary data shall be transported regularly in addition to text data, why not specify CBOR (for example) as the data serialization standard instead of JSON? 

Best regards
Kapali 

-----Original Message-----
From: Rick Taylor [mailto:[email-masked]] 
Sent: Wednesday, August 19, 2015 6:25 PM
To: I-Viswanathan, Kapaleeswaran; Burleigh, Scott C (312B); Stephen Farrell; [email-masked]
Subject: Re: [dtn] CBAR

WHAT is: "What does a DTN forwarding agent require in a bundle in order to correctly deliver it to an endpoint?"

HOW is: "How shall I write this code: event-driven javascript or fork-and-accept blocking IO in C89?"  (or any other cool technology for a given definition of 'cool')

With that in mind, I believe that describing the WHAT using JSON has some benefits, as long as nothing in the protocol prevents a node from deciding to transform the JSON into something more suitable for communicating over its links, such as CBOR or SDNV.

An extension of that point is that even if the core DTN protocol is defined entirely in JSON, there is nothing to stop an implementation using an entirely different data representation internally and never actually formatting anything as JSON if the CLs in use do not use JSON.

Cheers,

Rick

> The 90:10 thing isn't a measurement, but I'd say it's not too far off 
> either so I would not suggest that we ignore the 10%, but we 
> definitely do not want to ignore the 90%! (For whom ease of 
> development/deployment are gigantically more important than saving a 
> bit or two in the encoding.)
>

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Wed, 19 Aug 2015 23:34:06 +0000

I think the focus group is obliged to focus on exactly WHAT travels over the wire, so that independently developed implementations can interoperate.

How the transmitted data are represented internally is certainly not the business of the WG.  But protocol specifications need to explain in detail how to construct and parse transmitted protocol data units.  Maybe that specification is "here are a bunch of data items to look for, just use JSON to find them," but if you leave that out you don't have a protocol specification; you've got a statement of requirements for a protocol specification.

Scott
________________________________________
From: Rick Taylor [[email-masked]]
Sent: Wednesday, August 19, 2015 5:55 AM
To: I-Viswanathan, Kapaleeswaran; Burleigh, Scott C (312B); Stephen Farrell; [email-masked]
Subject: Re: [dtn] CBAR

Cheers,

Rick

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Wed, 19 Aug 2015 23:48:03 +0000

Okay, suppose a node knows that it will use the same CL on ingress and egress and decides not to mess with the encoding.  By this, I infer you mean that this decision mitigates the mapping/unmapping overhead I was complaining about, making the processing suitable for resource-constrained nodes?  In order for this to be true, "not to mess with the encoding" would mean no mapping/unmapping, correct?  In which case, the protocol procedures have to operate natively on the binary-encoded data, correct?  In order to do so, there would have to be an implementation of the protocol that enacts all of the protocol's procedures without ever receiving any protocol traffic data in the text-only format, right?  That implementation would have to adhere to a specification in order to be standard-compliant, right?  In which case, that specification would define exactly the thing that we've been calling the Bundle Protocol.

So now we are talking about two distinct over-the-wire protocols that (possibly) encompass the same procedures but apply those procedures to data encoded in two radically different forms.  Neither one runs over the other.  A node that implements both would be a gateway between the two.

Does that solve everybody's problems?  (Aside from which one gets to be called "Bundle Protocol" and what do we call the other one?)

Scott
________________________________________
From: Stephen Farrell [[email-masked]]
Sent: Wednesday, August 19, 2015 5:29 AM
To: Burleigh, Scott C (312B); I-Viswanathan, Kapaleeswaran; [email-masked]
Subject: Re: [dtn] CBAR

Cheers,
S.

---

From: <[email-masked]>
Date: Thu, 20 Aug 2015 01:36:57 +0000

The encoding issue is moot and a red herring. SMTP was 7-bit, but unicode and modern systems are 8 - binary all the way.

One of the nice things about HTTP is that its MIME supports 8-bit encoding. Textual headers are easily malleable and mutable and customizable, which is a separate plus, but payloads can be binary.

Translating payloads is compute-intensive and best avoided.

Lloyd Wood
http://http-dtn.sf.net/
________________________________________
From: dtn <[email-masked]> on behalf of Stephen Farrell <[email-masked]>
Sent: Wednesday, 19 August 2015 10:29 PM
To: Burleigh, Scott C (312B); I-Viswanathan, Kapaleeswaran; [email-masked]
Subject: Re: [dtn] CBAR

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 20 Aug 2015 10:38:08 +0100

On 20/08/15 02:36, [email-masked] wrote:
> The encoding issue is moot and a red herring. SMTP was 7-bit, but
> unicode and modern systems are 8 - binary all the way.
> 
> One of the nice things about HTTP is that its MIME supports 8-bit
> encoding. Textual headers are easily malleable and mutable and
> customizable, which is a separate plus, but payloads can be binary.

Right, making 5050bis be "HTTP with a few more headers" is another
possible approach, and I think one you suggested quite a while
back. I wasn't so keen on that then (it arguably requires some
updated middleboxes and mods to apache/nginx) but I certainly
agree that with HTTP/2.0, that idea is well worth another look.
HTTP/2.0 gets rid of the head-of-line blocking from which HTTP/1.1
suffered and HTTP/2.0 supports binary and compressed headers.
And QUIC will mean that there's a "native" connectionless transport
for that too.

On balance I think I'd still end up preferring putting the BP
primary block stuff in a a JSON body-part in the HTTP request
and response payload, but I'd fully agree that one ought look
afresh at the current HTTP infrastructure and see if that ends
up being better.

Cheers,
S.

> Lloyd Wood http://http-dtn.sf.net/ 
> ________________________________________ From: dtn
> <[email-masked]> on behalf of Stephen Farrell
> <[email-masked]> Sent: Wednesday, 19 August 2015 10:29 PM 
> No. As I read it, you claimed that my argument means that I don't
> care about constrained environment use-cases. I do. I just also care
> about other things as well:-)
> 
>> If the definition of BP protocol traffic is all based on text and
>> it only becomes binary at the convergence layer, then everything
>> gets mapped to binary every time it is transmitted over a
>> constrained link and unmapped as soon as it is received, at every
>> node.  If the entire network is constrained nodes, then it happens
>> at every single node, on every hop, for every bundle transmitted
>> from every node to every other node.  All wasted.
> 
> That's where your and my views of this as just a protocol or as an
> entire service cause a difference. For me, it's just fine if a node
> that knows it'll (possibly or certainly) use the same CL on ingress
> and egress decides to not mess with the encoding. For you, I guess
> you want the exact same treatment to happen internally regardless of
> which CLs are available, which I agree could lead to waste. (But it'd
> not have to either if one is smart about it.)
> 
> Cheers, S.
> 
>> 
>> Scott ________________________________________ From: Stephen
>> Farrell [[email-masked]] Sent: Wednesday, August 19,
>> 2015 5:11 AM To: Burleigh, Scott C (312B); I-Viswanathan,
>> Kapaleeswaran; [email-masked] Subject: Re: [dtn] CBAR
>> 
>> Hiya,
>> 
>>> Except this presupposes that the constrained-environment use
>>> cases don't really matter,
>> 
>> What I'd assume is that the last non-constrained router would be
>> the first one to start using the CL that works for the 10%. I don't
>> see any problems doing so and I do think that allocates processing
>> where it can be best done (or allows one to).
>> 
>> S.
>> 
> 
> _______________________________________________ dtn mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/dtn
> 
> _______________________________________________ dtn mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/dtn
>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 20 Aug 2015 10:48:16 +0100

On 20/08/15 00:48, Burleigh, Scott C (312B) wrote:
> Okay, suppose a node knows that it will use the same CL on ingress
> and egress and decides not to mess with the encoding.  By this, I
> infer you mean that this decision mitigates the mapping/unmapping
> overhead I was complaining about, making the processing suitable for
> resource-constrained nodes?  In order for this to be true, "not to
> mess with the encoding" would mean no mapping/unmapping, correct? 

I'm not quite sure what you mean by mapping/unmapping. In any
environment some decoding of the inbound bundle is needed to
check if this node is a destination (or in the dest endpoint if
we want to be pedantic) and its very likely that that decoding
would also suffice to handle forwarding/routing decisions.

But in many cases there'd be no need to fully-decode e.g. all
extension block values, and certainly no need to re-encode the
entire bundle. (In any case, the BPA code will deal with some
local data structures that contain more than just what's
decoded from the received bundle.)

So I don't see there being any problem at all.

> In
> which case, the protocol procedures have to operate natively on the
> binary-encoded data, correct?  In order to do so, there would have to
> be an implementation of the protocol that enacts all of the
> protocol's procedures without ever receiving any protocol traffic
> data in the text-only format, right?  That implementation would have
> to adhere to a specification in order to be standard-compliant,
> right?  In which case, that specification would define exactly the
> thing that we've been calling the Bundle Protocol.
> 
> So now we are talking about two distinct over-the-wire protocols that
> (possibly) encompass the same procedures but apply those procedures
> to data encoded in two radically different forms.  Neither one runs
> over the other.  A node that implements both would be a gateway
> between the two.

I think the above is just another way to describe CLs. (And yes, I
do know that not everyone will agree with that:-)

S.

> 
> Does that solve everybody's problems?  (Aside from which one gets to
> be called "Bundle Protocol" and what do we call the other one?)
> 
> [[email-masked]] Sent: Wednesday, August 19, 2015 5:29 AM

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Thu, 20 Aug 2015 13:07:58 +0000

What I mean by mapping/unmapping is what you were writing about on Wednesday:

"RFC4838 has the concept of a convergence layer. [1] So
using something web friendly for the 90% and something
mappable to/from that (e.g. map from JSON to CBOR) for
the 10% would seem entirely sensible to me."

And of course you are free to use the term "CL" to mean anything you like.  By using it in a way that is very different from its usage in the DTNRG RFCs I think you are innovating without communicating.  However, if the last sentence of your post means we agree that what I described is what you advocate, then maybe we have reached a sort of convergence.

Scott
________________________________________
From: Stephen Farrell [[email-masked]]
Sent: Thursday, August 20, 2015 2:48 AM
To: Burleigh, Scott C (312B); I-Viswanathan, Kapaleeswaran; [email-masked]
Subject: Re: [dtn] CBAR

S.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 20 Aug 2015 14:18:50 +0100

On 20/08/15 14:07, Burleigh, Scott C (312B) wrote:
> "RFC4838 has the concept of a convergence layer. [1] So using
> something web friendly for the 90% and something mappable to/from
> that (e.g. map from JSON to CBOR) for the 10% would seem entirely
> sensible to me."
> 
> And of course you are free to use the term "CL" to mean anything you
> like.  By using it in a way that is very different from its usage in
> the DTNRG RFCs I think you are innovating without communicating.

Yeah, maybe that's fair.

I think so long as all of the various CL-specific representations of
a bundle can be mapped to any of the others (*) then we're fine without
a canonical wire format encoding of the bundle. That is a bit but not
that much different from RFC5050.

(*) One could discuss whether or not CL-specific extensions should
be allowed. I'm unsure myself, but would maybe allow 'em so long as
they're defined so as to be ok if they get dropped at some DTN node
on the path.

> However, if the last sentence of your post means we agree that what I
> described is what you advocate, then maybe we have reached a sort of
> convergence.

I'm not sure - I still think what I'm advocating is just fine but
I dunno if you agree with that.

(That said, in all of this it would be reasonable for the WG to
decide to not want to make such big changes, what I'm saying is
if the WG does make that big a change, and the WG should, then
the world will be better in the ways we've discussed.)

S.

> [[email-masked]] Sent: Thursday, August 20, 2015 2:48 AM 
>> overhead I was complaining about, making the processing suitable
>> for resource-constrained nodes?  In order for this to be true, "not
>> to mess with the encoding" would mean no mapping/unmapping,
>> correct?
> 
> environment some decoding of the inbound bundle is needed to check if
> this node is a destination (or in the dest endpoint if we want to be
> pedantic) and its very likely that that decoding would also suffice
> to handle forwarding/routing decisions.
> 
> extension block values, and certainly no need to re-encode the entire
> bundle. (In any case, the BPA code will deal with some local data
> structures that contain more than just what's decoded from the
> received bundle.)
> 
>> In which case, the protocol procedures have to operate natively on
>> the binary-encoded data, correct?  In order to do so, there would
>> have to be an implementation of the protocol that enacts all of
>> the protocol's procedures without ever receiving any protocol
>> traffic data in the text-only format, right?  That implementation
>> would have to adhere to a specification in order to be
>> standard-compliant, right?  In which case, that specification would
>> define exactly the thing that we've been calling the Bundle
>> Protocol.
>> 
>> So now we are talking about two distinct over-the-wire protocols
>> that (possibly) encompass the same procedures but apply those
>> procedures to data encoded in two radically different forms.
>> Neither one runs over the other.  A node that implements both would
>> be a gateway between the two.
> 
> I think the above is just another way to describe CLs. (And yes, I do
> know that not everyone will agree with that:-)
> 
> S.
> 
>> 
>> Does that solve everybody's problems?  (Aside from which one gets
>> to be called "Bundle Protocol" and what do we call the other one?)
>> 
>> 2015 5:29 AM To: Burleigh, Scott C (312B); I-Viswanathan,
>>> If the definition of BP protocol traffic is all based on text
>>> and it only becomes binary at the convergence layer, then
>>> everything gets mapped to binary every time it is transmitted
>>> over a constrained link and unmapped as soon as it is received,
>>> at every node.  If the entire network is constrained nodes, then
>>> it happens at every single node, on every hop, for every bundle
>>> transmitted from every node to every other node.  All wasted.
>> 
>> entire service cause a difference. For me, it's just fine if a
>> node that knows it'll (possibly or certainly) use the same CL on
>> ingress and egress decides to not mess with the encoding. For you,
>> I guess you want the exact same treatment to happen internally
>> regardless of which CLs are available, which I agree could lead to
>> waste. (But it'd not have to either if one is smart about it.)
>> 
>> Cheers, S.
>> 
>>> 
>>> If the mapping/unmapping happens at the layer above BP, then
>>> it's done at the ends, where the applications live who want it.
>>> 
>>> the first one to start using the CL that works for the 10%. I
>>> don't see any problems doing so and I do think that allocates

---

From: <[email-masked]>
Date: Thu, 20 Aug 2015 13:24:12 +0000

Stephen

it's not about webservers or middleboxes in the middlebox sense. it never was. there are no middleboxes or proxies, just peers.

head of line blocking is really not a significant problem in this use case. the binary headers of http 2.0 and the complexities of QUIC are actually disadvantages. Premature optimization is the root of all evil, as they say, and jumping on new shiny things because they're new and shiny is not useful. http took over the planet because of its simplicity.

We looked at putting the bundle protocol over http, and didn't see the point - http headers are simply more flexible than an obscure binary format with custom number format (sdnv) and a not-very-useful dictionary. http headers make the primary block redundant, no matter what its format.

Lloyd Wood
http://http-dtn.sf.net
________________________________________
From: Stephen Farrell <[email-masked]>
Sent: Thursday, 20 August 2015 7:38:08 PM
To: Wood L  Dr (Elec Electronic Eng); [email-masked]; [email-masked]; [email-masked]
Subject: Re: [dtn] CBAR

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 20 Aug 2015 14:48:32 +0100

On 20/08/15 14:24, [email-masked] wrote:
> Stephen
> 
> it's not about webservers or middleboxes in the middlebox sense. it
> never was. there are no middleboxes or proxies, just peers.

Well, I don't think one can ignore the existence of all deployed
HTTP middleboxen. There are enough of those that the web folks
concluded they couldn't effectively upgrade HTTP in-line on port
80 but needed to use 443 not for security but to avoid the problems
with middleboxes (including transparent HTTP proxies) that muck
with traffic or insist on a certain subset of HTTP/1.1.

If one could ignore deployed middleboxen, then yes, you'd be
correct I think.

> 
> head of line blocking is really not a significant problem in this use
> case. the binary headers of http 2.0 and the complexities of QUIC are
> actually disadvantages. Premature optimization is the root of all
> evil, as they say, and jumping on new shiny things because they're
> new and shiny is not useful. http took over the planet because of its
> simplicity.

Maybe.

> We looked at putting the bundle protocol over http, and didn't see
> the point - http headers are simply more flexible than an obscure
> binary format with custom number format (sdnv) and a not-very-useful
> dictionary. 

I agree with the above.

> http headers make the primary block redundant, no matter
> what its format.

I don't agree there. I think the trade-offs between an HTTP header
based approach and a JSON form/body part would favour the latter.

S.

> 
> Lloyd Wood http://http-dtn.sf.net 
> ________________________________________ From: Stephen Farrell
> <[email-masked]> Sent: Thursday, 20 August 2015 7:38:08
> PM To: Wood L  Dr (Elec Electronic Eng);
> [email-masked]; [email-masked];
> possible approach, and I think one you suggested quite a while back.
> I wasn't so keen on that then (it arguably requires some updated
> middleboxes and mods to apache/nginx) but I certainly agree that with
> HTTP/2.0, that idea is well worth another look. HTTP/2.0 gets rid of
> the head-of-line blocking from which HTTP/1.1 suffered and HTTP/2.0
> supports binary and compressed headers. And QUIC will mean that
> there's a "native" connectionless transport for that too.
> 
> On balance I think I'd still end up preferring putting the BP primary
> block stuff in a a JSON body-part in the HTTP request and response
> payload, but I'd fully agree that one ought look afresh at the
> current HTTP infrastructure and see if that ends up being better.
> 
> Cheers, S.
> 
>> 
>> <[email-masked]> Sent: Wednesday, 19 August 2015 10:29
>> PM To: Burleigh, Scott C (312B); I-Viswanathan, Kapaleeswaran; 
>> care about constrained environment use-cases. I do. I just also
>> care about other things as well:-)
>>

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 20 Aug 2015 21:21:49 +0000

I must be missing something. One of the key requirements of an encoding scheme
for BP is compact representation of data over the network. I can see clearly how
that is accomplished for CBOR, but I am struggling to understand how JSON would
meet that need. What am I missing?

Thanks - Fred
[email-masked]

---

From: <[email-masked]>
Date: Thu, 20 Aug 2015 21:36:13 +0000

google "binary json"

the need for a binary json has long been recognised, with many approaches to satisfy high demand.

Lloyd Wood
http://http-dtn.sf.net
________________________________________
From: dtn <[email-masked]> on behalf of Templin, Fred L <[email-masked]>
Sent: Friday, 21 August 2015 7:21:49 AM
To: [email-masked]
Subject: Re: [dtn] CBAR

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 20 Aug 2015 21:43:31 +0000

OK, but what I am interested in is efficiency over the network and lightweight
processing overhead. I can see clearly from the spec that these are fundamental
design principles of CBOR. Has anyone done a side by side comparison of CBOR
and JSON in terms of networking and processing efficiency?

Thanks - Fred

> Sent: Thursday, August 20, 2015 2:36 PM
> To: Templin, Fred L; [email-masked]
> Subject: Re: [dtn] CBAR
> 
> google "binary json"
>

---

From: <[email-masked]>
Date: Thu, 20 Aug 2015 21:56:18 +0000

Stephen,

did you ever read the important key bit, stressed in the http-dtn spec and papers about how unfamiliar Content-* headers are rejected by webservers and proxies, per section 9.6 of RFC2616, and http-dtn can be deliberately entirely separate from the existing web and deployed middleboxes as a result? Thus making middlebox mangling of http-dtn (as opposed to http-dtn peer forwarding) a none-problem? And web folk a none-problem, because this is not the web, and is not used where the web is used?

it's only the key insight of the design. and having that insight makes me correct about middleboxes.

Lloyd Wood
http://http-dtn.sf.net
________________________________________
From: Stephen Farrell <[email-masked]>
Sent: Thursday, 20 August 2015 11:48:32 PM
To: Wood L  Dr (Elec Electronic Eng); [email-masked]; [email-masked]; [email-masked]
Subject: Re: [dtn] CBAR

Maybe.

I agree with the above.

S.

---

From: <[email-masked]>
Date: Sat, 22 Aug 2015 05:19:33 +0000

https://github.com/BurntSushi/rust-cbor

scroll down to benchmarks.

Seriously, this google search engine thing is quite good. You really should try it.

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: Templin, Fred L <[email-masked]>
Sent: Friday, 21 August 2015 7:43 AM
To: Wood L  Dr (Elec Electronic Eng); [email-masked]
Subject: RE: [dtn] CBAR

Thanks - Fred

---

From: Eric Travis <[email-masked]>
Date: Sat, 22 Aug 2015 01:58:29 -0400

But it is *so* much easier to employ a mechanical turk;  Not only are the search
results intelligently filtered for you, but they are also disseminated
to all interested
parties.  Most importantly, in some cases you just can't beat the price.

Thanks for sharing!  It's always interesting to read someone else's Rust code.

----

The Internet is truly a magical place - idle wishes freely granted.

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Sun, 23 Aug 2015 23:17:41 +0000

Okay, trying to sum up:

The Bundle Protocol procedures include those procedures that apply to bundle sources, those that apply to bundle destinations, and those that apply to nodes that relay bundles.  These sets of procedures are not disjoint, and in each case some of the applicable procedures are mandatory and some are optional.  One could organize the BP specification along these lines so that, for example, a BP node that enacts only the mandatory procedures for a bundle source could be very simple while remaining completely compliant.

Given this, we contemplate that the production and consumption of bundles over the Internet might be undertaken natively by lots of code bases beyond the small number of DTN stack implementations that function as (and may be delivered as) operating system extensions (libraries, jarfiles, whatever) - "services".  This would be advantageous.

But it won't happen if bundle production and consumption require that all developers write complicated code that composes and parses bundles.  So bundle structure needs to be defined in such a way that bundles can be easily composed and parsed using something like JSON.

However, data interchange systems like JSON that encode data in human-readable text are unsuitable for the resource-constrained environments that characterize many of the use cases that the DTN WG must support.  For those environments, data must be encoded in binary representation for efficiency in transmission and processing.

So maybe the resolution here is to simply to define the BP protocol data items in terms of function and nature rather than in terms of representation.  Supplementary RFCs would define the encoding of those data items in JSON representation, in CBOR representation, and potentially in any number of other data interchange schemes.  Obviously nodes would have to agree on a data representation in order to exchange bundles, but initially we can just do this by management; a protocol can be developed later.

Note that these different bundle encoding representations would not be different "convergence layer" protocols in the sense in which the term is used in RFC 4838.  Convergence layer adapters "manage the protocol-specific details of interfacing with particular underlying protocols and present a consistent interface to the bundle layer."  This is important because we will want to operate within the cross-product of bundle encoding representations and underlying protocols: e.g., both JSON-encoded and CBOR-encoded bundles may need to be forwarded over UDP/IP to support different use cases, and CBOR-encoded bundles may need to be forwarded over both UDP/IP and AX.25 to support others.

And it must *not* be necessary to translate to and from one encoding representation at each forwarding node of an end-to-end path.  There may be end-to-end paths such that the bundle encoding representation is different on different path segments, but the translation of encoding representations is required only at the boundaries between these different path segments; it's a gateway function rather than a layering function.

Does that work for everybody?

Scott

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Thursday, August 20, 2015 6:19 AM
To: Burleigh, Scott C (312B); [email-masked]
Subject: Re: [dtn] CBAR

On 20/08/15 14:07, Burleigh, Scott C (312B) wrote:
> something web friendly for the 90% and something mappable to/from that 
> (e.g. map from JSON to CBOR) for the 10% would seem entirely sensible 
> to me."
> 

Yeah, maybe that's fair.

I think so long as all of the various CL-specific representations of a bundle can be mapped to any of the others (*) then we're fine without a canonical wire format encoding of the bundle. That is a bit but not that much different from RFC5050.

(*) One could discuss whether or not CL-specific extensions should be allowed. I'm unsure myself, but would maybe allow 'em so long as they're defined so as to be ok if they get dropped at some DTN node on the path.

> described is what you advocate, then maybe we have reached a sort of 

I'm not sure - I still think what I'm advocating is just fine but I dunno if you agree with that.

(That said, in all of this it would be reasonable for the WG to decide to not want to make such big changes, what I'm saying is if the WG does make that big a change, and the WG should, then the world will be better in the ways we've discussed.)

S.

> pedantic) and its very likely that that decoding would also suffice to 
> handle forwarding/routing decisions.
> 
>> have to be an implementation of the protocol that enacts all of the 
>> to data encoded in two radically different forms.
>> [[email-masked]] Sent: Wednesday, August 19,
>>> If the definition of BP protocol traffic is all based on text and it 
>>> only becomes binary at the convergence layer, then everything gets 
>>> mapped to binary every time it is transmitted over a constrained 
>>> link and unmapped as soon as it is received, at every node.  If the 
>>> entire network is constrained nodes, then it happens at every single 
>>> node, on every hop, for every bundle transmitted from every node to 
>>> every other node.  All wasted.
>> 
>>> [[email-masked]] Sent: Wednesday, August 19,

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 24 Aug 2015 01:29:52 +0100

Good summary. If this WG takes that road, I'll be keen to help. (Which
could be seen as a positive or a negative:-)

S.

---

From: <[email-masked]>
Date: Mon, 24 Aug 2015 08:16:05 +0000

Good to see that the new 'simplified' bundle protocol is going to be even more complex than the old one, thus ensuring a long-drawn out design and development process.

Lloyd Wood
http://sat-net.com/L.Wood
________________________________________
From: dtn <[email-masked]> on behalf of Burleigh, Scott C (312B) <[email-masked]>
Sent: Monday, 24 August 2015 9:17 AM
To: [email-masked]
Subject: Re: [dtn] CBAR

Okay, trying to sum up:

Scott

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]]
Sent: Thursday, August 20, 2015 6:19 AM
To: Burleigh, Scott C (312B); [email-masked]
Subject: Re: [dtn] CBAR

Yeah, maybe that's fair.

S.

---

From: "I-Viswanathan, Kapaleeswaran" <[email-masked]>
Date: Mon, 24 Aug 2015 09:40:38 +0000

Hi Fred

I believe that the (2015) document at the following URL must be of interest for your question and this discussion. I believe that this document may be more scholarly than blogs and therefore can be referenced because are more likely to contained reviewed and peer-reviewed content.

https://wiki.nps.edu/display/NOW/2015/06/12/EVALUATION+OF+EFFICIENT+XML+INTERCHANGE+(EXI)+FOR+LARGE+DATASETS+AND+AS+AN+ALTERNATIVE+TO+BINARY+JSON+ENCODINGS

In particular, you are interested in the following plot in the thesis in Page 82 of 136. The question it tries to answer is: “Does post-compression with conventional algorithms increase the compactness of BSON or CBOR?”

The following IEEE document may be useful to understand the relative merits of marshalling (serialization) routines. It does not include CBOR as it was published in 2011. Nevertheless it is useful to understand a structured framework to understand the relative merits of marshalling routines.

http://dx.doi.org/10.1109/SERVICES.2011.61

The following is a line from its conclusion: "If standardization

does not play any major role in the solution and human

readability is not needed, Google offers a good choice as

regards the format but also considering the available JAXB

standard API."

Best regards

Kapali

-----Original Message-----
From: Eric Travis [mailto:[email-masked]]
Sent: Saturday, August 22, 2015 11:28 AM
To: [email-masked]
Cc: Templin, Fred L; [email-masked]
Subject: Re: [dtn] CBAR

But it is *so* much easier to employ a mechanical turk;  Not only are the search results intelligently filtered for you, but they are also disseminated to all interested parties.  Most importantly, in some cases you just can't beat the price.

----

> Seriously, this google search engine thing is quite good. You really

> should try it.

> From: Templin, Fred L <[email-masked]<mailto:[email-masked]>>

> To: Wood L  Dr (Elec Electronic Eng); [email-masked]<mailto:[email-masked]>

> OK, but what I am interested in is efficiency over the network and

> lightweight processing overhead. I can see clearly from the spec that

> these are fundamental design principles of CBOR. Has anyone done a

> side by side comparison of CBOR and JSON in terms of networking and

> processing efficiency?

> [email-masked]<mailto:[email-masked]>

>> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]

>> To: Templin, Fred L; [email-masked]<mailto:[email-masked]>

>> the need for a binary json has long been recognised, with many

>> approaches to satisfy high demand.

>> From: dtn <[email-masked]<mailto:[email-masked]>> on behalf of Templin, Fred L

>> <[email-masked]<mailto:[email-masked]>>

>> To: [email-masked]<mailto:[email-masked]>

>> I must be missing something. One of the key requirements of an

>> encoding scheme for BP is compact representation of data over the

>> network. I can see clearly how that is accomplished for CBOR, but I

>> am struggling to understand how JSON would meet that need. What am I

>> missing?

>> [email-masked]<mailto:[email-masked]>

>> [email-masked]<mailto:[email-masked]>

> [email-masked]<mailto:[email-masked]>

---

From: "I-Viswanathan, Kapaleeswaran" <[email-masked]>
Date: Mon, 24 Aug 2015 09:52:38 +0000

>> > The Bundle Protocol procedures include those procedures that apply to bundle sources, those that apply to bundle destinations, and those that apply to nodes that relay bundles.  These sets of procedures are not disjoint, and in each case some of the applicable procedures are mandatory and some are optional.  

- This is a good idea for efficiency improvements on the routers. All routers need not be expected to unmarshall the entire bundle but unmarshall only those parts of the bundle that are needed to perform its routing function as per its policy.  

>>But it won't happen if bundle production and consumption require that all developers write complicated code that composes and parses bundles.  So bundle structure needs to be defined in such a way…

- Marshalling and unmarshalling JSON is user friendly only because programmers never do the same. They use tried and tested JSON APIs. This true even for XML and every data serialization technique including Java Serialization API, which is specific and proprietary to Java. Therefore, we must not assume that JSON is more user-friendly than any other representation as it is a false assumption.

>>> However, data interchange systems like JSON that encode data in human-readable text are unsuitable for the resource-constrained environments that characterize many of the use cases that the DTN W…

- There is a growing realization even in the world of terrestrial Web Services, that the use of JSON machine-to-machine communications is an overhead.

>>> .....Obviously nodes would have to agree on a data representation in order to exchange bundles, but initially we can just do this by management; a protocol can be developed later.

- The Bundle Protocol specification will have to specify a data marshalling and serialization routine for the following reason. 
1. Even if two nodes were to negotiate (or agree) on a data representation before exchanging bundles, such negotiation protocol will need to have a data representation specified. So, we may rather specify the same right away. 
2. The prospective negotiation algorithm is an overhead even if it can be designed to be delay-and-disruption tolerant.  

Best regards
Kapali 

-----Original Message-----
On 24/08/15 00:17, Burleigh, Scott C (312B) wrote:
> (That said, in all of this it would be reasonable for the WG to decide 
> to not want to make such big changes, what I'm saying is if the WG 
> does make that big a change, and the WG should, then the world will be 
> better in the ways we've discussed.)
> 
> S.
> 
> 
>>
>>> that
>>> which CLs are available, which I agree could lead to waste. (But 
>>> it'd not have to either if one is smart about it.)
>>>
>>> Cheers, S.
>>>
>>>>

---

From: Rick Taylor <[email-masked]>
Date: Mon, 24 Aug 2015 10:13:18 +0000

Great summary Scott,

This is where I was heading with my 'how the hell is this all going to 
plug together?' musings.  Aiming the output of the DTN-WG towards a 
gateway specification, i.e. how does one move bundles from one DTN 
system to another, along with a set of common requirements for a bundle 
will go a very a long way to global standardized DTN inter-operation.

There is a parallel here with how the IETF defined SMTP (how might one 
move email around the Internet), POP3 (how might an client application 
get email from a Mail Agent) and RFC2822 (What is expected in an email 
message).

Rather than the IETF trying to specify the 'One DTN to Rule them All', 
and never satisfying anyone completely; designing the protocols to allow 
mission-specific DTNs to interoperate at gateways seems the most 
pragmatic and feasible approach.

The reality of all IETF work is that we have day-jobs, and despite some 
of our daily work being DTN related, we have to target our limited 
cycles at achievable goals.  That being said, if the WG goes in this 
direction, I'm in.

Rick

---

From: Rick Taylor <[email-masked]>
Date: Mon, 24 Aug 2015 10:19:24 +0000

Lloyd,

I think that is a misreading of Scott's points.  I believe his 
suggestion is too look at standardizing the interoperation of DTN 
islands, rather than attempt a grand unifying protocol.  This would 
allow CCSDS and friends to continue to use a 5050-bis but allow other 
communities to use what is appropriate for them, and only align at the 
gateway.

But I might be the one misreading...

Rick

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Mon, 24 Aug 2015 16:50:46 +0000

Rick, I think a lot depends on exactly what we mean when we say "protocol".  My suggestion was for something that's not quite as loose as the email ecosystem but that still can encompass a wide range of types of participants.  That is:

-	The BP spec would define some procedures (some mandatory, some optional) that would be executed (somehow) by anything that sends a bundle, including the bundle's original source.  The output from those procedures would be a "bundle" that (a) is encoded in some supported representation and (b) is transmitted via some supported convergence-layer protocol.

-	The BP spec would define some procedures (some mandatory, some optional) that would be executed (somehow) by anything that receives a bundle, including the bundle's final destination.  The input to those procedures would be a bundle that (a) is encoded in some supported representation and (b) is received via some supported convergence-layer protocol.

-	A BP node that is functioning as a relay point along an end-to-end path would execute the bundle reception procedures, select the next node(s) to forward to, and then execute the bundle sending procedures.  If the representation on output is different from the representation on input, then the relay node is functioning as a translation gateway.  If the representation on output is the same as the representation on input, but the CL protocol on output is different from the CL protocol on input, then the relay node is functioning as an infrastructure gateway.  If both the representation and CL protocol on output are the same as on input, then the relay node is just functioning as a router.  But if we define the procedures and data items clearly enough, the BP spec itself doesn't have to address these variations (or any of various other alternatives) at all.

That is, a bundle would still contain the same information regardless of representation.  Some bundle nodes might function only as extremely simple bundle sources; others might be very elaborate forwarders.  But they would all still interoperate without data loss.

Does that align with your reading?

Scott

-----Original Message-----
From: Rick Taylor [mailto:[email-masked]] 
Sent: Monday, August 24, 2015 3:19 AM
To: [email-masked]; Burleigh, Scott C (312B) <[email-masked]>; [email-masked]
Subject: Re: [dtn] CBAR

Lloyd,

I think that is a misreading of Scott's points.  I believe his suggestion is too look at standardizing the interoperation of DTN islands, rather than attempt a grand unifying protocol.  This would allow CCSDS and friends to continue to use a 5050-bis but allow other communities to use what is appropriate for them, and only align at the gateway.

Rick

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Mon, 24 Aug 2015 17:37:10 +0000

Kapali, a couple of remarks in-line (-->) below.

Scott

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of I-Viswanathan, Kapaleeswaran
Sent: Monday, August 24, 2015 2:53 AM
To: [email-masked]
Subject: Re: [dtn] CBAR

-->	The intent of what I wrote here is that it's unnecessary for us to argue over what the best representation is: JSON, CBOR, cuneiform, I don't care.  Let developers use what works for them, and let the network operators decide which variations they're willing to support; winning and losing alternatives will sort themselves out.

-->	No argument from me; I suspect that over time the binary representations will be adopted more widely than expected.  But at this point there's no need for us to guess, and possibly guess wrong.

-->	That's why I said "initially we can just do this by management", which is delay-tolerant.  Data representation agreement is in this sense exactly analogous to convergence-layer protocol agreement, and I expect that like CL configuration it would eventually be encompassed by the DTN network management protocol.  We didn't need to specify a canonical CL in the BP spec, and I think we similarly don't need to specify a canonical on-the-wire representation, so long as the nature and function of each protocol data item and the functional details of each procedure are clearly defined.

Best regards
Kapali

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 24 Aug 2015 21:29:22 +0100

On 24/08/15 10:52, I-Viswanathan, Kapaleeswaran wrote:
> - Marshalling and unmarshalling JSON is user friendly only because
> programmers never do the same. They use tried and tested JSON APIs.

User friendly is not the right term here. Developer-friendly perhaps.

But that also misses an important point. There have been a huge number
of CVEs over the years relating to codecs like these and the more that
one re-uses a widely tested library, the better off one is. Custom
codecs and options that are rarely used in standard codecs (e.g.
extension fields with odd uses) are significant sources of bugs.

> This true even for XML 

Simpler is also way better though and XML is not simple, compared to
JSON or CBOR. (E.g. I had a student find a buffer overrun in a very
popular XML decoder in the schemaLocation attribute value - things
like that are an inherent consequence of the complexity of the
codec.

While nothing in this space is perfect, and today's fashion will be
old hat in a few years, there are some good choices that can be
made at any point in time. Today, for DTN, I'd strongly argue that
JSON or CBOR are the best answers. But as Scott says that can change
over time and vary between environments as long as we maintain the
ability to translate at gateways.

It also strikes me that gatewaying to/from 5050 was I think always
one of the baseline goals for 5050bis, so this new direction is
actually very consistent with that, albeit perhaps in an unexpected
way.

S.

---

From: "I-Viswanathan, Kapaleeswaran" <[email-masked]>
Date: Tue, 25 Aug 2015 06:50:24 +0000

Hi Scott

I understand your viewpoint as follows. 
1. Various applications of DTN may prefer different bundle serialization formats. 
2. A market including DTN Developers and DTN Network operators shall decide the preferred bundle serialization format.
3. For interoperability purposes: (a) standard shall only say what bundle networking information needs to be present in a bundle -- it will not say how it shall be represented; (b) standard shall specify a special DTN Router (function?) that shall convert bundle from one format into another depending on the needs/natures of the DTN networks that it interconnects. 

I feel that such a viewpoint could have value for the DTN standardization process. 

PS: Email has one format conversion approach. XMPP has another. It appears that we are look at the approach taken by the Email community.

Best regards
Kapali 

-----Original Message-----
From: Burleigh, Scott C (312B) [mailto:[email-masked]] 
Sent: Monday, August 24, 2015 11:07 PM
To: [email-masked]
Subject: Re: [dtn] CBAR

Scott

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of I-Viswanathan, Kapaleeswaran
Sent: Monday, August 24, 2015 2:53 AM
To: [email-masked]
Subject: Re: [dtn] CBAR

Best regards
Kapali

---

From: "I-Viswanathan, Kapaleeswaran" <[email-masked]>
Date: Tue, 25 Aug 2015 06:59:58 +0000

Hi Stephen

1. I agree with you that simple algorithms for marshalling and unmarshalling serialized data will be more understandable and result in fewer bugs (security or otherwise). Just like the codec world, the intrusion detection community has also seen  the use of well-and-maliciously-formed IP Packets for evading intrusion detection systems and injecting viruses into various networks. A simple and secure serialization format is a formidable challenge. 

2.  Translation gateways for converting one format into another so as to interconnect DTNs using different serialization formats is a good approach. The DTN operator may need to design her/his network with an appropriate data serialization format and proper translation gateways whenever DTN interconnection is required. It would be useful to understand the requirements for such translation gateways so that DTN network-design and management can be kept easy and simple. 

Best regards
Kapali  

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Tuesday, August 25, 2015 1:59 AM
To: I-Viswanathan, Kapaleeswaran; [email-masked]
Subject: Re: [dtn] CBAR

But that also misses an important point. There have been a huge number of CVEs over the years relating to codecs like these and the more that one re-uses a widely tested library, the better off one is. Custom codecs and options that are rarely used in standard codecs (e.g.
extension fields with odd uses) are significant sources of bugs.

> This true even for XML

Simpler is also way better though and XML is not simple, compared to JSON or CBOR. (E.g. I had a student find a buffer overrun in a very popular XML decoder in the schemaLocation attribute value - things like that are an inherent consequence of the complexity of the codec.

While nothing in this space is perfect, and today's fashion will be old hat in a few years, there are some good choices that can be made at any point in time. Today, for DTN, I'd strongly argue that JSON or CBOR are the best answers. But as Scott says that can change over time and vary between environments as long as we maintain the ability to translate at gateways.

It also strikes me that gatewaying to/from 5050 was I think always one of the baseline goals for 5050bis, so this new direction is actually very consistent with that, albeit perhaps in an unexpected way.

S.

---

From: Victor Ramiro-Cid <[email-masked]>
Date: Tue, 25 Aug 2015 09:33:38 +0200

Hi,

I’ve tried to follow the discussion, but I have some questions:

The serialisation we are discussing here is for the whole bundle? isn’t just the bundle's payload the only important information for the programer (so it can be coded/encoded in JSON or whatever format it suits him). But the whole bundle should be encoded in a binary representation that allows easy access to headers in order to take actions.

There is a trade-off between the idea to serialise bundles in order to gain efficiency and the need to take actions based on the bundle contents (hence serialise/deserialise over the path).

Doesn’t that mean that we should think in some extensible headers for the bundles (such as IPv6)? Those extended headers could be serialised in any format that suit the specific user (the one who actually will use the information)

Just a little lost with all the emails. Thanks for clarifying the questions.

Cheers,
— Victor

> On 25 Aug 2015, at 08:50, I-Viswanathan, Kapaleeswaran <[email-masked]> wrote:
> 
> Hi Scott
>

---

From: Rick Taylor <[email-masked]>
Date: Tue, 25 Aug 2015 08:55:30 +0000

Scott,

Yes, I am in total agreement.

In my opinion, the IETF DTN 'protocol' should be the 'set of procedures
for operation' rather than 'bit X means Y in packet Z at time T', i.e.
closer to definition 1.1 from the Oxford English Dictionary
(http://www.oxforddictionaries.com/definition/english/protocol): "The
accepted or established code of procedure or behaviour in any group,
organization, or situation", rather than definition 4: "A set of rules
governing the exchange or transmission of data between devices".

Like you, I would like to see a standard specification of the
responsibilities of a Bundle Processing Agent. As you said, how to send,
receive and forward bundles, including handling of processing
notifications, (non) delivery reporting, and custody transfer.

I would also like to see a specification of the minimum set of data
items to be included in a bundle, described in some format-neutral
manner, that are required by a Bundle Processing Agent to perform the
previously defined operations.

 From this, accompanying documents can define specific convergence layer
representations of this data, and the wire-protocol to be used to
perform the procedures defined above for each individual transport protocol.

In summary, I'm re-describing what you have just said!

Rick

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Tue, 25 Aug 2015 15:35:16 +0000

Hi, Victor.  Yes, the serialization we're discussing here applies to the whole bundle including the primary block and BP's IPv6-like extension blocks.  Different serialization systems will be more convenient for different user communities: bit-efficient binary representation is important for some use cases, while a more Web-friendly textual representation will work fine for others.  For any single bundle, all blocks of the bundle will be serialized using the same representation system.  Translation from one representation to another should be straightforward (when necessary), since the information conveyed in the blocks of the bundle is the same regardless of the representation.

Scott

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of Victor Ramiro-Cid
Sent: Tuesday, August 25, 2015 12:34 AM
To: I-Viswanathan, Kapaleeswaran <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn] CBAR

Hi,

Cheers,
— Victor

>>> However, if the last sentence of your post means we agree that what 
>>> I described is what you advocate, then maybe we have reached a sort 
>>> of convergence.
>> 
>> decide to not want to make such big changes, what I'm saying is if 
>> the WG does make that big a change, and the WG should, then the world 
>> will be better in the ways we've discussed.)
>> 
>> S.
>> 
>> 
>>> 
>>>> to mess with the encoding" would mean no mapping/unmapping, correct?
>>> 
>>> environment some decoding of the inbound bundle is needed to check 
>>> if this node is a destination (or in the dest endpoint if we want to 
>>> be
>>> entire bundle. (In any case, the BPA code will deal with some local 
>>> data structures that contain more than just what's decoded from the 
>>> received bundle.)
>>> 
>>>> data in the text-only format, right?  That implementation would 
>>>> have to adhere to a specification in order to be 
>>>> define exactly the thing that we've been calling the Bundle Protocol.
>>>> 
>>>> you want the exact same treatment to happen internally regardless 
>>>> of which CLs are available, which I agree could lead to waste. (But