[e2e] end of interest

John Day day at std.com
Sun May 11 12:06:21 PDT 2008

At 10:52 -0400 2008/05/11, David P. Reed wrote:
>Snooping honors the Layeristi - granting them rhetorical power they 
>never deserved.   It sounds like "cheating" or "illegal" operation. 
>The Internet was born without layers - it used architectural

See previous note.  No matter how you cut it. Whether you call them 
layers or framing.  If you have to look at stuff that doesn't belong 
to you, you haven't done something right or there is something you 
don't understand.

>framing differently (e.g., one arch principle illustrative: 
>encapsulation is not layering, and even survives as IP gets 
>encapsulated in TCP port 8 VPNs, much to the chagrin of the 
>Layeristi purists who explain it as a "bug", rather than looking at 
>its roots in passing IP datagrams over SNA and NCP virtual circuits).

Gosh. How is this a bug?  Sounds right to me!

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

Well, it is hard.  I can testify to that!  Not sure it is harder than 
Jon thinks.  Jon seems to think pretty hard much of the time. 
Although he doesn't want it to show.  ;-)

>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.

No, it is a question of learning to listen carefully to what the 
problem is telling you and not imposing your own ideas on it.  (I 
will admit that I have found that we do the later it is often wrong. 
Embarrassing when it happens.  But if you are careful when you write 
it up no one notices!)  ;-)

>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 
>>>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,
>>>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