Subject: [dtn-interest] 5050bis - a different approach - SPDY it up!

From: Stephen Farrell <[email-masked]>
Date: Thu, 16 May 2013 21:32:07 +0100

I'll do this in a new thread, because its a very
different approach and it mightn't get any support.

I agree with Will that unless we have folks with enough
energy and some funding, we're not likely to do much better
than evolving 5050. We had both when 5050 was developed,
but that's much less the case now at least in terms of
direct funding for this specific chunk of work.

But there are other ways to leverage folks' efforts, for
example to develop a 5050bis that has far more in common
with mainstream Internet protocols than was, understandably,
the case for 5050, when the space community were far ahead
of everyone else, and we knew less about DTNs.

The idea I'd like (but haven't yet got time/funding) to
explore would be for 5050bis to be as close as possible
to HTTP/2.0 (aka SPDY). Basically, start from HTTP/2.0
and break it as little as you have to do in order to
meet DTN requirements.

Why? HTTP/2.0 will have an extensible binary encoding
with a lot of real work done on compression (way more
than was ever done with the BP already) and if we had
a DTN variant of that then we could probably leverage
a lot of other folks' code and far more easily deploy
lots of DTNs. (You could just forget different
platform ports being a huge challenge for example.)

Another major benefit we'd get is that we'd immediately
know how to transport all interesting content types
(using MIME) again making integration with loads and
loads of applications much easier.

And if we do think ICN has promise (and I think it does
though for fewer applications than claimed), then all
ICN approaches (not to mention CDNs) also have to have
an HTTP story, so we start from being close-to-covered
in that respect too.

Clearly, some new HTTP headers would need to be defined,
and some form of CL-like concept would be needed for
cases where TCP breaks (maybe DTLS/LTP or just LTP?),
with a different state machine from HTTP's, but those
seem quite doable. The latter does mean that 5050bis
would not directly interop with the web when links
can't use TCP, but in many DTNs, links can use TCP.
And even when you can't you're often just one or two
hops from a network that can use TCP.

For the space folks, I'm pretty sure you could easily
enough gateway between such a beast and 5050 in an
agency's ground/space-segment, in the ways we discussed
when we met last time in Google. In fact, a bunch of
us have almost done that kind of gatewaying already
when we've done web stuff via 5050 in various DTN
deployments with flavours of HTTP/BP and this'd just
be a better thought out equivalent I reckon.

Lloyd in fact suggested something similar quite a while
ago and has kept an I-D more-or-less up to date. [1]
That's worth looking at but I think HTTP/2.0 offers
a much better starting point than HTTP/1.1 and one
that wasn't available when Lloyd was writing earlier.
(Since the choice of SPDY for HTTP/2.0 only happened
last year.) For example, HTTP/2.0 promises much
better avoidance of head-of-line blocking, which
fits nicely with the idea of DTN routing I think.
With HTTP/1.1 I suspect you'd need much more open
heart surgery on code to get it to do the kind of
thing that'd be needed.

Anyway, that's my €0.02 for now. I do hope to get a
chance to develop the argument beyond the arm-waving
stage before Berlin but I suspect I won't get time. I'd
be delighted if someone else wanted to push that along
and would be happy to help 'em out as time permits.

Cheers,
S.

PS: A similar argument could be made to start from CoAP.

[1] http://tools.ietf.org/html/draft-wood-dtnrg-http-dtn-delivery-07

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Fri, 17 May 2013 10:16:52 -0500

I would back this up.  You would have much better chance of large scale
deployment.

The space community can then take a look at super simplifying RFC5050 so it
can run high speed and be implemented using FPGAs.  I know of groups already
doing this, but in non-standard ways. For example, for space, you really
don't need SDNVs and such.

Will

---

From: Kevin Fall <[email-masked]>
Date: Fri, 17 May 2013 11:44:04 -0400

One of Ion Stoica's papers argued along the same line.
[http://dl.acm.org/citation.cfm?id=1868453]

Might be worth discussing in a bigger group.

- K

On Thu, May 16, 2013 at 4:32 PM, Stephen Farrell
<[email-masked]> wrote:
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/dtn-interest
>

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 17 May 2013 17:12:17 +0100

> [http://dl.acm.org/citation.cfm?id=1868453]

Right. But I think (more arm-waving:-) HTTP/2.0 is much
more attractive for DTNs than was HTTP/1.1.

> Might be worth discussing in a bigger group.

The generic thin-waist thing is certainly bigger than
just a discussion for this list. But this list is I think
the right place to discuss the potential of HTTP/2.0
for DTNs.

S.

---

From: Kevin K Gifford <[email-masked]>
Date: Fri, 17 May 2013 10:42:52 -0600

Will: What are you suggesting that Stephen "backs up"?  His preliminary
assertion - so that we can discuss - the concept of ICN in HTTP2.0 with
SPDY as a potential networking (information-centric) architecture to
evaluate in regards to DTN?

I may be missing something, but my take was that it was an academic and
engineering suggestion to evaluate the latest in the evolving network
(Internet) topics and to determine if there is a substantial basis to
leverage that improves DTN capabilities.  The brief synopsis provided
makes it seems that is well worth evaluating.

No need to back up the espoused concept at this point.  DTN2 is not ION
and consideration of the strategy for DTN2 to de-emphasize the space
domain and emphasizing terrestrial applications has a strong sensible
appeal.

Kevin

---

From: Kevin K Gifford <[email-masked]>
Date: Fri, 17 May 2013 14:48:18 -0600

Will: I re-read your statement and I believe I mis-interpreted "I would
back this up" as a statement directed at Stephen when in fact you were
advocating in support ("I back this this measure") of the suggestion.  So
do I.

Apologies for the mis-interprertation - I was a bonehead (don't everybody
go hog wild and +1 my boneheadedness).

Kevin

---

From: "Burleigh, Scott C (313B)" <[email-masked]>
Date: Sat, 18 May 2013 00:06:29 +0000

Stephen, I certainly agree that this is an idea that merits thoughtful discussion.  I myself am not yet a fan (unsurprising, I guess), but I know it's usually a mistake to resist a technically superior concept just because it's different from what we're familiar with.

From what you say about gatewaying between DT-SPDY (to coin a term) and 5050, I am guessing that you would anticipate that BP would be retained for space flight communications and would be supplanted by DT-SPDY only in the terrestrial DTN environment; is that right?  That is, DT-SPDY wouldn't need to address the problem of half-hour signal propagation times -- it would be more purely Disruption-Tolerant Networking, rather than Delay-Tolerant Networking?

So we'd have two DTN architectures?  That's not necessarily a bad thing, and it would make DT-SPDY somewhat easier to implement.  You wouldn't need to worry about delay-tolerant security key distribution because nodes would usually be able to consult certificate authorities just as they do now.  You wouldn't need to do delay-tolerant, anticipatory congestion control because you'd usually be able to use acknowledgment back pressure to signal congestion at a node.  These are problems that matter in the Interplanetary Internet but wouldn't have to be solved in terrestrial DTN.

I don't yet fully understand how basing DTN on SPDY rather than on BP would be technically superior.  Judging from Lloyd's I-D, which I believe is the most complete discussion of this idea we've currently got, I suspect you'd end up re-developing most of what is in BP now.  SPDY itself wouldn't do the DTN end-to-end route computation, so that job would fall to (in Lloyd's words) the "HTTP-using application" -- i.e., every application would have to do this itself -- or else you'd factor that function out into a common layer above SPDY (that issues the PUTs and so on), right?

If the latter, would you do things like resource management (managing the persistent files that are being forwarded on SPDY hops) in that layer too?  Would you have something like custody transfer up there?  Reporting on the status of forwarded objects as they make their way through the network?  Would the encryption of data at rest be managed at that layer?  It seems to me that this layer would end up looking a bit like BP, with SPDY looking like a very capable convergence-layer protocol.  What have I got wrong?

I definitely see the appeal of leveraging off the enormous body of work supporting HTTP, so maybe that's the overwhelming argument here.  But I think at least one part of that argument isn't altogether compelling: why couldn't we add MIME encapsulation of payloads to BP and thereby latch onto at least the MIME component of that HTTP leverage without going all the way to replacing BP with SPDY?

My questions here are sincere, not rhetorical.  I think I've still got an open mind on this topic.

Scott

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Thursday, May 16, 2013 1:32 PM
To: DTN interest
Subject: [dtn-interest] 5050bis - a different approach - SPDY it up!

I'll do this in a new thread, because its a very different approach and it mightn't get any support.

I agree with Will that unless we have folks with enough energy and some funding, we're not likely to do much better than evolving 5050. We had both when 5050 was developed, but that's much less the case now at least in terms of direct funding for this specific chunk of work.

But there are other ways to leverage folks' efforts, for example to develop a 5050bis that has far more in common with mainstream Internet protocols than was, understandably, the case for 5050, when the space community were far ahead of everyone else, and we knew less about DTNs.

The idea I'd like (but haven't yet got time/funding) to explore would be for 5050bis to be as close as possible to HTTP/2.0 (aka SPDY). Basically, start from HTTP/2.0 and break it as little as you have to do in order to meet DTN requirements.

