CSCI -1680 Layering and Encapsulation

  • View

  • Download

Embed Size (px)


CSCI -1680 Layering and Encapsulation. Rodrigo Fonseca. Based partly on lecture notes by David Mazires , Phil Levis, John Jannotti. Administrivia. Sign and hand in Collaboration Policy Signup for Snowcast milestone Thursday from 8pm to 11pm See Piazza for links Github. Today. Review - PowerPoint PPT Presentation


CSCI-1680 :: Computer Networks

CSCI-1680Layering and EncapsulationBased partly on lecture notes by David Mazires, Phil Levis, John JannottiRodrigo FonsecaAdministriviaSign and hand in Collaboration PolicySignup for Snowcast milestoneThursday from 8pm to 11pmSee Piazza for linksGithubTodayReviewSwitching, Multiplexing

Layering and EncapsulationIntro to IP, TCP, UDPPerformance MetricsA Taxonomy of networksCommunication NetworkSwitchedCommunication NetworkBroadcastCommunication NetworkCircuit-SwitchedCommunication NetworkPacket-SwitchedCommunication NetworkDatagram NetworkVirtual Circuit NetworkA hybrid of circuits and packets; headers include a circuit identifier established during a setup phasePoint-to-point networkCircuit SwitchingGuaranteed allocationTime division / Frequency division multiplexingLow space overheadEasy to reason about

Failures: must re-establish connectionFor any failures along pathOverload: all or nothingNo graceful degradationWaste: allocate for peak, waste for less than peakSet up time

Packet SwitchingBreak information in small chunks: packetsEach packet forwarded independentlyMust add metadata to each packetAllows statistical multiplexingHigh utilizationVery flexibleFairness not automaticHighly variable queueing delaysDifferent paths for each packet

Traceroute map of the Internet, ~5 million edges, circa 2003. opte.orgManaging ComplexityVery large number of computersIncredible variety of technologiesEach with very different constraintsNo single administrative entityEvolving demands, protocols, applicationsEach with very different requirements!

How do we make sense of all this?

LayeringSeparation of concernsBreak problem into separate partsSolve each one independentlyTie together through common interfaces: abstractionEncapsulate data from the layer above inside data from the layer belowAllow independent evolution

LayersApplication what the users sees, e.g., HTTPPresentation crypto, conversion between representationsSession can tie together multiple streams (e.g., audio & video)Transport demultiplexes, provides reliability, flow and congestion controlNetwork sends packets, using routingData Link sends frames, handles media accessPhysical sends individual bits10OSI Reference Model

Application ProtocolTransport ProtocolNetwork ProtocolLink-Layer ProtocolOpen Systems Interconnect, ISO11Layers, Services, ProtocolsLayer NProtocol: rules for communicationwithin same layer Layer N-1Layer N+1Service: abstraction provided to layer aboveAPI: concrete way of using the serviceLayer N uses the services provided by N-1 toimplement its protocol and provide its own servicesLayers, Services, ProtocolsNetworkLinkPhysicalTransportApplicationService: move bits to other node across link Service: move frames to other node across link.May add reliability, medium access controlService: move packets to any other node in the networkIP: Unreliable, best-effort service modelService: multiplexing applicationsReliable byte stream to other node (TCP), Unreliable datagram (UDP)Service: user-facing application.Application-defined messagesProtocolsWhat do you need to communicate?Definition of message formatsDefinition of the semantics of messagesDefinition of valid sequences of messagesIncluding valid timingsAlso, who do you talk to? AddressingEach node typically has a unique* nameWhen that name also tells you how to get to the node, it is called an addressEach layer can have its own naming/addressingRouting is the process of finding a path to the destinationIn packet switched networks, each packet must have a destination addressFor circuit switched, use address to set up circuitSpecial addresses can exist for broadcast/multicast/anycast* within the relevant scopeChallengeDecide on how to factor the problemWhat services at which layer?What to leave out?More on this later (End-to-end principle)For example: IP offers pretty crappy service, even on top of reliable links why?TCP: offers reliable, in-order, no-duplicates service. Why would you want UDP?

Guiding principle: if you offer functionality in one layer, you force everyone above you to use it, even if they dont need it.16IP as the Narrow WaistMany applications protocols on top of UDP & TCPIP works over many types of networksThis is the Hourglass architecture of the Internet. If every network supports IP, applications run over many different networks (e.g., cellular network)

