# Networking Essentials: Architecture and Principles Original: https://swyx.io/networking-essentials-architecture-and-principles-2g5e Published: 2018-09-04 > Discussing the architecture of the Internet and its the principles that guided its original design. *This is the first in a series of class notes as I go through the [free Udacity Computer Networking Basics course](https://www.udacity.com/course/computer-networking--ud436).* ## The Fundamental Goal *For much of this information our chief reference is David Clark's [The Design Philosophy of the DARPA Internet Protocols](http://ccr.sigcomm.org/archive/1995/jan95/ccr-9501-clark.pdf) paper published in 1988.* The fundamental design goal of the Internet was to achieve "effective multiplexed utilization of existing interconnected networks". In English, that means we **share** usage of **connected** networks. - The goal of **sharing** is solved by **[statistical multiplexing](https://en.wikipedia.org/wiki/Statistical_time-division_multiplexing)** (aka packet switching). In **packet switching**, every packet sent carries it's own destination information, so it can be forwarded along, similar to how a letter sent through the mail has its destination on it. This means the network can deliver the packet on a [best effort](https://en.wikipedia.org/wiki/Best-effort_delivery) basis, which enables sharing because many senders can use the same network at the same time but at the risk of some droppped packages. This is in contrast to **circuit switching**, which is more like a phone network - direct connections are established, transmissions have less chance of losing/dropping packets, but if the available capacity is taken up, you're out of luck. - The goal of **connecting** networks is solved by the "[narrow waist](https://www.youtube.com/watch?v=uXumm52oBMo)". With reference to [the OSI 7 layer systems model](https://en.wikipedia.org/wiki/OSI_model), our **network layer** is very thin - it mostly consists of [the Internet Protocol](https://en.wikipedia.org/wiki/Internet_Protocol)! IP provides guarantees to the **transport layer** sitting above it, usually [TCP](https://en.wikipedia.org/wiki/Transmission_Control_Protocol) or [UDP](https://en.wikipedia.org/wiki/User_Datagram_Protocol), and the combination of [TCP/IP](https://en.wikipedia.org/wiki/Internet_protocol_suite) is the most common end to end data transmission stack. On top of this solid foundation we can layer whatever protocols we want to send data, e.g. [HTTP](https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol) for websites or [SMTP](https://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol) for mail! Below the IP layer we also have the [link layer](https://en.wikipedia.org/wiki/Data_link_layer) and [physical layers](https://en.wikipedia.org/wiki/Physical_layer) with still more protocols like [Ethernet](https://en.wikipedia.org/wiki/Ethernet) and [SONET](https://en.wikipedia.org/wiki/Synchronous_optical_networking). But the point is, the middle network layer is "narrow" - it just consists of IP. This means it is fairly easy to get any device on the network, it just has to speak IP! ![the key parts of OSI model](https://images.slideplayer.com/24/7320353/slides/slide_25.jpg) ## Secondary Goals The secondary goals all consist of further defining what the word "effective" really means in the "fundamental goal" listed above: 1. **Survivability**: Internet communication **must continue despite loss** of networks or gateways. 2. **Heterogeneity 1**: The Internet must support **multiple types of communications service**. 3. **Heterogeneity 2**: The Internet architecture must accommodate **a variety of networks**. 4. **Decentralization**: The Internet architecture must **permit distributed management** of its resources. 5. **Cost**: The Internet architecture must be **cost effective**. 6. **Ease**: The Internet architecture must permit **host attachment with a low level of effort**. 7. **Trackability**: The resources used in the internet architecture must be **accountable**. We don't have space to discuss the implications of them all here, but will dwell on a few important ones. ## Survivability We take this to mean that the network should continue to work even if some devices fail or are compromised. How do we achieve this? One way to do it is through **replication**, where we duplicate state in another node so that there is always a backup ready to take over in case of failure. However this trades off against cost, another of our goals. Another interesting method is [fate-sharing](https://en.wikipedia.org/wiki/Fate-sharing) - where if the node disconnects, we consider it acceptable to simply lose all information relevant to that node. ## Heterogeneity The Internet's "narrow waist" design allows multiple protocols to be supported over IP, not just TCP (as previously discussed). This lends itself very well to picking the right protocol for the job, for example picking UDP for the purpose of streaming data since it is more important to be realtime than to be completely lossless. You can even use a [combination of protocols](https://en.wikipedia.org/wiki/Domain_Name_System#DNS_Protocol_transport) to get the best of both speed and losslessness. The "best-effort" principle of delivery also means data can be delivered over and between any sort of network (including [carrier pigeon](https://www.cnet.com/news/pigeon-powered-internet-takes-flight/)!!) with the tradeoff of difficulty of debugging since no failure data comes back. ## Decentralization Distributed management of resources can be seen in how [Addressing](http://what-when-how.com/data-communications-and-networking/addressing-data-communications-and-networking/) is achieved - which I will detail in a future primer. We have five [Regional Internet Registries](https://en.wikipedia.org/wiki/Regional_Internet_registry) worldwide - In the US we have [ARIN](https://en.wikipedia.org/wiki/American_Registry_for_Internet_Numbers) and the European equivalent is [RIPE](https://en.wikipedia.org/wiki/R%C3%A9seaux_IP_Europ%C3%A9ens_Network_Coordination_Centre). We also have decentralization in naming - [DNS](https://en.wikipedia.org/wiki/Domain_Name_System) delegates the responsibility of assigning domain names and mapping those names to Internet resources by designating authoritative name servers for each domain. Routing through [Border Gateway Protocol (BGP)](https://en.wikipedia.org/wiki/Border_Gateway_Protocol) is decentralized as well between peers and communities. We will also return to both in a future primer. Because no single entity is in charge, the Internet has been able to grow organically and is very stable. However the lack of ownership also makes it hard to address problems. ## Problems and Growing Pains ![ipv4 rundown](https://images.theconversation.com/files/83083/original/image-20150527-4812-1iqroxb.png?ixlib=rb-1.1.0&q=45&auto=format&w=1000&fit=clip) Many of the problems we see on the Internet today are a direct result of the needs of the network outgrowing the design considerations of the 70's and 80's: - We are [running out of IPv4 addresses](https://www.theregister.co.uk/2017/02/15/no_more_ipv4/) - only 4 billion IP addresses, [inefficiently allocated](https://www.quora.com/How-did-MIT-end-up-with-an-entire-class-A-subnet-of-the-IP-address-space). - [Congestion Control](http://ecomputernotes.com/computernetworkingnotes/communication-networks/what-is-congestion-control-describe-the-congestion-control-algorithm-commonly-used) - our networks get very unperformant over flaky connections, especially because retransmissions are triggered. I will cover this in a future primer. - [Routing](http://www.enterprisenetworkingplanet.com/netsp/article.php/3615896/Networking-101-Understanding-BGP-Routing.htm) - a topic I will cover in a later primer, but basically it has no security, is easily misconfigured, and exhibits poor convergence and non-determinism. But it sorta works. - [Security](https://isc.sans.edu/presentations/first_things_first.html) deserves its own primer as well: methods for encryption and authentication exist, but we haven't done so well at making sure that they are *used*. Also key management and secure software deployment are open problems. - [Denial of Service](https://www.digitalattackmap.com/understanding-ddos/) - the Internet maybe does too good of a job delivering packages to the recipient, even if the recipient doesn't wan't them. ## Next in our series Hopefully this has been a good high level overview of why we need Switches and how they might work if we were to make our own Internet. I am planning more primers and would love your feedback and questions on: - [Architecture and Principles](https://dev.to/swyx/networking-essentials-architecture-and-principles-2g5e) - [Switching](https://dev.to/swyx/networking-essentials-switching-3eba) - [Routing](https://dev.to/swyx/networking-essentials-routing-5gb7/) - [Naming/Addressing/Forwarding](https://dev.to/swyx/networking-essentials-naming-addressing-and-forwarding-13kk) - [DNS](https://dev.to/swyx/networking-essentials-dns-1dl7) - [Congestion Control and Streaming](https://dev.to/swyx/networking-essentials-congestion-control-26n2) - [Rate Limiting and Traffic Shaping](https://dev.to/swyx/networking-essentials-rate-limiting-and-traffic-shaping-43ii) - [Content Distribution](https://dev.to/swyx/networking-essentials-content-distribution-jag) - [Software Defined Networks](https://dev.to/swyx/networking-essentials-software-defined-networking-35n9) - [Traffic Engineering](https://dev.to/swyx/networking-essentials-traffic-engineering-13c4) - [Network Security](https://dev.to/swyx/networking-essentials-network-security-1fcp)