Why? HTTP/2.0 will have an extensible binary encoding with a lot of real work done on compression (way more than was ever done with the BP already) and if we had a DTN variant of that then we could probably leverage a lot of other folks' code and far more easily deploy lots of DTNs. (You could just forget different platform ports being a huge challenge for example.)

Another major benefit we'd get is that we'd immediately know how to transport all interesting content types (using MIME) again making integration with loads and loads of applications much easier.

And if we do think ICN has promise (and I think it does though for fewer applications than claimed), then all ICN approaches (not to mention CDNs) also have to have an HTTP story, so we start from being close-to-covered in that respect too.

Clearly, some new HTTP headers would need to be defined, and some form of CL-like concept would be needed for cases where TCP breaks (maybe DTLS/LTP or just LTP?), with a different state machine from HTTP's, but those seem quite doable. The latter does mean that 5050bis would not directly interop with the web when links can't use TCP, but in many DTNs, links can use TCP.
And even when you can't you're often just one or two hops from a network that can use TCP.

For the space folks, I'm pretty sure you could easily enough gateway between such a beast and 5050 in an agency's ground/space-segment, in the ways we discussed when we met last time in Google. In fact, a bunch of us have almost done that kind of gatewaying already when we've done web stuff via 5050 in various DTN deployments with flavours of HTTP/BP and this'd just be a better thought out equivalent I reckon.

Lloyd in fact suggested something similar quite a while ago and has kept an I-D more-or-less up to date. [1] That's worth looking at but I think HTTP/2.0 offers a much better starting point than HTTP/1.1 and one that wasn't available when Lloyd was writing earlier.
(Since the choice of SPDY for HTTP/2.0 only happened last year.) For example, HTTP/2.0 promises much better avoidance of head-of-line blocking, which fits nicely with the idea of DTN routing I think.
With HTTP/1.1 I suspect you'd need much more open heart surgery on code to get it to do the kind of thing that'd be needed.

Anyway, that's my €0.02 for now. I do hope to get a chance to develop the argument beyond the arm-waving stage before Berlin but I suspect I won't get time. I'd be delighted if someone else wanted to push that along and would be happy to help 'em out as time permits.

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 18 May 2013 02:02:08 +0100

Hi Scott,

On 05/18/2013 01:06 AM, Burleigh, Scott C (313B) wrote:
> Stephen, I certainly agree that this is an idea that merits 
> thoughtful discussion.  I myself am not yet a fan (unsurprising, I 
> guess), but I know it's usually a mistake to resist a technically 
> superior concept just because it's different from what we're
> familiar with.

And equally, a change like this would need serious criticism and
not just fans like me:-)

> From what you say about gatewaying between DT-SPDY (to coin a term) 
> and 5050, I am guessing that you would anticipate that BP would be 
> retained for space flight communications and would be supplanted by 
> DT-SPDY only in the terrestrial DTN environment; is that right?

s/would be/could be/ but yes, I think that the space community,
particularly for flight wouldn't use 5050bis (don't like the
DT-SPDY term btw, not sure why;-) for quite some time to come.
And 5050 will continue to work just fine.

As we discussed last summer that means any 5050bis does have to
work well via gateways with 5050 implementations and I think we
should definitely keep that as a hard requirement.

In practice, I think that means you can get everything to work
except e2e security. Since hop by hop security is of more interest
for space agency uses of 5050 (as I understand it), that seems ok.

> That is, DT-SPDY wouldn't need to address the problem of half-hour
> signal propagation times -- it would be more purely
> Disruption-Tolerant Networking, rather than Delay-Tolerant
> Networking?

Mostly yes. There are non-space high latency links too (e.g.
acoustic) and e2e path latencies can easily be hours. I do
think it'd be worthwhile and helpful to consider high latency
links for 5050bis as well though.

The HTTP/2.0 folks are also highly latency sensitive though.
Not for the same reasons, but arguably with similar impact.

> So we'd have two DTN architectures?  

Not two architectures, no. Two different protocols that both
are equally consistent with 4838 seems quite doable though.

> That's not necessarily a bad 
> thing, and it would make DT-SPDY somewhat easier to implement.  You 
> wouldn't need to worry about delay-tolerant security key
> distribution because nodes would usually be able to consult
> certificate authorities just as they do now.  

I could write an essay at this point;-) I'll do it via bullets:
- Key management is always needed and always hard.
- Today’s Web PKI works, but only just. See Diginotar.
- a SPDY-based 5050bis/TLS is a fine thing, esp given ALPN which
  allows you to negotiate protocols on a per-hop basis (needed
  for HTTP/2.0 to handle upgrade from HTTP/1.1)
- DTLS/LTP might be as good as it gets for real key management
  over high latency links - radically better ideas haven't
  emerged in the last decade for DTN key management

> You wouldn't need to
> do delay-tolerant, anticipatory congestion control because you'd
> usually be able to use acknowledgment back pressure to signal
> congestion at a node.  These are problems that matter in the
> Interplanetary Internet but wouldn't have to be solved in terrestrial
> DTN.

Congestion needs study. A minor argument for the SPDY-based 5050bis
approach is that there are many people who care about congestion
in HTTP/2.0. Their expertise can be more than useful.

> I don't yet fully understand how basing DTN on SPDY rather than on
> BP would be technically superior.  Judging from Lloyd's I-D, which I 
> believe is the most complete discussion of this idea we've currently 
> got, I suspect you'd end up re-developing most of what is in BP now. 

