Transport Layer – Multiplexing and Reliability

1. Transport Layer – Multiplexing and Reliability UIUC CS438: Communication Networks Summer 2014 Fred Douglas Slides: Fred, Kurose&Ross(sometimes edited), Caesar&many others (also edited)

2. 3.1 transport-layer services 3.2 multiplexing and demultiplexing 3.3 connectionless transport: UDP 3.4 principles of reliable data transfer 3.5 connection-oriented transport: TCP segment structure reliable data transfer flow control connection management 3.6 principles of congestion control 3.7 TCP congestion control Chapter 3 outline

3. application transport network data link physical application transport network data link physical logical end-end transport logical end-end transport logical end-end transport End-to-end transport: components • Multiplexing • Reliability • Congestion control • View of data • Stream of bytes • Packets • TCP • TCP • TCP • UDP

4. 3.1 transport-layer services 3.2 multiplexing and demultiplexing 3.3 connectionless transport: UDP 3.4 principles of reliable data transfer 3.5 connection-oriented transport: TCP segment structure reliable data transfer flow control connection management 3.6 principles of congestion control 3.7 TCP congestion control Chapter 3 outline

5. Multiplexing

6. Application-level data is split into segments, and given these headers  Host receives IP packets with: Source IP address Destination IP address Source port Destination port IP addresses & port numbersare used to determine the recipient socket How (de)multiplexing works 32 bits source IP address I P destination IP address (other header fields) source port # dest port # Transport other header fields Application segment of application data (payload)

7. The 5-tuple • The 5-tuple: last slide’s conclusion • Source IP address • Destination IP address • Source port • Destination port • Protocol (TCP, UDP, etc.) Network layer Transport layer

8. Identifying “flows” via 5-tuple Src IP: 1.2.3.4 Dst IP: 5.6.7.8 (is TCP) Src port: 37521 Dst port: 80 [data payload 2] Src IP: 1.2.3.4 Dst IP: 5.6.7.8 (is TCP) Src port: 37521 Dst port: 80 [data payload 1] Src IP: 1.2.3.4 Dst IP: 5.6.7.8 (is TCP) Src port: 26233 Dst port: 80 [data payload 5] Src IP: 1.2.3.4 Dst IP: 5.6.7.8 (is UDP*) Src port: 37521 Dst port: 80* [data payload 6] These are from the same flow different flow Same flow, other direction Src IP: 5.6.7.8 Dst IP: 1.2.3.4 (is TCP) Src port: 80 Dst port: 37521 [data payload 3] Src IP: 5.6.7.8 Dst IP: 1.2.3.4 (is TCP) Src port: 80 Dst port: 37521 [data payload 4] *Note: UDP port 80 not realistic

9. More on Ports • Separate 16-bit port address space for UDP and TCP • “Well known” ports(0-1023): everyone agrees which core services run on these ports • e.g., ssh:22, http:80 • helps client know server’s port: no “DNS for ports” • requires root: “the person running the program owns the computer” • Higher ports (1024+): choose one for your program • 3306: MySQL • 9418: git • 16567: Battlefield 2 • 27017: mongoDB • Ephemeral ports (high numbered): picked at random by client • IANA suggests 49152 – 65535 • Used by Windows Vista+, FreeBSD 4.6+ • Linux uses 32768 – 61000

10. 3.1 transport-layer services 3.2 multiplexing and demultiplexing 3.3 connectionless transport: UDP 3.4 principles of reliable data transfer 3.5 connection-oriented transport: TCP segment structure reliable data transfer flow control connection management 3.6 principles of congestion control 3.7 TCP congestion control Chapter 3 outline

11. The name says it all Let user-level code Send IP datagrams IP’s behavior: Packetized data Unreliable Can try sending very fast Connectionless No connection setup overhead Every packet is its own thing.“Here’s a packet from me.” UDP: User Datagram Protocol [RFC 768] • UDP use: • Skype etc. • Games • DNS • SNMP (managing switches) • Special reliability or congestion control logic (e.g. μTP) • End-to-end principle: • You need an unusual thing, so do it yourself • This algorithm is too specialized to add to the kernel

12. UDP is just multiplexed IP packet flows …so we’re done with it! (now back to abstract concepts for quite a while)

13. 3.1 transport-layer services 3.2 multiplexing and demultiplexing 3.3 connectionless transport: UDP 3.4 principles of reliable data transfer 3.5 connection-oriented transport: TCP segment structure reliable data transfer flow control connection management 3.6 principles of congestion control 3.7 TCP congestion control Chapter 3 outline

14. Reliable Transport • In a perfect world, reliable transport is easy @Sender • send packets @Receiver • wait for packets

15. Reliable Transport • In a perfect world, reliable transport is easy • All the bad things best-effort can do • a packet is corrupted (bit errors) • a packet is lost • a packet is delayed • packets are reordered • a packet is duplicated

16. Dealing with Packet Corruption 1  ack 2  nack . . . 2 Sender Receiver Time

