SlideShare a Scribd company logo

1 lost layer130123

•
•
A
ARCFIRE ICT

This document discusses the evolution of computer networking and the layered model. It describes early packet switching networks in the 1960s and 1970s like CYCLADES which introduced a layered architecture. There was debate between the INWG 39 and 61 proposals for an international transport protocol. By 1976 a synthesis called INWG 96 was approved, though TCP/IP was still developed separately. Significantly, all the early proposals included addressing at multiple layers of scope, unlike the later Internet architecture of TCP, IP, and data link layers.

Related slideshows

Ficod 2011 pdf (with notes)
Ficod 2011 pdf (with notes)Ficod 2011 pdf (with notes)
Ficod 2011 pdf (with notes)
 
Vermont Internet Guide
Vermont Internet GuideVermont Internet Guide
Vermont Internet Guide
 
P2P Capstone
P2P CapstoneP2P Capstone
P2P Capstone
 
1 of 42
Download to read offline
© John Day, 2013 Rights Reserved The Pouzin Society Surviving Networking’s Dark Ages IRATI RINA Workshop John Day Barcelona 2013 OSI only had a Network Layer, but the Internet has an Internet Layer! - Noel Chiappa, 1999 or How in the Hell Do You Lose a Layer!?
© John Day, 2013 Rights Reserved The Pouzin Society Preamble •  A Couple of Remarks on the Nature of Layering and a Quiz: •  The advent of packet switching required much more complex software than heretofore, and so the concept of layers was brought in from operating systems. •  In operating systems, layers are a convenience, one design choice. •  Why Do We Use Layers in Network Architecture? •  In networks, they are a necessity.
© John Day, 2013 Rights Reserved The Pouzin Society The (really) Important Thing about Layers (From first lecture of my intro to networks course) •  Networks have loci of distributed shared state with different scopes •  At the very least, differences of scope require different layers. •  It is this property that makes the earlier telephony or datacomm “beads-on-a-string” model untenable. –  – Or any other proposal that does not accommodate scope. •  This has always been understood. Host or End System Router Increasing Scope
© John Day, 2013 Rights Reserved The Pouzin Society Refining the Concept of Layer •  The Necessary and (usually) Sufficient Condition for a Layer is that there are loci of shared state of different scope. •  For Operating Systems and Networks, layers are ranges of resource allocation. •  If there are layers of the same scope, their functions must be completely independent. •  Dykstra wasn’t wrong: Functions do not repeat . . . in the same scope. •  The hardware at the time was so constrained he could only see one scope. •  If there is partitioning within the layer, it will generally be orthogonal to the attributes that impose layers.
© John Day, 2013 Rights Reserved The Pouzin Society The Beads on A String Model •  Over the years the Phone Companies Had Adopted what could be called, a “Beads-on-a-String” architecture. •  Perfectly reasonable for the technology they had. •  The model not only organized the work, but also defined the market. –  This was what was taught in most data comm courses prior to the 1980s. phone CO CO phone
© John Day, 2013 Rights Reserved The Pouzin Society Packet Switching •  In the early 1960s, Paul Baran at The Rand Corporation writes a series of reports investigating the networking requirements for the DoD. •  He finds that the requirements for data are very different than those for voice. •  Data is bursty. Voice is continuous. •  Data connections are short. Voice connections have long durations. •  There would be distinct advantages for a network built specifically for data. •  Greater efficiency. •  Greater survivability. •  Data would be sent in individual packets, rather than as continuous streams. •  Packet switching is born and •  By the late 1960s, the Advance Research Projects Agency decides building one would reduce the cost of research.
© John Day, 2013 Rights Reserved The Pouzin Society But was Packet Switching a Major Breakthrough? •  Strange as it may seem, it depends. •  During this period many things are age dependent. •  If your formative years had occurred prior to the mid-60s (pre-boomer), your model of communication was defined by telephony. –  Then this is revolutionary. •  If you are younger (boomer), your model is determined by computers. –  Data is in buffers, How do you do communications: •  Pick up a buffer and send it. –  What could be more obvious!
© John Day, 2013 Rights Reserved The Pouzin Society The Cyclades Architecture (1972) •  Transport Service provides end-to-end reliability. •  In that case, hop-by-hop reliability does not have to be perfect. •  Need only be sufficiently reliable to make end-to-end cost effective. •  Over a connectionless datagram network, Cigale •  Yields a simpler, more effective and robust data network. •  CYCLADES brings in the traditional layering from operating systems. •  This represents a new model, in fact, a new paradigm completely at odds with the beads-on-a-string model. Physical Data Link Network Transport Application Host or End System Router TS: End-to-End Reliability Cigale Subnet
© John Day, 2013 Rights Reserved The Pouzin Society The New Model Had 4 Characteristics ��  It was a peer network of communicating equals not a hierarchical network connecting a mainframe master with terminal slaves. •  The approach required coordinating distributed shared state at different scopes, which were treated as black boxes. This lead to the concept of layers being adopted from operating systems and •  There was a shift from largely deterministic to non-deterministic approaches, not just with datagrams in networks, but also with interrupt driven, as opposed to polled, operating systems, and physical media like Ethernet, and last but far from least, •  This was a computing model, a distributed computing model, not a Telecom or Data comm model. The network was the infrastructure of a computing facility
© John Day, 2013 Rights Reserved The Pouzin Society 1972 Was an Interesting Year •  Tinker AFB joined the ‘Net exposing the multihoming problem. •  The ARPANET had its coming out at ICCC ‘72. •  As fallout from ICCC 72, the research networks decided it would be good to form an International Network Working Group. –  ARPANET, NPL, CYCLADES, and other researchers –  Chartered as IFIP WG6.1 very soon after •  Major project was an International Transport Protocol. –  Also a virtual terminal protocol –  And work on formal description techniques •  But a major 3-sided war was just breaking
© John Day, 2013 Rights Reserved The Pouzin Society While the New Model Made Perfect Sense to Computing, It Was a Threat to Phone Companies. •  Transport Seals Off the Lower Layers from Applications. — Making the Network a Commodity, with very little possibility for value-add. •  TPC counters that Transport Layers are unnecessary, their networks are reliable. Transport The Network And they have their head in the sand, “Data will never exceed voice traffic”
© John Day, 2013 Rights Reserved The Pouzin Society The Phone Companies Responded •  And they tried to adapt. Using their model, to define markets. –  As they always had. •  Imitating the new concept of layers, they tried to introduce it. –  But even a simple idea like an interface wasn’t the same. Start-stop DTE PAD DCE DCE Packet -mode DTE Terminal Host Host Router Router The Network as seen by the new Networking Model The Network as seen by the PTTs Interface Interface
© John Day, 2013 Rights Reserved The Pouzin Society IBM had Two Problems Computing and Memory Prices were headed South . . . Fast. Computing Power and Capacity were headed North . . . Fast. By the late 70’s, it was clear that IBM’s days as the dominant computer maker were numbered And if that weren’t enough. LogH/W Prices CSEducated CheckSigners (Linear) 60’s 70’s 80’s 90’s 2000 Time 107 103
© John Day, 2013 Rights Reserved The Pouzin Society In Networking IBM Found Itself at a Dead-End Mainframe You can always make a peer architecture hierarchical But you can’t go the other way. But IBM and the PTTs had carefully stayed out of each other’s turf. Had IBM made SNA a peer network and subset it for the 70’s hierarchical market, the Internet would have been nothing but an interesting research project.
© John Day, 2013 Rights Reserved The Pouzin Society A Nasty Brawl Was Shaping Up The Phone Companies Against the Computer Companies and Everyone against IBM
© John Day, 2013 Rights Reserved The Pouzin Society Meanwhile Back at INWG There Were Two Proposals •  INWG 39 based on the early TCP and •  INWG 61 based on CYCLADES TS. •  And a healthy debate, see Alex McKenzie, “INWG and the Conception of the Internet: An Eyewitness Account” IEEE Annals of the History of Computing, 2011. •  Two sticking points –  How fragmentation should work –  Whether the data flow was an undifferentiated stream or maintained the integrity of the units sent (letter). •  These were not major differences.
© John Day, 2013 Rights Reserved The Pouzin Society After a Hot Debate •  A Synthesis was proposed: INWG 96 •  There was a vote in 1976, which approved INWG 96. •  As Alex says, NPL and CYCLADES immediately said they would convert to INWG 96; EIN said it would deploy only INWG 96. •  “But we were all shocked and amazed when Bob Kahn announced that DARPA researchers were too close to completing implementation of the updated INWG 39 protocol to incur the expense of switching to another design. As events proved, Kahn was wrong (or had other motives); the final TCP/IP specification was written in 1980 after at least four revisions.” –  Neither was right. The real breakthrough came two years later. •  But the differences weren’t the most interesting thing about this work.
© John Day, 2013 Rights Reserved The Pouzin Society The Similarity Among all 3 Is Much More Interesting •  This is before IP was separated from TCP. All 3 Transport Protocols carried addresses. •  This means that the Architecture that INWG was working to was: •  Three Layers of Different Scope each with Addresses. •  If this does not hit you like a ton of bricks, you haven’t been paying attention. •  This is NOT the architecture we have. Internetwork Transport Layer Network Layer Data Link Layer TCP IP MAC LLC SNDC SNAC
© John Day, 2013 Rights Reserved The Pouzin Society INWG’s Internet Model •  An Internet Layer addressed Hosts and Internet Gateways. •  Several Network Layers of different scope, possibly different technology, addressing hosts on that network and that network’s routers and its gateways. –  Inter-domain routing at the Internet Layer; Intra-Domain routing at the Network Layer. •  Data Link Layer smallest scope with addresses for the devices (hosts or routers) on segment it connects •  The Internet LOST A LAYER!! Internet Gateways Data Link Network Internet Application Data Link Network Internet Application Net 1 Net 2 Net 3 Host Host
© John Day, 2013 Rights Reserved The Pouzin Society How Did They Lose a Layer? •  To Hazard a Guess: (This is subtle so pay close attention) ‒  A Case of Sorcerer’s Apprentices (Thought they knew more than they did) –  The Internet was a DoD project with the ARPANET at its center •  Built and operated by BBN. Only BBN made IMPs –  In a sense, BBN was their PTT. –  Initially, the initial growth was LANs at the Edge connected by •  Internet Gateways: Ethernet on one side; BBN 1822 or X.25 on the other. •  The ARPANET had no “peers” in this environment. Now we split IP from TCP Remember, only one or two people involved in this were also involved in INWG MAC TCP 1822 ARPANET TCP MAC 1822 TCP ARPANET The View About 1976 Before IP is Split from TCP An Ethernet The ARPANET Internet Gateway Host Host
© John Day, 2013 Rights Reserved The Pouzin Society How Did They Lose A Layer? II After IP is Split Off •  But the ARPANET is a black box. Only BBN can see inside it. •  So to everyone else it looks like just another LAN. –  They start to think that way. •  Most of the new entries are workstations on LANs being connected together over short and long distances (with leased lines). •  Which leads to a picture that looks like: The View After 1976 Now IP is Split from TCP 1822 ARPANET TCP MAC 1822 TCP ARPANET An Ethernet IP IP IP MAC TCP IP Host Host Internet Gateway PPP TCP MAC IP IP Router An Ethernet The ARPANET
© John Day, 2013 Rights Reserved The Pouzin Society How Did They Lose a Layer? III •  And there are lots of them connecting to each other! –  The ARPANET is becoming less and less important. •  Voilà! Did you see it disappear? –  This is not an Internet, it is a beads-on-a-string Network! –  Just like the ITU!! –  No Internet Gateways, only Routers. The term disappears in the early 80s •  Separating IP from TCP; not understanding the importance of scope; the misconception of one protocol, one layer; just doing the next thing; all contributed to being an Internet in name only. MAC TCP An Ethernet IP PPP TCP MAC IP IP MAC TCP PPP IP IP MAC TCP IP An Ethernet Leased Line Host Host Router Router
© John Day, 2013 Rights Reserved The Pouzin Society So What Layer Did They Lose? •  It is not obvious. •  At first glance, one might say the Network Layer. –  The Protocol is called IP after all! –  Removing the ARPANET, “removed” the Network Layer, –  Everything just dropped down. •  But the Address continued to name the Interface, the subnet point of attachment, just like ARPANET addresses! –  Actions speak louder than words •  We must conclude that, . . . They Lost the Internet Layer!!!
© John Day, 2013 Rights Reserved The Pouzin Society The Big Mistake: Splitting IP from TCP •  The Rules say if there are two layers of the same scope, the functions must be completely independent. •  Are Separating Error and Flow Control from Relaying and Multiplexing independent? No! –  IP also handles fragmentation across networks. –  Remember, Don’t repeat functions in different layers of the same scope? •  Problem: IP fragmentation doesn’t work. –  IP has to receive all of the fragments of the same packet to reassemble. –  Retransmissions by TCP are distinct and not recognized by IP. •  Must be held for MPL (5 secs!). •  There can be considerable buffer space occupied. •  There is a fix: –  The equivalent of “doc, it hurts when I do this!” “Then don’t do it.” –  Not a “big” problem, but big enough to be suspicious. MTU Discovery.
© John Day, 2013 Rights Reserved The Pouzin Society But it is the Nature of the Problem That is Interesting •  The problem arises because there is a dependency between IP and TCP. The rule is broken. –  It tries to make it a beads on a string solution. •  A Careful Analysis of this Class of Protocols shows that the Functions naturally cleave (orthogonally) along lines of Control and Data. •  TCP was split in the Wrong Direction! •  It is one layer, not two. –  IP was a bad idea. Relaying/ Muxing Data Transfer Data Transfer Control Delimiting Seq Frag/Reassemb SDU Protection Retransmission and Flow Control
© John Day, 2013 Rights Reserved The Pouzin Society A Chance to Get Things on Track •  We knew in 1972, that we needed Application Names and some kind of Directory. •  Downloading the Host file from the NIC was clearly temporary. •  When the time came to automate it, it would be a good time to introduce Application Names! •  Nope, Just Automate the Host file. Big step backwards with DNS. •  Now we have domain names –  Macros for IP addresses •  And URLs –  Macros for jump points in low memory –  The path to the Application is named, but Nothing names the Application.
© John Day, 2013 Rights Reserved The Pouzin Society Then in ‘86: Congestion Collapse •  Caught Flat-footed. Why? Everyone knew about this? –  Had been investigated for 15 years at that point •  With a Network Architecture they put it in Transport. –  Worst place. •  Most important property of any congestion control scheme is minimizing time to notify. Internet maximizes it and its variance. •  And implicit detection makes it predatory. –  Virtually impossible to fix •  Whereas,
© John Day, 2013 Rights Reserved The Pouzin Society Congestion Control in an Internet is Clearly a Network Problem •  With an Internet Architecture, it clearly goes in the Network Layer –  Which was what everyone else had done. •  Time to Notify can be bounded and with less variance. •  Explicit Congestion Detection confines its effects to a specific network and to a specific layer. Internet Gateways Data Link Network Internet Application Data Link Network Internet Application Net 1 Net 2 Net 3 Host Host
© John Day, 2013 Rights Reserved The Pouzin Society Would be Nice to Manage the Network •  With a choice between a modern object-oriented protocol (HEMS) and a traditional approach (SNMP), err sorry . . . “a simple approach.” IETF goes with “simple.” –  Must be simple, it has the Largest implementation of the 3: •  SNMP, HEMS, CMIP. –  So simple too complex to use •  IEEE had tried the SNMP approach several years earlier so the shortcomings were well-known. •  Everything connectionless making it impossible to snapshot tables •  No attempt at commonality across MIBs. •  Router vendors played them for suckers and they fell for it. –  Not secure, can’t use for configuration. •  (Isn’t ASN.1 an encryption algorithm?) –  Much better to send passwords in the clear. –  It is all about account control
© John Day, 2013 Rights Reserved The Pouzin Society IPv6 Still Names the Interface? Why on Earth? •  Known about this problem since 1972 –  No Multihoming, kludged mobility –  Notice in an Internet Architecture this is straightforward. –  Signs the Internet crowd didn’t understand the Tinker AFB lesson. –  DARPA never made them fix it. •  By the Time of IPng, Tradition trumps Everything. •  IPv7 would have fixed it. –  But that fight was too intense. This is no longer science, let alone engineering. •  When they can’t ignore, and given post-IPng trauma they look for a workaround. •  “Deep thought” yields Voilà! Loc/Id Split!
© John Day, 2013 Rights Reserved The Pouzin Society Loc/ID Split (these are people who lost a layer to begin with, right?) •  You’ve got to be kidding?! Right! •  First off: –  Saltzer [1977] defines “resolve” as in “resolving a name” as “to locate an object in a particular context, given its name.” –  All names in computing locate something. •  So either nothing can be identified without locating it, nor located without identifying it, OR •  anything that doesn’t locate something is being used outside its context •  Hence it is either a false distinction or it is meaningless. •  Second, one must route to the end of the path. –  The locator is on the path to the end, it isn’t the end. –  The “identifier” locates the end of the path but they aren’t routing on it. –  No wonder it doesn’t scale •  There is no workaround. IP is fundamentally flawed.
© John Day, 2013 Rights Reserved The Pouzin Society Never Get a Busy Signal on the Internet! •  Golly Gee Whiz! What a Surprise!! •  With Plenty of Memory in NICs, Getting huge amounts of buffer space backing up behind flow control. •  If peer flow control in the protocol, pretty obvious one needs interface flow control as well. •  Well, Duh! What did you think was going to happen? –  If you push back, it has to go somewhere! –  Now you can have local congestion collapse! Flow Control 2010 They Discovered Buffer Bloat! No Interface Flow Control
© John Day, 2013 Rights Reserved The Pouzin Society Taking Stock •  The Internet has: –  Botched the protocol design –  Botched the architecture –  Botched the naming and addressing –  When they had an opportunity move in the right direction with application names, they didn’t. They did DNS. –  When they had an opportunity to move in the right direction with node addresses, they didn’t. They did IPv6. –  More than Botched Network Management –  Botched the Congestion Control twice –  Once so bad it probably can not be fixed. •  By my count this makes them 0 for 8! •  It defies reason! Do these guys have an anti-Midas touch or wha!?
© John Day, 2013 Rights Reserved The Pouzin Society But It is a Triumph! •  But It Works! •  So did DOS. Still does. •  ‘With Sufficient Thrust even Pigs Can Fly!’ - RFC 1925 •  As long as fiber and Moore’s Law stayed ahead of Internet Growth, there was no need to confront the mistakes. •  Now it is catching up to us, limiting us, and can’t be fixed. –  Fundamentally flawed, a dead end. –  Any further effort based on IP is a waste of time and effort. •  Throwing good money after bad –  Every patch (and that is all we see) is taking us further from where we need to be. (By that argument, so was DOS)
© John Day, 2013 Rights Reserved The Pouzin Society Want to Feel Really Bad? •  A Chapter of a forthcoming Book on the History of the Networking Business traces development in the 1980s: –  First companies were developing LAN products •  Workstations coming in but SNA is still dominant –  Then products to connect LANs together in the workplace. •  Novell and others are making inroads. –  Then connecting LANs over distances to create corporate networks. •  Corporations were concerned about security and wanted their own networks –  By the mid to late-80s, corporations wanted their suppliers on their networks. –  The next step would have been so many corporate networks wanting their suppliers on them, that it would have been advantageous to have a single network connecting the corporate networks. –  Notice this is a natural progression to the INWG Model. –  The Meddling of Big Government Caused the Entire Mess –  How Do I know this is what would have happened? –  Because it did. In the Middle of this is dumped free software and a subsidized ISP but with a flawed architecture and a lot of hype: The Internet!!
© John Day, 2013 Rights Reserved The Pouzin Society It Was the Computer Companies Who Were Doing the OSI Network Layer •  The other major effort at the time. •  The well-known 7-layer model was adopted at the first meeting in March 1978 and frozen. After that, they had to work within that. •  They knew they would have to accommodate different networks of different quality and different technology. •  One of their concerns in the Network Layer deliberations was interworking over a less capable network: •  Would need to enhance the less capable network with an additional protocol high-quality network low-quality network high-quality network high-quality network low-quality network high-quality network
© John Day, 2013 Rights Reserved The Pouzin Society They Sub-Divided the Network Layer •  This concern and the recognition that there would be different networks interworking lead OSI to divide the Network Layer into three sublayers, which might be optional depending on configuration: Subnet Independent Convergence (SNIC) Subnet Dependent Convergence (SNDC) Subnet Access (SNAC)
© John Day, 2013 Rights Reserved The Pouzin Society And Came to the INWG Model •  With the Transport Layer, this is the same as the INWG model. •  For different political reasons, OSI made a similar split to TCP/IP. •  Remember PTTs didn’t want a Transport Layer at all. –  This is independent confirmation. None of the OSI Network Layer group had been involved in INWG. •  So OSI had an Internet Architecture and the Internet has a Network Architecture. •  You just can’t make this stuff up! •  And signs of a repeating structure. Transport Layer Subnet Independent Subnet Dependent Subnet Access Data Link LLC Data Link MAC
© John Day, 2013 Rights Reserved The Pouzin Society INWG Was on The Right Track!! •  They were Close to Seeing it was a Repeating Structure –  A Structure we arrived at independently by a similar approach. •  This is a unique event in the History of Science –  There is no other example of a new paradigm being diverted by a flawed variant of the old paradigm, and completely crowds out any other view. –  The last 30 years have been the Dark Ages of Networking. –  Our task is to put things back on track. Not to go back to INWG, but to carry it forward, to adopt their method, to go back to doing science. Internetwork Transport Layer Network Layer Data Link Layer TCP IP MAC LLC SNDC SNAC
© John Day, 2013 Rights Reserved The Pouzin Society How Lucky Can You Get!? •  RINA picks up where INWG left off. RINA takes it the next step. –  Is RINA the answer? Who knows? We are doing the science and letting the chips fall where they may. –  Can you propose something that is simpler and answers more questions, makes predictions about things we haven’t seen? –  RINA does and has. . . . •  There is so much to explore! –  It is Interesting How Different the Fundamentals Are •  By Maximizing Invariance and Minimizing Discontinuity –  To scale, resource allocation problems require a repeating (recursive) structure. (confirmed by Herb Simon’s Science of the Artificial) –  A Layer is a Distributed Application for Managing InterProcess Communication.
© John Day, 2013 Rights Reserved The Pouzin Society Really Lucky! •  So Much to Explore! –  Multiple layers of the same rank implies a means to choose which one to use. •  Neither a global address space nor a global name space are absolute requirements –  The nature of security is much clearer, simpler, and more robust. –  Many new avenues to explore in congestion control and quality of service. –  And the adoption can be seamless. –  And there are implications beyond IPC to distributed systems in general that we are just beginning to understand: •  Hint: Distributed Applications are Local Computations. •  Is there more to Discover? •  Undoubtedly! (At all sorts of levels of detail, we basically have to finally understand networking.) –  This is the most fun you can have with your clothes on! ;-) •  Will it set conventional wisdom on its ear?! –  Been doing pretty good so far! ;-)
© John Day, 2013 Rights Reserved The Pouzin Society Questions?

