Introduction ============= * Outline - What is the Internet made of? - Visualize all the steps when you browse a webpage - Layering abstraction, encapsulation - Overview of all the layers of the network stack - Circuit switching vs packet switching - A brief history of the Internet * What is the Internet made of? - Computers connected by links. - Multiple links terminate at a switch/router. Switches and routers connect a set of computers to one another. - Many switches/routers in an organization like IITB to connect all the end-hosts. - Internet Service providers (ISPs) connect multiple such end-user organizations. - ISP networks have several routers that provide interconnections and form the "backbone" of the Internet. - Some end hosts also provide useful services and applications (e.g., web and mail servers). So the internet is mainly "endhosts" and "routers". * Notion of IP addresses: every machine (well, almost...) on the Internet has a unique address called the IP address . Assigned statically or dynamically (e.g., DHCP). Can be public or private (e.g., like in IITB). * Example: what happens when you open a web page from a computer by typing in a URL? - The URL gets resolved into an IP address of the web server that hosts this page via DNS. - Browser opens a TCP connection to the web server, and sends a GET request for the web page - Server sends some HTML content, which the browser displays - Browser may send several GET requests for different images and other objects, may open multiple TCP connections - One layer below, the TCP data to the server must be routed to the server's IP address. - Several routers along the way forward these TCP segments from one IP hop to the next. - At the final IP hop, the IP router next to the web server hands the packet to the web server over the LAN. - Several TCP segments and ACKs go back and forth this way to transfer the complete web page. * The above example illustrates the concept of layering. There are several functions in the networking "stack", each handled by a layer. A layer at one host talks to its "peer" layer at the other host using a set of "protocols" that they both follow. Every layer provides a "service" or "abstraction" that the higher layer uses. For example, the application layer at client says GET a page and the application layer at server sends the page. This is the HTTP protocol. HTTP protocol uses the transport "service" provided by the TCP layer. That is, once it hands over the GET message to the TCP layer, the TCP layer takes care of actually transporting the bits in the message to the other end. * There are 5/7 layers depending on which system you look (OSI vs Internet). The 5 layers are the most important ones: from top to bottom they are: application, transport, network, link, and physical. * Encapsulation and decpasulation. Every layer adds headers to the bytes it gets from the layer above. The headers are useful for operations of that layer. These headers are consumed and removed by the peer at the other end. * Application layer: just concerned with the application-level semantics. GET a web page and display it. Browser issues requests and displays result. Web server holds all the pages on its disk/memory (or computes them dynamically), and serves them when a request arrives. Several application layer protocols exist. HTTP is the most popular one, but several others exist (SMTP for email), P2P protocols etc. We will study some popular application layer protocols, and learn how they are built using the socket interface. * The transport layer (usually TCP, but sometimes UDP/RTP etc) is concerned with the transfer of the bits and bytes that make up the application data. This layer takes the application layer "messages", makes them into TCP "segments", transmits them at a suitable pace that the network can handle, makes sure they are received and acknowledged by the other end host, retransmits them when needed. TCP does not care about what the data is (that's the job of the application layer), or how the data gets there (thats the job of the lower layers). That is, TCP provides a reliable in-order data stream abstraction. TCP performs congestion/flow control to ensure that it sends data at an optimum rate that the underlying network can handle (not too slow, not too fast). TCP is the most common, but UDP is used when reliability is not needed. RTP is used for real time services like VOIP applications. There are several variants of TCP also. We will study TCP's design and algorithms in detail, and get hands-on experience using simulations. * The application and transport layers are end-to-end: they run at only the end hosts, and don't care what the network does in between. The end-to-end principle is a design principle of the internet, which says that all "intelligence" and applications should reside at the end hosts, and the network core should be "dumb" and just concern itself with efficient transportation of information. * Next is the network or IP layer or Layer 3. TCP segments are converted to "IP datagrams". The datagram has a source and destination IP address. The job of the network layer is to route the datagram to its destination IP address. Each IP router along the way looks up the destination address and decides which link it should forward the packet next. * IP addresses have hierarchical structure, and are aggregated into IP prefixes. Every IP router has several incoming links/ports (port is physical attachment point for an incoming/outgoing link) and several outgoing links/ports. For every incoming packet, IP router looks up a "forwarding table" and decides which port to send packet on. Forwarding table maps IP prefixes to next hop IP addresses (and hence to outgoing port that connects to the next hop IP router). * Forwarding tables are computed by routing protocols. Routing protocols help compute "routes" which decide how to forward a packet. A route is a specification of the path to reach a certain IP prefix. Minimally, for every IP prefix, its route tells us the next hop IP router on the path and the distance/metric to get to the destination along this path. Optionally, it can provide more details about the path. For every IP prefix, routing protocols gather information about several routes, pick the best one by some metric (e.g., shortest path), and insert this best route into the forwarding table. A routing table is this a superset of the forwarding table. * Intradomain routing (within an organization) and interdomain/wide-area routing (across the internet) are two different things. The former just deals with shortest paths while the latter has to deal with policy as well (i.e., the guy on the shortest path may not carry your data if he has no financial relationship with you). So separate routing protocols exist for intra and interdomain routing. * Intradomain routing protocols like OSPF run on IP routers in an organiztion and compute shortest paths. BGP is the interdomain routing protocol that runs or "border" routers that connect several organizations. BGP computes shortest paths subject to policy constraints. That is, the Inernet can be viewed as a network of networks. One layer of networks are managed by the intradomain routing protocols, and BGP ties up all these individual networks. Large ISP networks (called Tier-I networks) have several hundreds of BGP routers that connect to several smaller ISP networks (tier-II), which in turn connect to smaller ISPs and end-user organizations. The large ISP networks at the middle of the Inernet form the core or backbone of the Internet. * Next is link layer (layer 2). Deals with delivering a link layer "frame" from the last IP hop to the end-host, through a shared LAN or a switch. First, the link layer maps IP address of destination to its MAC address (using the ARP protocol), then delivers the packet from IP last hop to the end host using the layer-2 or MAC address. Finally, the physical layer deals with transmitting the actual bits over a physical medium like a copper wire, optical fiber, or wireless radio. We won't deal much with physical layer in this course. * Layer 2: Link layer. Local area network (LAN). The link can be point-to-point link connecting two computers, or a shared broadcast medium like Ethernet/WiFi. In a shared broadcast medium, multiple computers try to transmit using the same channel, and try not to transmit at the same time and step on each other. Such broadcast LANs do not scale beyond a certain number of machines due to "collisions". So multiple such broadcast domains can be connected via "bridges". Bridges connect multiple shared broadcast media into one large boradcast medium by forwarding packets between them. However, instead of blindly flooding every packet to all hosts, these learning bridges intelligently learn which hosts reside on which broadcast medium and forward appropriately. These days, Ethernet is moving away from shared broadcast medium to switched Ethernet due to scalability requirements. Switches do not flood but learn which MAC addresses are connected to which port. * Note that several link layer technologies can be connected together via IP. A host connected to an Ethernet network can communicate with another host connected to a wireless network, as long as they both speak IP and are connected by a path of IP routers. That is, the links between any two IP hops can be very different. Thus the Internet has grown as a network of networks due to the unifying IP protocol. * Finally, put it all together from bottom to top. A figure showing links, switches, routers, the wide-area internet, all coming together to connect two end hosts running a transport protocol, and application on top of it. * Some other concepts: circuit-swtching vs packet switching. These are two fundamantal ways of transporting data through a network. Circuit switching - to set up a data flow, reserve resources along all links of the path. It is like you have a circuit from one end point to the other, through which you can push data. The links along the path are shared by time/frequency division multiplexing (TDM/FDM). With TDM for example, you have a timeslot reserved for every established flow on all links. Telephone networks work this way. Lower delay and jitter, but may potentially waste resources (e.g., when voice call is idle). Packet switching is different. You put your data in a "packet" and forward it on the first link. The node at the end of that link receives the packet and forwards it along as soon as it can. Thus the intermediate nodes are called "store-and-forward" nodes. * The links are shared not by TDM like methods, but by "statistical multiplexing". That is, all packets that arrive at a node go on the outgoing link in a first-come-first-serve or some other order. Intermediate nodes have buffers to store packets till they are forwarded. Packets may incur a queueing delay if there are many packets arriving at a node and waiting to be forwarded. Some packets may also be dropped if the buffer at an intermediate node overflows. Thus you cannot provide any guaranteed Quality of service (QoS), it is only "best effort". Packet switched networks incur longer delays and jitter, but lead to better utilization of resources. The concept of packet swtching started in the 1960s. The Inernet is packet switched. Recently, cellular data networks (4G etc) are also moving towards packet switching with better scheduling to provide QoS. * Problem: statistical multiplexing vs TDMA. Consider a link of rate 1 Mbps. Users generating data at 100 kbps when busy, but are busy with probability 0.1. With TDMA, we can support only 10 users, and 90% of slots are wasted. If M users in total, probability that N users are active = choose(M,N) * p^N * (1-p)^{M-N}. So, for 35 users, prob that 11 or more active is 0.0004. So most of the time it is okay as 10 or fewer users are active. When more than 10 users active, queueing takes place, and queue drains when fewer than 10 users are active. Statistical mux can support 3 times as many users. Also, leads to better utilization of the link. * Note the notion of a packet: the unit at which you transmit information. If you have a big application message, you split it into smaller packets, put a header on each one, and send each one independently through the packet switched network. Headers are not so important for circuit switching because a circuit and timeslot schedule is established. Headers are a must for packet switching. How big should a packet be? Small packets - relatively greater overhead due to repeating header information in every packet, so larger packets are better this way. But with large packets, there is a long delay for the packet to traverse every hop. With smaller packets, the first packet can do down the second link while the first packet arrives. Also, even if one bit is corrupted, the full packet must be retransmitted (at link layer or transport layer). So choosing optimum packet size is a fine balancing act. * History of networking: telephone networks existed for a long time. Packet switching concepts and theory developed in the 1960s. Several proprietary packet switched networks in the 1970s beginning with ARPANET. The need came to up to integrate these networks using a top-level store-and-forward gateways. The primitive TCP/IP protocols came into place around this time, but TCP and IP laters were integrated. What lead to the split into layers we see now? - One of the main goals of the internet - survivability, fault tolerance. The intermediate gateways have a lot of state. How should this state be preserved across failures? It was decided that the core would store soft state (periodically refreshed, nothing permanent, okay to lose state once in a while), and would only forward datagrams, in a connection-less manner. The end hosts would maintain any connection state needed. This results in "fate sharing", that is, a host would lose state if it also went down. So one host going down will only impact its own state. - People also realized that TCP provides only one type of transport, and people may want to use different transport protocols for different types of applications. For example, not all applications will want the reliability provided by TCP. So, TCP and IP were split. UDP was provided as another alternative simpler transport. - Finally, we have IP that runs on any network that can deliver a datagram from one IP address to another. No assumptions made on the underlying network (in order, reliable etc). TCP and other transport run on top of IP and customize the transport protocol to the application needs. - The split of TCP and IP is also referred to as the end-to-end argument. All application and transport "intelligence" (reliability, security etc) should reside at the end hosts. The core of the network should be kept "dumb", with only the job of delivering datagrams as well as it can. It may be possible to spend a lot of energy in engineering the network core to do some of the jobs of the application layer (e.g., provide reliability guarantees), but it was decided that the effort to realize it in the core was too high to be worth it, and the end points would be doing it anyways. End-to-end checks, retries, recovery etc makes more sense. The tradeoff of where to place a certain functionality - end hosts or network - is a common debate in several aspects of networking. * Continuing the story, late 1980s saw a refining of the TCP congestion control algorithms. The internet grew. US government let go of the backbone routers and decided to commercialize it. So ISPs came up in 1990s. Late 1990s, early 2000s - dotcom bubble, explosion of usage and applications, driven by web and email. 2000s saw stabilization, growth of cellular/mobile data and convergence with the Internet. * Demo: show wireshark trace of a browsing session * Further reading: - "The design philosophy of the DARPA internet protocols", David Clark. For more history and reasoning behind the internet architecture, read this classic paper.