Network Layer: Internet Protocol (IP)Used by most computer networks todayRuns over a variety of physical networks, can connect Ethernet, wireless, modem lines, etc.Every host has a unique 4-byte IP address (IPv4)E.g., network knows how to route a packet to any addressNeed more to build something like the WebNeed naming (DNS)Interface for browser and server software (next lecture)Need demultiplexing within a host: which packets are for web browser, Skype, or the mail program?Inter-process CommunicationTalking from host to host is great, but we want abstraction of inter-process communicationSolution: encapsulate another protocol within IP

Transport: UDP and TCPUDP and TCP most popular protocols on IPBoth use 16-bit port number & 32-bit IP addressApplications bind a port & receive traffic on that portUDP User (unreliable) Datagram ProtocolExposes packet-switched nature of InternetSent packets may be dropped, reordered, even duplicated (but there is corruption protection)TCP Transmission Control ProtocolProvides illusion of reliable pipe or stream between two processes anywhere on the networkHandles congestion and flow controlUses of TCPMost applications use TCPEasier to program (reliability is convenient)Automatically avoids congestion (dont need to worry about taking down the networkServers typically listen on well-know ports:SSH: 22SMTP (email): 25Finger: 79HTTP (web): 80Transport: UDP and TCPUDP and TCP most popular protocols on IPBoth use 16-bit port number & 32-bit IP addressApplications bind a port & receive traffic on that portUDP User (unreliable) Datagram ProtocolExposes packet-switched nature of InternetSent packets may be dropped, reordered, even duplicated (but there is corruption protection)TCP Transmission Control ProtocolProvides illusion of reliable pipe or stream between two processes anywhere on the networkHandles congestion and flow controlInternet LayeringStrict layering not requiredTCP/UDP cheat to detect certain errors in IP-level information like addressOverall, allows evolution, experimentation

We didnt cover these in class, but these concepts about the socket API are useful for, and exercised by, the Snowcast assignment!Using TCP/IPHow can applications use the network?Sockets API. Originally from BSD, widely implemented (*BSD, Linux, Mac OS X, Windows, )Important do know and do onceHigher-level APIs build on themAfter basic setup, much like filesSockets: Communication Between MachinesNetwork sockets are file descriptors tooDatagram sockets: unreliable message deliveryWith IP, gives you UDPSend atomic messages, which may be reordered or lostSpecial system calls to read/write: send/recvStream sockets: bi-directional pipesWith IP, gives you TCPBytes written on one end read on anotherReads may not return full amount requested, must re-readSystem calls for using TCPClientServer socket make socketbind assign address, portlisten listen for clientssocket make socketbind* assign addressconnect connect to listening socketaccept accept connection

This call to bind is optional, connect can choose address & port. Socket NamingRecall how TCP & UDP name communication endpointsIP address specifies host ( port number demultiplexes within hostWell-known services listen on standard ports (e.g. ssh 22, http 80, mail 25, see /etc/services for list)Clients connect from arbitrary ports to well known portsA connection is named by 5 componentsProtocol, local IP, local port, remote IP, remote portTCP requires connected sockets, but not UDPDealing with Address TypesAll values in network byte order (Big Endian)htonl(), htons(): host to network, 32 and 16 bitsntohl(), ntohs(): network to host, 32 and 16 bitsRemember to always convert!All address types begin with familysa_family in sockaddr tells you actual typeNot all addresses are the same sizee.g., struct sockaddr_in6 is typically 28 bytes, yet generic struct sockaddr is only 16 bytesSo most calls require passing around socket lengthNew sockaddr_storage is big enoughClient Skeleton (IPv4)

Server Skeleton (IPv4)

Using UDPCall socket with SOCK_DGRAM, bind as beforeNew calls for sending/receiving individual packetssendto(int s, const void *msg, int len, int flags, const struct sockaddr *to, socklen t tolen);recvfrom(int s, void *buf, int len, int flags, struct sockaddr *from, socklen t *fromlen);Must send/get peer address with each packetExample: udpecho.cCan use UDP in connected mode (Why?)connect assigns remote addresssend/recv syscalls, like sendto/recvfrom w/o last two argumentsUses of UDP Connected SocketsKernel demultiplexes packets based on portCan have different processes getting UDP packets from different peersFeedback based on ICMP messages (future lecture)Say no process has bound UDP port you sent packet toServer sends port unreachable message, but you will only receive it when using connected socketServing Multiple ClientsA server may block when talking to a clientRead or write of a socket connected to a slow client can blockServer may be busy with CPUServer might be blocked waiting for disk I/OConcurrency through multiple processesAccept, fork, close in parent; child services requestAdvantages of one process per clientDont block on slow clientsMay use multiple coresCan keep disk queues full for disk-heavy workloadsThreadsOne process per client has disadvantages:High overhead fork + exit ~100secHard to sh