[e2e] end of interest

[Rajesh Krishnan]

John, and others,

Hello, from a long-time lurker.

> >I don't think it said don't bother touching TCP and below so much as said
> >they don't matter.  That's certainly what Van said in a more recent talk.
> >And I think it is right -- if you think you have a game changing paradigm
> >that can work over existing stuff but might work better over new stuff,
> >focus on your core idea -- if it works, the rest of the network will
> >morph to support it.
> 
> Some time ago, Microsoft had the same idea about dealing with having 
> half an operating system.  Didn't work for them, not going to work 
> here.  Overlays are building on sand, or trying to sweep the mess 
> under the layer.  They can't fix what is fundamentally an incomplete 
> architecture.

Would it be blasphemous to suggest here that the TCP/IP Internet pretty
much grew as an overlay on a network designed to do voice?

When we take an IP-centric thin-waist view, we can usually ignore the
fact that indeed there may be another Layer 3, (or in fact an entire
protocol stack that we will reduce to a Layer 2 interface) below.  The
power of abstraction works great until the underlying problem changes
radically.

Several decades ago, did packet switching fix an incomplete
architecture, or did it just change the problem?  What if we could
repeat that, especially if as Van suggests the key problem to solve has
indeed changed?  What if we only got another incomplete architecture
that offered a different value proposition from IP, just as IP offered a
different one from the phone network, but still arguably incomplete?

As a practical matter, suppose we wanted to experiment with different
abstractions that addressed storage concerns at the network layer and
not insist that is an application layer concern.  Suppose we wanted to
move from content-agnostic, topology-obsessed ;) abstractions to ones
that focused on reachability to descriptively named/tagged content.
Our choices of deployment strategy include:

  (i)  build everything from scratch, and reinvent a lot

  (ii) focus on the new abstractions, but roll it out as an overlay 
       over the Internet, and if successful, who knows the core
       infrastructure may morph to match as Craig suggests

I believe the latter strategy is more likely to succeed (unless a
from-scratch solution that goes after a need that is under-served by the
Internet succeeds and eventually moves up-market -- borrowing ideas from
Christensen's book "The Innovator's Dilemma").  In any case, overlays
are a cheaper way to weed out the evolutionary dead-ends.

Networks seem to need a critical mass of adoption, and usually an
evolutionarily smart vector to succeed.  The DTN Bundle Protocol (or its
successor, with metadata extension block semantics that will hopefully
remain flexible and user-definable) might just offer an opportunity for
acquiring a new critical mass, but only if it finds the smart vector
(that does what Mosaic did for HTTP/HTML, and perhaps BSD for TCP/IP).

I think overlays or middleware by some name or the other are inevitable
(and perhaps even symptomatic of the network having failed us in some
way :).  Do we want a million fragmented stove-piped overlays that can
never talk to each other, or should we attempt to change the (level of)
abstraction for the services provided the network?

Best Regards,
Rajesh