[e2e] end of interest

[bran@metacomm.com]

> an architecture that was purely
> constraint based (i.e. just said what
> you DONT do) would be very
> interesting:)

I did that in the eighties/nineties. See
"Integration Through Meta-Communication" of INFOCOM 90
and "Archetype A Unified Method for the Design and Implementation of
Protocol Architectures". IEEE Trans. Software Eng. 14(6): 822-837 (1988).

Branislav
>
>
> In missive <a06240808c44cf2bbbebf@[10.0.1.5]>,
> John Day typed:
>
>  >>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
>  >>>>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
>
>