CMPE 252A: Computer Networks

CMPE 252A: Computer Networks Set 13: End-to-End Transmission Control (TCP and UDP)

Transport Protocols • Services: • Addressing of processes • Reliable or unreliable transport from source process to end process(es) • Multiplexing and demultiplexing • Flow control • Avoid overflowing receiver’s buffer • Congestion control • Avoid overflowing the network bottleneck • Examples: UDP and TCP

Why Multiplexing • IP delivers packets from source host to destination host. • However, multiple processes run in the hosts! • Applications require communication among processes, not just host computers. • Example: Multiple telnet sessions, email, ftp sessions, and www can all be running concurrently in the same host. • Ports are defined as the addresses of processes inside a host. • How do we identify processes uniquely and efficiently?

Host A Host B Client Server Source port = 23 Source port = x Dst. port = 23 Dst. port = x Segment Well-Known Applications • Well-known ports under 1024, such as • FTP - port # 21 • Telnet - port # 23 • HTTP - port # 80

Transport Protocols • Transport protocols used today are point to point • UDP used for: • Remote file server (NFS), name translation (DNS), intra-domain routing (RIP), network management (SNMP), multimedia applications. • TCP used for: • Electronic mail (SMTP), file transfer (FTP), remote login (Telnet), web (HTTP) • No standard multipoint e-t-e protocol yet!

“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 others UDP: User Datagram Protocol [RFC 768] • Why is there a UDP? • No connection establishment (which can add delay) • Simple: no connection state at sender, receiver • Small header • No congestion control: UDP can blast away as fast as desired

Header specifies the minimum needed for multiplexing and framing. Source and destination ports: identify the end points. Often used for streaming multimedia apps Loss tolerant Rate sensitive Other UDP uses: DNS Reliable transfer over UDP Must be at application layer Application-specific error recovery UDP 32 bits Source port # Dest port # Checksum Length Length, in bytes of UDP segment, including header Application data (message) UDP segment format Checksum: optional; if not used, set to zero.

UDP Checksum • Computed over a pseudo-header + UDP header+data+padding (to even number of bytes if needed). • Pseudo-header: 0 31 Source IP address Destination IP address 00000000 Protocol Segment length

High-Level TCP Characteristics • Protocol implemented entirely at the ends • Fate sharing (on IP) • Protocol has evolved over time and will continue to do so • Nearly impossible to change the header • Use options to add information to the header • Change processing at endpoints • Backward compatibility is what makes it TCP

Differences From Link Layer • Logical link vs. physical link • Must establish connection • Variable RTT • May vary within a connection • Reordering • How long can packets live implies max segment lifetime • Endpoints need not match link • Buffer space availability • Transmission rate • Must be found

Abstraction: Reliable. Ordered. Point-to-point. Byte-stream. Mechanisms: Window-based flow control. Sequence numbers/ordering, 3-way handshake. Reliability (ACK, retransmission policies). Congestion control. RTT estimation. TCP in a Nutshell

TCP Header Source port Destination port Sequence number Flags: SYN FIN RESET PUSH URG ACK Acknowledgement HdrLen Advertised window Flags 0 Checksum Urgent pointer Options (variable) Data

History of TCP • “The” Internet protocol for reliable end-to-end communication • First key paper: • V. Cerf and R. Kahn, “A Protocol for Packet Network Interconnection,” IEEE Trans. Commun., 1974, pp. 627-641. • Designed per se in the early ‘80s • J. Postel, RFC 793 (also IP and UDP) • Network assumptions: • reliable links • losses due to congestion only! • symmetric network connections • Implicit in order delivery of packets (more than IP can promise!)

Evolution of TCP 1984 Nagel’s algorithm to reduce overhead of small packets; predicts congestion collapse 1975 Three-way handshake Raymond Tomlinson In SIGCOMM 75 1987 Karn’s algorithm to better estimate round-trip time 1990 4.3BSD Reno fast retransmit delayed ACK’s 1983 BSD Unix 4.2 supports TCP/IP 1988 Van Jacobson’s algorithms congestion avoidance and congestion control (most implemented in 4.3BSD Tahoe) 1986 Congestion collapse observed 1974 TCP described by Vint Cerf and Bob Kahn In IEEE Trans Comm 1982 TCP & IP RFC 793 & 791 1990 1975 1980 1985

