TCP Basics

1. TCP Basics Alan L. Cox alc@cs.rice.edu T. S. Eugene Ng eugeneng@cs.rice.edu Some slides adapted from COMP429 (credits go to Alan L. Cox, Edward W. Knightly, T. S. Eugene Ng, Ion Stoica, Hui Zhang)

2. Objectives • To give you a rough overview of what’s going on behind stream socket communications • How is reliable communication achieved? • How is congestion control achieved? • This material is not going to be on final exam! So just enjoy it! • BTW, Alan & Eugene are looking for undergraduate research assistants to work on interesting projects. Contact them if you are interested! TCP Basics

3. Reliability • Goal: transmit correct information • Problem: packets can get corrupted and/or lost • Electrical interference, congestion • Solution • Detect error • Retransmit TCP Basics

4. Simple Error Detection: Checksum • Sender: add all words of a packet and append the result (checksum) to the packet • Receiver: add all words of a received packet and compare the result with the checksum • Example: Internet checksum • Use 1’s complement addition TCP Basics

5. -15+16 = 1 00000000 1 + 1 00000001 1’s Complement • Negative number –x is x with all bits inverted • When two numbers are added, the carry-on is added to the result • Example: -15 + 16; assume 8-bit representation 15 = 00001111  -15 = 11110000 + 16 = 00010000 TCP Basics

6. Internet Checksum Implementation u_short cksum(u_short *buf, int count) { register u_long sum = 0; while (count--) { sum += *buf++; if (sum & 0xFFFF0000) { /* carry occurred, so wrap around */ sum &= 0xFFFF; sum++; } } return ~(sum & 0xFFFF); } TCP Basics

7. Properties • How many bits of error can Internet checksum detect? • What’s the overhead? • Why use this algorithm? • Link layer typically has stronger error detection • Most Internet protocol processing in the early days (70’s 80’s) was done in software with slow CPUs, argued for a simple algorithm • Seems to be OK in practice • In reality, many other stronger error detection mechanisms are simultaneously used TCP Basics

8. Retransmission • Problem: obtain correct information once errors are detected • Retransmission is one popular approach • Algorithmic challenges • Achieve high link utilization, and low overhead TCP Basics

9. Stop & Wait • Send; wait for acknowledgement (ACK); repeat • If timeout, retransmit TRANS DATA Receiver Sender RTT Inefficient if TRANS << RTT Round-Trip-Time ACK Time TCP Basics

10. Stop & Wait TRANS DATA Receiver Sender ACK Timeout Lost Time TCP Basics

11. Is a Sequence Number Needed? • Need a 1 bit sequence number (i.e. alternate between 0 and 1) to distinguish duplicate frames Frame Frame timeout ACK ACK Frame Frame ACK ACK TCP Basics

12. Problem with Stop-and-Go • Lots of time wasted in waiting for acknowledgements • What if you have a 10Gbps link and a delay of 10ms? • Need 100Mbit to fill the pipe with data • If packet size is 1500B (like Ethernet), because you can only send one packet per RTT • Throughput = 1500*8bit/(2*10ms) = 600Kbps! • A utilization of 0.006% TCP Basics

13. Sliding Window • window = set of adjacent sequence numbers • The size of the set is the window size (WS) • Denote it n • Let A be the last ack’d packet of sender without gap; then window of sender = {A+1, A+2, …, A+n} • Sender can send packets in its window without wait • Let B be the last received packet without gap by receiver, then window of receiver = {B+1,…, B+n} • Receiver can accept out of sequence packets, if in window A … … TCP Basics

14. Example WS = 9 Time TCP Basics

15. Basic Timeout and Acknowledgement • Every packet k transmitted is associated with a timeout • Basic acknowledgement scheme • Receiver sends ack for packet k+1 when all packets with sequence numbers <= k have been received • An ack k+1 means every packet up to k has been received • Suppose packets B, C, D have been received, but receiver is still waiting for A. Ack for A sent when receiving B,C,D. But as soon as A arrives, an ack for D+1 is sent by the receiver, and the receiver window slides • If by timeout(k), ack for k+1 has not yet been received, the sender retransmits k A B C D … … TCP Basics

16. Example with Errors Window size = 3 packets 1 2 3 4 5 6 Timeout Packet 5 7 5 Time Sender Receiver TCP Basics

17. Efficiency WS = 9, i.e. 9 packets in one RTT Can be fully efficient as long as WS is large enough RTT Time TCP Basics

18. Observations • With sliding windows, it is possible to fully utilize a link, provided the window size is large enough. Throughput is proportional to (WS/RTT) • Stop & Wait is like WS = 1. • Sender has to buffer all unacknowledged packets, because they may require retransmission • Receiver may accept out-of-order packets, but only if they fall within window TCP Basics

19. Setting Timers • The sender needs to set retransmission timers in order to know when to retransmit a packet that may have been lost • How long to set the timer for? • Too short: may retransmit before data or ACK has arrived, creating duplicates • Too long: if a packet is lost, will take a long time to recover (inefficient) TCP Basics

20. Timing Illustration 1 1 Timeout RTT RTT 1 Timeout 1 Timeout too long  inefficiency Timeout too short  duplicate packets TCP Basics

