Subject: [dtn-interest] Fwd: New Version Notification for draft-perreault-dtnrg-http-00.txt

From: Simon Perreault <[email-masked]>
Date: Wed, 22 Aug 2012 13:09:22 -0400

Dear delay-tolerant people,

We have (finally) written a new draft about transporting HTTP over BP. 
We would really appreciate comments.

Here's an ascii art teaser that should make it clear what this is about:

>  +--------+  +------------+                +-----------+  +------------+
>  | Sensor |--| Spacecraft |------<BP>------|  Mission  |--| Monitoring |
>  | (HTTP  |  +----+-------+                | operation |  |  station   |
>  | server)|       |HTTP/BP|                +-------+--+   |  (HTTP     |
>  +--------+       | proxy |                |HTTP/BP|      |  client)   |
>                   +-------+                | proxy |      +------------+
>                                            +-------+
>
>  |-----------IP-----------|                |------------IP-------------|
>
>
>
>  <-------------------------------------- GET /sensors/heartbeat HTTP/1.1
>                                          Host: sensor.example.net
>
>  HTTP/1.1 200 OK ------------------------------------------------------>
>  Content-Length: ...
>  Content-Type: text/html
>
>  ...
>
>                Figure 3: Use of HTTP over BP in a Space DTN

-------- Message original --------
Sujet: New Version Notification for draft-perreault-dtnrg-http-00.txt
Date : Wed, 22 Aug 2012 09:58:48 -0700
De : [email-masked]
Pour : [email-masked]

A new version of I-D, draft-perreault-dtnrg-http-00.txt
has been successfully submitted by Simon Perreault and posted to the
IETF repository.

Filename:	 draft-perreault-dtnrg-http
Revision:	 00
Title:		 HTTP over Bundle Protocol for Delay-Tolerant Networks (DTN)
Creation date:	 2012-08-22
WG ID:		 Individual Submission
Number of pages: 9
URL: 
http://www.ietf.org/internet-drafts/draft-perreault-dtnrg-http-00.txt
Status:          http://datatracker.ietf.org/doc/draft-perreault-dtnrg-http
Htmlized:        http://tools.ietf.org/html/draft-perreault-dtnrg-http-00

Abstract:
    This document defines how HTTP is transported over DTN using the
    Bundle Protocol.

The IETF Secretariat

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Thu, 23 Aug 2012 23:11:54 -0500

Simon,  
I don't think BP custody is related to reliability.  Rather, I think you have to use BSP with the reliability cypher suites.  
I may be mistaken, but  I believe custody just says "I received the bundle and will do my best to forward it."  
Custody doesn't mean "I received the bundle CORRECTLY". In the current set of RFCs, you need to use BSP to ensure reliability.
- Will

4.4.  Reliability

   HTTP depends on the transport protocol (traditionally TCP) to provide
   reliability.  Over BP, custody transfer SHOULD be used.

---

From: Vint Cerf <[email-masked]>
Date: Fri, 24 Aug 2012 06:45:08 -0400

is HTTP 1.1 likely to work properly if:

1. there are large delays
2. bundles may arrive out of order and have to be resequenced and possibly
re-transmitted

To what degree are their timeouts in HTTP?

v

On Wed, Aug 22, 2012 at 1:09 PM, Simon Perreault <
[email-masked]> wrote:

> We have (finally) written a new draft about transporting HTTP over BP. We
> would really appreciate comments.
>
>>  <-----------------------------**--------- GET /sensors/heartbeat
>> HTTP/1.1
>>                                          Host: sensor.example.net
>>
>>  HTTP/1.1 200 OK ------------------------------**
>> ------------------------>
>>  Content-Length: ...
>>  Content-Type: text/html
>>
>>  ...
>>
> Sujet: New Version Notification for draft-perreault-dtnrg-http-00.**txt
> A new version of I-D, draft-perreault-dtnrg-http-00.**txt
> URL: http://www.ietf.org/internet-**drafts/draft-perreault-dtnrg-**
> http-00.txt<http://www.ietf.org/internet-drafts/draft-perreault-dtnrg-http-00.txt>
> Status:          http://datatracker.ietf.org/**
> doc/draft-perreault-dtnrg-http<http://datatracker.ietf.org/doc/draft-perreault-dtnrg-http>
> Htmlized:        http://tools.ietf.org/html/**
> draft-perreault-dtnrg-http-00<http://tools.ietf.org/html/draft-perreault-dtnrg-http-00>
>
>
> Abstract:
> ______________________________**_________________
> dtn-interest mailing list
> [email-masked]
> https://www.irtf.org/mailman/**listinfo/dtn-interest<https://www.irtf.org/mailman/listinfo/dtn-interest>
>

