Re: Internet "architecture"
Jon Crowcroft <[email protected]>
| Newsgroups | gmane.network.end2end |
|---|---|
| Message-ID | <CAEeTej+SfBpG9cEfVciVXAVozZxUH+Bu=4Fwzf_nFQ-Qcm_euw@mail.gmail.com> |
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, <[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] > > > > 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" < > [email protected]> 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 <[email protected]> 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:[email protected]>fre [email protected] <[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 >>> >>> >> >>> >>> >>--============_-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:[email protected]">[email protected] >>> </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:[email protected]">[email protected]</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 >>> >>