Subject: Re: [icnrg] FW: New Version Notification for draft-kutscher-icnrg-netinf-proto-00.txt,

From: <[email-masked]>
Date: Fri, 5 Oct 2012 10:12:37 +0100

Well, this NetInf (ni:) effort is interesting.

I am reminded of Monty Python's 'The Knights that say "Ni"'
from the Holy Grail. Except, in this case, it's the-authors-who-
say-ni-formerly-known-as-the-authors-that-said-dtn.

As in the Grail, there were words that, when said, had odd
effects on the authors-that-said-dtn: these included
'reliability' and 'MIME'.

In the world of delay-tolerant networking, just a research
group over from here, the bundle protocol did not need MIME -
even though dtn networks, like all networks, have to move
content around. Good to see that this ni effort uses MIME
"for significant specification and code re-use. For example,
we do not need to invent a new typing scheme nor any
associated registration rules nor registries."

It's a shame that such arguments never went far with
the bundle protocol.

Like dtn and the bundle protocol (and CFDP before it),
ni adopts convergence layers, to avoid the effort
of engineering a new transport and getting bogged
down in transport issues. Sensibly, in the ni draft below,
section 3 calls out the requirements that convergence layers
must meet:
"   Each CL has to offer the following minimal set of capabilities:
   o  unidirectional point-to-point transport of NetInf messages from
      source to destination,
   o  preservation of message boundaries,
   o  reliable transmission of message octets, and
   o  in-order delivery of message octets to the destination node."

Unfortunately, neither of the convergence layers proposed in the
draft meets those stated requirements: neither HTTP or UDP is by
itself reliable. (And, strictly speaking, neither is really much good as
a transport.)

HTTP would need Content-MD5: or similar as a minimum; UDP needs
a transport shim like LTP or Saratoga. And HTTP and UDP aren't
remotely similar in semantics or capabilities, in terms of message size,
security capabilities, content identification (MIME is not a port), etc.

Treating them as equivalent convergence layers is just wrong.
The bundle protocol tried treating UDP and TCP as equivalent; that
didn't work too well.

If the convergence layer doesn't offer reliability, perhaps the ni layer
running over it could do so? Apparently not. The bundle protocol has
that problem too.

Funnily enough, leveraging HTTP for content delivery has been
looked into before:
http://tools.ietf.org/html/draft-wood-dtnrg-http-dtn-delivery
http://sat-net.com/L.Wood/dtn/http-dtn.html

but since that was submitted in the dtnrg group, it never gained the
approval of the authors-who-said-dtn. That's proposing a bit of
re-engineering of the network stack to turn http into a layer in its
own right, supported by multiple transports - or convergence layers.

Once that's in place, building everything on http is much easier.
So http isn't just one convergence layer for a new protocol; it
becomes the common substrate for an ecosystem.

And something like ni becomes rather simpler, being
able to leverage rather than reinvent aspects of http; publish and
subscribe always map to http PUT and GET semantics, rather than
floundering over UDP.

But that was proposed in the wrong group, at the wrong time.
Really, dtn's funding bubble is waning, and content networking's is
waxing; it's a new paradigm for old ideas.

Bring out your dead ideas! We collect them!

L.

"Look, matey, I know a dead protocol when I see one, and I'm
looking at one right now." - with apologies to the Blue Norwegian Parrot.

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

***

Hello,

We have written up a specification of the NetInf protocol and submitted this as an Internet Draft today (see link below).

This includes a description of some underlying concepts, a specification of a message-based protocol, and a specification of HTTP and UDP convergence layers for the protocol.

Most of this is implemented in the Open Source NetInf software: http://sourceforge.net/projects/netinf/

We'd appreciate any feedback.

Thanks,
Dirk

-----Original Message-----
From: internet-drafts at ietf.org [mailto:internet-drafts at ietf.org] 
Sent: Donnerstag, 4. Oktober 2012 10:07
To: Dirk Kutscher
Cc: davieseb at scss.tcd.ie; stephen.farrell at cs.tcd.ie
Subject: New Version Notification for draft-kutscher-icnrg-netinf-proto-00.txt

A new version of I-D, draft-kutscher-icnrg-netinf-proto-00.txt
has been successfully submitted by Dirk Kutscher and posted to the IETF repository.

Filename:	 draft-kutscher-icnrg-netinf-proto
Revision:	 00
Title:		 The NetInf Protocol
Creation date:	 2012-10-04
WG ID:		 Individual Submission
Number of pages: 21
URL:             http://www.ietf.org/internet-drafts/draft-kutscher-icnrg-netinf-proto-00.txt
Status:          http://datatracker.ietf.org/doc/draft-kutscher-icnrg-netinf-proto
Htmlized:        http://tools.ietf.org/html/draft-kutscher-icnrg-netinf-proto-00