---

From: Dan Brown <[email-masked]>
Date: Fri, 24 Aug 2012 11:25:47 +0000

My recollection of working with HTTP over high latency links (something like a 40 second round trip) is that timeouts were dictated at the application layer.  This was in 2005-06.  Setting the browser's timeout settings, was sufficient to make the system tolerant to large delays.  If I recall correctly, the server was stock Apache, but I had to find a browser that supported modifying the initial TCP connect timeout.

This is based on my own experience.  I don't know the answer with respect to the standards.

> -----Original Message-----
> From: [email-masked] [mailto:dtn-interest-
> [email-masked]] On Behalf Of Vint Cerf
> Sent: Friday, August 24, 2012 6:45 AM
> To: Simon Perreault
> Cc: [email-masked]
> Subject: Re: [dtn-interest] Fwd: New Version Notification for draft-
> perreault-dtnrg-http-00.txt
> 
> On Wed, Aug 22, 2012 at 1:09 PM, Simon Perreault
> <[email-masked]> wrote:
> 
> 
> 	We have (finally) written a new draft about transporting HTTP over
> BP. We would really appreciate comments.
> 
> 	URL: http://www.ietf.org/internet-drafts/draft-perreault-dtnrg-
> http-00.txt <http://www.ietf.org/internet-drafts/draft-perreault-dtnrg-
> http-00.txt>
> 	Status:          http://datatracker.ietf.org/doc/draft-perreault-dtnrg-
> http <http://datatracker.ietf.org/doc/draft-perreault-dtnrg-http>
> 	Htmlized:        http://tools.ietf.org/html/draft-perreault-dtnrg-http-
> 00 <http://tools.ietf.org/html/draft-perreault-dtnrg-http-00>
> 
> 
> 	Abstract:
> 	_______________________________________________
> 	https://www.irtf.org/mailman/listinfo/dtn-interest
> <https://www.irtf.org/mailman/listinfo/dtn-interest>
> 
>

---

From: Marc Blanchet <[email-masked]>
Date: Fri, 24 Aug 2012 07:35:08 -0400

A typical scenario has three HTTP "legs". For example,
1) onboard spacecraft HTTP over IP between a sensor/camera/... and an onboard IP-DTN gateway. This gateway implements an HTTP proxy.
2) DTN space network.
3) earth station that has DTN-IP gateway, implementing HTTP proxy and then relaying HTTP over IP.

The proxy architecture enables the capability of caching and re-assembly as needed, therefore, the timeouts are local to legs 1 and 3.  The proxy are in fact like web caches on the Internet today (but configured and managed with the DTN/BP environment in mind: i.e. you don't want the proxies to cache everything they see…).  

There is also a code point in this draft reserved for prefetching, therefore filling a "useful" content before its use by one of the local proxies/caches.

So in summary, it is http and the proxy/cache mechanism that is key.

hope it is more understandable.

Marc.

Le 2012-08-24 à 06:45, Vint Cerf a écrit :

> 2. bundles may arrive out of order and have to be resequenced and possibly re-transmitted
> 
> On Wed, Aug 22, 2012 at 1:09 PM, Simon Perreault <[email-masked]> wrote:
> We have (finally) written a new draft about transporting HTTP over BP. We would really appreciate comments.
> 
> URL: http://www.ietf.org/internet-drafts/draft-perreault-dtnrg-http-00.txt

---

From: Vint Cerf <[email-masked]>
Date: Fri, 24 Aug 2012 07:54:52 -0400

marc, the proxy helps a great deal since it isolates some of the timing and
confines it to local, potentially low-delay paths. thanks

v

On Fri, Aug 24, 2012 at 7:35 AM, Marc Blanchet <[email-masked]>wrote:

> 1) onboard spacecraft HTTP over IP between a sensor/camera/... and an
> onboard IP-DTN gateway. This gateway implements an HTTP proxy.
> 2) DTN space network.
> The proxy architecture enables the capability of caching and re-assembly
> as needed, therefore, the timeouts are local to legs 1 and 3.  The proxy
> are in fact like web caches on the Internet today (but configured and
> managed with the DTN/BP environment in mind: i.e. you don't want the
> proxies to cache everything they see…).
>
> There is also a code point in this draft reserved for prefetching,
> therefore filling a "useful" content before its use by one of the local
> proxies/caches.
>

---

From: Joerg Ott <[email-masked]>
Date: Fri, 24 Aug 2012 15:18:15 +0300

Right.  See below for an early proxy design (but we learned quite
a few lessons since)

http://www.netlab.tkk.fi/~jo/papers/2006-wnept-bundling-the-web.pdf

Jörg

On 24.08.2012 14:54, Vint Cerf wrote:
> marc, the proxy helps a great deal since it isolates some of the timing
> and confines it to local, potentially low-delay paths. thanks
>
> v
>
>
> On Fri, Aug 24, 2012 at 7:35 AM, Marc Blanchet
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     1) onboard spacecraft HTTP over IP between a sensor/camera/... and
>     an onboard IP-DTN gateway. This gateway implements an HTTP proxy.
>     2) DTN space network.
>     The proxy architecture enables the capability of caching and
>     re-assembly as needed, therefore, the timeouts are local to legs 1
>     and 3.  The proxy are in fact like web caches on the Internet today
>     (but configured and managed with the DTN/BP environment in mind:
>     i.e. you don't want the proxies to cache everything they see…).
>
>     therefore filling a "useful" content before its use by one of the
>     local proxies/caches.
>
>>     <[email-masked] <mailto:[email-masked]>>
>>     wrote:
>>
>>         We have (finally) written a new draft about transporting HTTP
>>         over BP. We would really appreciate comments.
>>
>>              <-----------------------------__--------- GET
>>             /sensors/heartbeat HTTP/1.1
>>                                                      Host:
>>             sensor.example.net <http://sensor.example.net/>
>>
>>              HTTP/1.1 200 OK
>>             ------------------------------__------------------------>
>>              Content-Length: ...
>>              Content-Type: text/html
>>
>>              ...
>>
>>         Sujet: New Version Notification for
>>         draft-perreault-dtnrg-http-00.__txt
>>         De : [email-masked] <mailto:[email-masked]>
>>         <mailto:[email-masked]>
>>
>>
>>         A new version of I-D, draft-perreault-dtnrg-http-00.__txt
>>         http://www.ietf.org/internet-__drafts/draft-perreault-dtnrg-__http-00.txt
>>         <http://www.ietf.org/internet-drafts/draft-perreault-dtnrg-http-00.txt>
>>         Status:
>>         http://datatracker.ietf.org/__doc/draft-perreault-dtnrg-http
>>         <http://datatracker.ietf.org/doc/draft-perreault-dtnrg-http>
>>         Htmlized:
>>         http://tools.ietf.org/html/__draft-perreault-dtnrg-http-00
>>         <http://tools.ietf.org/html/draft-perreault-dtnrg-http-00>
>>
>>
>>         Abstract:
>>         _________________________________________________
>>         [email-masked] <mailto:[email-masked]>
>>         https://www.irtf.org/mailman/__listinfo/dtn-interest
>>     [email-masked] <mailto:[email-masked]>

---

From: <[email-masked]>
Date: Fri, 24 Aug 2012 13:22:24 +0100

Timeouts are coded in the application or in the transport that HTTP uses; HTTP is traditionally heavily tied to TCP. Without these, HTTP will work fine provided that it has a streaming interface.

Using HTTP in DTNs is straightforward if it is decoupled from its existing applications and transports (which at the moment are pretty much TCP, a little SCTP), so that it becomes more of an independent (sub)layer in its own right. We wrote this up in:
http://tools.ietf.org/html/draft-wood-dtnrg-http-dtn-delivery-07
http://sat-net.com/L.Wood/dtn/http-dtn.html
but that requires some reimplementation and reengineering of existing stacks to get the clear layering and multiple transport support for http, which is a little more ambitious than just putting A into B.

We found that the existing HTTP proxy/cache model doesn't _quite_ work for DTNs; all 'proxy caches' have to be equivalent peers, and PUT becomes at least as important as GET for moving data around. That, for reliability, an HTTP-level check of Content-MD5: is useful for ensuring reliability that the transport can't guarantee - the bundle custody transfer mechanism is sorely lacking in this regard. And that the bundle protocol is not required.

The only reason I can see to put http over the bundle protocol is to give the bundle protocol MIME functionality, which is useful for application disambiguation. Otherwise, that exercise introduces a whole bunch of fragmentation headaches best avoided, and is as redundant as layering CFDP over the bundle protocol.

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

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Vint Cerf [[email-masked]]
Sent: 24 August 2012 11:45
To: Simon Perreault
Cc: [email-masked]
Subject: Re: [dtn-interest] Fwd: New Version Notification for   draft-perreault-dtnrg-http-00.txt

v

On Wed, Aug 22, 2012 at 1:09 PM, Simon Perreault <[email-masked]<mailto:[email-masked]>> wrote:
Dear delay-tolerant people,

 <-------------------------------------- GET /sensors/heartbeat HTTP/1.1
                                         Host: sensor.example.net<http://sensor.example.net>

 ...

-------- Message original --------
Sujet: New Version Notification for draft-perreault-dtnrg-http-00.txt
Date : Wed, 22 Aug 2012 09:58:48 -0700
De : [email-masked]<mailto:[email-masked]>
Pour : [email-masked]<mailto:[email-masked]>

Abstract:

The IETF Secretariat

_______________________________________________
dtn-interest mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/dtn-interest

---

From: John Zinky <[email-masked]>
Date: Fri, 24 Aug 2012 09:10:35 -0400

The Phish Bouncer DTN-HTTP proxy took a similar approach, where the HTTP protocols terminated on both ends with DTN in the middle.
Here we used one type of bundle to send requests for URLs and another to return the "Content" of a URL (one URL, one bundle)
Basically, the request was to update the local cache, and the remote would send back the content of that specific URL and prefetch all the URL references in the content (by actually running the page's javascript on the remote end using the users context from the request).

One problem is giving feed back to the user, if the local cache does not have the desired content.
Here we returned a "working-on-it" page that would periodically poll the local cache.
The working-on-it page also estimated when the actual page would arrive. 
Alternatively, an RSS feed could be setup for the page and the user informed of the page's arrival hours later.
RSS feeds could also be used as a hint for what content might be requested to help the prefetching.

http://www.computer.org/portal/web/csdl/doi/10.1109/MIC.2010.103

Over a DTN you do not get many round trips, so each round trip needs to send as much data as possible. 
So Web over DTN performance is really about the effectiveness of the caching algorithms.
I think all the old caching tricks may be superseded by html5 techniques.

---

From: Simon Perreault <[email-masked]>
Date: Fri, 24 Aug 2012 09:12:47 -0400

Le 2012-08-24 00:11, Ivancic, William D. (GRC-RHN0) a écrit :
> Custody doesn't mean "I received the bundle CORRECTLY".

We use the term "reliability" in the sense of e.g. "TCP provides 
reliability over an unreliable network". TCP does that with end-to-end 
ack and retransmit. BP does it semi hop-by-hop with custody.

I believe what you're referring to would better be described as 
"integrity", which indeed requires cryptography.

Does this clarify?

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Simon Perreault <[email-masked]>
Date: Fri, 24 Aug 2012 09:18:11 -0400

> My recollection of working with HTTP over high latency links (something like a 40 second round trip) is that timeouts were dictated at the application layer.  This was in 2005-06.  Setting the brow…

Right. HTTP itself does not have a built-in timeout. Browsers do have 
timeouts by default, which are usually configurable.

Note that browsers are far from being the only things that use HTTP...

Thanks,
Simon

---

From: <[email-masked]>
Date: Fri, 24 Aug 2012 14:27:02 +0100

Simon,

When you speak of reliability you mean assured delivery.

Reliability is protection against inadvertent corruption. It does not require crypto. An ethernet crc is not viewed as crypto. Neither is an ip checksum.

Integrity is protection against an attacker, and does require crypto.

RFC5050 provides neither reliability nor integrity, and the assured delivery is a bit hit or miss.

See five years of discussion on this mailing list for more on these topics.

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

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Simon Perreault [[email-masked]]
Sent: 24 August 2012 14:12
To: Ivancic, William D. (GRC-RHN0)
Cc: [email-masked]
Subject: Re: [dtn-interest] Fwd: New Version Notification for   draft-perreault-dtnrg-http-00.txt

Does this clarify?

Simon

---

From: Simon Perreault <[email-masked]>
Date: Fri, 24 Aug 2012 09:31:02 -0400

> One problem is giving feed back to the user, if the local cache does not have the desired content.

Right. That problem exists when you have human users with normal 
browsers. However it disappears in contexts where you don't have this 
expectation of immediate feedback. It is important to understand that 
HTTP itself does not have such limits intrinsically.

> I think all the old caching tricks may be superseded by html5 techniques.

Interesting!

Thanks,
Simon

---

From: Simon Perreault <[email-masked]>
Date: Fri, 24 Aug 2012 09:35:24 -0400

> Reliability is protection against inadvertent corruption. It does not require crypto. An ethernet crc is not viewed as crypto. Neither is an ip checksum.

Ah, I see. Yes, that's what I meant. I'll change the draft so that we 
say "assured delivery" instead of "reliability".

> See five years of discussion on this mailing list for more on these topics.

Right, I know of these discussions, thanks.

As for HTTP-over-BP, we definitely need assured delivery, not sure about 
reliability (probably?), and definitely not integrity (can be considered 
optional). Thoughts?

Thanks,
Simon

---

From: Simon Perreault <[email-masked]>
Date: Fri, 24 Aug 2012 09:42:50 -0400

> http://tools.ietf.org/html/draft-wood-dtnrg-http-dtn-delivery-07

This looks like BP over HTTP, not HTTP over BP. Right?

Thanks,
Simon

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Fri, 24 Aug 2012 08:50:55 -0500

> 
> As for HTTP-over-BP, we definitely need assured delivery, 

Simon,

I believe, in theory, that Custody Transfer does not necessarily provide hop-by-hop assured delivery.  I seem to recall that a BP-forwarding "Custody Accepting" agent ma y be multiple BP hops away from the BP-forwarding "Custody Requesting" agent with other BP-forwarding agents not accepting custody, but passing it on.  I think, in theory, this is the design concept.  I suspect, in practice, it has never been tested, and perhaps not implemented.

There is no document that states what is expected of a BP agent that I know off.  Most has been assumptions.  If you are not interoperating with other implementations you sort of know what those assumptions are.  For example, I think you may be assuming that the next hop BP agent will accept custody as the default operation. That may be the case for your implementation or perhaps all current implementations, but I don't believe this is specified or required.

- Will

---

From: <[email-masked]>
Date: Fri, 24 Aug 2012 15:27:34 +0100

HTTP-DTN does not use the bundle protocol. "Delay-tolerant network" should not automatically mean "bundle network".

If you're focusing on the throwaway comment at end about the possibility of  transporting bundles easily with a mimetype, you are missing the bigger picture. Read the paper and presentations.

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

________________________________________
From: Simon Perreault [[email-masked]]
Sent: 24 August 2012 14:42
To: Wood L  Dr (Electronic Eng)
Cc: [email-masked]; [email-masked]
Subject: Re: [dtn-interest] Fwd: New Version Notification for draft-perreault-dtnrg-http-00.txt

Thanks,
Simon

---

From: Simon Perreault <[email-masked]>
Date: Fri, 24 Aug 2012 10:34:04 -0400

Le 2012-08-24 09:50, Ivancic, William D. (GRC-RHN0) a écrit :
> I believe, in theory, that Custody Transfer does not necessarily
> provide hop-by-hop assured delivery.

Since there is no assurance that a node will accept custody, that is 
true. We should say custodian-by-custodian assured delivery. And it also 
depends on your routing metric being "good".

> There is no document that states what is expected of a BP agent that
> I know off.  Most has been assumptions.  If you are not
> interoperating with other implementations you sort of know what those
> assumptions are.  For example, I think you may be assuming that the
> next hop BP agent will accept custody as the default operation. That
> may be the case for your implementation or perhaps all current
> implementations, but I don't believe this is specified or required.

I'm having difficulty understanding your underlying point. I understand 
that in practice not all nodes will accept custody. That's allowed by 
the spec. But I fail to see the consequence on HTTP-over-BP. Should we 
mention that more custodians make a DTN network more reliable?

Thanks,
Simon

---

From: Simon Perreault <[email-masked]>
Date: Fri, 24 Aug 2012 10:36:58 -0400

> If you're focusing on the throwaway comment at end about the possibility of  transporting bundles easily with a mimetype, you are missing the bigger picture. Read the paper and presentations.

I have.

What we're proposing is very specific to BP. We're trying to define a 
standard protocol for transporting HTTP over BP. While other topic about 
HTTP and DTN are very interesting, I'm trying to focus on HTTP over BP.

Thanks,
Simon

---

From: <[email-masked]>
Date: Fri, 24 Aug 2012 16:07:14 +0100

Yes, that's exactly where we started - how to carry HTTP over BP, to fix BP's MIME problem, give access to HTTP-dependent APIs, etc.

Eventually, we realised that the BP got in the way of doing the job well, restricted htp streaming, had insoluble fragmentation problems, couldn't provide assured delivery, made for complex proxy translation and caching, and wasn't needed. And that led to HTTP-DTN.

In time, you may encounter the same problems. Good luck!

Lloyd Wood

Sent: 24 August 2012 15:36

I have.

Thanks,
Simon

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Fri, 24 Aug 2012 10:07:56 -0500

> depends on your routing metric being "good".

That would work.

> I'm having difficulty understanding your underlying point.

The only point I was trying to make is that there is no specified default operations for BP-forwarding agents.  So, one implementor may assume something that another implementor does not and it could result in unforeseen consequences.  For example, one implementation might continue to forward a bundle that it didn't take custody for.  A second my silently discard it.  I don't think either operation is explicitly specified.

> I understand 
> the spec. But I fail to see the consequence on HTTP-over-BP.

It was just that the original wording implied (at least to me) that custody would be automatically accepted by the next-hop BP forwarding agent.

> Should we 

I don't think that is necessary.  In fact, I don't even know if it is true.  It may be false. 

(I believe I have this correct)  Alan Hylton recently did a test at GRC on ION performance and found that we had better performance and got more bundles through the system when not using Custody Transfer than when using Custody transfer.  The paper should be published at the 30th AIAA International Communications Satellite Systems Conference (ICSSC) and 18th Ka and Broadband Communications, Navigation and Earth Observation Conference, 24 - 27 September 2012
Location: Ottawa, Ontario

- Will

---

From: Simon Perreault <[email-masked]>
Date: Fri, 24 Aug 2012 11:35:48 -0400

> The only point I was trying to make is that there is no specified default operations for BP-forwarding agents.  So, one implementor may assume something that another implementor does not and it cou…

As I see. Sounds like good input for 5050bis!

> It was just that the original wording implied (at least to me) that custody would be automatically accepted by the next-hop BP forwarding agent.

Understood. I'll try to fix the text so it's clear this is not implied.

> Location: Ottawa, Ontario

Very interesting!

Thanks,
Simon