Nope. Check out compression in HTTP/2.0 for example. Its way better
than the dictionary stuff ever was. Its entirely fair to say that
the SPDY-based 5050bis thing is not written down really. MIME body
parts is also way better than what we have now with the BP.

> SPDY itself wouldn't do the DTN end-to-end route computation, so
> that job would fall to (in Lloyd's words) the "HTTP-using
> application" -- i.e., every application would have to do this itself
> -- or else you'd factor that function out into a common layer above
> SPDY (that issues the PUTs and so on), right?

Well, how you'd map DTN concepts into HTTP methods is TBD. There
are a few ways that could work.

There are also two ways one could address this work - to map
from 5050 to HTTP/2.0 and see what works, or to map from HTTP/2.0
to DTN requirements and see what doesn't work and then fix that
and look at how to make a 5050 gateway. I think I prefer the
latter as it'd get more benefit from HTTP efforts elsewhere.

> If the latter, would you do things like resource management
> (managing the persistent files that are being forwarded on SPDY hops)
> in that layer too?  

We had a similar need for ICN and wrote an I-D about it. [1]
reckon a similar approach would be ok here too.

   [1] http://tools.ietf.org/html/draft-kutscher-icnrg-netinf-proto

CDNs also do that kind of thing routinely.

> Would you have something like custody transfer up
> there? Reporting on the status of forwarded objects as they make
> their way through the network?  

Not considered at all yet. (By me anyway)

> Would the encryption of data at rest
> be managed at that layer?  

Not sure. I do think we ought figure our security needs going in
this time (as opposed to grafting it on as we did with 5050) and
then make sure those are met.

> It seems to me that this layer would end
> up looking a bit like BP, with SPDY looking like a very capable
> convergence-layer protocol.  What have I got wrong?

That's a way to look at it, and not crazy. I do think it involves
an expansion of what the term convergence layer can mean though.
But I think that's a useful expansion of the CL concept.

> I definitely see the appeal of leveraging off the enormous body of 
> work supporting HTTP, so maybe that's the overwhelming argument
> here. 

Yep. Elephant, meet room:-)

> But I think at least one part of that argument isn't
> altogether compelling: why couldn't we add MIME encapsulation of
> payloads to BP and thereby latch onto at least the MIME component of
> that HTTP leverage without going all the way to replacing BP with
> SPDY?

We could do that. I reckon we'd end up with a messy mismatch
between wanting metadata as a JSON MIME body part and using BP
extension blocks though.

But yes, all of the functional changes we've discussed could be
done via much more minor additions and changes to 5050. I just
think that'd be a bad plan.

> got an open mind on this topic.

Great. That's all I ask at this point. And I'll emphasise again
that I don't have a worked out proposal, so work is needed.

Cheers,
S.

> 
> Scott
> 
> -----Original Message----- From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Stephen Farrell 
> Sent: Thursday, May 16, 2013 1:32 PM To: DTN interest Subject: 
> [dtn-interest] 5050bis - a different approach - SPDY it up!
> 
> 
> I agree with Will that unless we have folks with enough energy and 
> some funding, we're not likely to do much better than evolving 5050. 
> We had both when 5050 was developed, but that's much less the case 
> now at least in terms of direct funding for this specific chunk of 
> work.
> 
> But there are other ways to leverage folks' efforts, for example to 
> develop a 5050bis that has far more in common with mainstream 
> Internet protocols than was, understandably, the case for 5050, when 
> the space community were far ahead of everyone else, and we knew
> less about DTNs.
> 
> The idea I'd like (but haven't yet got time/funding) to explore
> would be for 5050bis to be as close as possible to HTTP/2.0 (aka
> SPDY). Basically, start from HTTP/2.0 and break it as little as you
> have to do in order to meet DTN requirements.
> 
> Why? HTTP/2.0 will have an extensible binary encoding with a lot of 
> real work done on compression (way more than was ever done with the 
> BP already) and if we had a DTN variant of that then we could 
> probably leverage a lot of other folks' code and far more easily 
> deploy lots of DTNs. (You could just forget different platform ports 
> being a huge challenge for example.)
> 
> Another major benefit we'd get is that we'd immediately know how to 
> transport all interesting content types (using MIME) again making 
> integration with loads and loads of applications much easier.
> 
> And if we do think ICN has promise (and I think it does though for 
> fewer applications than claimed), then all ICN approaches (not to 
> mention CDNs) also have to have an HTTP story, so we start from
> being close-to-covered in that respect too.
> 
> Clearly, some new HTTP headers would need to be defined, and some 
> form of CL-like concept would be needed for cases where TCP breaks 
> (maybe DTLS/LTP or just LTP?), with a different state machine from 
> HTTP's, but those seem quite doable. The latter does mean that 
> 5050bis would not directly interop with the web when links can't use 
> TCP, but in many DTNs, links can use TCP. And even when you can't 
> you're often just one or two hops from a network that can use TCP.
> 
> For the space folks, I'm pretty sure you could easily enough gateway 
> between such a beast and 5050 in an agency's ground/space-segment,
> in the ways we discussed when we met last time in Google. In fact, a 
> bunch of us have almost done that kind of gatewaying already when 
> we've done web stuff via 5050 in various DTN deployments with 
> flavours of HTTP/BP and this'd just be a better thought out 
> equivalent I reckon.
> 
> Lloyd in fact suggested something similar quite a while ago and has 
> kept an I-D more-or-less up to date. [1] That's worth looking at but 
> I think HTTP/2.0 offers a much better starting point than HTTP/1.1 
> and one that wasn't available when Lloyd was writing earlier. (Since 
> the choice of SPDY for HTTP/2.0 only happened last year.) For 
> example, HTTP/2.0 promises much better avoidance of head-of-line 
> blocking, which fits nicely with the idea of DTN routing I think. 
> With HTTP/1.1 I suspect you'd need much more open heart surgery on 
> code to get it to do the kind of thing that'd be needed.
> 
> Anyway, that's my €0.02 for now. I do hope to get a chance to
> develop the argument beyond the arm-waving stage before Berlin but I
> suspect I won't get time. I'd be delighted if someone else wanted to
> push that along and would be happy to help 'em out as time permits.
> 
> Cheers, S.
> 
> _______________________________________________ dtn-interest mailing 
> list [email-masked]

---

From: "Burleigh, Scott C (313B)" <[email-masked]>
Date: Sun, 19 May 2013 15:01:19 +0000

We may have at least a little bit of common ground here.  I am increasingly convinced that the ability to leverage the functionality of protocols at the convergence layer is one of the great strengths of the DTN architecture.  Like extension blocks, which I think we tend to think of as merely experimental when in fact they may be vital permanent (though optional) features of BP, convergence-layer adapters tend to be regarded as afterthoughts in DTN.  I think we're on much firmer ground, in the long term, when we think of the core Bundle Protocol as primarily a mechanism for efficiently knitting together a wide array of independently developed, maybe environment-specific, communication capabilities, rather than a single master communications solution with some options that you can turn on and off.

Scott

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Friday, May 17, 2013 6:02 PM
To: Burleigh, Scott C (313B)
Cc: DTN interest
Subject: Re: [dtn-interest] 5050bis - a different approach - SPDY it up!

Hi Scott,

