[e2e] Internet "architecture"
Jon Crowcroft
Jon.Crowcroft at cl.cam.ac.uk
Sun Apr 14 12:16:15 PDT 2013
your work on ML and active nets is the ancestor of our work on
verifiable control plane stuff, so i was referring to the broader
stream of less well formulated work in this space
i am disappointed at people being pessimistic about the fruits of
computer science (science, not just engineering) in practice
we;ve made great strides (e.g. in information flow, and symbolic
execution) and people unaware of work on verfying device drivers by
byron cook and others need to get up to speed a bit more ...
cheers!
In missive <E5F633B7-5746-4206-BBA2-3DCE6A3A790A at cis.upenn.edu>, "Jonathan M. S
mith" typed:
>>Jon:
>> How exactly did AN go wrong?
>> =
>> -JMS
>>
>>On Apr 14, 2013, at 12:51 PM, Jon Crowcroft <jon.crowcroft at cl.cam.ac.uk> =
>>wrote:
>>
>>> I'm not claiming CS can architect things better - I am claiming that =
>>people architecting things today should assimilatethe idea that we have =
>>differt CS tools at our disposal - this is quite a different.claim
>>>=20
>>> architecure remains as hard as ever, and as rare in any discipline =
>>(except maybe norman foster's :-)
>>>=20
>>> I totally agree that things could go either way - SDN (like active =
>>nets before it) could go horribly horribly wrong....
>>>=20
>>> on the other hand, i suppose, it would then not get adopted much...
>>>=20
>>>=20
>>> On Sun, Apr 14, 2013 at 5:40 PM, <dpreed at reed.com> wrote:
>>> Jon - I strongly disagree with your views that SDN *will* solve the =
>>problem of simplifying network architecture and that computer scientists =
>>today are capable of architecting systems much better than those 40 =
>>years ago. I don't have a problem with SDN technology per se, but it =
>>changes very little in regard to most aspects of quality network design =
>>and architecture.
>>> [usual disclaimer about my posts being blocked to the full e2e list, =
>>but I invited to the conversation some people who might agree or =
>>disagree, because I think it's an interesting question]
>>> =20
>>> As someone who has worked on SDN (with McKeown's own code, at HP =
>>Labs), I think it can go either way -
>>> =20
>>> 1) do a better job of moving flexibility and function to the edges, or
>>> 2) create a vast nightmarish terrain of virtual middleboxes that do =
>>unpredictable and random things to traffic packets.
>>> =20
>>> Having seen what the deployers of middleboxes get wrong, I'm not sure =
>>that a virtualization platform for middleboxes will do to reduce the =
>>problems. It's a sociopolitical problem, not a technical one.
>>> =20
>>> Inside a company, where the fabric is completely owned and operated by =
>>a unified IT dept. (there is much evidence that IT dept's in large =
>>companies are hardly unified, though), SDN's can be extremely helpful - =
>>precisely because the network is virtualized by SDN. You can roll out =
>>changes in a coordinated fashion, orchestrate resilience in the face of =
>>faults and signficant load changes, etc. All that is quite doable, even =
>>while preserving the essential separation between transport and =
>>heterogeneous infrastructure. That separation is quite important to the =
>>long-term nature of the systems that use any network.
>>> =20
>>> However, the mess that is evolving in IPv4 comes from poorly thought =
>>out regulations (wiretapping and "firewall" mechanisms that try to =
>>operate at a level where there is no end-point semantics, for example) =
>>and a struggle to create business "control points" that can be =
>>monopolized.
>>> =20
>>> Merely emulating that mess (perfectly feasible with SDN) creates the =
>>opportunity to ramify the process of chaotic evolution of the network.
>>> =20
>>> As far as your view that modern computer science and computer =
>>scientists can now do what we couldn't do 40 years ago, I'm =
>>extraordinarily skeptical. Modern computer scientists (the people) are =
>>much less capable of clean architectural thinking on the average, and =
>>being faced with problems with a vast increase in interactions among =
>>uncontrollable factors.
>>> =20
>>> This is why I continue to complain about network pedagogy that starts =
>>with the idea that networks somehow live in a world of stationary random =
>>processes that are all Gaussian, and that there is a "central limit =
>>theorem" that therefore makes aggregation reduce complexity. I've even =
>>heard someone say that there may be a little bit of "fractal" structure, =
>>but that it is "drowned out" by Gaussian stationary traffic. Anyone who =
>>understood the actual math would be appalled, but computer scientists =
>>*pretend* to be mathematicians for the most part, applying cookbook =
>>formulas and "gut instincts" that they got by solving simple textbook =
>>exercises and watching lectures without questioning assumptions, and =
>>never challenging their professors.
>>> =20
>>> 40 years ago, there was not so much teachiing of "things that we know =
>>that 'taint so" as the phrase goes. So in that sense, today's computer =
>>scientists have a herd instinct that never questions anything, and =
>>worse, feels completely empowered to disregard those who don't agree =
>>with the consensus, no matter how well they put the alternative forth.
>>> =20
>>> How else did we end up in a place where nearly every access network =
>>has key links where "bufferbloat" can allow a single person to run an =
>>application that builds up a blockage in either the downlink or the =
>>uplink, creating latencies of 1-4 seconds when the nominal latency is on =
>>the order of < 10 msec and the cross-country latency including all hops =
>>is around 30 msec? Was this "expertise by computer scientists"? =
>>Hardly. It was vastly ramified result of ignorance, not expertise.
>>> =20
>>> And worse, NO ONE in the community bothers to actually measure the =
>>real Internet in any detail. That would make their publications in =
>>academic journals be suspect, and eliminate the cozy world of =
>>conferences that seem to be more like a mutual admiration society among =
>>an isolated elite.
>>> =20
>>> So I'm skeptical that there is this wonderful world of computer =
>>scientists that have mastered anything.
>>> =20
>>> Some people in the community are pretty damn smart. Too few. Most are =
>>mis-employed.
>>> =20
>>> So, in the case of SDN, I'm pretty sure that the mess will continue to =
>>get worse due precisely to the ease with which SDN enables the blind =
>>deployment of bad ideas, and does not enhance the ability to detect the =
>>effects of bad ideas, measure their problems, and chuck the bad ideas.
>>> =20
>>> SDN becomes an accelerator of a network Gresham's Law, if that is the =
>>way things go.
>>> =20
>>> Nonetheless, SDN is a really helpful concept, put in its place - =
>>virtualization can be enormously helpful when it creates a simple =
>>abstraction without "cross-layer optimization".
>>> =20
>>> And don't get me started on the academic fascination in computer =
>>science with how "great" cross-layer optimizations are. Next we'll have =
>>thousands of papers talking about the wonders of kludges and crocks in =
>>network designs.
>>> =20
>>>=20
>>>=20
>>> On Sunday, April 14, 2013 6:04am, "Jon Crowcroft" =
>><jon.crowcroft at cl.cam.ac.uk> said:
>>>=20
>>> I think you can look at it a different way - SDN lets you move even =
>>more smarts out of the network into end systems - as far as we implement =
>>it, that looks even less like the ITU than the current =
>>ancient-route-computation/firewall/middlebox ridden IPv4 ossification of =
>>today
>>> so i can see that you could cast SDN in the Wicked Witch of the ITU =
>>role, but equally, I think of it as not being in Kansas anymore....
>>> cheers
>>> jon
>>>=20
>>>=20
>>> On Sat, Apr 13, 2013 at 10:39 PM, John Day <jeanjour at comcast.net> =
>>wrote:
>>> Yea, I have seen their stuff too, pretty amusing. about as disruptive =
>>as a speed bump. ;-)
>>>=20
>>> Actually you have it backwards, we *are* using the reactionary designs =
>>of 40 years ago and that is what is holding things back, rather than the =
>>forward looking designs that were being pursued.
>>>=20
>>> Those weren't the answer, but it was on the way to the answer, that is =
>>clear now and they would have found it if they had been able to keep =
>>going.
>>>=20
>>> Things become much simpler once you are out of the ITU model that SDN =
>>and Open Flow are locked into.
>>>=20
>>> Have fun,
>>> John
>>>=20
>>>=20
>>>=20
>>> At 8:25 PM +0100 4/13/13, Jon Crowcroft wrote:
>>> well i've seen scott shenker do his SDN vision talk a couple of times,
>>> and I know nick mckeown's work pretty well, and I do not think they
>>> are bell heads
>>>=20
>>> one point is that computer science has grown up slightly since 40+
>>> years ago, so we are capabile of building way more flexible safe,
>>> secure and performant systems that in the past, when the design
>>> constraints on protocol stacks were set by 1960s ideas of s/w...
>>>=20
>>> so the stuff out of berkeley, stanford, princeton, gatech etc
>>> in this space is not constrained by the old rules
>>>=20
>>> it is deconstrained by new capabilities...
>>>=20
>>> [slightly stolen from John Doyle's cool idea of de-constraining
>>> constraints]
>>>=20
>>>=20
>>> so the realpolitik of openflow is (as it was with GSMP) to get arms
>>> length from the legacy router biz, and move the functionality somwhere
>>> where we can do disruptive innovation
>>>=20
>>> but that is another chapter...
>>>=20
>>> In missive <a062408c2cd8f33d66244@[10.0. 1.3]>, John Day typed:
>>>=20
>>>=20
>>> >>Jon.
>>> >>
>>> >>Yes, precisely. The first place it shows up is in ISDN, then Frame
>>> >>Relay, ATM, and MPLS. All those CCITT-like connection oriented
>>> >>solutions. And you undoubtedly are correct, it was brought into the
>>> >>Internet by the Europeans where the new model was largely ignored
>>> >>after the suppression of CYCLADES and the completion other early =
>>work
>>> >>such as the Cambridge DS. (As near as I can tell the vast majority
>>> >>of European universities never strayed too far from the traditional
>>> >>ITU model during the 70s to 90s. In fact most of the research still
>>> >>bears a strong mark of it with an Internet veneer.)
>>> >>
>>> >>Yes, it did arrive sometime back and has been a constant source of
>>> >>humor since the ATM lunacy. In fact, this is what makes it so
>>> >>wonderful that OpenFlow and SDN have embraced the ITU world view so
>>> >>completely. The Internet becomes about as anti-Internet as it can
>>> >>get. The Bell-heads have taken over. You have to admit it is =
>>pretty
>>> >>amusing.
>>> >>
>>> >>Take care,
>>> >>John
>>> >>
>>> >>
>>> >>At 12:29 PM +0100 4/13/13, Jon Crowcroft wrote:
>>> >>>so the dogma here was that the business of manageing the net was =
>>just
>>> >>>another distributed system (see the Cambridge Distributed System)
>>> >>>wherre name services, router services, security services were
>>> >>>implemented in exactly the same way as any other distributred =
>>system
>>> >>>(file systems, transaction services, distributed computation =
>>tools)...
>>> >>>
>>> >>>but the control plane model of the net arrived in internet-land =
>>some
>>> >>>time back - for example simon crosby took ideas (this was around =
>>the
>>> >>>time when everyone was trying to do IP over ATM, which morphed into
>>> >>>mpls) from "switchlet" territory with remote computation as
>>> >>>controlplanestechnology... other people, e.g. ipsilon, also took =
>>the
>>>=20
>>> >>>seperation of concerns that are
>>> >>>forwarding packets as fast as you can,
>>> >>>from
>>> >>>working out where they should and shouldn't go
>>> >>>and put them on different boxes, originally to be coordinated via =
>>the
>>> >>>Generic Switch Management Protocol
>>> >>>later re-discoverd as Software Definted Networkign and Openflow...
>>> >>>
>>> >>>plus ca change...
>>> >>>In missive <a062408a1cd8ddf0a5bcd@[10.0. 1.3]>, John Day typed:
>>>=20
>>> >>>
>>> >>> >>The whole distinction of data plane and control plane arises =
>>with
>>> >>> >>ISDN. It is a CCITT concept and was never used to describe =
>>anything
>>> >>> >>Internet related, either in the US or Europe. Such distinctions =
>>only
>>> >>> >>make sense in the beads-on-a-string models of the ITU. =
>>Routing,
>>> >>> >>ICMP, DHCP, etc. type functions were characterized as layer
>>> >>> >>management, which can exist to greater or lesser degree in all =
>>layers
>>> >>> >>and must be within the layer owing to the different scopes of =
>>the
>>> >>> >>layers.
>>> >>> >>
>>> >>> >>Take care,
>>> >>> >>John Day
>>> >>> >>
>>> >>> >>>
>>> >>> >>>the post-hoc rationalisation phrase is way too =
>>glib....certainly not
>>> >>> >>>intended to be rude to people that created this cool stuff we =
>>all
>>> >>> >>>use - in fact i was conflating three things
>>> >>> >>>
>>> >>> >>>1. a bunch of work fairly recently on optimal protocols and =
>>narrow
>>> >>> >>>waist of the hour glass...
>>> >>> >>>2. the ordering of constrints on the design of the internet
>>> >>> >>>protocols (as per dave clarks 88 paper)
>>> >>> >>>and
>>> >>> >>>3. the apparent simplicity of IP - my missing point was that =
>>the
>>> >>> >>>complexity pops out somewhere, and that place is in the =
>>control
>>> >>> >>>plane....as we've since disovered...
>>> >>> >>>
>>> >>> >>>of course, there were people that ran dynamic distributed =
>>routing
>>> >>> >>>for VC networks (X.25 for example - we had switches in the =
>>JANET
>>> >>> >>>network that did this) so they were even more complex in both =
>>data
>>> >>> >>>and control plane (what with crankback etc etc:)
>>> >>> >>>
>>> >>> >>>so yes, a bit glib really...sorry
>>> >>> >>>
>>> >>> >>>normal service will be resumed as soon as I get my IPTV QoS =
>>back :)
>>> >>> >>>
>>> >>> >>>j.
>>> >>> >>>
>>> >>> >>>
>>> >>> >>>On Fri, Apr 12, 2013 at 3:07 PM, Fred Baker (fred)
>>> >>> >>><<mailto:fred at cisco.com>fre d at cisco.com> wrote:
>>> >>> >>>
>>> >>> >>>I'd suggest running the assertion by Vint. I made a similar
>>> >>> >>>assertion in a document not too long ago, which I ran by him =
>>for
>>> >>> >>>comment, and he told me I was flatly wrong. Yes, the circuit =
>>switch
>>> >>> >>>folks were using the term "catenet" to refer to networks that
>>> >>> >>>interoperated through translation, such as frame relay/ATM
>>> >>> >>>interoperation, he asserted, but at least some (he?) was using =
>>the
>>> >>> >>>term "Internet" as early as the mid 1970's.
>>> >>> >>>
>>> >>> >>>
>>> >>> >>>On Apr 11, 2013, at 8:59 PM, Dave Crocker
>>> >>> >>><<mailto:dhc2 at dcrocker.net>dhc2 at dcrocker.net> wrote:
>>> >>> >>>
>>> >>> >>>> This is a risky query. There have been previous threads =
>>about
>>> >>> >>>>such things as the "start" of the Internet. Instead, I want =
>>to ask
>>> >>> >>>>about the "architecture" of the Internet.
>>> >>> >>>>
>>> >>> >>>> Here's a comment that I sent earlier today, to a =
>>non-technical
>>> >>> >>>>person who is aware of the overall Internet timeline, but I =
>>believe
>>> >>> >>>>does not understand what is distinctive about Internet
>>> >>> >>>>'architecture'. I'm curious about reactions on this list, =
>>and any
>>> >>> >>>>possible improvements -- including complete replacement -- =
>>but more
>>> >>> >>>>importantly I'm interested in filling in the details:
>>> >>> >>> >
>>> >>> >>>> The original use of the term Internet was to describe a
>>> >>> >>>>distinctive technical design for a distributed, scalable data
>>> >>> >>>>exchange fabric. Its design characteristics differ =
>>dramatically
>>> >>> >>>>from those of its predecessor, the Arpanet, and from other =
>>related
>>> >>> >>>>efforts.
>>> >>> >>>>
>>> >>> >>>> That's what I sent. To prime the pump for the detail:
>>> >>> >>>>
>>> >>> >>>> By saying 'fabric' I meant to distinguish the mechanism =
>>for
>>> >>> >>>>moving raw data from the applications that used it. What I'd =
>>class
>>> >>> >>>>as distinctive were the TCP/IP separation, the remarkably =
>>modest
>>> >>> >>>>functionality of IP, even to the point of moving it's control =
>>plane
>>> >>> >>>>to the next level up with ICMP, and continuing with modest
>>> >>> >>>>expectations the layer below (which made it possible to =
>>operate
>>> >>> >>>>over any medium including birds.) This is usually =
>>characterized as
>>> >>> >>>>moving robustness to the edges.
>>> >>> >>>>
>>> >>> >>>>
>>> >>> >>>> Thoughts?
>>> >>> >>>>
>>> >>> >>>> d/
>>> >>> >>>>
>>> >>> >>>> --
>>> >>> >>>> Dave Crocker
>>> >>> >>>> Brandenburg InternetWorking
>>> >>> >>>> <http://bbiw.net>bbiw.net
>>> >>> >>
>>> >>> >>--=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D_-846339397=3D=3D_ma=3D=3D=3D=
>>=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>> >>> >>Content-Type: text/html; charset=3D"us-ascii"
>>> >>> >>
>>> >>> >><!doctype html public "-//W3C//DTD W3 HTML//EN">
>>> >>> >><html><head><style type=3D"text/css"><!--
>>> >>> >>blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 =
>>}
>>> >>> >> --></style><title>Re: [e2e] Internet
>>> >>> >>"architecture"</title></head><body>
>>> >>> >><div>This is a can of worms, but. . .</div>
>>> >>> >><div><br></div>
>>> >>> >><div>At 4:23 PM +0200 4/12/13, Jon Crowcroft wrote:</div>
>>> >>> >><blockquote type=3D"cite" cite>the folks who called it catenet =
>>included
>>> >>> >>bob braden who was working at UCL when i was there - of course, =
>>we
>>> >>> >>were concatenating networks that ran other protocols (Cambridge =
>>Ring,
>>> >>> >>X.25 (transport layer relays) and so on...so perhaps I'm =
>>conflating
>>> >>> >>two things - the interconnection of multiple disprate protocol
>>> >>> >>systems, and the IP interconenction of multiple IP networks =
>>with
>>> >>> >>disparete layer 2 and below....</blockquote>
>>> >>> >><div><br></div>
>>> >>> >><div>Early on the term catenet was applied without respect to
>>> >>> >>connection or connectionless, but only with respect to =
>>forwarding vs.
>>> >>> >>translation (if necessary).</div>
>>> >>> >><div><br></div>
>>> >>> >><blockquote type=3D"cite" cite><br></blockquote>
>>> >>> >><blockquote type=3D"cite" cite>it is the case (as some other =
>>folks
>>> >>> >>privately pointed out to me) that IENs (including IEN 1 written =
>>at
>>> >>> >>UCL) are Internet Experiment Notes, and go back to mid 1970s, =
>>so i'm
>>> >>> >>wrong to say "internet"</blockquote>
>>> >>> >><blockquote type=3D"cite" cite><br></blockquote>
>>> >>> >><blockquote type=3D"cite" cite>however, my point about =
>>parsimony is
>>> >>> >>really over compressed - IP trades off simplicity in the data =
>>plane,
>>> >>> >>for complexity in the control plane - its not a pure trade off =
>>(it can
>>> >>> >>be seen partly as a win-win, as signaling protocols for VC =
>>networks
>>> >>> >>can be nearly as complex (or in X.25 and B-ISDN's Q.2931's =
>>cases, more
>>> >>> >>complex) as routing protocols....nevertheless, getting routing =
>>right
>>> >>> >>and all associated components is seriously non-trivial - other =
>>systems
>>> >>> >>(the aforesaid cambridge ring protocol stack) represent a =
>>different
>>> >>> >>trade off that is also quite elegant.</blockquote>
>>> >>> >><div><br></div>
>>> >>> >><div>The whole distinction of data plane and control plane =
>>arises with
>>> >>> >>ISDN. It is a CCITT concept and was never used to describe =
>>anything
>>> >>> >>Internet related, either in the US or Europe. Such distinctions =
>>only
>>> >>> >>make sense in the beads-on-a-string models of the ITU. =
>>Routing,
>>> >>> >>ICMP, DHCP, etc. type functions were characterized as layer
>>> >>> >>management, which can exist to greater or lesser degree in all =
>>layers
>>> >>> >>and must be within the layer owing to the different scopes of =
>>the
>>> >>> >>layers.</div>
>>> >>> >><div><br></div>
>>> >>> >><div>Take care,</div>
>>> >>> >><div>John Day</div>
>>> >>> >><div><br></div>
>>> >>> >><blockquote type=3D"cite" cite><br></blockquote>
>>> >>> >><blockquote type=3D"cite" cite>the post-hoc rationalisation =
>>phrase is
>>> >>> >>way too glib....certainly not intended to be rude to people =
>>that
>>> >>> >>created this cool stuff we all use - in fact i was conflating =
>>three
>>> >>> >>things</blockquote>
>>> >>> >><blockquote type=3D"cite" cite><br></blockquote>
>>> >>> >><blockquote type=3D"cite" cite>1. a bunch of work fairly =
>>recently on
>>> >>> >>optimal protocols and narrow waist of the hour =
>>glass...</blockquote>
>>> >>> >><blockquote type=3D"cite" cite>2. the ordering of constrints on =
>>the
>>> >>> >>design of the internet protocols (as per dave clarks 88
>>> >>> >>paper)</blockquote>
>>> >>> >><blockquote type=3D"cite" cite>and</blockquote>
>>> >>> >><blockquote type=3D"cite" cite>3. the apparent simplicity of IP =
>>- my
>>> >>> >>missing point was that the complexity pops out somewhere, and =
>>that
>>> >>> >>place is in the control plane....as we've since
>>> >>> >>disovered...</blockquote>
>>> >>> >><blockquote type=3D"cite" cite><br></blockquote>
>>> >>> >><blockquote type=3D"cite" cite>of course, there were people =
>>that ran
>>> >>> >>dynamic distributed routing for VC networks (X.25 for example - =
>>we had
>>> >>> >>switches in the JANET network that did this) so they were even =
>>more
>>> >>> >>complex in both data and control plane (what with crankback etc
>>> >>> >>etc:)</blockquote>
>>> >>> >><blockquote type=3D"cite" cite><br></blockquote>
>>> >>> >><blockquote type=3D"cite" cite>so yes, a bit glib
>>> >>> >>really...sorry</blockquote>
>>> >>> >><blockquote type=3D"cite" cite><br></blockquote>
>>> >>> >><blockquote type=3D"cite" cite>normal service will be resumed =
>>as soon as
>>> >>> >>I get my IPTV QoS back :)</blockquote>
>>> >>> >><blockquote type=3D"cite" cite><br></blockquote>
>>> >>> >><blockquote type=3D"cite" cite>j.</blockquote>
>>> >>> >><blockquote type=3D"cite" cite><br>
>>> >>> >><br>
>>> >>> >></blockquote>
>>> >>> >><blockquote type=3D"cite" cite>On Fri, Apr 12, 2013 at 3:07 PM, =
>>Fred
>>> >>> >>Baker (fred) <<a =
>>href=3D"mailto:fred at cisco.com">fred at cisco.com</a>>
>>> >>> >>wrote:<br>
>>> >>> >><blockquote>I'd suggest running the assertion by Vint. I made a
>>> >>> >>similar assertion in a document not too long ago, which I ran =
>>by him
>>> >>> >>for comment, and he told me I was flatly wrong. Yes, the =
>>circuit
>>> >>> >>switch folks were using the term "catenet" to refer =
>>to
>>> >>> >>networks that interoperated through translation, such as frame
>>> >>> >>relay/ATM interoperation, he asserted, but at least some (he?) =
>>was
>>> >>> >>using the term "Internet" as early as the mid =
>>1970's.<br>
>>> >>> >></blockquote>
>>> >>> >><blockquote><br>
>>> >>> >>On Apr 11, 2013, at 8:59 PM, Dave Crocker <<a
>>> >>> >>href=3D"mailto:dhc2 at dcrocker.net">dhc2 at dcrocker.net</a>> =
>>wrote:<br>
>>> >>> >><br>
>>> >>> >>> This is a risky query. There have been previous =
>>threads
>>> >>> >>about such things as the "start" of the Internet.
>>> >>> >> Instead, I want to ask about the "architecture" =
>>of the
>>> >>> >>Internet.<br>
>>> >>> >>><br>
>>> >>> >>> Here's a comment that I sent earlier today, to a =
>>non-technical
>>> >>> >>person who is aware of the overall Internet timeline, but I =
>>believe
>>> >>> >>does not understand what is distinctive about Internet =
>>'architecture'.
>>> >>> >> I'm curious about reactions on this list, and any =
>>possible
>>> >>> >>improvements -- including complete replacement -- but more =
>>importantly
>>> >>> >>I'm interested in filling in the details:</blockquote>
>>> >>> >><blockquote>><br>
>>> >>> >>> The original use of the term =
>>Internet was
>>> >>> >>to describe a distinctive technical design for a distributed, =
>>scalable
>>> >>> >>data exchange fabric. Its design characteristics differ
>>> >>> >>dramatically from those of its predecessor, the Arpanet, and =
>>from
>>> >>> >>other related efforts.<br>
>>> >>> >>><br>
>>> >>> >>> That's what I sent. To prime the pump for the =
>>detail:<br>
>>> >>> >>><br>
>>> >>> >>> By saying 'fabric' I meant to =
>>distinguish
>>> >>> >>the mechanism for moving raw data from the applications that =
>>used it.
>>> >>> >> What I'd class as distinctive were the TCP/IP separation, =
>>the
>>> >>> >>remarkably modest functionality of IP, even to the point of =
>>moving
>>> >>> >>it's control plane to the next level up with ICMP, and =
>>continuing with
>>> >>> >>modest expectations the layer below (which made it possible to =
>>operate
>>> >>> >>over any medium including birds.) This is usually =
>>characterized
>>> >>> >>as moving robustness to the edges.<br>
>>> >>> >>><br>
>>> >>> >>><br>
>>> >>> >>> Thoughts?<br>
>>> >>> >>><br>
>>> >>> >>> d/<br>
>>> >>> >>><br>
>>> >>> >>> --<br>
>>> >>> >>> Dave Crocker<br>
>>> >>> >>> Brandenburg InternetWorking<br>
>>> >>> >>> <a href=3D"http://bbiw.net">bbiw.net</a></blockquote>
>>> >>> >></blockquote>
>>> >>> >><div><br></div>
>>> >>> >></body>
>>> >>> >></html>
>>> >>> >>--=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D_-846339397=3D=3D_ma=3D=3D=3D=
>>=3D=3D=3D=3D=3D=3D=3D=3D=3D--
>>> >>>
>>> >>> cheers
>>> >>>
>>> >>> jon
>>> >>
>>>=20
>>> cheers
>>>=20
>>> jon
>>>=20
>>
cheers
jon
More information about the end2end-interest
mailing list