17. Dealing with Duplicate Packets CLASS? 1 P(1)  ack(1)  1 P(1) Packet #1 or #2? ack(1) 2 P(2) Data and ACK packets carry sequence numbers What if the ACK/NACK is corrupted? Sender Receiver Time

18. Timeout Dealing with Packet Loss CLASS? 1 P(1)  1 P(1) ack(1) P(2) Sender Receiver Timer-driven loss detectionSet timer when packet is sent; retransmit on timeout Time

19. Timeout Dealing with duplicate because of a packet loss 1 P(1)  1 P(1) duplicate! ack(1) P(2) Sender Receiver Time

20. Timeout Dealing with duplicate because of a packet loss (different timing) 1 P(1) ack(1) 1 P(1) duplicate! . . . ack(1) P(2) Sender Receiver Timer-driven retx. can lead to duplicates Time

21. Components of a solution (so far) • checksums (to detect bit errors) • acknowledgements (positive or negative) • sequence numbers (to deal with duplicates) • timers (to detect loss)

22. A Solution: “Stop and Wait” • We have a correct reliable transport protocol! • Probably the world’s most inefficient one… @Sender • send packet(I); (re)set timer; wait for ack • If (ACK) • I++; repeat • If (NACK or TIMEOUT) • repeat @Receiver • wait for packet • if packet is OK, send ACK • else, send NACK • repeat

23. Stop & Wait is Inefficient TRANS DATA RTT Inefficient if TRANS << RTT ACK Receiver Sender

24. Sliding Window • window = set of adjacent sequence numbers • The size of the set is the window size; assume window size is n • General idea: send up to n packets at a time • Sender can send packets in its window • Receiver can accept packets in its window • Window of acceptable packets “slides” on successful reception/acknowledgement • Aside: why only n packets? • We’ll get there, just accept it for now

25. Sliding Window Last contiguous packet n Already ACK’d Sent but not ACK’d Cannot be sent sequence number 

26. Acknowledgements w/ Sliding Window • Two common options • cumulative ACKs: ACK carries next in-order sequence number that the receiver expects

27. Cumulative Acknowledgements (1) • At receiver Received and ACK’d n B Acceptable but notyet received Cannot be received • After receiving B+1, B+2: n B

28. Cumulative Acknowledgements (2) • At receiver Received and ACK’d n B Acceptable but notyet received Cannot be received • After receiving B+4, B+5 n B • Receiver sends (some ACK; let’s talk about that now!)

29. ACK Types, Sliding Window Protocols • Two options for ACKs • cumulative ACKs: ACK all contiguous packets • ACK n:“Packet n is the next one I need” • selective ACKs: ACK individual packets • ACK n: “I received packet n” • Two naturally resulting resend behaviors • Go-Back-N • Selective Repeat • (TCP is a little of both)

30. Go-Back-N (GBN) • Sender transmits up to n unacknowledged packets • Receiver only accepts packets in order • discards out-of-order packets (i.e., packets other than B+1) • Receiver uses cumulative acknowledgements • i.e., sequence# in ACK = next expected in-order sequence# • Sender sets timer for 1st outstanding ack (A+1) • If timeout, retransmit A+1,… , A+n

31. {1} 1 {1, 2} 2 {1, 2, 3} 3 {2, 3, 4} 4 {3, 4, 5} 5 {4, 5, 6} 6 GBN Example w/o Errors Sender Window Window size = 3 packets Receiver Window . . . . . . Sender Receiver Time

32. 1 2 3 4 5 Timeout Packet 4 6 4 5 6 GBN Example with Errors Window size = 3 packets Sender Receiver

33. Selective Repeat (SR) • Sender transmits up to n unacknowledged packets • Receiver sends an invidual ACK referring to each data packet • Situation: packet k is lost, k+1 is not • Receiver: ACK packet k+1 • Sender: after timeout, retransmit only packet k • Pro: only retransmit what’s needed (saves bandwidth!) • Con: more to keep track of: one timer per packet

34. Timeout Packet 4 SR Example with Errors Window size = 3 packets {1} 1 {1, 2} 2 {1, 2, 3} 3 {2, 3, 4} 4 {3, 4, 5} 5 6 {4, 5, 6} ACK=5 {4,5,6} ACK=6 4 {4,5,6} Time ACK=4 {7, 8, 9} 7 Sender Receiver

35. Observations • With sliding windows, it is possible to fully utilize a link, provided the window size is large enough. • When things go smoothly, what is the throughput? • Throughput is ~ (n/RTT) • Stop & Wait is like n = 1. • Sender has to buffer all unacknowledged packets, because they may require retransmission • Receiver may be able to accept out-of-order packets, but only up to its buffer limits • Implementation complexity depends on protocol details (GBN vs. SR)

36. Recap: components of a solution • Checksums (for error detection) • Acknowledgments • cumulative • selective • Sequence numbers (duplicates, windows) • Timers (for loss detection) • Sliding Windows (for efficiency)