On 05/18/2013 01:06 AM, Burleigh, Scott C (313B) wrote:
> Stephen, I certainly agree that this is an idea that merits thoughtful 
> discussion.  I myself am not yet a fan (unsurprising, I guess), but I 
> know it's usually a mistake to resist a technically superior concept 
> just because it's different from what we're familiar with.

And equally, a change like this would need serious criticism and not just fans like me:-)

> DT-SPDY only in the terrestrial DTN environment; is that right?

s/would be/could be/ but yes, I think that the space community, particularly for flight wouldn't use 5050bis (don't like the DT-SPDY term btw, not sure why;-) for quite some time to come.
And 5050 will continue to work just fine.

As we discussed last summer that means any 5050bis does have to work well via gateways with 5050 implementations and I think we should definitely keep that as a hard requirement.

In practice, I think that means you can get everything to work except e2e security. Since hop by hop security is of more interest for space agency uses of 5050 (as I understand it), that seems ok.

> Disruption-Tolerant Networking, rather than Delay-Tolerant Networking?

Mostly yes. There are non-space high latency links too (e.g.
acoustic) and e2e path latencies can easily be hours. I do think it'd be worthwhile and helpful to consider high latency links for 5050bis as well though.

> So we'd have two DTN architectures?  

Not two architectures, no. Two different protocols that both are equally consistent with 4838 seems quite doable though.

> wouldn't need to worry about delay-tolerant security key distribution 
> because nodes would usually be able to consult certificate authorities 
> just as they do now.

> Interplanetary Internet but wouldn't have to be solved in terrestrial 

Congestion needs study. A minor argument for the SPDY-based 5050bis approach is that there are many people who care about congestion in HTTP/2.0. Their expertise can be more than useful.

> I don't yet fully understand how basing DTN on SPDY rather than on BP 
> would be technically superior.  Judging from Lloyd's I-D, which I 

Nope. Check out compression in HTTP/2.0 for example. Its way better than the dictionary stuff ever was. Its entirely fair to say that the SPDY-based 5050bis thing is not written down really. MIME body parts is also way better than what we have now with the BP.

> SPDY itself wouldn't do the DTN end-to-end route computation, so that 
> job would fall to (in Lloyd's words) the "HTTP-using application" -- 
> i.e., every application would have to do this itself

Well, how you'd map DTN concepts into HTTP methods is TBD. There are a few ways that could work.

There are also two ways one could address this work - to map from 5050 to HTTP/2.0 and see what works, or to map from HTTP/2.0 to DTN requirements and see what doesn't work and then fix that and look at how to make a 5050 gateway. I think I prefer the latter as it'd get more benefit from HTTP efforts elsewhere.

> If the latter, would you do things like resource management (managing 
> the persistent files that are being forwarded on SPDY hops) in that 
> layer too?

We had a similar need for ICN and wrote an I-D about it. [1] reckon a similar approach would be ok here too.

> Would you have something like custody transfer up there? Reporting on 
> the status of forwarded objects as they make their way through the 
> network?

> be managed at that layer?  

Not sure. I do think we ought figure our security needs going in this time (as opposed to grafting it on as we did with 5050) and then make sure those are met.

> It seems to me that this layer would end up looking a bit like BP, 
> with SPDY looking like a very capable convergence-layer protocol.  
> What have I got wrong?

That's a way to look at it, and not crazy. I do think it involves an expansion of what the term convergence layer can mean though.
But I think that's a useful expansion of the CL concept.

> work supporting HTTP, so maybe that's the overwhelming argument here.

> But I think at least one part of that argument isn't altogether 
> compelling: why couldn't we add MIME encapsulation of payloads to BP 
> and thereby latch onto at least the MIME component of that HTTP 
> leverage without going all the way to replacing BP with SPDY?

We could do that. I reckon we'd end up with a messy mismatch between wanting metadata as a JSON MIME body part and using BP extension blocks though.

But yes, all of the functional changes we've discussed could be done via much more minor additions and changes to 5050. I just think that'd be a bad plan.

> an open mind on this topic.

Great. That's all I ask at this point. And I'll emphasise again that I don't have a worked out proposal, so work is needed.

Cheers,
S.

> We had both when 5050 was developed, but that's much less the case now 
> at least in terms of direct funding for this specific chunk of work.
> 
> develop a 5050bis that has far more in common with mainstream Internet 
> protocols than was, understandably, the case for 5050, when the space 
> community were far ahead of everyone else, and we knew less about 
> DTNs.
> 
> The idea I'd like (but haven't yet got time/funding) to explore would 
> be for 5050bis to be as close as possible to HTTP/2.0 (aka SPDY). 
> Basically, start from HTTP/2.0 and break it as little as you have to 
> do in order to meet DTN requirements.
> 
> real work done on compression (way more than was ever done with the BP 
> already) and if we had a DTN variant of that then we could probably 
> leverage a lot of other folks' code and far more easily deploy lots of 
> DTNs. (You could just forget different platform ports being a huge 
> challenge for example.)
> 
> mention CDNs) also have to have an HTTP story, so we start from being 
> close-to-covered in that respect too.
> 
> Clearly, some new HTTP headers would need to be defined, and some form 
> of CL-like concept would be needed for cases where TCP breaks (maybe 
> DTLS/LTP or just LTP?), with a different state machine from HTTP's, 
> but those seem quite doable. The latter does mean that 5050bis would 
> not directly interop with the web when links can't use TCP, but in 
> many DTNs, links can use TCP. And even when you can't you're often 
> just one or two hops from a network that can use TCP.
> 
> between such a beast and 5050 in an agency's ground/space-segment, in 
> the ways we discussed when we met last time in Google. In fact, a 
> we've done web stuff via 5050 in various DTN deployments with flavours 
> of HTTP/BP and this'd just be a better thought out equivalent I 
> reckon.
> 
> kept an I-D more-or-less up to date. [1] That's worth looking at but I 
> think HTTP/2.0 offers a much better starting point than HTTP/1.1 and 
> one that wasn't available when Lloyd was writing earlier. (Since the 
> choice of SPDY for HTTP/2.0 only happened last year.) For example, 
> HTTP/2.0 promises much better avoidance of head-of-line blocking, 
> which fits nicely with the idea of DTN routing I think.
> Anyway, that's my €0.02 for now. I do hope to get a chance to develop 
> the argument beyond the arm-waving stage before Berlin but I suspect I 
> won't get time. I'd be delighted if someone else wanted to push that 
> along and would be happy to help 'em out as time permits.
> 
> Cheers, S.
>

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 19 May 2013 20:26:57 +0100

Hiya,

On 05/19/2013 04:01 PM, Burleigh, Scott C (313B) wrote:
> We may have at least a little bit of common ground here.  

More than a little I think. Or, put another way, that bit
of common ground is more than a little important.

> I am
> increasingly convinced that the ability to leverage the functionality
> of protocols at the convergence layer is one of the great strengths
> of the DTN architecture.  Like extension blocks, which I think we
> tend to think of as merely experimental when in fact they may be
> vital permanent (though optional) features of BP, convergence-layer
> adapters tend to be regarded as afterthoughts in DTN.  I think we're
> on much firmer ground, in the long term, when we think of the core
> Bundle Protocol as primarily a mechanism for efficiently knitting
> together a wide array of independently developed, maybe
> environment-specific, communication capabilities, rather than a
> single master communications solution with some options that you can
> turn on and off.

