Re: Internet "architecture"

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 <[email protected]>, "Jonathan M. S
mith" typed:

 >>Jon:
 >>	How exactly did AN go wrong?
 >>										=
 >>					-JMS
 >>
 >>On Apr 14, 2013, at 12:51 PM, Jon Crowcroft <[email protected]> =
 >>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, <[email protected]> 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" =
 >><[email protected]> 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 <[email protected]> =
 >>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:[email protected]>fre [email protected]> 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:[email protected]>[email protected]> 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
 >>> >>>  >>&quot;architecture&quot;</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 &quot;internet&quot;</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.&nbsp; =
 >>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) &lt;<a =
 >>href=3D"mailto:[email protected]">[email protected]</a>&gt;
 >>> >>>  >>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 &quot;catenet&quot; 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 &quot;Internet&quot; as early as the mid =
 >>1970's.<br>
 >>> >>>  >></blockquote>
 >>> >>>  >><blockquote><br>
 >>> >>>  >>On Apr 11, 2013, at 8:59 PM, Dave Crocker &lt;<a
 >>> >>>  >>href=3D"mailto:[email protected]">[email protected]</a>&gt; =
 >>wrote:<br>
 >>> >>>  >><br>
 >>> >>>  >>&gt; This is a risky query. &nbsp;There have been previous =
 >>threads
 >>> >>>  >>about such things as the &quot;start&quot; of the Internet.
 >>> >>>  >>&nbsp;Instead, I want to ask about the &quot;architecture&quot; =
 >>of the
 >>> >>>  >>Internet.<br>
 >>> >>>  >>&gt;<br>
 >>> >>>  >>&gt; 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'.
 >>> >>>  >>&nbsp;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>&gt;<br>
 >>> >>>  >>&gt;&nbsp;&nbsp;&nbsp;&nbsp; The original use of the term =
 >>Internet was
 >>> >>>  >>to describe a distinctive technical design for a distributed, =
 >>scalable
 >>> >>>  >>data exchange fabric. &nbsp;Its design characteristics differ
 >>> >>>  >>dramatically from those of its predecessor, the Arpanet, and =
 >>from
 >>> >>>  >>other related efforts.<br>
 >>> >>>  >>&gt;<br>
 >>> >>>  >>&gt; That's what I sent. &nbsp;To prime the pump for the =
 >>detail:<br>
 >>> >>>  >>&gt;<br>
 >>> >>>  >>&gt;&nbsp;&nbsp;&nbsp;&nbsp; By saying 'fabric' I meant to =
 >>distinguish
 >>> >>>  >>the mechanism for moving raw data from the applications that =
 >>used it.
 >>> >>>  >>&nbsp;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.) &nbsp;This is usually =
 >>characterized
 >>> >>>  >>as moving robustness to the edges.<br>
 >>> >>>  >>&gt;<br>
 >>> >>>  >>&gt;<br>
 >>> >>>  >>&gt; Thoughts?<br>
 >>> >>>  >>&gt;<br>
 >>> >>>  >>&gt; d/<br>
 >>> >>>  >>&gt;<br>
 >>> >>>  >>&gt; --<br>
 >>> >>>  >>&gt; Dave Crocker<br>
 >>> >>>  >>&gt; Brandenburg InternetWorking<br>
 >>> >>>  >>&gt; <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