TCP Through the 1990s 1994 T/TCP (Braden) Transaction TCP 1996 SACK TCP (Floyd et al) Selective Acknowledgement 1996 FACK TCP (Mathis et al) extension to SACK 1996 Hoe NewReno startup and loss recovery 1993 TCP Vegas (Brakmo et al) delay-based congestion avoidance 1994 ECN (Floyd) Explicit Congestion Notification 1994 1993 1996

Services Provided • End-to-end flow control • Reliable byte stream • In-order packet delivery (buffering) • Connection-oriented • Socket <host address, port> • uniquely identify connection

TCP Service Model • TCP connections are full-duplex and point-to-point. • Byte stream (not message stream). • Message boundaries are not preserved e2e. A B C D A B C D 2048 bytes of data delivered to application in single READ Four 512-byte segments sent as separate IP datagrams

TCP Byte Stream • When application passes data to TCP, it may send it immediately or buffer it. • Sometimes application wants to send data immediately. • Example: interactive applications. • Use PUSH flag to force transmission. • URGENT flag. • Also forces TCP to transmit at once.

TCP Header • Important fields: • source port and destination port: identify connection end points • 32 bit SN: identifies byte in segment • 32 bit ACK: identifies next byte expected • 4 bit header length: how many 32-bit words in header • 16-bit window size (max. 64KB) advertised by the receiver (RAW) • checksum: checks header, data and pseudo-header • Flags: SYN, FIN, ACK, URG, PUSH • Options: Way to add more information. • Important: Only one sequence number! • Identifies the segment, but does not identify which retransmission of the segment is being sent!

TCP Header Flags Six TCP flags: • URG: indicates urgent data present; urgent pointer gives byte offset from current sequence number where urgent data are. Generally not used. • ACK: indicates whether segment contains acknowledgment; if 0, acknowledgement number field ignored. • PUSH: indicates PUSHed data so receiver delivers it to application immediately. Generally not used. • RST: used to reset connection, reject invalid segment, or refuse to open connection. • SYN: used to establish connection; connection request, SYN=1, ACK=0. • FIN: used to release connection.

TCP Connection Management TCP Server Lifecycle TCP Client Lifecycle

TCP Transmission • Sender process initiates connection. • Once connection established, TCP can start sending data. • Sender writes bytes to TCP stream. • TCP sender breaks byte stream into segments. • Each byte assigned sequence number. • Segment sent and timer started.

TCP Transmission • If timer expires, retransmit segment. • After retransmitting segment for maximum number of times, assumes connection is dead and closes it. • If user aborts connection, sending TCP flushes its buffers and sends RESET segment. • Receiving TCP decides when to pass received data to upper layer.

Timeout-Based Recovery • Wait at least one RTT before retransmitting • Importance of accurate RTT estimators: • Low RTT  unneeded retransmissions • High RTT  poor throughput • RTT estimator must adapt to change in RTT • But not too fast, or too slow! • Spurious timeouts • “Conservation of packets” principle – more than a window worth of packets in flight

Data received from app: Create segment with seq # Seq # is byte-stream number of first data byte in segment start timer if not already running (think of timer as for oldest unacked segment) expiration interval: TimeOutInterval Timeout expires: Retransmit segment that caused timeout Restart timer Acknowledgments: If acknowledges previously unacked segments update what is known to be acked start timer if there are outstanding segments TCP Sender Events:

TCP ACK Generation[RFC 1122, RFC 2581] TCP Receiver action Delayed ACK. Wait up to 500ms for next segment. If no next segment, send ACK Immediately send single cumulative ACK, ACKing both in-order segments Immediately send duplicate ACK, indicating seq. # of next expected byte Immediate send ACK, provided that segment starts at lower end of gap Event at Receiver Arrival of in-order segment with expected seq #. All data up to expected seq # already ACKed Arrival of in-order segment with expected seq #. One other segment has ACK pending Arrival of out-of-order segment higher-than-expect seq. # . Gap detected Arrival of segment that partially or completely fills gap