Right. That was more or less the conclusion we arrived at when
doing the NetInf ICN stuff - let CLs do as much as possible.

That, plus the benefits of being able to do DTN with just
reasonably small modifications to widely used open-source seem
very attractive to me. (Assuming that a SPDY-based 5050bis does
turn out ok, which remains a major assumption.)

S

> 
> Scott
> 
> -----Original Message----- From: Stephen Farrell
> [mailto:[email-masked]] Sent: Friday, May 17, 2013 6:02
> PM To: Burleigh, Scott C (313B) Cc: DTN interest Subject: Re:
>>  retained for space flight communications and would be supplanted
>> by DT-SPDY only in the terrestrial DTN environment; is that right?
> 
> particularly for flight wouldn't use 5050bis (don't like the DT-SPDY
> term btw, not sure why;-) for quite some time to come. And 5050 will
> continue to work just fine.
> 
> As we discussed last summer that means any 5050bis does have to work
> well via gateways with 5050 implementations and I think we should
> definitely keep that as a hard requirement.
> 
> In practice, I think that means you can get everything to work except
> e2e security. Since hop by hop security is of more interest for space
> agency uses of 5050 (as I understand it), that seems ok.
> 
> acoustic) and e2e path latencies can easily be hours. I do think it'd
> be worthwhile and helpful to consider high latency links for 5050bis
> as well though.
> 
> The HTTP/2.0 folks are also highly latency sensitive though. Not for
> the same reasons, but arguably with similar impact.
> 
> Not two architectures, no. Two different protocols that both are
> equally consistent with 4838 seems quite doable though.
> 
>> That's not necessarily a bad thing, and it would make DT-SPDY
>> somewhat easier to implement.  You wouldn't need to worry about
>> delay-tolerant security key distribution because nodes would
>> usually be able to consult certificate authorities just as they do
>> now.
> 
> I could write an essay at this point;-) I'll do it via bullets: - Key
> management is always needed and always hard. - Today’s Web PKI works,
> but only just. See Diginotar. - a SPDY-based 5050bis/TLS is a fine
> thing, esp given ALPN which allows you to negotiate protocols on a
> per-hop basis (needed for HTTP/2.0 to handle upgrade from HTTP/1.1) -
> DTLS/LTP might be as good as it gets for real key management over
> high latency links - radically better ideas haven't emerged in the
> last decade for DTN key management
> 
>> You wouldn't need to do delay-tolerant, anticipatory congestion
>> control because you'd usually be able to use acknowledgment back
>> pressure to signal congestion at a node.  These are problems that
>> matter in the Interplanetary Internet but wouldn't have to be
>> solved in terrestrial DTN.
> 
> approach is that there are many people who care about congestion in
> HTTP/2.0. Their expertise can be more than useful.
> 
>> BP would be technically superior.  Judging from Lloyd's I-D, which
>> I believe is the most complete discussion of this idea we've
>> currently got, I suspect you'd end up re-developing most of what is
>> in BP now.
> 
> than the dictionary stuff ever was. Its entirely fair to say that the
> SPDY-based 5050bis thing is not written down really. MIME body parts
> is also way better than what we have now with the BP.
> 
>> application" -- i.e., every application would have to do this
>> itself -- or else you'd factor that function out into a common
>> layer above SPDY (that issues the PUTs and so on), right?
> 
> There are also two ways one could address this work - to map from
> 5050 to HTTP/2.0 and see what works, or to map from HTTP/2.0 to DTN
> requirements and see what doesn't work and then fix that and look at
> how to make a 5050 gateway. I think I prefer the latter as it'd get
> more benefit from HTTP efforts elsewhere.
> 
>> (managing the persistent files that are being forwarded on SPDY
>> hops) in that layer too?
> 
>> Would you have something like custody transfer up there? Reporting
>> on the status of forwarded objects as they make their way through
>> the network?
> 
>> Would the encryption of data at rest be managed at that layer?
> 
> Not sure. I do think we ought figure our security needs going in this
> time (as opposed to grafting it on as we did with 5050) and then make
> sure those are met.
> 
> That's a way to look at it, and not crazy. I do think it involves an
> expansion of what the term convergence layer can mean though. But I
> think that's a useful expansion of the CL concept.
> 
>> compelling: why couldn't we add MIME encapsulation of payloads to
>> BP and thereby latch onto at least the MIME component of that HTTP
> We could do that. I reckon we'd end up with a messy mismatch between
> wanting metadata as a JSON MIME body part and using BP extension
> blocks though.
> 
> But yes, all of the functional changes we've discussed could be done
> via much more minor additions and changes to 5050. I just think
> that'd be a bad plan.
> 
> Great. That's all I ask at this point. And I'll emphasise again that
> I don't have a worked out proposal, so work is needed.
> 
> Cheers, S.
> 
>> 
>> Scott
>> 
>> [mailto:[email-masked]] On Behalf Of Stephen
>> Farrell Sent: Thursday, May 16, 2013 1:32 PM To: DTN interest
>>  some funding, we're not likely to do much better than evolving
>> 5050. We had both when 5050 was developed, but that's much less the
>> case now at least in terms of direct funding for this specific
>> chunk of work.
>> 
>> Internet protocols than was, understandably, the case for 5050,
>> when the space community were far ahead of everyone else, and we
>> knew less about DTNs.
>> 
>>  real work done on compression (way more than was ever done with
>> the BP already) and if we had a DTN variant of that then we could
>> deploy lots of DTNs. (You could just forget different platform
>> ports being a huge challenge for example.)
>> 
>> 5050bis would not directly interop with the web when links can't
>> use TCP, but in many DTNs, links can use TCP. And even when you
>> can't you're often just one or two hops from a network that can use
>> TCP.
>> 
>> For the space folks, I'm pretty sure you could easily enough
>> gateway between such a beast and 5050 in an agency's
>> ground/space-segment, in the ways we discussed when we met last
>> time in Google. In fact, a bunch of us have almost done that kind
>> of gatewaying already when we've done web stuff via 5050 in various
>> DTN deployments with flavours of HTTP/BP and this'd just be a
>> better thought out equivalent I reckon.
>> 
>>  kept an I-D more-or-less up to date. [1] That's worth looking at
>> but I think HTTP/2.0 offers a much better starting point than
>> HTTP/1.1 and one that wasn't available when Lloyd was writing
>> earlier. (Since the choice of SPDY for HTTP/2.0 only happened last
>> year.) For example, HTTP/2.0 promises much better avoidance of
>> head-of-line blocking, which fits nicely with the idea of DTN
>> routing I think. With HTTP/1.1 I suspect you'd need much more open
>> heart surgery on code to get it to do the kind of thing that'd be
>> needed.
>> 
>> develop the argument beyond the arm-waving stage before Berlin but
>> I suspect I won't get time. I'd be delighted if someone else wanted
>> to push that along and would be happy to help 'em out as time
>> permits.
>> 
>> Cheers, S.
>> 
>> [1]
>> http://tools.ietf.org/html/draft-wood-dtnrg-http-dtn-delivery-07
>> 
>> 
>> 
>> _______________________________________________ dtn-interest
>> mailing list [email-masked]

---

From: Vint Cerf <[email-masked]>
Date: Sun, 19 May 2013 17:24:35 -0400

