Subject: [dtn] convergence layer over HTTP CL ?

From: Loiseau lucien <[email-masked]>
Date: Thu, 27 Aug 2020 15:32:59 +0800

Hi,

I was wondering if there was any documented or standardized effort to use
HTTP as the convergence layer for the bundle protocol ?

This is especially useful when a DTN node is hosted with a cloud provider
(such as AWS / GCP) for which front gateway are HTTP only.

Regards,
Lucien

--
Lucien Loiseau

---

From: Rick Taylor <[email-masked]>
Date: Thu, 27 Aug 2020 09:25:36 +0000

Hi Lucien,

Some time ago I started to draft an HTTP-CL, as I agree it is a really interesting concept.  However, I stalled due to lack of time and one issue that I failed to completely resolve to my satisfaction:

HTTP is a naturally request/response, client-server protocol.  A client asks for something, the server gives it.  A DTN CL usually facilitates the bi-directional transmission of bundles between agents.

So, my conclusion was that an HTTP CL would work very elegantly as a submission protocol, where an ‘edge‘ agent would pass bundles to a well-known upstream BPA, and collect any outstanding bundles waiting for it.  However, in the ‘transit’ network, between BPA agents acting as routers, it is less obvious how it would work well.

This doesn’t mean that an HTTP CL is a bad idea, and I would be happy to help flesh something out, but it does need a bit of careful thought.

Note: I am not referring to using BP to carry ‘web’ requests, but using HTTP to move bundles.

Cheers,

Rick

From: dtn [mailto:[email-masked]] On Behalf Of Loiseau lucien
Sent: 27 August 2020 08:33
To: [email-masked]
Subject: [dtn] convergence layer over HTTP CL ?

Hi,

I was wondering if there was any documented or standardized effort to use HTTP as the convergence layer for the bundle protocol ?

This is especially useful when a DTN node is hosted with a cloud provider (such as AWS / GCP) for which front gateway are HTTP only.

Regards,
Lucien

--
Lucien Loiseau

---

From: Loiseau lucien <[email-masked]>
Date: Thu, 27 Aug 2020 17:54:43 +0800

Hi Rick,

thanks for your answer, can you provide a link to your draft though I
reckon it must have expired already?

The use case I have falls exactly in the configuration you describe with an
edge node connecting to an upstream BPA for submission and collection.
In our case, the request/response paradigm fits nicely because the edge
nodes only have intermittent connectivity to the Internet and so bundle
moving
in/out needs to be initiated by the client.

For the Transit use case, I imagine that routing BPA agents would need to
perform an HTTP request as soon as the queue hits a threshold
(a threshold of 1 being one HTTP request per bundle) or a timeout (say
every 30 seconds) both could be configurable.

Maybe the draft could recommend to use HTTP-CL only for the upstream use
case ?

Otherwise an elegant solution would be to use WebSockets that would more
naturally work for both the upstream and transit use case since
it leaves open the possibility to keep the websocket connection open for an
extended period of time and allow for bidirectional transmission.

Regards,
Lucien

On Thu, Aug 27, 2020 at 5:25 PM Rick Taylor <[email-masked]>
wrote:

> Hi Lucien,
>
>
>
> Some time ago I started to draft an HTTP-CL, as I agree it is a really
> interesting concept.  However, I stalled due to lack of time and one issue
> that I failed to completely resolve to my satisfaction:
>
>
>
> HTTP is a naturally request/response, client-server protocol.  A client
> asks for something, the server gives it.  A DTN CL usually facilitates the
> bi-directional transmission of bundles between agents.
>
>
>
> So, my conclusion was that an HTTP CL would work very elegantly as a
> submission protocol, where an ‘edge‘ agent would pass bundles to a
> well-known upstream BPA, and collect any outstanding bundles waiting for
> it.  However, in the ‘transit’ network, between BPA agents acting as
> routers, it is less obvious how it would work well.
>
>
>
> This doesn’t mean that an HTTP CL is a bad idea, and I would be happy to
> help flesh something out, but it does need a bit of careful thought.
>
>
>
> *From:* dtn [mailto:[email-masked]] *On Behalf Of *Loiseau lucien
> *Sent:* 27 August 2020 08:33
> *To:* [email-masked]
> *Subject:* [dtn] convergence layer over HTTP CL ?
>
>
>
> Hi,
>
>
>

-- 
--
Lucien Loiseau

---

From: Mehmet Adalier <[email-masked]>
Date: Thu, 27 Aug 2020 08:52:07 -0700

Lucien, Rick,

In our approach to this particular use-case we utilized the Constrained Application Protocol (CoAP), per RFC 7252, which is designed to be a specialized web transfer protocol for use with constrained nodes and networks. CoAP is intended to be used in Machine 2 Machine environments as an optimized subset of Presentational State Transfer (REST) common with HTTP and can interface with the full HTTP for integration with the Web.

With CoAP, nodes may act both as client and servers, and change their roles as needed, which supprot many applications of DTN.

