Internet and Intranet Protocols and Applications Lecture 2: The Transport Layer in the Internet January 18, 2005 Arthur Goldberg Computer Science Department New York University artg@cs.nyu.edu 9/19/2018

Internet Transport Protocols Two Transport Protocols Available Transmission Control Protocol (TCP) connection oriented most applications use TCP User Datagram Protocol (UDP) connectionless 9/19/2018

Transport layer addressing Communications endpoint addressed by: IP address (32 bit) in IP Header Port number (16 bit) in TP Header1 Transport protocol (TCP or UDP) in IP Header 1 TP => Transport Protocol (UDP or TCP) 9/19/2018

Some standard services and port numbers (last updated 2004-01-16) http://www.iana.org/assignments/port-numbers 9/19/2018

UDP: 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 the application connectionless: no handshaking between UDP sender, receiver each UDP segment handled independently of others Why 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 desired 9/19/2018

UDP Port Management Source (client) Destination Obtains a free port number Specifies port of destination (server) Destination Receives datagram Sends datagram to destination IP:port Can send replies to source IP:port 9/19/2018

UDP: more often used for streaming multimedia apps loss tolerant rate sensitive other UDP uses (why?): DNS SNMP reliable transfer over UDP: add reliability at application layer application-specific error recover! 32 bits source port # dest port # Length, in bytes of UDP segment, including header length checksum Application data (message) UDP segment format 9/19/2018

UDP checksum Goal: detect “errors” (e.g., flipped bits) in transmitted segment Sender: 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 field Receiver: compute checksum of received segment check if computed checksum equals checksum field value: NO - error detected YES - no error detected. But may be errors nonetheless? More later …. 9/19/2018

Transmission Control Protocol (TCP) Connection-oriented service Point-to-point Full-duplex communication Stream interface (no message boundary!) Stream divided into segments for transmission Each segment encapsulated in IP datagram Uses protocol ports to identify applications 9/19/2018

TCP Port Management When a connection is established Source (client) Obtains a free port number Specifies IP:port of destination (server) Destination Receives connection request Sends data to destination IP:port The 4-tuple (source IP:port, destination IP:port) identifies where data goes 9/19/2018

TCP Segment Sequence number specifies where in stream data belongs Few segments contain options TF 6-24 9/19/2018

TCP Segment Format Segment divided into two parts Header Payload area (zero or more bytes of data) Header contains Protocol port numbers to identify Sending application Receiving application Bits to specify items such as SYN FIN ACK Fields for window advertisement, acknowledgment, etc. 9/19/2018

Reliability in an Unreliable World IP offers best-effort (unreliable) delivery TCP uses IP TCP provides completely reliable transfer How is this possible? How can TCP realize: Reliable connection startup? Reliable data transmission? Graceful connection shutdown? 9/19/2018

Reliable Data Transmission Positive acknowledgment Receiver returns short message when data arrives Called acknowledgment Retransmission Sender starts timer whenever message is transmitted If timer expires before acknowledgment arrives, sender retransmits message 9/19/2018

simple telnet scenario TCP seq. #’s and ACKs Seq. #’s: byte stream “number” of first byte in segment’s data ACKs: seq # of next byte expected from other side cumulative ACK Q: how receiver handles out-of-order segments A: TCP spec doesn’t say, - up to implementer Host A Host B User types ‘C’ Seq=42, ACK=79, data = ‘C’ host ACKs receipt of ‘C’, echoes back ‘C’ Seq=79, ACK=43, data = ‘C’ host ACKs receipt of echoed ‘C’ Seq=43, ACK=80 time simple telnet scenario 9/19/2018

Timing Problem! The delay required for data to reach a destination and an acknowledgment to return depends on traffic in the internet as well as the distance to the destination. Because it allows multiple application programs to communicate with multiple destinations concurrently, TCP must handle a variety of delays that can change rapidly. How does TCP handle this ..... 9/19/2018

Solving Timing Problem Keep estimate of round trip time on each connection Use current estimate to set retransmission timer Known as adaptive retransmission Key to TCP’s success 9/19/2018

TCP Flow Control Receiver Sender Advertises available buffer space Called window Sender Can send up to entire window before ACK arrives Each acknowledgment carries new window information Called window advertisement Can be zero (called closed window) Interpretation: I have received up through X, and can take Y more octets 9/19/2018