how do we get around the problems of delay and disruption? SPDY and HTTP2.0
are not great in disrupted, variably-delayed environments. the dependence
of http on DNS is another issue (at least insofar as http rides on TCP much
of the time. I think there are a lot of little details that need to be
looked at before I get too excited.

v

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 19 May 2013 22:42:30 +0100

Hiya,

On 05/19/2013 10:24 PM, Vint Cerf wrote:
> are not great in disrupted, variably-delayed environments. 

Yes, that's an issue. I think what'd be needed would be to be able to
run SPDY over a non-TCP substrate, e.g. LTP or UDP. That kinds of thing
has been done with HTTP/1.1 (always as non-standard hacks afaik).

We'd also need a good understanding of how SPDY does behave in less
than ideal TCP environments (e.g. higher latency or with more errors
that aren't due to congestion) in order to know when we'd want to
use the above non-TCP substrate.

Having said that, there are a lot of terrestrial DTN use cases where
TCP is just fine for DTN hops but where you don't have an e2e path.

> the dependence
> of the time. 

Yes, for that I think senders act as if always using a forward
proxy which appears simple enough.

And if we have proxies that hold requests for extended periods,
then we do need to modify the HTTP state machine. (Probably with
some new result codes at the very least.)

> I think there are a lot of little details that need to be

Fully agree. I think the best I'd hope for in this thread is to
better identify those details enough to convince folks (incl.
myself;-) that its really worth spending time on the idea.

S.

---

From: William Immerman <[email-masked]>
Date: Mon, 20 May 2013 19:57:41 -0400

> has been done with HTTP/1.1 (always as non-standard hacks afaik).

Stephen--

Putting this together with your response to Scott, wouldn't that imply that it would be better to run the application protocol over BP to abstract from the need to fix on a particular CL? From a network engineering perspective, I took your concurrence with Scott to mean that you both have experienced value in being able to engineer the right CL in a DTN on a per-hop basis, but from a DTN user perspective, once that hop is engineered and implemented, don't we want the user to be able to communicate without regard for the specifics of the hop-by-hop implementation? If you omit the BP layer, and run directly over the CL that's appropriate right now, doesn't that leave the end-to-end application vulnerable to changes in the environment or requirements that might necessitate reworking the CL, or introducing a hybrid of multiple CLs between endpoints?

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 21 May 2013 01:17:06 +0100

Hi

On 05/21/2013 12:57 AM, William Immerman wrote:
>>> how do we get around the problems of delay and disruption? SPDY
>>> and HTTP2.0 are not great in disrupted, variably-delayed
>>> environments.
>> 
>> Yes, that's an issue. I think what'd be needed would be to be able
>> to run SPDY over a non-TCP substrate, e.g. LTP or UDP. That kinds
>> of thing has been done with HTTP/1.1 (always as non-standard hacks
>> afaik).
> 
> Stephen--
> 
> Putting this together with your response to Scott, wouldn't that
> imply that it would be better to run the application protocol over BP
> to abstract from the need to fix on a particular CL? 

Better? Not sure. Could be, but then again maybe not. I think
it'd depend on whether or not the putative SPDY thing proved
to be more useful to more people for more use-cases or not.

> From a network
> engineering perspective, I took your concurrence with Scott to mean
> that you both have experienced value in being able to engineer the
> right CL in a DTN on a per-hop basis, but from a DTN user
> perspective, once that hop is engineered and implemented, don't we
> want the user to be able to communicate without regard for the
> specifics of the hop-by-hop implementation? If you omit the BP layer,
> and run directly over the CL that's appropriate right now, doesn't
> that leave the end-to-end application vulnerable to changes in the
> environment or requirements that might necessitate reworking the CL,
> or introducing a hybrid of multiple CLs between endpoints?

If 5050 were perfect that argument would be true. Given that 5050
is not perfect, but does work well enough, its still an argument,
but perhaps no longer winning.

I don't get the last bit though, with 5050, CLs can differ on
different hops already so I don't see that "moving" most features
between the "core" BP and the CL makes much difference in the
face of those kinds of change - you still need to update the
node regardless.

I think we probably do want routing to be CL-independent (or
at least mostly), but things like the encoding of EIDs or the
use or not of SDNVs seem entirely ok to me to change on a hop
by hop basis.

The reality seems to be that there are few CLs that actually
get used. The TCPCL is almost universal in terrestrial DTNs.
The LTPCL is the only other one I've used in near-anger and
that was for an ESA study and not a live deployment. So
even if one pushes lots of functionality into the CL, its
not that dangerous in reality.

S.

> 
> 
>> 
>> We'd also need a good understanding of how SPDY does behave in
>> less than ideal TCP environments (e.g. higher latency or with more
>> errors that aren't due to congestion) in order to know when we'd
>> want to use the above non-TCP substrate.
>> 
>> Having said that, there are a lot of terrestrial DTN use cases
>> where TCP is just fine for DTN hops but where you don't have an e2e
>> path.
>> 
>>> the dependence of http on DNS is another issue (at least insofar
>>> as http rides on TCP much of the time.
>> 
>>> I think there are a lot of little details that need to be looked
>>> at before I get too excited.
>> 
>>>> More than a little I think. Or, put another way, that bit of
>>>> common ground is more than a little important.
>>>> 
>>>>> I am increasingly convinced that the ability to leverage the
>>>>> functionality of protocols at the convergence layer is one of
>>>>> the great strengths of the DTN architecture.  Like extension
>>>>> blocks, which I think we tend to think of as merely
>>>>> experimental when in fact they may be vital permanent (though
>>>>> optional) features of BP, convergence-layer adapters tend to
>>>>> be regarded as afterthoughts in DTN.  I think we're on much
>>>>> firmer ground, in the long term, when we think of the core 
>>>>> Bundle Protocol as primarily a mechanism for efficiently
>>>>> knitting together a wide array of independently developed,
>>>>> maybe environment-specific, communication capabilities,
>>>>> rather than a single master communications solution with some
>>>>> options that you can turn on and off.
>>>> 
>>>> very attractive to me. (Assuming that a SPDY-based 5050bis
>>>> does turn out ok, which remains a major assumption.)
>>>> 
>>>> S
>>>> 
>>>>> 
>>>>> Scott
>>>>> 
>>>>> [mailto:[email-masked]] Sent: Friday, May 17, 2013
>>>>> 6:02 PM To: Burleigh, Scott C (313B) Cc: DTN interest
>>>>>> Stephen, I certainly agree that this is an idea that
>>>>>> merits thoughtful discussion.  I myself am not yet a fan
>>>>>> (unsurprising, I guess), but I know it's usually a mistake
>>>>>> to resist a technically superior concept just because it's
>>>>>> different from what we're familiar with.
>>>>> 
>>>>>> From what you say about gatewaying between DT-SPDY (to coin
>>>>>> a term) and 5050, I am guessing that you would anticipate
>>>>>> that BP would be retained for space flight communications
>>>>>> and would be supplanted by DT-SPDY only in the terrestrial
>>>>>> DTN environment; is that right?
>>>>> 
>>>>> s/would be/could be/ but yes, I think that the space
>>>>> community, particularly for flight wouldn't use 5050bis
>>>>> (don't like the DT-SPDY term btw, not sure why;-) for quite
>>>>> some time to come. And 5050 will continue to work just fine.
>>>>> 
>>>>> As we discussed last summer that means any 5050bis does have
>>>>> to work well via gateways with 5050 implementations and I
>>>>> think we should definitely keep that as a hard requirement.
>>>>> 
>>>>> In practice, I think that means you can get everything to
>>>>> work except e2e security. Since hop by hop security is of
>>>>> more interest for space agency uses of 5050 (as I understand
>>>>> it), that seems ok.
>>>>> 
>>>>>> That is, DT-SPDY wouldn't need to address the problem of
>>>>>> half-hour signal propagation times -- it would be more
>>>>>> purely Disruption-Tolerant Networking, rather than
>>>>>> Delay-Tolerant Networking?
>>>>> 
>>>>>> That's not necessarily a bad thing, and it would make
>>>>>> DT-SPDY somewhat easier to implement.  You wouldn't need to
>>>>>> worry about delay-tolerant security key distribution
>>>>>> because nodes would usually be able to consult certificate
>>>>>> authorities just as they do now.
>>>>> 
>>>>> I could write an essay at this point;-) I'll do it via
>>>>> bullets: - Key management is always needed and always hard. -
>>>>> Today’s Web PKI works, but only just. See Diginotar. - a
>>>>> SPDY-based 5050bis/TLS is a fine thing, esp given ALPN which
>>>>> for HTTP/2.0 to handle upgrade from HTTP/1.1) - DTLS/LTP
>>>>> might be as good as it gets for real key management over high
>>>>> latency links - radically better ideas haven't emerged in
>>>>> the last decade for DTN key management
>>>>> 
>>>>>> You wouldn't need to do delay-tolerant, anticipatory
>>>>>> congestion control because you'd usually be able to use
>>>>>> acknowledgment back pressure to signal congestion at a
>>>>>> node.  These are problems that matter in the Interplanetary
>>>>>> Internet but wouldn't have to be solved in terrestrial
>>>>>> DTN.
>>>>> 
>>>>> Congestion needs study. A minor argument for the SPDY-based
>>>>> 5050bis approach is that there are many people who care about
>>>>> congestion in HTTP/2.0. Their expertise can be more than
>>>>> useful.
>>>>> 
>>>>>> I don't yet fully understand how basing DTN on SPDY rather
>>>>>> than on BP would be technically superior.  Judging from
>>>>>> Lloyd's I-D, which I believe is the most complete
>>>>>> discussion of this idea we've currently got, I suspect
>>>>>> you'd end up re-developing most of what is in BP now.
>>>>> 
>>>>> Nope. Check out compression in HTTP/2.0 for example. Its way
>>>>> better than the dictionary stuff ever was. Its entirely fair
>>>>> to say that the SPDY-based 5050bis thing is not written down
>>>>> really. MIME body parts is also way better than what we have
>>>>> now with the BP.
>>>>> 
>>>>>> SPDY itself wouldn't do the DTN end-to-end route
>>>>>> computation, so that job would fall to (in Lloyd's words)
>>>>>> the "HTTP-using application" -- i.e., every application
>>>>>> would have to do this itself -- or else you'd factor that
>>>>>> function out into a common layer above SPDY (that issues
>>>>>> the PUTs and so on), right?
>>>>> 
>>>>> from 5050 to HTTP/2.0 and see what works, or to map from
>>>>> HTTP/2.0 to DTN requirements and see what doesn't work and
>>>>> then fix that and look at how to make a 5050 gateway. I think
>>>>> I prefer the latter as it'd get more benefit from HTTP
>>>>> efforts elsewhere.
>>>>> 
>>>>>> If the latter, would you do things like resource
>>>>>> management (managing the persistent files that are being
>>>>>> forwarded on SPDY hops) in that layer too?
>>>>> 
>>>>> http://tools.ietf.org/html/draft-kutscher-icnrg-netinf-proto
>>>>> 
>>>>>> Would you have something like custody transfer up there?
>>>>>> Reporting on the status of forwarded objects as they make
>>>>> Not sure. I do think we ought figure our security needs going
>>>>> in this time (as opposed to grafting it on as we did with
>>>>> 5050) and then make sure those are met.
>>>>> 
>>>>>> It seems to me that this layer would end up looking a bit
>>>>>> like BP, with SPDY looking like a very capable
>>>>> That's a way to look at it, and not crazy. I do think it
>>>>> involves an expansion of what the term convergence layer can
>>>>> mean though. But I think that's a useful expansion of the CL
>>>>> concept.
>>>>> 
>>>>>> I definitely see the appeal of leveraging off the enormous
>>>>>> body of work supporting HTTP, so maybe that's the
>>>>>> overwhelming argument here.
>>>>> 
>>>>>> altogether compelling: why couldn't we add MIME
>>>>>> encapsulation of payloads to BP and thereby latch onto at
>>>>>> least the MIME component of that HTTP leverage without
>>>>>> going all the way to replacing BP with SPDY?
>>>>> 
>>>>> between wanting metadata as a JSON MIME body part and using
>>>>> BP extension blocks though.
>>>>> 
>>>>> But yes, all of the functional changes we've discussed could
>>>>> be done via much more minor additions and changes to 5050. I
>>>>> just think that'd be a bad plan.
>>>>> 
>>>>>> My questions here are sincere, not rhetorical.  I think
>>>>>> I've still got an open mind on this topic.
>>>>> 
>>>>> Great. That's all I ask at this point. And I'll emphasise
>>>>> again that I don't have a worked out proposal, so work is
>>>>> needed.
>>>>> 
>>>>> Cheers, S.
>>>>> 
>>>>>> 
>>>>>> Scott
>>>>>> 
>>>>>> [mailto:[email-masked]] On Behalf Of
>>>>>> Stephen Farrell Sent: Thursday, May 16, 2013 1:32 PM To:
>>>>>> DTN interest Subject: [dtn-interest] 5050bis - a different
>>>>>> approach - SPDY it up!
>>>>>> 
>>>>>> 
>>>>>> I'll do this in a new thread, because its a very different
>>>>>> approach and it mightn't get any support.
>>>>>> 
>>>>>> with mainstream Internet protocols than was,
>>>>>> understandably, the case for 5050, when the space community
>>>>>> were far ahead of everyone else, and we knew less about
>>>>>> DTNs.
>>>>>> 
>>>>>> explore would be for 5050bis to be as close as possible to
>>>>>> HTTP/2.0 (aka SPDY). Basically, start from HTTP/2.0 and
>>>>>> break it as little as you have to do in order to meet DTN
>>>>>> requirements.
>>>>>> 
>>>>>> Why? HTTP/2.0 will have an extensible binary encoding with
>>>>>> a lot of real work done on compression (way more than was
>>>>>> ever done with the BP already) and if we had a DTN variant
>>>>>> of that then we could probably leverage a lot of other
>>>>>> folks' code and far more easily deploy lots of DTNs. (You
>>>>>> could just forget different platform ports being a huge
>>>>>> challenge for example.)
>>>>>> 
>>>>>> know how to transport all interesting content types (using
>>>>>> MIME) again making integration with loads and loads of
>>>>>> applications much easier.
>>>>>> 
>>>>>> though for fewer applications than claimed), then all ICN
>>>>>> approaches (not to mention CDNs) also have to have an HTTP
>>>>>> story, so we start from being close-to-covered in that
>>>>>> respect too.
>>>>>> 
>>>>>> and some form of CL-like concept would be needed for cases
>>>>>> where TCP breaks (maybe DTLS/LTP or just LTP?), with a
>>>>>> different state machine from HTTP's, but those seem quite
>>>>>> doable. The latter does mean that 5050bis would not
>>>>>> directly interop with the web when links can't use TCP, but
>>>>>> in many DTNs, links can use TCP. And even when you can't
>>>>>> when we met last time in Google. In fact, a bunch of us
>>>>>> have almost done that kind of gatewaying already when we've
>>>>>> done web stuff via 5050 in various DTN deployments with
>>>>>> Lloyd in fact suggested something similar quite a while ago
>>>>>> and has kept an I-D more-or-less up to date. [1] That's
>>>>>> worth looking at but I think HTTP/2.0 offers a much better
>>>>>> starting point than HTTP/1.1 and one that wasn't available
>>>>>> when Lloyd was writing earlier. (Since the choice of SPDY
>>>>>> for HTTP/2.0 only happened last year.) For example,
>>>>>> HTTP/2.0 promises much better avoidance of head-of-line
>>>>>> blocking, which fits nicely with the idea of DTN routing I
>>>>>> think. With HTTP/1.1 I suspect you'd need much more open 
>>>>>> heart surgery on code to get it to do the kind of thing
>>>>>> that'd be needed.
>>>>>> 
>>>>>> Anyway, that's my €0.02 for now. I do hope to get a chance
>>>>>> to develop the argument beyond the arm-waving stage before
>>>>>> Berlin but I suspect I won't get time. I'd be delighted if
>>>>>> someone else wanted to push that along and would be happy
>>>>>> to help 'em out as time permits.
>>>>>> 
>>>>>> Cheers, S.
>>>>>>

---

From: "Scott, Keith L." <[email-masked]>
Date: Tue, 28 May 2013 15:22:28 +0000

Stephen et. al.,

Can we identify the 'high-order-bit' on how SPDY would/could deal with non-contemporaneous end-to-end paths?  That (to me) is the heart of what DTN does, and the thing that Internet protocols don't do so well.  Good compression, MIME encoding, etc. are all good, but could be incorporated into the current 5050-like implementation  as well / separately from a conversion from 'classic' BP to SPDY (I would think; I too will be reading up on HTTP2.0).

If we could get a notion of how a SPDY-based approach would deal with paths involving disruptions / data mules I think that would go a ways toward seeing how much of 5050-like DTN would or would not have to be ported to SPDY (i.e. how much of 'classic' BP would have to be 're-done' for an http2 approach).

Addressing has also always been interesting in DTN, and we might be able to come up with a few concrete proposals for how it might work in the http2.0 world.  Things like: do we support one or multiple address spaces?  How much does a source have to know about the existence / location of a destination address before sending, etc.

		--keith

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Sunday, May 19, 2013 5:43 PM
To: Vint Cerf
Cc: DTN interest
Subject: Re: [dtn-interest] 5050bis - a different approach - SPDY it up!

Hiya,

S.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 28 May 2013 16:33:22 +0100

Hiya,

> If we could get a notion of how a SPDY-based approach would deal with paths involving disruptions / data mules I think that would go a ways toward seeing how much of 5050-like DTN would or would no…

<arm-waving>

For DTN hops that can use TCP, then use that. The e2e path is
like a series of forward HTTP proxies but where requests and
responses are queued for significant periods which means a
different state machine, but the messages should be almost
the same.

Not sure how easy it might be to use a different reverse
path, which is probably needed and would again be a different
state machine, or perhaps where a different reverse path is
desirable requests would just get the moral-equivalent of
200 OK and no response body and all real responses would
look like new POST-method requests back to where they need
to go.

Where TCP breaks, we'd need some form of CL. Which could be
like the LTPCL perhaps. But otherwise the e2e path is as for
the above TCP case.

</arm-waving>

So, significant arm-waving, yes. But if it could work and
could lead to a lot of code re-use and possibly even the
ability to use current servers on well-connected parts of
paths, then it might be a real winner.

Or, maybe I'm just wrong and its broken;-)

S.

---

From: "Scott, Keith L." <[email-masked]>
Date: Tue, 28 May 2013 15:53:08 +0000

Stephen,

OK, so using this approach (assuming your hand-waving results in the correct magic) we could still support unidirectional links (getting acknowledgements or any other required reverse-traffic via a different reverse path) and, if we chose to carry it forward, custody transfer.  I'm willing to stipulate for now that we could graft as many / the correct types of CLs underneath as we need and that they could do all sorts of interesting transformations (e.g. gzip, deflate) on the data.

So I think a big piece of the augmented state machine / proxy would be how to reconcile end-to-end addressing (included in the HTTP header?) with the hop-by-hop (CL) addressing that for the moment we could just say is / model as IP.  Do you have (or does anyone have) particular thoughts on how that would work, or is that TBD?

		--keith

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Tuesday, May 28, 2013 11:33 AM
To: Scott, Keith L.
Cc: Vint Cerf; DTN interest
Subject: Re: [dtn-interest] 5050bis - a different approach - SPDY it up!

Hiya,

<arm-waving>

</arm-waving>

S.

---

From: <[email-masked]>
Date: Wed, 29 May 2013 00:22:21 +0100

Keith,

See
http://sat-net.com/L.Wood/dtn/http-dtn
Which has a discussion of how to do end-to-end addressing, thoughts on convergence layers for http , etc.

Be very careful in using the word 'proxy'. The web proxy model does not map well to a disconnected DTN.

Also remember that SPDY is designed as a transparent compatible upgrade/optimisation/binary restructuring of http - there is a reason it's called SPDY. Get http working first as the base model, then decide what parts of SPDY can be used in this new model. (Compression is likely an http/spdy function, not a CL function)

Otherwise, it's a bit like importing your sports car to the Solomon Islands and breaking an axle on the roads (true story). Those just aren't the conditions the transport is optimised for - but a less speedy http truck willk work over a wider range of conditions.

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Scott, Keith L. [[email-masked]]
Sent: 28 May 2013 16:53
To: Stephen Farrell
Cc: DTN interest
Subject: Re: [dtn-interest] 5050bis - a different approach - SPDY it up!

Stephen,

                --keith

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]]
Sent: Tuesday, May 28, 2013 11:33 AM
To: Scott, Keith L.
Cc: Vint Cerf; DTN interest
Subject: Re: [dtn-interest] 5050bis - a different approach - SPDY it up!

Hiya,

<arm-waving>

</arm-waving>

S.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 29 May 2013 01:16:30 +0100

Hi Lloyd,

> Which has a discussion of how to do end-to-end addressing, thoughts on convergence layers for http , etc.

Been a while since I looked at that, must go back to it.

> Otherwise, it's a bit like importing your sports car to the Solomon Islands and breaking an axle on the roads (true story). 

Ouch:-(

> Those just aren't the conditions the transport is optimised for - but a less speedy http truck willk work over a wider range of conditions.

You may be right. My guess is otherwise, but just a guess - but I think
for either HTTP/1.1 or SPDY one has to deviate from the existing state
machine for at least some hops, so I don't think there is an "http
truck" nor a spdy truck, but we're rather in the business of
bastardising one or other of http/spdy in this argument.

S.