Review of Previous LectureAnnouncementChapter 3: Transport LayerOutlineTransport services and protocolsTransport vs. network layerInternet transport-layer protocolsSlide 8Multiplexing/demultiplexingHow demultiplexing worksConnectionless demultiplexingConnectionless demux (cont)Connection-oriented demuxConnection-oriented demux (cont)Connection-oriented demux: Threaded Web ServerSlide 16UDP: User Datagram Protocol [RFC 768]UDP: moreUDP checksumSlide 20Principles of Reliable data transferSlide 22Slide 23Reliable data transfer: getting startedSlide 25Rdt1.0: reliable transfer over a reliable channelRdt2.0: channel with bit errorsrdt2.0: FSM specificationrdt2.0: operation with no errorsrdt2.0: error scenarioBackup SlidesIP datagram formatSome slides are in courtesy of J. Kurose and K. RossReview of Previous Lecture•Electronic Mail: SMTP, POP3, IMAP•DNS•Socket programming with TCPAnnouncement•Homework 1 and project 1 due Wed. midnight•Submission instruction posted in the newsgroup•Recitation materials onlineChapter 3: Transport LayerOur goals: •understand principles behind transport layer services:–multiplexing/demultiplexing–reliable data transfer–flow control–congestion control•learn about transport layer protocols in the Internet:–UDP: connectionless transport–TCP: connection-oriented transport–TCP congestion controlOutline•Transport-layer services•Multiplexing and demultiplexing•Connectionless transport: UDP•Principles of reliable data transferTransport services and protocols•provide logical communication between app processes running on different hosts•transport protocols run in end systems –send side: breaks app messages into segments, passes to network layer–rcv side: reassembles segments into messages, passes to app layerapplicationtransportnetworkdata linkphysicalapplicationtransportnetworkdata linkphysicalnetworkdata linkphysicalnetworkdata linkphysicalnetworkdata linkphysicalnetworkdata linkphysicalnetworkdata linkphysicallogical end-end transportTransport vs. network layer•network layer: logical communication between hosts•transport layer: logical communication between processes –relies on, enhances, network layer services•On one host, there may be several processes communicating with processes on several other hosts, with different protocolsInternet transport-layer protocols•reliable, in-order delivery (TCP)–congestion control –flow control–connection setup•unreliable, unordered delivery: UDP–no-frills extension of “best-effort” IP•services not available: –delay guarantees–bandwidth guaranteesapplicationtransportnetworkdata linkphysicalapplicationtransportnetworkdata linkphysicalnetworkdata linkphysicalnetworkdata linkphysicalnetworkdata linkphysicalnetworkdata linkphysicalnetworkdata linkphysicallogical end-end transportOutline•Transport-layer services•Multiplexing and demultiplexing•Connectionless transport: UDP•Principles of reliable data transferMultiplexing/demultiplexingapplicationtransportnetworklinkphysicalP1applicationtransportnetworklinkphysicalapplicationtransportnetworklinkphysicalP2P3P4P1host 1host 2host 3= process= socketdelivering received segmentsto correct socketDemultiplexing at rcv host:gathering data from multiplesockets, enveloping data with header (later used for demultiplexing)Multiplexing at send host:How demultiplexing works•Host receives IP datagrams–each datagram has source IP address, destination IP address–each datagram carries 1 transport-layer segment–each segment has source, destination port number (recall: well-known port numbers for specific applications)•Host uses IP addresses & port numbers to direct segment to appropriate socketsource port # dest port #32 bitsapplicationdata (message)other header fieldsTCP/UDP segment formatConnectionless demultiplexing•UDP socket identified by two-tuple:(dest IP address, dest port number)•When host receives UDP segment:–checks destination port number in segment–directs UDP segment to socket with that port number•IP datagrams with different source IP addresses and/or source port numbers directed to same socketConnectionless demux (cont)ClientIP:BP2client IP: AP1P1P3serverIP: CSP: 6428DP: 9157SP: 9157DP: 6428SP: 6428DP: 5775SP: 5775DP: 6428SP provides “return address”Connection-oriented demux•TCP socket identified by 4-tuple: –source IP address–source port number–dest IP address–dest port number•recv host uses all four values to direct segment to appropriate socket•Server host may support many simultaneous TCP sockets:–each socket identified by its own 4-tuple•Web servers have different sockets for each connecting client–non-persistent HTTP will have different socket for each requestConnection-oriented demux (cont)ClientIP:BP1client IP: AP1P2P4serverIP: CSP: 9157DP: 80SP: 9157DP: 80P5P6P3D-IP:CS-IP: AD-IP:CS-IP: BSP: 5775DP: 80D-IP:CS-IP: BConnection-oriented demux: Threaded Web ServerClientIP:BP1client IP: AP1P2serverIP: CSP: 9157DP: 80SP: 9157DP: 80P4P3D-IP:CS-IP: AD-IP:CS-IP: BSP: 5775DP: 80D-IP:CS-IP: BOutline•Transport-layer services•Multiplexing and demultiplexing•Connectionless transport: UDP•Principles of reliable data transferUDP: User Datagram Protocol [RFC 768]•“no frills,” “bare bones” Internet transport protocol•“best effort” service, UDP segments may be:–lost–delivered out of order to app•connectionless:–no handshaking between UDP sender, receiver–each UDP segment handled independently of othersWhy is there a UDP?•no connection establishment (which can add delay)•simple: no connection state at sender, receiver•small segment header•no congestion control: UDP can blast away as fast as desiredUDP: more•often used for streaming multimedia apps–loss tolerant–rate sensitive•reliable transfer over UDP: add reliability at application layer–application-specific error recovery!source port # dest port #32 bitsApplicationdata (message)UDP segment formatlengthchecksumLength, inbytes of UDPsegment,includingheaderUDP checksumSender:•treat segment contents as sequence of 16-bit integers•checksum: addition (1’s complement sum) of segment contents•sender puts checksum value into UDP checksum fieldReceiver:•addition of all segment contents + checksum•check if all bits are 1:–NO - error detected–YES - no error detected. But maybe errors nonetheless? More later ….Goal: detect “errors” (e.g., flipped bits) in