TCP Flow Control flow control receiver: explicitly informs sender of (dynamically changing) amount of free buffer space RcvWindow field in TCP segment sender: keeps the amount of transmitted, unACKed data less than most recently received RcvWindow sender won’t overrun receiver’s buffers by transmitting too much, too fast RcvBuffer = size or TCP Receive Buffer RcvWindow = amount of spare room in Buffer receiver buffering 9/19/2018

Why Startup/ Shutdown Difficult? Segments can be Lost Duplicated Delayed Delivered out of order Either side can crash Either side can reboot Need to avoid duplicate ‘‘shutdown’’ message from affecting later connection 9/19/2018

TCP’s Startup/ Shutdown Solution Uses three-message exchange known as 3-way handshake Necessary and sufficient for Unambiguous, reliable startup Unambiguous, graceful shutdown SYN used for startup, FIN used for shutdown 9/19/2018

TCP Connection Management (OPEN) client server opening SYN opening SYNACK ACK established closed 9/19/2018

TCP Connection Management (CLOSE) client server closing FIN ACK closing FIN ACK timed wait closed closed 9/19/2018

TCP Connection Management (cont) TCP server lifecycle TCP client lifecycle 9/19/2018

Transport Protocol Summary Transport protocols fit between applications and Internet Protocol Two transport protocols in TCP/IP suite User Datagram Protocol (UDP) Transmission Control Protocol (TCP) UDP Unreliable Message-oriented interface TCP Major transport protocol used in Internet Complete reliability Stream-oriented interface Uses adaptive retransmission 9/19/2018

Extra slides follow

Principles of Congestion Control informally: “too many sources sending too much data too fast for network to handle” different from flow control! manifestations: lost packets (buffer overflow at routers) long delays (queueing in router buffers) a top-10 problem! 9/19/2018

Approaches towards congestion control Two broad approaches towards congestion control: End-end congestion control: no explicit feedback from network congestion inferred from end-system observed loss, delay approach taken by TCP Network-assisted congestion control: routers provide feedback to end systems single bit indicating congestion (SNA, DECbit, TCP/IP ECN, ATM) explicit rate sender should send at 9/19/2018

TCP Congestion Control end-end control (no network assistance) transmission rate limited by congestion window size, Congwin, over segments: Congwin w segments, each with MSS bytes sent in one RTT: throughput = w * MSS RTT Bytes/sec 9/19/2018

TCP congestion control: “probing” for usable bandwidth: ideally: transmit as fast as possible (Congwin as large as possible) without loss increase Congwin until loss (congestion) loss: decrease Congwin, then begin probing (increasing) again two “phases” slow start congestion avoidance important variables: Congwin threshold: defines threshold between two slow start phase, congestion control phase 9/19/2018

TCP Slowstart Slowstart algorithm initialize: Congwin = 1 Host A Slowstart algorithm Host B one segment initialize: Congwin = 1 for (each segment ACKed) Congwin++ until (loss event OR CongWin > threshold) RTT two segments four segments exponential increase (per RTT) in window size (not so slow!) loss event: timeout (Tahoe TCP) and/or or three duplicate ACKs (Reno TCP) time 9/19/2018

TCP Congestion Avoidance /* slowstart is over */ /* Congwin > threshold */ Until (loss event) { every w segments ACKed: Congwin++ } threshold = Congwin/2 Congwin = 1 perform slowstart 1 1: TCP Reno skips slowstart (fast recovery) after three duplicate ACKs 9/19/2018

TCP Fairness Fairness goal: if N TCP sessions share same bottleneck link, each should get 1/N of link capacity TCP connection 1 bottleneck router capacity R TCP connection 2 9/19/2018

Why is TCP fair? Two competing sessions: Additive increase gives slope of 1, as throughout increases multiplicative decrease decreases throughput proportionally R equal bandwidth share loss: decrease window by factor of 2 congestion avoidance: additive increase Connection 2 throughput loss: decrease window by factor of 2 congestion avoidance: additive increase Connection 1 throughput R 9/19/2018

More on Reliable Data Transfer 9/19/2018