[e2e] end of interest

[Jon Crowcroft]

In missive <4827081A.1090305 at reed.com>, "David P. Reed" typed:

 >>I'd suggest that first-principles thinking is harder than Jon thinks.   

gosh - i thought I just wrote something - i didnt realize andy lipmann's 
medialab goal of telepathy had already  been reached and you could figure out
how hard I thought first principles thinking is....thats neat - 
if you can teach the rest of us that trick, we
could save a lot of bandwidth and carpal pain

one of the first principles of architectural thinking is that 
architectures are not created fully formed by some smart person 
(no matter who gets the credit) but are in fact
emergent from a bunch of work that is teasing out
problems and partial solutions around the cracks of an earlier
system

what i was suggesting is that snooping is just such a piece of work.
as are other layer "violations"

to claim that the internet was not layered is pretty imaginative - 
the ncp->tcp/ip split and the bezerkeley socket code 
(and early System V and MIT C code) stacks were just that: stacks. 
OSs were layered at the same time (as were most systems)

to pretend that the consequences of different ways of component thinking
were intellectually  avaialble to people before the 1980s would be 
fairly far fetched....

indeed the work by tenenhouse and clark way way after the layering religion on
application layer framing, and integrated layer processing betray a DEEP embedded 
layerist mode of thinking -  why not? it served incredibly well, in terms of seperating
concerns and defining tussle spaces and software/hardware (pace, hennesy/patterson) 
division of labour

 >>It's not just a matter of choosing sides in a war, or acting as an arms 
 >>merchant to both sides.   It's about thinking more squarely about the 
 >>real underlying issues that comprise communications . In fact, as some 
 >>of us have suggested, perhaps the idea that communications can be 
 >>considered as a "pure" architectural/linguistic frame independent of 
 >>storage and computation and sensing is the real issue we ought to be 
 >>addressing today, with pervasive comms/storage/computational elements 
 >>capable of all three.

sure  - we have a number of NEW ideas on the table now that were not present the
last time around - lets work with them, shall we?
 
 >>John Day wrote:
 >>> At 9:08 +0100 2008/05/11, Jon Crowcroft wrote:
 >>>> nice example of 0nership by warring protocol layer factions
 >>>>
 >>>> mesh wifi people need to learn to do layer 3 snooping
 >>>> same way telecom people did...
 >>>
 >>> The need to do snooping is an indication of the current model's 
 >>> inability or refusal to innovate.  A failure to dig more deeply into 
 >>> the model.  (Or a fear to challenge their religion.)
 >>>
 >>> (It turns out once there is a complete architecture, not one of these 
 >>> DOS look-a-likes, snooping isn't necessary.)
 >>>
 >>>>
 >>>> there's a great e2e topic -
 >>>> we have sort of gotten out of the
 >>>> denial phase on middle boxes and
 >>>> we're probably ok with multicast's niches now ...
 >>>
 >>> Middleboxes are alos an artifact of an incomplete architecture.  In a 
 >>> full (shall we say, a wff) architecture, they aren't necessary.
 >>>
 >>>>
 >>>> but should we raise the
 >>>> art of _snooping_ to being a
 >>>> first class component of any decent
 >>>> postmodern internet architecture?
 >>>
 >>> No, snooping is an admission of failure.  Calling it a component of a 
 >>> "decent" internet architecture is merely making excuses for our failures.
 >>>
 >>>>
 >>>> knowing
 >>>> multicast group members locations from lookin at IGMP traffic from 
 >>>> "below"
 >>>> is one exxaple (think dslams too) but another would be
 >>>> P2P aware Traffic Engineering, for example
 >>>
 >>> Recognizing that a multicast address is the name of a set deals with 
 >>> most of this.  (Of course, this means that strictly speaking multicast 
 >>> addresses aren't really addresses but names.) A multicast or anycast 
 >>> address must always resolve at some point to a normal address.  The 
 >>> idea of a multicast address as an ambiguous address is fundamentally 
 >>> broken.
 >>>
 >>>>
 >>>> "layer violations" as taught in protocls #101 has traditionally
 >>>> been restricted to upper layer tweaking layer-2 operating parameters
 >>>> (think Application/TCP causing Dial up), rather than
 >>>> vice versa - but the other way round stretches
 >>>> programming API paradigms more athletically
 >>>> so may be condusive to progress...
 >>>
 >>> If I understand what you are alluding to, this is addressed by not 
 >>> ignoring the existence of the enrollment phase in communication.
 >>>
 >>> What I have found is that in a wff architecture there are no need for 
 >>> layer violations.  In other words, if you have layer violations, you 
 >>> are doing something wrong some place.  Either in how you are trying to 
 >>> do what you want to do, or in what you think a layer is.  In this case 
 >>> it seems to be a bit of both.
 >>>
 >>> Take care,
 >>> John
 >>>
 >>>>
 >>>> In missive <1210445625.6167.138.camel at jg-laptop>, Jim Gettys typed:
 >>>>
 >>>>  >>On Sat, 2008-05-10 at 12:18 -0400, David P. Reed wrote:
 >>>>  >>
 >>>>  >>> There are huge aspects of that future that depend on getting the
 >>>>  >>> low-level abstractions right (in the sense that they match real 
 >>>> physical
 >>>>  >>> reality).  And at the same time, constructing a stack of 
 >>>> abstractions
 >>>>  >>> that work to maximize the utility of radio.
 >>>>  >>>
 >>>>  >>
 >>>>  >>First hand reality in the OLPC project: use of multicast/broadcast 
 >>>> based
 >>>>  >>protocols when crossed with nascent wireless protocols (802.11s), can
 >>>>  >>cause spectacularly "interesting" (as in Chinese curse) interactions.
 >>>>  >>
 >>>>  >>First hand experience is showing that one had better understand what
 >>>>  >>happens at the lowest wireless layers while building application
 >>>>  >>middleware protocols and applications....  Some existing protocols 
 >>>> that
 >>>>  >>have worked well on wired networks, and sort of worked OK on 
 >>>> 802.11abc
 >>>>  >>networks, just doesn't work well (or scale well) on a mesh 
 >>>> designed to
 >>>>  >>try to hide what's going on under the covers.
 >>>>  >>
 >>>>  >>While overlays are going to play an important role in getting us 
 >>>> out of
 >>>>  >>the current morass (without transition strategies, we're toast; 
 >>>> that was
 >>>>  >>what got the Internet out of telecom circuit switching as the only
 >>>>  >>mechanism), I have to emphatically agree with Dave that we'd 
 >>>> better get
 >>>>  >>moving on more fundamental redesign and rethinking of networking....
 >>>>  >>                           - Jim
 >>>>  >>
 >>>>  >>--
 >>>>  >>Jim Gettys <jg at laptop.org>
 >>>>  >>One Laptop Per Child
 >>>>  >>
 >>>>
 >>>>  cheers
 >>>>
 >>>>    jon
 >>>
 >>>

 cheers

   jon