Seq. #’s: byte stream “number” of first byte in segment’s data ACKs: seq # of next byte expected from other side cumulative ACK Piggybacking NOTE: TCP spec does not dictate how receiver handles out-of-order segments (store them with modern hardware) time TCP Seq. #’s and ACKs Host A Host B User types ‘U’ Seq=42, ACK=79, data = ‘U’ host ACKs receipt of ‘U’, echoes back ‘U’ Seq=79, ACK=43, data = ‘U’ host ACKs receipt of echoed ‘U’ Seq=43, ACK=80 simple telnet scenario

Flow Control vs. Congestion Control • Congestion control • Global issue: concerns all routers and hosts on path from Source to Destination • make sure every subnet can handle the traffic Router Router 1Mbps 1Mbps 1Mbps Receiver Senders

Server 1Gbps File transfer PC 1Mbps Flow Control vs. Congestion Control • Flow Control • Involves two endpoints • Make sure sender doesn’t transmit faster than receiver can absorb packets

End-to-End Congestion Control • Why do it at the transport layer? • Real fix to congestion is to slow down sender. • Use law of “conservation of packets”. • Keep number of packets in the network constant, just below maximum that bottleneck can take • Don’t inject new packet until old one leaves. • Congestion indicator: packet loss.

TCP Flow Control • TCP is a sliding window protocol • For window size n, can send up to n bytes without receiving an acknowledgement • When the data is acknowledged then the window slides forward • Each packet advertises a window size • Indicates number of bytes the receiver has space for • Original TCP always sent entire window • Congestion control now limits this

Pr Pb receiver sender Ab As Ar Self-Clocking • If we have large actual window, should we send data in one shot? • No, use ACKs to clock sending new data.

TCP Congestion Control Mechanisms • Collection of interrelated mechanisms: • Slow start. • Congestion avoidance. • Accurate retransmission timeout estimation. • Fast retransmit. • Fast recovery.

TCP Flow Control • Transmission Window, a.k.a. congestion window ( cwnd ) • Sliding window • maintained by sender • conservation of packets • Receiver’s window set through socket API • controlled by the receiver • advertised to the sender in field of TCP header ( RAW ) cwnd 1 2 3 4 5 6 7 8 9 10 11 12 ... Sent and ACKed Can’t send Sent, not ACKed Send ASAP

Sender/Receiver Statew/o Buffering at Receiver Sender Receiver Next expected Max acceptable Max ACK received Next seqnum … … … … Sender window Receiver window Sent & Acked Sent Not Acked Received & Acked Acceptable Packet OK to Send Not Usable Not Usable

Window Flow Control: Send Side Packet Received Packet Sent Source Port Dest. Port Source Port Dest. Port Sequence Number Sequence Number Acknowledgment Acknowledgment HL/Flags Window HL/Flags Window D. Checksum Urgent Pointer D. Checksum Urgent Pointer Options… Options... App write acknowledged sent to be sent outside window

TCP Flow Control: Observations • TCP sender not required to transmit data as soon as it comes in form application. • Example: when first 2KB of data come in, sender could wait for more data since window is 4KB. • Receiver not required to send ACKs as soon as possible. • Example: Wait for data so ACK is piggybacked.

Data Flow • Conservation of packets • Inject new packets at the rate ACKs are returned by receiver • New window: cwnd • initially cwnd = 1 segment • Sender’s window = min(cwnd, RAW)

TCP Congestion ControlSlow Start • Due to Van Jacobson (SIGCOMM 88) • Algorithm: • Initialize cwnd = 1 MSS. • If an ACK is received before timeout: cwnd = cwnd + 1 MSS for each acknowledged segment • Algorithm used at the beginning of a connection and after a timeout • Leads to exponential growth in the amount of outstanding data in network • cwnd doubles every RTT epoch (i.e., once last segment in current window is acknowledged) • How do we avoid congesting the network?

