[e2e] Revisiting RON ("traffic engineering considered harmful"

[Jon Crowcroft]

In message <200110210205.f9L25Hk02106 at central.cis.upenn.edu>, "Jonathan M. Smit
h" typed:

 >> Hi Jon - as always thoughtful comments. After thinking about RON a bit more,
 >>I think of it as placing a router in the host. Thus, ALAN is a generalization
 >>as it could implement the RON algorithms as well as others.
 >>	I think many of the criticisms of AN proferred in the SIGCOMM and
 >>e2e communities are rather unthoughtful. Much of the bad feeling this
 >>community feels has nothing intellectual backing it - it is a resentment
 >>cropping up from DARPA funding active networking at the same time that some
 >>of the Internet community's research funding was discontinued. Many folks
 >>incorrectly believe that there was some malicious causality linking these
 >>two events. Not so. Correlated not causal, yet such an eminence as VJ more
 >>or less blasted active networking for exactly this at the 1997 SIGCOMM
 >>debate that had Dave Sincoskie and I pro-AN and Jon C and Van anti. 

there were several questions in that specific debate which were raised
by the "anti" community based on 
i) requirement
ii) halting problem
iii) other more complex vulnerabilities

I belive that the current debate on e2e's fragile real-world
cliffhanger of survival has exposed that the first is there (which
wasn't obvious back then - overlays are a resposne ot the problem that
obviates active routers or switches, but still fit in the same space)

I don't spose anyone has gainsaid turing recently, but
iii) seems to have been tackled by you and some of the AN community
pretty comprehensively...

 >>	The reality is that some of us in the networking research community
 >>believed that a way to introduce services faster was needed. While the
 >>WWW provided an overlay that was useful for many high-level services, there
 >>were a bunch of purpose-built network-embedded functions appearing: NATs,
 >>firewalls, etc. Why not make a beautiful general-purpose environment that
 >>could be used to add new services, allowed them to be tuned to play nice
 >>with TCP, etc.? That was the goal. While capsules were an interesting
 >>extreme case, they proved to distract too much energy away from the larger
 >>goal of providing an environment for adding new services. So people are
 >>attacking incrementally rather than head-on: FIRE, packet-marking.
 >>	But intellectually, you are going to get back to the logical
 >>equivalent of the problem IP was designed to address: interoperability.
 >>The set of these purpose-built services begins to resemble the purpose-built
 >>networks that an INTER-(Latin for between)-network was intended to weave
 >>into a useful fabric. Then some set of folks will remember that some folks
 >>in the late 90s looked into this, devise a good standard after reflecting on
 >>the lessons, and embed it in the commodity Internet.
 
aha - actornets then?
 

 cheers

   jon