More Related Content

1 lost layer130123

  • 1. © John Day, 2013 Rights Reserved The Pouzin Society Surviving Networking’s Dark Ages IRATI RINA Workshop John Day Barcelona 2013 OSI only had a Network Layer, but the Internet has an Internet Layer! - Noel Chiappa, 1999 or How in the Hell Do You Lose a Layer!?
  • 2. © John Day, 2013 Rights Reserved The Pouzin Society Preamble •  A Couple of Remarks on the Nature of Layering and a Quiz: •  The advent of packet switching required much more complex software than heretofore, and so the concept of layers was brought in from operating systems. •  In operating systems, layers are a convenience, one design choice. •  Why Do We Use Layers in Network Architecture? •  In networks, they are a necessity.
  • 3. © John Day, 2013 Rights Reserved The Pouzin Society The (really) Important Thing about Layers (From first lecture of my intro to networks course) •  Networks have loci of distributed shared state with different scopes •  At the very least, differences of scope require different layers. •  It is this property that makes the earlier telephony or datacomm “beads-on-a-string” model untenable. –  – Or any other proposal that does not accommodate scope. •  This has always been understood. Host or End System Router Increasing Scope
  • 4. © John Day, 2013 Rights Reserved The Pouzin Society Refining the Concept of Layer •  The Necessary and (usually) Sufficient Condition for a Layer is that there are loci of shared state of different scope. •  For Operating Systems and Networks, layers are ranges of resource allocation. •  If there are layers of the same scope, their functions must be completely independent. •  Dykstra wasn’t wrong: Functions do not repeat . . . in the same scope. •  The hardware at the time was so constrained he could only see one scope. •  If there is partitioning within the layer, it will generally be orthogonal to the attributes that impose layers.
  • 5. © John Day, 2013 Rights Reserved The Pouzin Society The Beads on A String Model •  Over the years the Phone Companies Had Adopted what could be called, a “Beads-on-a-String” architecture. •  Perfectly reasonable for the technology they had. •  The model not only organized the work, but also defined the market. –  This was what was taught in most data comm courses prior to the 1980s. phone CO CO phone
  • 6. © John Day, 2013 Rights Reserved The Pouzin Society Packet Switching •  In the early 1960s, Paul Baran at The Rand Corporation writes a series of reports investigating the networking requirements for the DoD. •  He finds that the requirements for data are very different than those for voice. •  Data is bursty. Voice is continuous. •  Data connections are short. Voice connections have long durations. •  There would be distinct advantages for a network built specifically for data. •  Greater efficiency. •  Greater survivability. •  Data would be sent in individual packets, rather than as continuous streams. •  Packet switching is born and •  By the late 1960s, the Advance Research Projects Agency decides building one would reduce the cost of research.
  • 7. © John Day, 2013 Rights Reserved The Pouzin Society But was Packet Switching a Major Breakthrough? •  Strange as it may seem, it depends. •  During this period many things are age dependent. •  If your formative years had occurred prior to the mid-60s (pre-boomer), your model of communication was defined by telephony. –  Then this is revolutionary. •  If you are younger (boomer), your model is determined by computers. –  Data is in buffers, How do you do communications: •  Pick up a buffer and send it. –  What could be more obvious!
  • 8. © John Day, 2013 Rights Reserved The Pouzin Society The Cyclades Architecture (1972) •  Transport Service provides end-to-end reliability. •  In that case, hop-by-hop reliability does not have to be perfect. •  Need only be sufficiently reliable to make end-to-end cost effective. •  Over a connectionless datagram network, Cigale •  Yields a simpler, more effective and robust data network. •  CYCLADES brings in the traditional layering from operating systems. •  This represents a new model, in fact, a new paradigm completely at odds with the beads-on-a-string model. Physical Data Link Network Transport Application Host or End System Router TS: End-to-End Reliability Cigale Subnet
  • 9. © John Day, 2013 Rights Reserved The Pouzin Society The New Model Had 4 Characteristics •  It was a peer network of communicating equals not a hierarchical network connecting a mainframe master with terminal slaves. •  The approach required coordinating distributed shared state at different scopes, which were treated as black boxes. This lead to the concept of layers being adopted from operating systems and •  There was a shift from largely deterministic to non-deterministic approaches, not just with datagrams in networks, but also with interrupt driven, as opposed to polled, operating systems, and physical media like Ethernet, and last but far from least, •  This was a computing model, a distributed computing model, not a Telecom or Data comm model. The network was the infrastructure of a computing facility
  • 10. © John Day, 2013 Rights Reserved The Pouzin Society 1972 Was an Interesting Year •  Tinker AFB joined the ‘Net exposing the multihoming problem. •  The ARPANET had its coming out at ICCC ‘72. •  As fallout from ICCC 72, the research networks decided it would be good to form an International Network Working Group. –  ARPANET, NPL, CYCLADES, and other researchers –  Chartered as IFIP WG6.1 very soon after •  Major project was an International Transport Protocol. –  Also a virtual terminal protocol –  And work on formal description techniques •  But a major 3-sided war was just breaking
  • 11. © John Day, 2013 Rights Reserved The Pouzin Society While the New Model Made Perfect Sense to Computing, It Was a Threat to Phone Companies. •  Transport Seals Off the Lower Layers from Applications. — Making the Network a Commodity, with very little possibility for value-add. •  TPC counters that Transport Layers are unnecessary, their networks are reliable. Transport The Network And they have their head in the sand, “Data will never exceed voice traffic”
  • 12. © John Day, 2013 Rights Reserved The Pouzin Society The Phone Companies Responded •  And they tried to adapt. Using their model, to define markets. –  As they always had. •  Imitating the new concept of layers, they tried to introduce it. –  But even a simple idea like an interface wasn’t the same. Start-stop DTE PAD DCE DCE Packet -mode DTE Terminal Host Host Router Router The Network as seen by the new Networking Model The Network as seen by the PTTs Interface Interface
  • 13. © John Day, 2013 Rights Reserved The Pouzin Society IBM had Two Problems Computing and Memory Prices were headed South . . . Fast. Computing Power and Capacity were headed North . . . Fast. By the late 70’s, it was clear that IBM’s days as the dominant computer maker were numbered And if that weren’t enough. LogH/W Prices CSEducated CheckSigners (Linear) 60’s 70’s 80’s 90’s 2000 Time 107 103
  • 14. © John Day, 2013 Rights Reserved The Pouzin Society In Networking IBM Found Itself at a Dead-End Mainframe You can always make a peer architecture hierarchical But you can’t go the other way. But IBM and the PTTs had carefully stayed out of each other’s turf. Had IBM made SNA a peer network and subset it for the 70’s hierarchical market, the Internet would have been nothing but an interesting research project.
  • 15. © John Day, 2013 Rights Reserved The Pouzin Society A Nasty Brawl Was Shaping Up The Phone Companies Against the Computer Companies and Everyone against IBM
  • 16. © John Day, 2013 Rights Reserved The Pouzin Society Meanwhile Back at INWG There Were Two Proposals •  INWG 39 based on the early TCP and •  INWG 61 based on CYCLADES TS. •  And a healthy debate, see Alex McKenzie, “INWG and the Conception of the Internet: An Eyewitness Account” IEEE Annals of the History of Computing, 2011. •  Two sticking points –  How fragmentation should work –  Whether the data flow was an undifferentiated stream or maintained the integrity of the units sent (letter). •  These were not major differences.
  • 17. © John Day, 2013 Rights Reserved The Pouzin Society After a Hot Debate •  A Synthesis was proposed: INWG 96 •  There was a vote in 1976, which approved INWG 96. •  As Alex says, NPL and CYCLADES immediately said they would convert to INWG 96; EIN said it would deploy only INWG 96. •  “But we were all shocked and amazed when Bob Kahn announced that DARPA researchers were too close to completing implementation of the updated INWG 39 protocol to incur the expense of switching to another design. As events proved, Kahn was wrong (or had other motives); the final TCP/IP specification was written in 1980 after at least four revisions.” –  Neither was right. The real breakthrough came two years later. •  But the differences weren’t the most interesting thing about this work.
  • 18. © John Day, 2013 Rights Reserved The Pouzin Society The Similarity Among all 3 Is Much More Interesting •  This is before IP was separated from TCP. All 3 Transport Protocols carried addresses. •  This means that the Architecture that INWG was working to was: •  Three Layers of Different Scope each with Addresses. •  If this does not hit you like a ton of bricks, you haven’t been paying attention. •  This is NOT the architecture we have. Internetwork Transport Layer Network Layer Data Link Layer TCP IP MAC LLC SNDC SNAC
  • 19. © John Day, 2013 Rights Reserved The Pouzin Society INWG’s Internet Model •  An Internet Layer addressed Hosts and Internet Gateways. •  Several Network Layers of different scope, possibly different technology, addressing hosts on that network and that network’s routers and its gateways. –  Inter-domain routing at the Internet Layer; Intra-Domain routing at the Network Layer. •  Data Link Layer smallest scope with addresses for the devices (hosts or routers) on segment it connects •  The Internet LOST A LAYER!! Internet Gateways Data Link Network Internet Application Data Link Network Internet Application Net 1 Net 2 Net 3 Host Host
  • 20. © John Day, 2013 Rights Reserved The Pouzin Society How Did They Lose a Layer? •  To Hazard a Guess: (This is subtle so pay close attention) ‒  A Case of Sorcerer’s Apprentices (Thought they knew more than they did) –  The Internet was a DoD project with the ARPANET at its center •  Built and operated by BBN. Only BBN made IMPs –  In a sense, BBN was their PTT. –  Initially, the initial growth was LANs at the Edge connected by •  Internet Gateways: Ethernet on one side; BBN 1822 or X.25 on the other. •  The ARPANET had no “peers” in this environment. Now we split IP from TCP Remember, only one or two people involved in this were also involved in INWG MAC TCP 1822 ARPANET TCP MAC 1822 TCP ARPANET The View About 1976 Before IP is Split from TCP An Ethernet The ARPANET Internet Gateway Host Host
  • 21. © John Day, 2013 Rights Reserved The Pouzin Society How Did They Lose A Layer? II After IP is Split Off •  But the ARPANET is a black box. Only BBN can see inside it. •  So to everyone else it looks like just another LAN. –  They start to think that way. •  Most of the new entries are workstations on LANs being connected together over short and long distances (with leased lines). •  Which leads to a picture that looks like: The View After 1976 Now IP is Split from TCP 1822 ARPANET TCP MAC 1822 TCP ARPANET An Ethernet IP IP IP MAC TCP IP Host Host Internet Gateway PPP TCP MAC IP IP Router An Ethernet The ARPANET
  • 22. © John Day, 2013 Rights Reserved The Pouzin Society How Did They Lose a Layer? III •  And there are lots of them connecting to each other! –  The ARPANET is becoming less and less important. •  Voilà! Did you see it disappear? –  This is not an Internet, it is a beads-on-a-string Network! –  Just like the ITU!! –  No Internet Gateways, only Routers. The term disappears in the early 80s •  Separating IP from TCP; not understanding the importance of scope; the misconception of one protocol, one layer; just doing the next thing; all contributed to being an Internet in name only. MAC TCP An Ethernet IP PPP TCP MAC IP IP MAC TCP PPP IP IP MAC TCP IP An Ethernet Leased Line Host Host Router Router
  • 23. © John Day, 2013 Rights Reserved The Pouzin Society So What Layer Did They Lose? •  It is not obvious. •  At first glance, one might say the Network Layer. –  The Protocol is called IP after all! –  Removing the ARPANET, “removed” the Network Layer, –  Everything just dropped down. •  But the Address continued to name the Interface, the subnet point of attachment, just like ARPANET addresses! –  Actions speak louder than words •  We must conclude that, . . . They Lost the Internet Layer!!!
  • 24. © John Day, 2013 Rights Reserved The Pouzin Society The Big Mistake: Splitting IP from TCP •  The Rules say if there are two layers of the same scope, the functions must be completely independent. •  Are Separating Error and Flow Control from Relaying and Multiplexing independent? No! –  IP also handles fragmentation across networks. –  Remember, Don’t repeat functions in different layers of the same scope? •  Problem: IP fragmentation doesn’t work. –  IP has to receive all of the fragments of the same packet to reassemble. –  Retransmissions by TCP are distinct and not recognized by IP. •  Must be held for MPL (5 secs!). •  There can be considerable buffer space occupied. •  There is a fix: –  The equivalent of “doc, it hurts when I do this!” “Then don’t do it.” –  Not a “big” problem, but big enough to be suspicious. MTU Discovery.
  • 25. © John Day, 2013 Rights Reserved The Pouzin Society But it is the Nature of the Problem That is Interesting •  The problem arises because there is a dependency between IP and TCP. The rule is broken. –  It tries to make it a beads on a string solution. •  A Careful Analysis of this Class of Protocols shows that the Functions naturally cleave (orthogonally) along lines of Control and Data. •  TCP was split in the Wrong Direction! •  It is one layer, not two. –  IP was a bad idea. Relaying/ Muxing Data Transfer Data Transfer Control Delimiting Seq Frag/Reassemb SDU Protection Retransmission and Flow Control
  • 26. © John Day, 2013 Rights Reserved The Pouzin Society A Chance to Get Things on Track •  We knew in 1972, that we needed Application Names and some kind of Directory. •  Downloading the Host file from the NIC was clearly temporary. •  When the time came to automate it, it would be a good time to introduce Application Names! •  Nope, Just Automate the Host file. Big step backwards with DNS. •  Now we have domain names –  Macros for IP addresses •  And URLs –  Macros for jump points in low memory –  The path to the Application is named, but Nothing names the Application.
  • 27. © John Day, 2013 Rights Reserved The Pouzin Society Then in ‘86: Congestion Collapse •  Caught Flat-footed. Why? Everyone knew about this? –  Had been investigated for 15 years at that point •  With a Network Architecture they put it in Transport. –  Worst place. •  Most important property of any congestion control scheme is minimizing time to notify. Internet maximizes it and its variance. •  And implicit detection makes it predatory. –  Virtually impossible to fix •  Whereas,
  • 28. © John Day, 2013 Rights Reserved The Pouzin Society Congestion Control in an Internet is Clearly a Network Problem •  With an Internet Architecture, it clearly goes in the Network Layer –  Which was what everyone else had done. •  Time to Notify can be bounded and with less variance. •  Explicit Congestion Detection confines its effects to a specific network and to a specific layer. Internet Gateways Data Link Network Internet Application Data Link Network Internet Application Net 1 Net 2 Net 3 Host Host
  • 29. © John Day, 2013 Rights Reserved The Pouzin Society Would be Nice to Manage the Network •  With a choice between a modern object-oriented protocol (HEMS) and a traditional approach (SNMP), err sorry . . . “a simple approach.” IETF goes with “simple.” –  Must be simple, it has the Largest implementation of the 3: •  SNMP, HEMS, CMIP. –  So simple too complex to use •  IEEE had tried the SNMP approach several years earlier so the shortcomings were well-known. •  Everything connectionless making it impossible to snapshot tables •  No attempt at commonality across MIBs. •  Router vendors played them for suckers and they fell for it. –  Not secure, can’t use for configuration. •  (Isn’t ASN.1 an encryption algorithm?) –  Much better to send passwords in the clear. –  It is all about account control
  • 30. © John Day, 2013 Rights Reserved The Pouzin Society IPv6 Still Names the Interface? Why on Earth? •  Known about this problem since 1972 –  No Multihoming, kludged mobility –  Notice in an Internet Architecture this is straightforward. –  Signs the Internet crowd didn’t understand the Tinker AFB lesson. –  DARPA never made them fix it. •  By the Time of IPng, Tradition trumps Everything. •  IPv7 would have fixed it. –  But that fight was too intense. This is no longer science, let alone engineering. •  When they can’t ignore, and given post-IPng trauma they look for a workaround. •  “Deep thought” yields Voilà! Loc/Id Split!
  • 31. © John Day, 2013 Rights Reserved The Pouzin Society Loc/ID Split (these are people who lost a layer to begin with, right?) •  You’ve got to be kidding?! Right! •  First off: –  Saltzer [1977] defines “resolve” as in “resolving a name” as “to locate an object in a particular context, given its name.” –  All names in computing locate something. •  So either nothing can be identified without locating it, nor located without identifying it, OR •  anything that doesn’t locate something is being used outside its context •  Hence it is either a false distinction or it is meaningless. •  Second, one must route to the end of the path. –  The locator is on the path to the end, it isn’t the end. –  The “identifier” locates the end of the path but they aren’t routing on it. –  No wonder it doesn’t scale •  There is no workaround. IP is fundamentally flawed.
  • 32. © John Day, 2013 Rights Reserved The Pouzin Society Never Get a Busy Signal on the Internet! •  Golly Gee Whiz! What a Surprise!! •  With Plenty of Memory in NICs, Getting huge amounts of buffer space backing up behind flow control. •  If peer flow control in the protocol, pretty obvious one needs interface flow control as well. •  Well, Duh! What did you think was going to happen? –  If you push back, it has to go somewhere! –  Now you can have local congestion collapse! Flow Control 2010 They Discovered Buffer Bloat! No Interface Flow Control
  • 33. © John Day, 2013 Rights Reserved The Pouzin Society Taking Stock •  The Internet has: –  Botched the protocol design –  Botched the architecture –  Botched the naming and addressing –  When they had an opportunity move in the right direction with application names, they didn’t. They did DNS. –  When they had an opportunity to move in the right direction with node addresses, they didn’t. They did IPv6. –  More than Botched Network Management –  Botched the Congestion Control twice –  Once so bad it probably can not be fixed. •  By my count this makes them 0 for 8! •  It defies reason! Do these guys have an anti-Midas touch or wha!?
  • 34. © John Day, 2013 Rights Reserved The Pouzin Society But It is a Triumph! •  But It Works! •  So did DOS. Still does. •  ‘With Sufficient Thrust even Pigs Can Fly!’ - RFC 1925 •  As long as fiber and Moore’s Law stayed ahead of Internet Growth, there was no need to confront the mistakes. •  Now it is catching up to us, limiting us, and can’t be fixed. –  Fundamentally flawed, a dead end. –  Any further effort based on IP is a waste of time and effort. •  Throwing good money after bad –  Every patch (and that is all we see) is taking us further from where we need to be. (By that argument, so was DOS)
  • 35. © John Day, 2013 Rights Reserved The Pouzin Society Want to Feel Really Bad? •  A Chapter of a forthcoming Book on the History of the Networking Business traces development in the 1980s: –  First companies were developing LAN products •  Workstations coming in but SNA is still dominant –  Then products to connect LANs together in the workplace. •  Novell and others are making inroads. –  Then connecting LANs over distances to create corporate networks. •  Corporations were concerned about security and wanted their own networks –  By the mid to late-80s, corporations wanted their suppliers on their networks. –  The next step would have been so many corporate networks wanting their suppliers on them, that it would have been advantageous to have a single network connecting the corporate networks. –  Notice this is a natural progression to the INWG Model. –  The Meddling of Big Government Caused the Entire Mess –  How Do I know this is what would have happened? –  Because it did. In the Middle of this is dumped free software and a subsidized ISP but with a flawed architecture and a lot of hype: The Internet!!
  • 36. © John Day, 2013 Rights Reserved The Pouzin Society It Was the Computer Companies Who Were Doing the OSI Network Layer •  The other major effort at the time. •  The well-known 7-layer model was adopted at the first meeting in March 1978 and frozen. After that, they had to work within that. •  They knew they would have to accommodate different networks of different quality and different technology. •  One of their concerns in the Network Layer deliberations was interworking over a less capable network: •  Would need to enhance the less capable network with an additional protocol high-quality network low-quality network high-quality network high-quality network low-quality network high-quality network
  • 37. © John Day, 2013 Rights Reserved The Pouzin Society They Sub-Divided the Network Layer •  This concern and the recognition that there would be different networks interworking lead OSI to divide the Network Layer into three sublayers, which might be optional depending on configuration: Subnet Independent Convergence (SNIC) Subnet Dependent Convergence (SNDC) Subnet Access (SNAC)
  • 38. © John Day, 2013 Rights Reserved The Pouzin Society And Came to the INWG Model •  With the Transport Layer, this is the same as the INWG model. •  For different political reasons, OSI made a similar split to TCP/IP. •  Remember PTTs didn’t want a Transport Layer at all. –  This is independent confirmation. None of the OSI Network Layer group had been involved in INWG. •  So OSI had an Internet Architecture and the Internet has a Network Architecture. •  You just can’t make this stuff up! •  And signs of a repeating structure. Transport Layer Subnet Independent Subnet Dependent Subnet Access Data Link LLC Data Link MAC
  • 39. © John Day, 2013 Rights Reserved The Pouzin Society INWG Was on The Right Track!! •  They were Close to Seeing it was a Repeating Structure –  A Structure we arrived at independently by a similar approach. •  This is a unique event in the History of Science –  There is no other example of a new paradigm being diverted by a flawed variant of the old paradigm, and completely crowds out any other view. –  The last 30 years have been the Dark Ages of Networking. –  Our task is to put things back on track. Not to go back to INWG, but to carry it forward, to adopt their method, to go back to doing science. Internetwork Transport Layer Network Layer Data Link Layer TCP IP MAC LLC SNDC SNAC
  • 40. © John Day, 2013 Rights Reserved The Pouzin Society How Lucky Can You Get!? •  RINA picks up where INWG left off. RINA takes it the next step. –  Is RINA the answer? Who knows? We are doing the science and letting the chips fall where they may. –  Can you propose something that is simpler and answers more questions, makes predictions about things we haven’t seen? –  RINA does and has. . . . •  There is so much to explore! –  It is Interesting How Different the Fundamentals Are •  By Maximizing Invariance and Minimizing Discontinuity –  To scale, resource allocation problems require a repeating (recursive) structure. (confirmed by Herb Simon’s Science of the Artificial) –  A Layer is a Distributed Application for Managing InterProcess Communication.
  • 41. © John Day, 2013 Rights Reserved The Pouzin Society Really Lucky! •  So Much to Explore! –  Multiple layers of the same rank implies a means to choose which one to use. •  Neither a global address space nor a global name space are absolute requirements –  The nature of security is much clearer, simpler, and more robust. –  Many new avenues to explore in congestion control and quality of service. –  And the adoption can be seamless. –  And there are implications beyond IPC to distributed systems in general that we are just beginning to understand: •  Hint: Distributed Applications are Local Computations. •  Is there more to Discover? •  Undoubtedly! (At all sorts of levels of detail, we basically have to finally understand networking.) –  This is the most fun you can have with your clothes on! ;-) •  Will it set conventional wisdom on its ear?! –  Been doing pretty good so far! ;-)
  • 42. © John Day, 2013 Rights Reserved The Pouzin Society Questions?