We wrote a new adaptation called CoAP-over-BP that removes hard bindings to UDP/DTLS. Our implementation, taraCoAP™ has been extensively tested with ION including SBSP/BPsec and includes several enhancements to the original CoAP spec.

We presented a paper at Aerospace Conference  (March 2020) describing taraCoAP and a case study as well as a previous paper at NAECON.

M. Adalier, A. Riffel, M. Galvan, B. Johnson, S. Burleigh, “Efficient and Secure Autonomous Communications for Deep Space Missions,” IEEE Aerospace Conference 2020, March 2020.
M. Adalier, S. Burleigh, “Cross-domain Autonomous Communication Protocol for DTN,” NAECON 2018, July 23, 2018.

Best

mehmet

From: dtn <[email-masked]> on behalf of Loiseau lucien <[email-masked]>
Date: Thursday, August 27, 2020 at 2:55 AM
To: Rick Taylor <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn] convergence layer over HTTP CL ?

Hi Rick,

thanks for your answer, can you provide a link to your draft though I reckon it must have expired already?

The use case I have falls exactly in the configuration you describe with an edge node connecting to an upstream BPA for submission and collection.

In our case, the request/response paradigm fits nicely because the edge nodes only have intermittent connectivity to the Internet and so bundle moving 

For the Transit use case, I imagine that routing BPA agents would need to perform an HTTP request as soon as the queue hits a threshold 

(a threshold of 1 being one HTTP request per bundle) or a timeout (say every 30 seconds) both could be configurable. 

Maybe the draft could recommend to use HTTP-CL only for the upstream use case ? 

Otherwise an elegant solution would be to use WebSockets that would more naturally work for both the upstream and transit use case since 

it leaves open the possibility to keep the websocket connection open for an extended period of time and allow for bidirectional transmission. 

Regards,

Lucien

On Thu, Aug 27, 2020 at 5:25 PM Rick Taylor <[email-masked]> wrote:

Hi Lucien,

Cheers,

Rick

Hi,

Regards,

Lucien

--
Lucien Loiseau

-- 

--
Lucien Loiseau

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

---

From: Rick Taylor <[email-masked]>
Date: Thu, 27 Aug 2020 16:33:50 +0000

Mehmet, Lucien,

Mehmet: Given the native CBOR encoding of BP, CoAP is a great candidate for a CL, as they have specifically addressed some of the directionality issues I started to forsee with an HTTP CL.

Lucien: I agree WebSockets makes it all much simpler, and it would be reasonable trivial to fork TCP-CL into a WebSockets-CL (if anyone fancies writing that draft I would certainly support it).

However, I am still a fan of an HTTP bundle submission protocol, I can see great uses for a simple Javascript implementation that pushes and pulls bundles from a remote HTTP server, suitable for embedding in browser/client-side code.  Where CoAP is such a good fit is that it is already natively CBOR, so my suggestion would be:  If we agree that HTTP is not really a good candidate transport for a bi-directional CL, and it’s advantages are as a submission protocol over the Internet (however briefly connected), and we assume we can round trip JSON (the de-facto data format of the web) to CBOR - Why not propose a bundle submission protocol that includes the relevant BP meta-data and payload formatted in mime-encapsulated JSON, and accessed via HTTP?

At that point I stopped typing as I realised I had to restart what I was proposing, so my HTTP-CL draft exists as boiler-plate and a set of ideas that were pointing the wrong way, still lurking on my laptop somewhere.

I’m interested in what others think?

Cheers,

Rick

From: Mehmet Adalier [mailto:[email-masked]]
Sent: 27 August 2020 16:52
To: Loiseau lucien; Rick Taylor
Cc: [email-masked]
Subject: Re: [dtn] convergence layer over HTTP CL ?

Lucien, Rick,

  1.  M. Adalier, A. Riffel, M. Galvan, B. Johnson, S. Burleigh, “Efficient and Secure Autonomous Communications for Deep Space Missions,” IEEE Aerospace Conference 2020, March 2020.
  2.  M. Adalier, S. Burleigh, “Cross-domain Autonomous Communication Protocol for DTN,” NAECON 2018, July 23, 2018.

Best
mehmet

Hi Rick,

Regards,
Lucien

On Thu, Aug 27, 2020 at 5:25 PM Rick Taylor <[email-masked]<mailto:[email-masked]>> wrote:
Hi Lucien,

Cheers,

Rick

From: dtn [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Loiseau lucien
Sent: 27 August 2020 08:33
To: [email-masked]<mailto:[email-masked]>
Subject: [dtn] convergence layer over HTTP CL ?

Hi,

Regards,
Lucien

--
Lucien Loiseau

---

From: [email-masked]
Date: Thu, 27 Aug 2020 21:49:08 +0000 (UTC)

We concluded that http could provide a lot of what the bundle protocol did for delay-tolerant networking, and came up with http-dtn.
http://http-dtn.sf.net/
https://tools.ietf.org/html/draft-wood-dtnrg-http-dtn-delivery-09 

Lloyd [email-masked]

On Thursday, August 27, 2020, 17:33, Loiseau lucien <[email-masked]> wrote:

Hi,
Regards,Lucien

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