Re: [dtn-interest] updated bundle checksum draft, slides for discussion

[Lloyd Wood <[e-mail]>]

Hi Rajesh,

some answers in brief here below to lay out my thinking around
http://tools.ietf.org/html/draft-wood-dtrng-http-dtn-delivery-01

At Tuesday 11/03/2008 20:18 -0400, Rajesh Krishnan wrote:
>Disclaimer: these are my personal views, not of my project, employer, or funding agency.
>
>Lloyd,
>
>Thanks for the briefing in advance, especially since I will not be there in Philly.
>
>An interesting proposal, but could you explain to me the primary purpose 
>and motivating requirement for HTTP-DTN please.  

Well, because we could. (and we can present it here in this research group to an
audience likely to have at least a passing interest.)

We'd been thinking about putting MIME'd files into bundles for a project, got to figuring
out that MIME objects could be delineated in each bundle via http instead of messy
custom encapsulations we made up, and suddenly realised that that was an http stream,
and that a continuous persistent pipelined http stream was the simple minimum necessary.
Creating Content-Destination: clinched it.


>I want to hear from you 
>about both upsides and downsides to adopting HTTP-DTN. 

    upside: it's not the bundle protocol.
downside: it's not the bundle protocol.


>Some questions/provocations that will aid me in better understanding the motivation:
>
>* Would the IETF EDIINT RFCs/I-Ds already cover your requirements for HTTP-DTN?
>  Or is EDIINT too specialized a domain?

EDIINT AS1 (RFC3335) depends on SMTP, and SMTP brings with it a lot of assumptions
about the infrastructure it depends on - DNS, MX records - even before the 'is this SMTP
still 7-bit?' question is raised. SMTP is rather chatty, with many timers. HTTP is less so.

The newer AS2 (RFC4130) is HTTP - interesting, thanks for pointing it out. But it's using
POST, is very transactional, and presumes an end-to-end http path as a result, which I
don't think is a good fit with ad-hoc DTN networks or long delays, or the use of http
hop-by-hop here, where PUT is more relied on. And a lot of email headers and email
assumptions about infrastructure (e.g. Message-ID, Disposition-Notification-To:) do
creep into AS2. It's really a port from email and AS1 to http, still with email dependencies.

AS3 (RFC4823) uses ftp - unlike http, not something that can be easily abstracted away
from TCP. I don't understand why this was created after AS2 http; http or scp seem
better starting points.

(I've no idea whether EDIINT's chosen security model would make sense in any DTN
environment.)


>* It appears folks are already doing similar things with HTTP/SOAP in the agent 
>  middleware world (e.g., www.cougaar.org)? They even seem to support a number of 
>  other messaging application protocols.  Would those solutions satisfy 
>  your current requirements that motivate HTTP-DTN, or do you see a real
>  need for a DTNRG specification in this area?  Such a need to me suggests
>  potential killer apps lurking for DTN, and I would sure like to hear of them.

HTTP-DTN can be an enabler for SOAP in DTN environments, in that SOAP expects
MIME and runs over HTTP. (Discussed in my answer to Stephen on the list when the
draft was first announced.)

So, if anyone wanted to run SOAP in an ad-hoc environment where nodes peer to pass
on information, I think something like HTTP-DTN would be required first as basic
supporting infrastructure.


>* Why not write a HTTP-CLA instead?  Why should DTN necessarily sit on top 
>  of the transport layer or any other specific layer for that matter?  As 
>  long as a suitable CLA is available, why not just do DTN over it?  Would
>  a HTTP/SOAP-CLA not achieve your goal?

What makes the Bundle Protocol compelling for DTN? Layering the BP over
HTTP/TCP wouldn't add much to the existing TCP/UDP convergence layers,
while losing access to MIME and the flexible HTTP headers.

(We've already adapted the Saratoga protocol as a convergence layer for the
Bundle Protocol:
http://tools.ietf.org/html/draft-wood-dtnrg-saratoga-03
- if all you want to do is already in the Bundle Protocol and that meets your
needs, then creating BP-specific convergence layers for your operational
scenario would be the right thing for you.)


>* Seems one can define a SMTP-DTN using the X-* headers too.  Why fragment 
>  the DTN world into BP-DTN, HTTP-DTN, SMTP-DTN, ...? 

Well, SMTP brings with it infrastructure and assumptions - see above.

Different scenarios with different needs may benefit from different tools.

>  I doubt that we 
>  will have a better/faster Internet if IP-datagram alternatives were 
>  ubiquitous.

MPLS is pretty widespread, and arguably contributed to that faster Internet.
Also, there's IPv6, the alternative to IPv4... and, for where the core of the
Internet is going, it's interesting to talk to Stewart Bryant on pseudowires
for core trunking of traffic. These are alternatives to IP, and they're
increasingly widespread.

