[e2e] Internet "architecture"
Jon Crowcroft
jon.crowcroft at cl.cam.ac.uk
Sun Apr 14 09:51:28 PDT 2013
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
architecure remains as hard as ever, and as rare in any discipline (except
maybe norman foster's :-)
I totally agree that things could go either way - SDN (like active nets
before it) could go horribly horribly wrong....
on the other hand, i suppose, it would then not get adopted much...
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]
>
>
>
> As someone who has worked on SDN (with McKeown's own code, at HP Labs), I
> think it can go either way -
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> Merely emulating that mess (perfectly feasible with SDN) creates the
> opportunity to ramify the process of chaotic evolution of the network.
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> So I'm skeptical that there is this wonderful world of computer scientists
> that have mastered anything.
>
>
>
> Some people in the community are pretty damn smart. Too few. Most are
> mis-employed.
>
>
>
> 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.
>
>
>
> SDN becomes an accelerator of a network Gresham's Law, if that is the way
> things go.
>
>
>
> 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".
>
>
>
> 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.
>
>
>
>
>
> On Sunday, April 14, 2013 6:04am, "Jon Crowcroft" <
> jon.crowcroft at cl.cam.ac.uk> said:
>
> 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
>
>
> 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. ;-)
>>
>> 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.
>>
>> 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.
>>
>> Things become much simpler once you are out of the ITU model that SDN and
>> Open Flow are locked into.
>>
>> Have fun,
>> John
>>
>>
>>
>> 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
>>>
>>> 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...
>>>
>>> so the stuff out of berkeley, stanford, princeton, gatech etc
>>> in this space is not constrained by the old rules
>>>
>>> it is deconstrained by new capabilities...
>>>
>>> [slightly stolen from John Doyle's cool idea of de-constraining
>>> constraints]
>>>
>>>
>>> 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
>>>
>>> but that is another chapter...
>>>
>>> In missive <a062408c2cd8f33d66244@[10.0. 1.3]>, John Day typed:
>>>
>>>
>>> >>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
>>>
>>> >>>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:
>>>
>>> >>>
>>> >>> >>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 <fred 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
>>> >>> >>
>>> >>> >>--============_-846339397==_ma============
>>> >>> >>Content-Type: text/html; charset="us-ascii"
>>> >>> >>
>>> >>> >><!doctype html public "-//W3C//DTD W3 HTML//EN">
>>> >>> >><html><head><style type="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="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="cite" cite><br></blockquote>
>>> >>> >><blockquote type="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="cite" cite><br></blockquote>
>>> >>> >><blockquote type="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="cite" cite><br></blockquote>
>>> >>> >><blockquote type="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="cite" cite><br></blockquote>
>>> >>> >><blockquote type="cite" cite>1. a bunch of work fairly recently on
>>> >>> >>optimal protocols and narrow waist of the hour
>>> glass...</blockquote>
>>> >>> >><blockquote type="cite" cite>2. the ordering of constrints on the
>>> >>> >>design of the internet protocols (as per dave clarks 88
>>> >>> >>paper)</blockquote>
>>> >>> >><blockquote type="cite" cite>and</blockquote>
>>> >>> >><blockquote type="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="cite" cite><br></blockquote>
>>> >>> >><blockquote type="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="cite" cite><br></blockquote>
>>> >>> >><blockquote type="cite" cite>so yes, a bit glib
>>> >>> >>really...sorry</blockquote>
>>> >>> >><blockquote type="cite" cite><br></blockquote>
>>> >>> >><blockquote type="cite" cite>normal service will be resumed as
>>> soon as
>>> >>> >>I get my IPTV QoS back :)</blockquote>
>>> >>> >><blockquote type="cite" cite><br></blockquote>
>>> >>> >><blockquote type="cite" cite>j.</blockquote>
>>> >>> >><blockquote type="cite" cite><br>
>>> >>> >><br>
>>> >>> >></blockquote>
>>> >>> >><blockquote type="cite" cite>On Fri, Apr 12, 2013 at 3:07 PM, Fred
>>> >>> >>Baker (fred) <<a href="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="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="http://bbiw.net">bbiw.net</a></blockquote>
>>> >>> >></blockquote>
>>> >>> >><div><br></div>
>>> >>> >></body>
>>> >>> >></html>
>>> >>> >>--============_-846339397==_ma============--
>>> >>>
>>> >>> cheers
>>> >>>
>>> >>> jon
>>> >>
>>>
>>> cheers
>>>
>>> jon
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130414/9737b696/attachment-0001.html
More information about the end2end-interest
mailing list