[e2e] end of interest

[Jim Gettys]

Snooping is insufficient.  It appears you need to have additional
knowledge at higher layers (that the wireless layers do not have), and
design significantly different protocols for reasonable scaling.

The consequences of trying to simulate a wired ethernet through first
802.11abg and then further the mesh's attempt to take this the next
step, while preserving "standard" multicast/broadcast semantics results
in "interesting" interactions.  In our case, it is to provide a presence
protocol that is the basis of our collaboration framework.  

Polychronis Ypodimatopoulos is, however, making good progress with a
protocol that is designed much more from first principles, and getting
very much better scaling properties.  If you are interested, you can
look up the work-in-progress.

Wireless != wired networking.  Everyone has to get over it...  Rather
than moaning about the end of end-to-end interest, how about solving
some real problems?  There is lots of interesting networking issues to
be revisited and revised in fundamental ways.  We *really* don't have
the right abstractions (e.g. presence services).  If all we have going
forward is what was done for wired ethernet and the 1990-2000 Internet,
we'll be missing the real boat.
                       - Jim

On Sun, 2008-05-11 at 09:40 +0100, 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...
> 
> 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 ...
> 
> but should we raise the 
> art of _snooping_ to being a 
> first class component of any decent 
> postmodern internet architecture?
> 
> 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
> 
> "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...
> 
> 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
> 
> 
-- 
Jim Gettys <jg at laptop.org>
One Laptop Per Child