Slow Start Example one RTT 0R 1 one pkt time 1R 1 2 3 2R 2 3 4 6 5 7 3R 4 5 6 7 8 10 12 14 9 11 13 15

When Should Slow-Start End?Congestion Avoidance • Want to end slow start when the pipe is full! • When cwnd > ssthresh. • Start with large ssthresh, but then refine it. • Slow start continues until BWDP is exceeded, then: • Routers drop packets -- losses occur • Need to stop exponential increase! • Use congestion avoidance to deal with lost packets! • Slow down the transmission rate • Provide for linear increase of the transmission window • Congestion avoidance implemented together with slow start

Congestion Avoidance • Introduce a new variable, ssthresh • Initialized to 65,535 (max. window) • On packet loss (timeout): • Set ssthresh = cwnd/2 and cwnd = 1 • Re-enter slow start, until cwnd = ssthresh • When cwnd = ssthresh, then • Grow cwndlinearly until it reaches RAW • When ACK is received before timeout then set cwnd = cwnd + 1/cwnd • Hence, cwnd increases by 1 segment every RTT

Putting it together: Slow start and congestion avoidance • The algorithm: • If cwnd < ssthresh • do slow start • Else if cwnd > ssthresh • do congestion avoidance

Problems with CA and SS • Slow start is an attempt to discover the network bandwidth (quickly) • Discovery proceeds by filling network queues in intermediate routers. • Once queues are full, routers drop packets. • Once loss is discovered, it’s too late! • TCP sender reduces window when loss is discovered • Queue level oscillates between full and cwnd/2 • What sort of problems does this introduce?

Tahoe TCP Congestion Control: Under-damped Feedback System! cwnd Very drastic a reaction to congestion! ssthresh ssthresh/2 1 MSS rt times Slow start Congestion avoidance Congestion avoidance Slow start Waiting timeout

Tuning TCP Tahoe’s Congestion Control • Coarse timeouts remained a problem, and Fast retransmit was added with TCP Tahoe. • Timeouts can cause connections to be idle for a long time waiting for timer to expire. • Fast retransmit: may trigger retransmission of dropped packet sooner. • Complements regular timeouts.

Fast Retransmit • When can duplicate ACKs occur? • Loss, packet re-ordering, or sender waits for some number of duplicate ACKs before retransmitting. • Assume packet re-ordering is infrequent. • Use receipt of 3 or more duplicate ACKs as loss indicator • Retransmit that segment before timeout. • Generally, fast retransmit eliminates abouthalf the coarse-grain timeouts. • Conventional wisdom is that this yields roughly a 20% improvement in throughput. • Note – fast retransmit does not eliminate all the timeouts due to small window sizes at the source.

Reno: Fast Recovery • Goal: • Reduce the number of times connection is slow-started. • Use ACKs in the pipe for self-clocking. • In congestion avoidance mode, after fast retransmit, reduce cwnd to half (rather than dropping it to 1). • Reno vs Tahoe: Slow start only used in the beginning of connection or when timeout occurs.

Reno: Tahoe with Fast Retransmit and Recovery • If 3 duplicate ACKs for segment N received: • Retransmit segment N. • Set ssthresh = 0.5*cwnd. • Set cwnd = ssthresh + 3*MSS. [account for 3 duplicate ACKs] • For every subsequent duplicate ACK: • Increase cwnd by 1 segment. • When “new” ACK received to retransmitted packet: • Reset cwnd = ssthresh • Resume congestion avoidance. • Result: cwnd is reset to half of the old cwnd after fast recovery

Delayed ACKs • Tries to optimize ACK transmission. • Delay ACKs (500msec) hoping to piggyback on data segment. • Example: telnet to interactive editor: • Send 1 character at a time: 20-byte TCP header+ 1-byte data+20-byte IP header. • Receiver ACKs immediately: 40-byte ACK. • When editor reads character, window update: 40-byte datagram. • Then echoes character back: 41-byte datagram.

CMPE 252A: Computer Networks