[e2e] Internet "architecture"
Jon Crowcroft
jon.crowcroft at cl.cam.ac.uk
Sun Apr 14 03:04:48 PDT 2013
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<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">f**red 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>">
>> 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 <http://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/4e4fee20/attachment-0001.html
More information about the end2end-interest
mailing list