But this is low-level plumbing down below application communication,
which I gather from your note is not really your area of interest.


> * HTTP is associated with a client-server model of the world, 
>  while DTN seems to try to move to a distributed, content-oriented 
>  world that may frequently not admit contemporaneous end-to-end paths.  
>  While HTTP itself can be torqued to such a distributed model, and you show 
>  one way to do it, the whole software infrastructure, tools, and mindset
>  surrounding the HTTP world will be from the client-server, end-to-end stable path 
>  view of the world.  Will HTTP-DTN fragment the web world into two halves 
>  requiring different mindsets and tool chains to do HTTP?   You can tell
>  me this is a red herring, and I won't mind. :)

Yes, HTTP-DTN is separate (use of new Content- headers guarantees it).

So there are two separate pieces - not halves, because one will always be vastly
larger than the other. Yes, the mindsets are different - no proxying; the end-to-end
http model is changed to a series of hop-by-hop http sessions along a path. It's an
interesting question as to how much of the toolsets can be reused usefully - or how
much you'd want to reuse them.

With its focus on MIME for content identification, http is all about content networking.


>* Why should HTTP be perpetuated as the new waist, why can't another new waist
>  emerge over time (and make HTTP pay for snatching that position from IP :) ?

HTTP-DTN can become the waist for its particular networks, as the glue
everything works to - and the idea of separating HTTP from TCP to create a truly
independent session layer is also interesting for research.

For other networks - Rosenberg has a draft in currently about how TCP/UDP are really
the real waist of the terrestrial internet due to NAT and firewalls discouraging anything
else.

Over time, stacks collapse, new chokepoints emerge, depending on the architecture
and what is being done. There's probably an argument for many apps that their
middleware is the waist as far as the applications are concerned, in that that
middleware hides many lower-level dependencies from the apps.

But that is high up, and http-dtn is down in the lower protocols and the plumbing.


>I want to take a general long-term networking research standpoint and currently 
>do not have commercial product experience/pressures.  I can imagine packet switching 
>that is not based on IP (I may get voted off the island for saying this :), and I
>can imagine content networking not based on HTTP/SOAP/XML.  

...while I can imagine DTNs not based on the Bundle Protocol.


>I have a rather romantic 
>notion of the BP evolving and supporting a clean-slate (yes I have read Dovrolis' 
>paper :) future Internet.  That is, with the BP being the slate that the new design 
>is written on.  I am being naive and unreasonable perhaps.

I don't see anything compelling in the Bundle Protocol to support that view.


>Schemas/Ontologies to populate the metadata extension block (to support content 
>networking), fast BP forwarders, and policy-based control of content networking 
>are some interesting research topics in this space.  I would like this RG move 
>up the value chain, and not get stuck in low-level protocol encapsulation and 
>message formatting issues. 

I don't see much point in moving up the stack unless the fundamental low-level issues
are worked out satisfactorily. Hence our ongoing discussion of reliability in the BP.
Getting the plumbing right for the environment means that you can build vast cities
in the environment around that plumbing. But the plumbing has to be right.

Also, there's an argument that the longest-lived protocols are always the flexible,
text-based ones, which are best suited to expressing metadata etc. Possibly one
reason why text http displaced binary gopher. And why XML is gaining adoption.

(Speaking of binary, I see
http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-sdnv-00.txt
expires next week...)

> (A shared encapsulation for DTN helps build critical mass 
>in the research community,  and future versions can fix shortcomings as needed and
>experience is gained, but a second encapsulation provides diminishing research 
>returns. I understand there may be other pragmatic considerations though.)

I think other approaches are also valid research topics that can provide rich
research returns. As a veteran of European research projects into ATM back when
Europe was funding only ATM networking projects, I'm sceptical of 'one chosen way',
and not a great fan of groupthink. The critical mass of European research into ATM
really didn't achieve much...


>So, from where I stand, I see that the BP-DTN buys me a more-or-less clean slate 
>without much baggage since I am not interested in the encapsulation per se.  

Yet from where I sit, http-dtn gives me a clean slate with a lot of tools that
I can choose to add to that slate.

thanks for looking at our work,

L.

>Who 
>is to say some good ideas from DTNRG can't eventually make their way back and get 
>retrofitted into incumbent Internet technologies including HTTP, but I worry if 
>it may be premature to force the DTNRG down that path.  Again, just speaking for 
>myself.
>
>For some of my other thoughts on DTN, see for example:
>http://advika.net/rkrishnan/talks/rkrishnan-coin-neu07.ppt
>
>With apologies for sending a long email and including shameless plugs.  ;)
>
>Best Regards,
>Rajesh
>
>P.S.:  I will disengage promptly and run away if anyone flames me, for I have 
>lots of other non-flaming dragons to slay.  :)

Saratoga: http://www.ee.surrey.ac.uk/Personal/L.Wood/dtn/

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[e-mail]>