[e2e] Open the floodgate

[David P. Reed]

Regarding routing at the endpoints: source routing was seriously advocated 
by a set of people that includes yours truly, Jerry Saltzer, Dave Farber, 
Dave Clark, etc. as a plausible and logical approach.   Most of the 
arguments for it, and a proposed architecture were presented in our paper 
"Source Routing for Campus-wide Internet Transport", and also in the 
protocol portion of our invited IEEE Proceedings paper - "An introduction 
to Local Area Networks". (both were written in the 1977 timeframe).  We had 
some success in getting the idea out: the architecture was used in creating 
the source-routing options of the IP layer.

The reason "campus-wide" appeared in the title was in my recollection 
largely "political" within the ARPA community.   The ARPANET routing 
community (McQuillen, et al) thought the idea was absurd, and our concerns 
about decentralizing and scalability out to billions of nodes were best 
made in a "campus" context where the idea that the infrastructure would be 
owned by an "AT&T" was not possible.   We believed that the "campus" issues 
in that paper applied to collections of independently administered networks 
even more so.   But the innovation was going to happen at the edges, not 
the benevolent dictatorship of the "center" - be it AT&T or ARPANET.

I think we were right in our intuition, but wrong in not fighting to make 
source routing services become one of the active areas of research in the 
Internet (part of the reason is my own fault, as one of the advocates I had 
to finish my Ph.D. and move on - my work on higher level distributed 
systems architectures at the endpoints was more productive, given the small 
scale of the Internet experiment for the next 10 years).

Now it's very clear that the Internet MUST accomodate decentralized 
management and decentralized control - and some kind of source control of 
routing makes sense.   In the case of wireless networking, the nature of 
propagation is such that end nodes that are radios must cooperate globally 
- there is no "isolation" called an "ingress point" - thus sources must 
cooperate in routing, congestion control, etc. because of the physics that 
results from lack of wires.  (that research is the essence of what we ca'l 
"viral radio").


At 10:13 PM 4/28/2004, Jonathan M. Smith wrote:

>Hi Bob, not clear. I think the issues are two: where you maintain state
>(i.e., reachability information) and how out of date this information becomes
>by the time it needs to be used, something which is at least partially
>a function of propagation delay, partly a function of how rapidly the
>information
>changes, and partly a function of how often it needs to be used. It seems
>to me not at all outrageous to think of discovering, maintaining and using
>routes entirely at the end points. It's perhaps an interesting coincidence
>that I have recently been reading Waldrop's "Dream Machine", which whether
>accurate or not (it seems so to me) argues that the real reason for IMPs
>rather than pure E2E (as we know it today) was that the operating system
>folks at the time (working on GENIE, MULTICS, etc.) would have been
>overwhelmed,
>and thus Wesley Clark of Wash U. suggested outboard packet switches. I wasn't
>there, but it is interesting to speculate how things might have evolved
>differently.
>
>Thanks,
>-JMS
>
> >
> >   *>
> >   *> so the one thing you could "add" in the network is somethign that we
> >   *> discussed on this list before (i think it was JMS who put it that the
> >   *> real purist end2end thing would be to take routing decisions out 
> of the
> >   *> net and put them in the end systems too along with error recovery) -
> >   *>
> >
> > If putting routing entirely in end systems were a consequence of strict
> > application of the E2E arguments, then I would say that the E2E
> > arguments must be wrong or at least incomplete.  But I don't believe
> > that is a correct deduction.  Datagram routing cannot be done
> > effectively by end systems alone (you encounter problems of robustness
> > and scalability), so it is not really a candidate for movement up the
> > stack and towards the edges.
> >
> > Bob Braden
>