Abstract:
   This document defines a conceptual protocol and corresponding node
   requirements for NetInf nodes in a NetInf network.  A NetInf network
   offers an information-centric paradigm that supports the creation,
   location, exchange and storage of Named Data Objects (NDOs).  NetInf
   nodes can provide different services to other NetInf nodes, e.g.,
   forwarding requests for information objects, delivering corresponding
   response messages, name resolution services etc.  This (abstract)
   protocol is intended to be run over some "convergence layer" that
   handles transport issues.  Two "wire" formats are defined, one that
   uses HTTP for message transfer and one layered on UDP.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 05 Oct 2012 11:03:25 +0100

Hi Lloyd,

I see the drum you constantly bang hasn't broken:-)

I'll not bother addressing your stale dtn-related gripes
but there are a couple of substantive points in your mail...

On 10/05/2012 10:12 AM, [email-masked] wrote:
>
> Sensibly, in the ni draft below,
> draft meets those stated requirements: 

I agree that we've not yet sorted this. That's the nice thing
about -00 drafts and experimental code, they can get fixed.

> neither HTTP or UDP is by
> a transport shim like LTP or Saratoga. 

That's worth considering. To be honest, we're not sure what
protection netinf messages need in this respect given how
nodes can change responses and given the ability to verify
name-data integrity.

Content-MD5 for the HTTP-CL might be useful/good-enough and
is worth a look though, or it might be better to add a checksum
and/or (and I know you'll love this:-) the ability to sign/MAC
into the NetInf messages themselves. We've thought about that
but haven't landed on answers we're really happy with so far.

> And HTTP and UDP aren't

True. The UDP CL is intended more for particular cases that
we've not documented in the draft yet. The idea is to use UDP
mainly for dealing with/finding a name resolution service
rather than for potentially large objects. We figured it was
better to start documenting it though.

Regards,
S.

---

From: <[email-masked]>
Date: Sat, 6 Oct 2012 02:44:05 +0100

Stephen,

alas, as the deficient designs of LTP-T and the bundle protocol have demonstrated,
that reliability drum has to be banged.

Fixing problems with -00 drafts is the normal way of things, when new concepts
are tried, described, and fleshed out. However, I am concerned that your
new icnrg draft hasn't learned anything from five years of thinking about
convergence layers in the dtnrg, and is now proposing exactly the same
mistakes to a new audience. If my dtn-related gripes are stale, so are your
'new' dtn-related ideas.

Lloyd Wood

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Stephen Farrell [[email-masked]]
Sent: 05 October 2012 11:03
To: Wood L  Dr (Electronic Eng)
Cc: [email-masked]
Subject: Re: [icnrg] FW: New Version Notification for   draft-kutscher-icnrg-netinf-proto-00.txt,

Hi Lloyd,

Regards,
S.

---

From: Dirk Kutscher <[email-masked]>
Date: Tue, 9 Oct 2012 16:58:49 +0000

Lloyd,

This is something different than the Bundle protocol. Regarding reliability, the one option (not specified in the draft) is that you'd use a (receiver-driven) transport protocol on top -- for example with the NetInf UDP CL.

Best regards,
Dirk

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Samstag, 6. Oktober 2012 03:44
> To: [email-masked]
> Cc: [email-masked]
> alas, as the deficient designs of LTP-T and the bundle protocol have
> demonstrated, that reliability drum has to be banged.
> 
> Fixing problems with -00 drafts is the normal way of things, when new
> concepts are tried, described, and fleshed out. However, I am concerned
> that your new icnrg draft hasn't learned anything from five years of thinking
> about convergence layers in the dtnrg, and is now proposing exactly the
> same mistakes to a new audience. If my dtn-related gripes are stale, so are
> your 'new' dtn-related ideas.
> 
> Lloyd Wood
> I'll not bother addressing your stale dtn-related gripes but there are a couple
> of substantive points in your mail...
> 
> > section 3 calls out the requirements that convergence layers must
> > meet:
> > Unfortunately, neither of the convergence layers proposed in the draft
> > meets those stated requirements:
> 
> I agree that we've not yet sorted this. That's the nice thing about -00 drafts
> and experimental code, they can get fixed.
> 
> > itself reliable. (And, strictly speaking, neither is really much good
> > as a transport.)
> >
> > HTTP would need Content-MD5: or similar as a minimum; UDP needs a
> > transport shim like LTP or Saratoga.
> 
> That's worth considering. To be honest, we're not sure what protection
> netinf messages need in this respect given how nodes can change responses
> and given the ability to verify name-data integrity.
> 
> Content-MD5 for the HTTP-CL might be useful/good-enough and is worth a
> look though, or it might be better to add a checksum and/or (and I know
> you'll love this:-) the ability to sign/MAC into the NetInf messages
> themselves. We've thought about that but haven't landed on answers we're
> really happy with so far.
> 
> > And HTTP and UDP aren't
> > remotely similar in semantics or capabilities, in terms of message
> > size, security capabilities, content identification (MIME is not a port), etc.
> 
> True. The UDP CL is intended more for particular cases that we've not
> documented in the draft yet. The idea is to use UDP mainly for dealing
> with/finding a name resolution service rather than for potentially large
> objects. We figured it was better to start documenting it though.
> 
> Regards,
> S.
> 
> _______________________________________________
> icnrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg