<div dir="ltr">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<div>
<br></div><div>architecure remains as hard as ever, and as rare in any discipline (except maybe norman foster's :-)<br><div><br></div><div>I totally agree that things could go either way - SDN (like active nets before it) could go horribly horribly wrong....</div>
<div><br></div><div>on the other hand, i suppose, it would then not get adopted much...</div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Apr 14, 2013 at 5:40 PM, <span dir="ltr"><<a href="mailto:dpreed@reed.com" target="_blank">dpreed@reed.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><font face="times new roman" size="3"><p style="margin:0;padding:0">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.</p>
<p style="margin:0;padding:0">[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]</p>
<p style="margin:0;padding:0"> </p>
<p style="margin:0;padding:0">As someone who has worked on SDN (with McKeown's own code, at HP Labs), I think it can go either way -</p>
<p style="margin:0;padding:0"> </p>
<p style="margin:0;padding:0">1) do a better job of moving flexibility and function to the edges, or</p>
<p style="margin:0;padding:0">2) create a vast nightmarish terrain of virtual middleboxes that do unpredictable and random things to traffic packets.</p>
<p style="margin:0;padding:0"> </p>
<p style="margin:0;padding:0">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.</p>
<p style="margin:0;padding:0"> </p>
<p style="margin:0;padding:0">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.</p>
<p style="margin:0;padding:0"> </p>
<p style="margin:0;padding:0">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.</p>
<p style="margin:0;padding:0"> </p>
<p style="margin:0;padding:0">Merely emulating that mess (perfectly feasible with SDN) creates the opportunity to ramify the process of chaotic evolution of the network.</p>
<p style="margin:0;padding:0"> </p>
<p style="margin:0;padding:0">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.</p>
<p style="margin:0;padding:0"> </p>
<p style="margin:0;padding:0">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.</p>
<p style="margin:0;padding:0"> </p>
<p style="margin:0;padding:0">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.</p>
<p style="margin:0;padding:0"> </p>
<p style="margin:0;padding:0">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.</p>
<p style="margin:0;padding:0"> </p>
<p style="margin:0;padding:0">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.</p>
<p style="margin:0;padding:0"> </p>
<p style="margin:0;padding:0">So I'm skeptical that there is this wonderful world of computer scientists that have mastered anything.</p>
<p style="margin:0;padding:0"> </p>
<p style="margin:0;padding:0">Some people in the community are pretty damn smart. Too few. Most are mis-employed.</p>
<p style="margin:0;padding:0"> </p>
<p style="margin:0;padding:0">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.</p>
<p style="margin:0;padding:0"> </p>
<p style="margin:0;padding:0">SDN becomes an accelerator of a network Gresham's Law, if that is the way things go.</p>
<p style="margin:0;padding:0"> </p>
<p style="margin:0;padding:0">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".</p>
<p style="margin:0;padding:0"> </p>
<p style="margin:0;padding:0">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.</p>
<div><div class="h5">
<p style="margin:0;padding:0"> </p>
<p style="margin:0;padding:0"><br><br>On Sunday, April 14, 2013 6:04am, "Jon Crowcroft" <<a href="mailto:jon.crowcroft@cl.cam.ac.uk" target="_blank">jon.crowcroft@cl.cam.ac.uk</a>> said:<br><br></p>
</div></div><div><div><div class="h5">
<div dir="ltr">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
<div></div>
<div>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....</div>
<div>cheers</div>
<div>jon</div>
</div>
</div></div><div class="gmail_extra"><br><br>
<div class="gmail_quote"><div><div class="h5">On Sat, Apr 13, 2013 at 10:39 PM, John Day <span dir="ltr"><<a href="mailto:jeanjour@comcast.net" target="_blank">jeanjour@comcast.net</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">Yea, I have seen their stuff too, pretty amusing. about as disruptive as a speed bump. ;-)<br>
<br> 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.<br><br> 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.<br>
<br> Things become much simpler once you are out of the ITU model that SDN and Open Flow are locked into.<br><br> Have fun,<br> John
</div></div><div>
<div><div><div class="h5"><br><br><br> At 8:25 PM +0100 4/13/13, Jon Crowcroft wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">well i've seen scott shenker do his SDN vision talk a couple of times,<br> and I know nick mckeown's work pretty well, and I do not think they<br>
are bell heads<br><br> one point is that computer science has grown up slightly since 40+<br> years ago, so we are capabile of building way more flexible safe,<br> secure and performant systems that in the past, when the design<br>
constraints on protocol stacks were set by 1960s ideas of s/w...<br><br> so the stuff out of berkeley, stanford, princeton, gatech etc<br> in this space is not constrained by the old rules<br><br> it is deconstrained by new capabilities...<br>
<br> [slightly stolen from John Doyle's cool idea of de-constraining<br> constraints]<br><br><br> so the realpolitik of openflow is (as it was with GSMP) to get arms<br> length from the legacy router biz, and move the functionality somwhere<br>
where we can do disruptive innovation<br><br> but that is another chapter...<br><br></div></div> In missive <a062408c2cd8f33d66244@[10.0.<span style="text-decoration:underline"> </span>1.3]>, John Day typed:<div><div class="h5">
<br><br> >>Jon.<br> >><br> >>Yes, precisely. The first place it shows up is in ISDN, then Frame<br> >>Relay, ATM, and MPLS. All those CCITT-like connection oriented<br> >>solutions. And you undoubtedly are correct, it was brought into the<br>
>>Internet by the Europeans where the new model was largely ignored<br> >>after the suppression of CYCLADES and the completion other early work<br> >>such as the Cambridge DS. (As near as I can tell the vast majority<br>
>>of European universities never strayed too far from the traditional<br> >>ITU model during the 70s to 90s. In fact most of the research still<br> >>bears a strong mark of it with an Internet veneer.)<br>
>><br> >>Yes, it did arrive sometime back and has been a constant source of<br> >>humor since the ATM lunacy. In fact, this is what makes it so<br> >>wonderful that OpenFlow and SDN have embraced the ITU world view so<br>
>>completely. The Internet becomes about as anti-Internet as it can<br> >>get. The Bell-heads have taken over. You have to admit it is pretty<br> >>amusing.<br> >><br> >>Take care,<br> >>John<br>
>><br> >><br> >>At 12:29 PM +0100 4/13/13, Jon Crowcroft wrote:<br> >>>so the dogma here was that the business of manageing the net was just<br> >>>another distributed system (see the Cambridge Distributed System)<br>
>>>wherre name services, router services, security services were<br> >>>implemented in exactly the same way as any other distributred system<br> >>>(file systems, transaction services, distributed computation tools)...<br>
>>><br> >>>but the control plane model of the net arrived in internet-land some<br> >>>time back - for example simon crosby took ideas (this was around the<br> >>>time when everyone was trying to do IP over ATM, which morphed into<br>
>>>mpls) from "switchlet" territory with remote computation as<br></div></div> >>>controlplanestechnology...<span style="text-decoration:underline"> </span>other people, e.g. ipsilon, also took the<div class="im">
<br> >>>seperation of concerns that are<br> >>>forwarding packets as fast as you can,<br> >>>from<br> >>>working out where they should and shouldn't go<br> >>>and put them on different boxes, originally to be coordinated via the<br>
>>>Generic Switch Management Protocol<br> >>>later re-discoverd as Software Definted Networkign and Openflow...<br> >>><br> >>>plus ca change...<br></div> >>>In missive <a062408a1cd8ddf0a5bcd@[10.0.<span style="text-decoration:underline"> </span>1.3]>, John Day typed:<div>
<div class="h5"><br> >>><br> >>> >>The whole distinction of data plane and control plane arises with<br> >>> >>ISDN. It is a CCITT concept and was never used to describe anything<br>
>>> >>Internet related, either in the US or Europe. Such distinctions only<br> >>> >>make sense in the beads-on-a-string models of the ITU. Routing,<br> >>> >>ICMP, DHCP, etc. type functions were characterized as layer<br>
>>> >>management, which can exist to greater or lesser degree in all layers<br> >>> >>and must be within the layer owing to the different scopes of the<br> >>> >>layers.<br>
>>> >><br> >>> >>Take care,<br> >>> >>John Day<br> >>> >><br> >>> >>><br> >>> >>>the post-hoc rationalisation phrase is way too glib....certainly not<br>
>>> >>>intended to be rude to people that created this cool stuff we all<br> >>> >>>use - in fact i was conflating three things<br> >>> >>><br> >>> >>>1. a bunch of work fairly recently on optimal protocols and narrow<br>
>>> >>>waist of the hour glass...<br> >>> >>>2. the ordering of constrints on the design of the internet<br> >>> >>>protocols (as per dave clarks 88 paper)<br> >>> >>>and<br>
>>> >>>3. the apparent simplicity of IP - my missing point was that the<br> >>> >>>complexity pops out somewhere, and that place is in the control<br> >>> >>>plane....as we've since disovered...<br>
>>> >>><br> >>> >>>of course, there were people that ran dynamic distributed routing<br> >>> >>>for VC networks (X.25 for example - we had switches in the JANET<br>
>>> >>>network that did this) so they were even more complex in both data<br> >>> >>>and control plane (what with crankback etc etc:)<br> >>> >>><br> >>> >>>so yes, a bit glib really...sorry<br>
>>> >>><br> >>> >>>normal service will be resumed as soon as I get my IPTV QoS back :)<br> >>> >>><br> >>> >>>j.<br> >>> >>><br>
>>> >>><br> >>> >>>On Fri, Apr 12, 2013 at 3:07 PM, Fred Baker (fred)<br></div></div><div><div class="h5"> >>> >>><<mailto:<a href="mailto:fred@cisco.com" target="_blank">fred@cisco.com</a>><a href="mailto:fred@cisco.com" target="_blank">fre<span style="text-decoration:underline"> </span>d@cisco.com</a>> wrote:<br>
>>> >>><br> >>> >>>I'd suggest running the assertion by Vint. I made a similar<br> >>> >>>assertion in a document not too long ago, which I ran by him for<br> >>> >>>comment, and he told me I was flatly wrong. Yes, the circuit switch<br>
>>> >>>folks were using the term "catenet" to refer to networks that<br> >>> >>>interoperated through translation, such as frame relay/ATM<br> >>> >>>interoperation, he asserted, but at least some (he?) was using the<br>
>>> >>>term "Internet" as early as the mid 1970's.<br> >>> >>><br> >>> >>><br> >>> >>>On Apr 11, 2013, at 8:59 PM, Dave Crocker<br>
>>> >>><<mailto:<a href="mailto:dhc2@dcrocker.net" target="_blank">dhc2@dcrocker.net</a>><a href="mailto:dhc2@dcrocker.net" target="_blank">dhc2@dcrocker.net</a>> wrote:<br> >>> >>><br>
>>> >>>> This is a risky query. There have been previous threads about<br> >>> >>>>such things as the "start" of the Internet. Instead, I want to ask<br> >>> >>>>about the "architecture" of the Internet.<br>
>>> >>>><br> >>> >>>> Here's a comment that I sent earlier today, to a non-technical<br> >>> >>>>person who is aware of the overall Internet timeline, but I believe<br>
>>> >>>>does not understand what is distinctive about Internet<br> >>> >>>>'architecture'. I'm curious about reactions on this list, and any<br> >>> >>>>possible improvements -- including complete replacement -- but more<br>
>>> >>>>importantly I'm interested in filling in the details:<br> >>> >>> ><br> >>> >>>> The original use of the term Internet was to describe a<br>
>>> >>>>distinctive technical design for a distributed, scalable data<br> >>> >>>>exchange fabric. Its design characteristics differ dramatically<br> >>> >>>>from those of its predecessor, the Arpanet, and from other related<br>
>>> >>>>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<br>
>>> >>>>moving raw data from the applications that used it. What I'd class<br> >>> >>>>as distinctive were the TCP/IP separation, the remarkably modest<br> >>> >>>>functionality of IP, even to the point of moving it's control plane<br>
>>> >>>>to the next level up with ICMP, and continuing with modest<br> >>> >>>>expectations the layer below (which made it possible to operate<br> >>> >>>>over any medium including birds.) This is usually characterized as<br>
>>> >>>>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" target="_blank">http://bbiw.net</a>><a href="http://bbiw.net" target="_blank">bbiw.net</a><br>
>>> >><br> >>> >>--============_-846339397==_ma============<br> >>> >>Content-Type: text/html; charset="us-ascii"<br> >>> >><br> >>> >><!doctype html public "-//W3C//DTD W3 HTML//EN"><br>
>>> >><html><head><style type="text/css"><!--<br> >>> >>blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }<br> >>> >> --></style><title>Re: [e2e] Internet<br>
>>> >>&quot;architecture&quot;</title></head><body><br> >>> >><div>This is a can of worms, but. . .</div><br> >>> >><div><br></div><br>
>>> >><div>At 4:23 PM +0200 4/12/13, Jon Crowcroft wrote:</div><br> >>> >><blockquote type="cite" cite>the folks who called it catenet included<br> >>> >>bob braden who was working at UCL when i was there - of course, we<br>
>>> >>were concatenating networks that ran other protocols (Cambridge Ring,<br> >>> >>X.25 (transport layer relays) and so on...so perhaps I'm conflating<br> >>> >>two things - the interconnection of multiple disprate protocol<br>
>>> >>systems, and the IP interconenction of multiple IP networks with<br> >>> >>disparete layer 2 and below....</blockquote><br> >>> >><div><br></div><br>
>>> >><div>Early on the term catenet was applied without respect to<br> >>> >>connection or connectionless, but only with respect to forwarding vs.<br> >>> >>translation (if necessary).</div><br>
>>> >><div><br></div><br> >>> >><blockquote type="cite" cite><br></blockquote><br> >>> >><blockquote type="cite" cite>it is the case (as some other folks<br>
>>> >>privately pointed out to me) that IENs (including IEN 1 written at<br> >>> >>UCL) are Internet Experiment Notes, and go back to mid 1970s, so i'm<br> >>> >>wrong to say &quot;internet&quot;</blockquote><br>
>>> >><blockquote type="cite" cite><br></blockquote><br> >>> >><blockquote type="cite" cite>however, my point about parsimony is<br> >>> >>really over compressed - IP trades off simplicity in the data plane,<br>
>>> >>for complexity in the control plane - its not a pure trade off (it can<br> >>> >>be seen partly as a win-win, as signaling protocols for VC networks<br> >>> >>can be nearly as complex (or in X.25 and B-ISDN's Q.2931's cases, more<br>
>>> >>complex) as routing protocols....nevertheless, getting routing right<br> >>> >>and all associated components is seriously non-trivial - other systems<br> >>> >>(the aforesaid cambridge ring protocol stack) represent a different<br>
>>> >>trade off that is also quite elegant.</blockquote><br> >>> >><div><br></div><br> >>> >><div>The whole distinction of data plane and control plane arises with<br>
>>> >>ISDN. It is a CCITT concept and was never used to describe anything<br> >>> >>Internet related, either in the US or Europe. Such distinctions only<br> >>> >>make sense in the beads-on-a-string models of the ITU.&nbsp; Routing,<br>
>>> >>ICMP, DHCP, etc. type functions were characterized as layer<br> >>> >>management, which can exist to greater or lesser degree in all layers<br> >>> >>and must be within the layer owing to the different scopes of the<br>
>>> >>layers.</div><br> >>> >><div><br></div><br> >>> >><div>Take care,</div><br> >>> >><div>John Day</div><br>
>>> >><div><br></div><br> >>> >><blockquote type="cite" cite><br></blockquote><br> >>> >><blockquote type="cite" cite>the post-hoc rationalisation phrase is<br>
>>> >>way too glib....certainly not intended to be rude to people that<br> >>> >>created this cool stuff we all use - in fact i was conflating three<br> >>> >>things</blockquote><br>
>>> >><blockquote type="cite" cite><br></blockquote><br> >>> >><blockquote type="cite" cite>1. a bunch of work fairly recently on<br> >>> >>optimal protocols and narrow waist of the hour glass...</blockquote><br>
>>> >><blockquote type="cite" cite>2. the ordering of constrints on the<br> >>> >>design of the internet protocols (as per dave clarks 88<br> >>> >>paper)</blockquote><br>
>>> >><blockquote type="cite" cite>and</blockquote><br> >>> >><blockquote type="cite" cite>3. the apparent simplicity of IP - my<br> >>> >>missing point was that the complexity pops out somewhere, and that<br>
>>> >>place is in the control plane....as we've since<br> >>> >>disovered...</blockquote><br> >>> >><blockquote type="cite" cite><br></blockquote><br>
>>> >><blockquote type="cite" cite>of course, there were people that ran<br> >>> >>dynamic distributed routing for VC networks (X.25 for example - we had<br> >>> >>switches in the JANET network that did this) so they were even more<br>
>>> >>complex in both data and control plane (what with crankback etc<br> >>> >>etc:)</blockquote><br> >>> >><blockquote type="cite" cite><br></blockquote><br>
>>> >><blockquote type="cite" cite>so yes, a bit glib<br> >>> >>really...sorry</blockquote><br> >>> >><blockquote type="cite" cite><br></blockquote><br>
>>> >><blockquote type="cite" cite>normal service will be resumed as soon as<br> >>> >>I get my IPTV QoS back :)</blockquote><br> >>> >><blockquote type="cite" cite><br></blockquote><br>
>>> >><blockquote type="cite" cite>j.</blockquote><br> >>> >><blockquote type="cite" cite><br><br> >>> >><br><br> >>> >></blockquote><br>
>>> >><blockquote type="cite" cite>On Fri, Apr 12, 2013 at 3:07 PM, Fred<br> >>> >>Baker (fred) &lt;<a href="mailto:<a href="mailto:fred@cisco.com" target="_blank">fred@cisco.com</a>"><a href="mailto:fred@cisco.com" target="_blank">fred@cisco.com</a></a>&gt;<br>
>>> >>wrote:<br><br> >>> >><blockquote>I'd suggest running the assertion by Vint. I made a<br> >>> >>similar assertion in a document not too long ago, which I ran by him<br>
>>> >>for comment, and he told me I was flatly wrong. Yes, the circuit<br> >>> >>switch folks were using the term &quot;catenet&quot; to refer to<br> >>> >>networks that interoperated through translation, such as frame<br>
>>> >>relay/ATM interoperation, he asserted, but at least some (he?) was<br> >>> >>using the term &quot;Internet&quot; as early as the mid 1970's.<br><br> >>> >></blockquote><br>
>>> >><blockquote><br><br> >>> >>On Apr 11, 2013, at 8:59 PM, Dave Crocker &lt;<a<br> >>> >>href="mailto:<a href="mailto:dhc2@dcrocker.net" target="_blank">dhc2@dcrocker.net</a>"><a href="mailto:dhc2@dcrocker.net" target="_blank">dhc2@dcrocker.net</a></a>&gt; wrote:<br><br>
>>> >><br><br> >>> >>&gt; This is a risky query. &nbsp;There have been previous threads<br> >>> >>about such things as the &quot;start&quot; of the Internet.<br>
>>> >>&nbsp;Instead, I want to ask about the &quot;architecture&quot; of the<br> >>> >>Internet.<br><br> >>> >>&gt;<br><br> >>> >>&gt; Here's a comment that I sent earlier today, to a non-technical<br>
>>> >>person who is aware of the overall Internet timeline, but I believe<br> >>> >>does not understand what is distinctive about Internet 'architecture'.<br> >>> >>&nbsp;I'm curious about reactions on this list, and any possible<br>
>>> >>improvements -- including complete replacement -- but more importantly<br> >>> >>I'm interested in filling in the details:</blockquote><br> >>> >><blockquote>&gt;<br><br>
>>> >>&gt;&nbsp;&nbsp;&nbsp;&nbsp; The original use of the term Internet was<br> >>> >>to describe a distinctive technical design for a distributed, scalable<br> >>> >>data exchange fabric. &nbsp;Its design characteristics differ<br>
>>> >>dramatically from those of its predecessor, the Arpanet, and from<br> >>> >>other related efforts.<br><br> >>> >>&gt;<br><br> >>> >>&gt; That's what I sent. &nbsp;To prime the pump for the detail:<br><br>
>>> >>&gt;<br><br> >>> >>&gt;&nbsp;&nbsp;&nbsp;&nbsp; By saying 'fabric' I meant to distinguish<br> >>> >>the mechanism for moving raw data from the applications that used it.<br>
>>> >>&nbsp;What I'd class as distinctive were the TCP/IP separation, the<br> >>> >>remarkably modest functionality of IP, even to the point of moving<br> >>> >>it's control plane to the next level up with ICMP, and continuing with<br>
>>> >>modest expectations the layer below (which made it possible to operate<br> >>> >>over any medium including birds.) &nbsp;This is usually characterized<br> >>> >>as moving robustness to the edges.<br><br>
>>> >>&gt;<br><br> >>> >>&gt;<br><br> >>> >>&gt; Thoughts?<br><br> >>> >>&gt;<br><br> >>> >>&gt; d/<br><br>
>>> >>&gt;<br><br> >>> >>&gt; --<br><br> >>> >>&gt; Dave Crocker<br><br> >>> >>&gt; Brandenburg InternetWorking<br><br>
>>> >>&gt; <a href="<a href="http://bbiw.net" target="_blank">http://bbiw.net</a>"><a href="http://bbiw.net" target="_blank">bbiw.net</a></a></blockquote><br> >>> >></blockquote><br>
>>> >><div><br></div><br> >>> >></body><br> >>> >></html><br> >>> >>--============_-846339397==_ma============--<br> >>><br>
>>> cheers<br> >>><br> >>> jon<br> >><br><br> cheers<br><br> jon<br></div></div></blockquote>
</div>
</div>
</blockquote>
</div>
</div>
</div></font></blockquote></div><br></div>