[e2e] Internet "architecture"
John Day
jeanjour at comcast.net
Mon Apr 15 06:13:59 PDT 2013
To my mind there are two parts of computer science: the mathematics
and the science.
The mathematics part is, and always has been, doing quite well. It
inherited its traditions from math and they are firmly in place.
The science portion of CS has faired far less well and is for the
most part degenerated into craft. Many people have complained to me
that one sees the same papers on about 5 year cycle with different
time constants.
I don't quite get your reference to verifying device drivers. I
guess I should go look at their work. But a device driver has the
same structure as a protocol layer. They are basically the same
problem and verifying protocols and their implementations has been
well-understood for 30 years.
The big problem with device drivers (as we all know) is figuring out
what the darn thing actually does. ;-) The documentation is never
accurate. That is more a test problem. Once you have that
verification, is straightforward, tedious, but straightforward.
At 8:16 PM +0100 4/14/13, Jon Crowcroft wrote:
>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