21. Adaptive Timers • The amount of time the sender should wait is about the round-trip time (RTT) between the sender and receiver • For multi-hop WAN, RTT not known a priori nor static • So protocol should measure and adapt to the path behavior TCP Basics

22. Three Congestion Control Problems • Sliding windows protocol’s throughput proportional to (WS/RTT) • TCP can’t change the RTT • How large should WS be? • Adjusting to bottleneck bandwidth • Adjusting to variations in bandwidth • Sharing bandwidth between flows TCP Basics

23. A B Abstraction • We ignore internal structure of network and model it as having a single bottleneck link Buffer in bottleneck Router Receiving Host Sending Host TCP Basics

24. A B Single Flow, Fixed Bandwidth • Adjust rate to match bottleneck bandwidth • without any a priori knowledge • could be gigabit link, could be a modem 100 Mbps TCP Basics

25. A B Single Flow, Varying Bandwidth • Adjust rate to match instantaneous bandwidth • Bottleneck can change because of a routing change BW(t) TCP Basics

26. A1 B1 100 Mbps A2 B2 A3 B3 Multiple Flows • Two Issues: • Adjust total sending rate to match bottleneck bandwidth • Allocation of bandwidth between flows TCP Basics

27. TCP Congestion Control • Dynamic Adjustment • Every sender probes network to test level of congestion • speeds up when no congestion • slows down when congestion • Distributed coordination problem! TCP Basics

28. TCP Congestion Control • TCP connection has window • controls number of unacknowledged packets • Sending rate proportional to WS/RTT • Vary window size to control sending rate • Congestion control is mainly a sender-side operation TCP Basics

29. Two Basic Components • Detecting congestion • Rate adjustment algorithm (change window size) • depends on congestion or not TCP Basics

30. Detecting Congestion • Packet drop is the most definitive sign of congestion • Delay-based methods are tricky • e.g. How to know delay change not caused by routing change (no congestion)? • How do you detect packet drops? ACKs • TCP uses ACKs to signal receipt of data • A sign of packet drops • No ACK after certain time interval: time-out • May not work well for wireless networks, why? TCP Basics

31. Rate Adjustment • Basic structure: • Upon receipt of ACK (of new data): increase rate • Data successfully delivered, perhaps can send faster • Upon detection of loss: decrease rate • But what increase/decrease functions should we use? • Restrict to linear functions: additive increase/decrease, multiplicative increase/decrease • AIAD • AIMD • MIAD • MIMD TCP Basics

32. equal bandwidth share Fair and link fully utilized (rate R) Fairness? Utilization? R Connection 2 throughput loss: decrease window size no loss: increase window size Connection 1 throughput R TCP Basics

33. C x A B y D E Limit rates: x and y depend on initial values AIAD TCP Basics

34. AIAD Sharing Dynamics x A B y D E • No congestion  x increases by one packet/RTT every RTT • Congestion  decrease x by 1 TCP Basics

35. C x A B y D E Limit rates: x = y AIMD TCP Basics

36. AIMD Sharing Dynamics x A B y D E • No congestion  rate increases by one packet/RTT every RTT • Congestion  decrease rate by factor 2 Rates equalize  fair share TCP Basics

37. TCP Implementation Details • Sliding window protocol • Use byte level sequence numbers • Bi-directional • Each host can be a receiver and a sender simultaneously TCP Basics

38. Sequence Number Space • Each byte in byte stream is numbered. • 32 bit value • Wraps around • Initial values selected at start up time • TCP breaks up the byte stream in packets (“segments”) • Packet size is limited to the Maximum Segment Size • Set to prevent packet fragmentation • Each segment has a sequence number. • Indicates where it fits in the byte stream 13450 14950 16050 17550 segment 8 segment 9 segment 10 TCP Basics

39. Connection Setup • Why need connection setup? • Mainly to agree on starting sequence numbers • Starting sequence number is randomly chosen • Reason, to reduce the chance that sequence numbers of old and new connections from overlapping TCP Basics

40. Important TCP Flags • SYN: Synchronize • Used when setting up connection • FIN: Finish • Used when tearing down connection • ACK • Acknowledging received data TCP Basics

41. Establishing Connection SYN: SeqC • Three-Way Handshake • Each side notifies other of starting sequence number it will use for sending • Each side acknowledges other’s sequence number • SYN-ACK: Acknowledge sequence number + 1 • Can combine second SYN with first ACK Client Server ACK: SeqC+1 SYN: SeqS ACK: SeqS+1 TCP Basics

42. Tearing Down Connection A B • Either Side Can Initiate Tear Down • Send FIN signal • “I’m not going to send any more data” • Other Side Can Continue Sending Data • Half open connection • Must continue to acknowledge • Acknowledging FIN • Acknowledge last sequence number + 1 FIN, SeqA ACK, SeqA+1 Data ACK FIN, SeqB ACK, SeqB+1 TCP Basics

43. That’s it for this semester • A popular comment past students made in course evaluation: “I learned C in COMP221.” • Is it just “C” that you learned? Think about it! • Apply what you’ve learned! • Hope to see you in future classes! TCP Basics