[e2e] end of interest

John Day day at std.com
Sun May 11 04:24:28 PDT 2008


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



More information about the end2end-interest mailing list