1. Transport Layer3-1 89350 מבוא לתקשורת הרצאות 3-5: רמת התמסורת (chapter 3 – Transport) פרופ ' אמיר הרצברג Computer Networking: A Top Down Approach Featuring the Internet, 3 rd edition. Jim Kurose, Keith Ross Addison-Wesley, July 2005. Based on foils by Kurose & Ross ©, see: http://www.aw.com/kurose-ross/ http://www.aw.com/kurose-ross/ My site: http://amirherzberg.comhttp://amirherzberg.com

2. Transport Layer3-2 Today (& Chapter 3): outline r 3.1 Transport-layer services r 3.2 Multiplexing and demultiplexing r 3.3 Connectionless transport: UDP r 3.4 Principles of reliable data transfer r 3.5 Connection-oriented transport: TCP m segment structure m reliable data transfer m flow control m connection management r 3.6 Principles of congestion control r 3.7 TCP congestion control

3. Transport Layer3-3 Processes & communication Process: program running within a host. r within same host, two processes communicate using inter-process communication (IPC) m Not in this course r processes in different hosts communicate by exchanging messages m In this course Client process: process that initiates communication Server process: process that waits to be contacted; always on

4. Transport Layer3-4 Transport services and protocols r communication between application processes (not just hosts) r Run in end systems m send segments via network layer m rcv side: reassemble segments to messages m Pass to application via socket (buffer) r Internet transport protocols: TCP and UDP application transport network data link physical application transport network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical logical end-end transport

5. Transport Layer3-5 Internet transport-layer protocols r Connection: TCP m Reliable, in-order delivery m congestion control m flow control m connection setup r Connection-less: UDP m Unreliable, unordered delivery m “best-effort”, like IP r Neither ensure: m delay guarantees m bandwidth guarantees application transport network data link physical application transport network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical logical end-end transport

6. Transport Layer3-6 Transport vs. network layer r network layer: logical communication between hosts r transport layer: logical communication between processes m relies on, enhances, network layer services m E.g., TCP adds reliability, and flow, congestion control Analogy / example: Sending order to bank r Re: saving or money acct r processes = accounts, clerks r hosts = bank branches r Application protocol = forms & process of saving, banking accts (SMTP, HTTP, …) r Network-layer protocol = postal service (or IP) r Transport protocol = `received at` stamp, in- branch routing to account- handling clerk (TCP)

7. Transport Layer3-7 Multiplexing of Packets within Host r Network layer delivers packet to correct host (by IP address) r Transport layer delivers packet to correct process r How to identify process (in host)? m Use 16-bit port number (in Transport Layer header) m Multiplexing: adding ports identifier to packet delivered to IP m Demultiplex: deliver packets to correct apps (using ports in packet) r Server: fixed port # <1024 m So request reach server m HTTP server: 80 m Mail server: 25 r Client: OS-assigned (`random`), dynamic port >1024 m Multiple client processes can work with same server r Process queues data of a connection/port via socket

8. Transport Layer3-8 Sockets and Sockets API r processes sends/receive messages via socket API r API=Application Program Interface r Socket: in/out buffer m Metaphor: mailbox process TCP/UDP socket host (Client / Server) process TCP/UDP socket host Internet r Sockets API functions: m Send, receive m Connection (TCP, not UDP): open, close m Fix a few parameters, e.g. buffer size (more on this later) m Choose transport service… Application Layer

9. Transport Layer3-9 Multiplexing/demultiplexing application transport network link physical P1 application transport network link physical application transport network link physical P2P3P4P1 Sending host 1 Receiving host Sending host 2 = process= socket deliver received segments to correct socket (identified in header) Demultiplexing at rcv host: Add to data a header (identifying source/destination sockets for later demultiplexing) Multiplexing at send host:

10. Transport Layer3-10 How demultiplexing works r host receives datagram m Datagram carries (one) transport-layer segment m Segment has source, destination port numbers r Use IP addresses & ports to identify socket r How? Depends… m UDP: one socket per port m TCP server: one socket per source port #dest port # 32 bits application data (message) other transport header fields Transport layer segment Internet layer packet source IP Address dest IP Address other Internet layer header fields source IP Address dest IP Address IP Header

11. Transport Layer3-11 IP Addresses / Ports and NAPT r IP addresses identify (source, dest) host r Ports identify (source, dest) process m A port is a 16-bit identifier m At beginning of IP payload r Fixed server ports: m HTTP (Web): 80, SMTP (email):25 … m Fixed so client knows port # to reach server process r Client ports assigned (`randomly`) by OS r Network Address/Port Translation (NAPT): share IP address, identify host by port

12. Transport Layer3-12 NAPT/NAT: Network Address (Port) Translation 1. SrcIP=10.0.0.1 SrcPort=3373 DstPort=80 2. SrcIP=133.44.5.8 SrcPort=6678 DstPort=80 3. DstIP=133.44.5.8 SrcPort=80 DstPort=6678 4. DstIP=10.0.0.1 SrcPort=80 DstPort=3373 Goal: share IP addresses among multiple hosts How: identify host by port

13. Transport Layer3-13 NAPT: Network Address/Port Translation 10.0.0.1 10.0.0.2 10.0.0.3 S: 10.0.0.1, 3345 D: 128.119.40.186, 80 1 10.0.0.4 138.76.29.7 1: host 10.0.0.1 sends datagram to 128.119.40, 80 NAT translation table WAN side addr LAN side addr 138.76.29.7, 5001 10.0.0.1, 3345 …… S: 128.119.40.186, 80 D: 10.0.0.1, 3345 4 S: 138.76.29.7, 5001 D: 128.119.40.186, 80 2 2: NAT router changes datagram source addr from 10.0.0.1, 3345 to 138.76.29.7, 5001, updates table S: 128.119.40.186, 80 D: 138.76.29.7, 5001 3 3: Reply arrives dest. address: 138.76.29.7, 5001 4: NAT router changes datagram dest addr from 138.76.29.7, 5001 to 10.0.0.1, 3345

14. Transport Layer3-14 UDP: Connectionless demultiplexing r Create sockets with port numbers: DatagramSocket mySocket1 = new DatagramSocket(9111); DatagramSocket mySocket2 = new DatagramSocket(); r UDP socket identified by destination port (and IP) r When host receives UDP segment: m checks destination port number in segment m directs UDP segment to socket with that port number r Regardless of source IP and port

15. Transport Layer3-15 UDP: Connectionless demux (cont) DatagramSocket serverSocket = new DatagramSocket(6428); Client IP:B P3 client IP: A P1 P2 server IP: C SP: 6428 DP: 9157 SP: 9157 DP: 6428 SP: 6428 DP: 5775 SP: 5775 DP: 6428 DP= Destination Port, SP= Source Port Client’s SP provides “return address” (server’s DP) Client’s DP (destination port on server) known to client (e.g. standard)

16. Transport Layer3-16 TCP: Connection-oriented demux r TCP socket identified by 4-tuple: m source IP address m source port number m dest IP address m dest port number r recv host uses all four values to direct segment to appropriate socket r Server host may support many simultaneous TCP sockets: m each socket identified by its own 4-tuple r E.g., web servers have different sockets for each connecting client

17. Transport Layer3-17 TCP: Connection-oriented demux Client IP:B P3 client IP: A P1 P3 server IP: C SP: 80 DP: 9157 SP: 9157 DP: 80 SP: 80 DP: 5775 SP: 5775 DP: 80 P4 What is different here? Would this work well for web server?

18. Transport Layer3-18 TCP: Connection-oriented demux Client IP:B P3 client IP: A P1 P2 server IP: C SP: 80 DP: 9157 SP: 9157 DP: 80 SP: 80 DP: 5775 SP: 5775 DP: 80 Multithreading server may listen to multiple ports

19. Transport Layer3-19 Internet transport layer services TCP service: r connection-oriented: setup overhead required m TCP setup: one round trip r reliable transport: no loss (but some overhead) r flow control: feed (send) at receiver’s speed r congestion control: throttle sender when network overloaded r does not provide: delay, bandwidth guarantees UDP service: r Datagram: no setup r Unreliable transport: loss r does not provide: m Reliability m Flow/congestion control m Delay or bandwidth guarantees Others (e.g. RDP) Q: Would we ever choose UDP?

20. Transport Layer3-20 Choosing transport service… Reliability, congestion, flow controls r TCP: yes, UDP: no r Overhead, slowdown r Often required m E.g. file transfer, e-mail m Not always, e.g., audiocast Size and complexity r Code size, complexity are sometimes critical (…UDP) m E.g., dust computer, sensor Bandwidth & Delay Guarantee r Not in TCP,UDP r Ok for “elastic” appl. m Use whatever bandwidth & delay they get m E.g. e-mail, Web r Phone & other apps require minimal Quality of Service Setup overhead? r TCP: yes, UDP: no r Ignore in long-lived app m E.g. file transfer, telnet r Sometimes significant m E.g. DNS queries

21. Transport Layer3-21 Chapter 3 outline r 3.1 Transport-layer services r 3.2 Multiplexing and demultiplexing r 3.3 Connectionless transport: UDP r 3.4 Principles of reliable data transfer r 3.5 Connection-oriented transport: TCP m segment structure m reliable data transfer m flow control m connection management r 3.6 Principles of congestion control r 3.7 TCP congestion control

22. Transport Layer3-22 UDP: User Datagram Protocol [RFC 768] r “no frills,” “bare bones” transport protocol r “best effort” service, UDP segments may be: m lost m delivered out of order to app r connectionless: m no handshaking m each UDP segment handled independently of others Why is there a UDP? r no connection setup (delay) r simple: no connection state at sender, receiver r no retransmission r no congestion control: UDP can blast away as fast as desired (or more…) r smaller segment header

23. Transport Layer3-23 UDP: header and more r UDP often used for streaming multimedia apps m loss tolerant m rate sensitive r other UDP uses m DNS (why?) m SNMP – Simple Network Management Protocol r UDP Congestion/flow control? m By application; flexible m Limited buffer per port [notes] r Reliability over UDP? m Checksum detects (most) corruptions [hidden foils] m Requires application-specific error recovery! source port #dest port # 32 bits Application data (message) UDP segment format length checksum Length, in bytes of UDP segment, including header

24. Transport Layer3-24 UDP checksum (error detection code) Sender: r treat segment contents as sequence of 16-bit integers r checksum: addition (1’s complement sum) of segment contents r sender puts checksum value into UDP checksum field Receiver: r compute checksum of received segment r check if computed checksum equals checksum field value: m NO – error, discard m YES - no error detected. But maybe errors nonetheless? m Coding theory – design of good error detection and correction codes Goal: detect and discard damaged segments (e.g., flipped bits)

25. Transport Layer3-25 Internet Checksum Example r Note m When adding numbers, a carryout from the most significant bit needs to be added to the result r Example: add two 16-bit integers 1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 1 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1 wraparound sum checksum

26. Transport Layer3-26 Chapter 3 outline r 3.1 Transport-layer services r 3.2 Multiplexing and demultiplexing r 3.3 Connectionless transport: UDP r 3.4 Principles of reliable data transfer r 3.5 Connection-oriented transport: TCP m segment structure m reliable data transfer m flow control m connection management r 3.6 Principles of congestion control r 3.7 TCP congestion control

27. Transport Layer3-27 Principles of Reliable data transfer r important in app., transport, link layers r top-10 list of important networking topics! r characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt)

28. Transport Layer3-28 Reliable data transfer: getting started send side receive side rdt_send(): called from above, (e.g., by app.). Passed data to deliver to receiver upper layer udt_send(): called by rdt, to transfer packet over unreliable channel to receiver rdt_rcv(): called when packet arrives on rcv-side of channel deliver_data(): called by rdt to deliver data to upper

29. Transport Layer3-29 RDT Protocol : Events r Finite state machine r Inputs: m rdt_send(m) – message m from application m rdt_rcv(p) – packet p from (unreliable) channel r Outputs: m udt_send(p) – packet p to (unreliable) channel m deliver_data(m) – message m to application m ready( ) – to receive another message from application r Execution: m Sequence of input, output events m Outputs defined by protocol

30. Transport Layer3-30 Reliable data transfer: plan We’ll: r Present few (improving) versions of RDT protocol m From strong to weak assumptions on input events (channel) m Later, also add more inputs/outputs… r Consider only unidirectional message transfer m but bidirectional packets (&control info) flow r Define protocol by pseudo-code or state diagram: m States S={S1,S2,…} m Events E={e1,e2,…} m Actions A={a1,a2,…} m Transition rules, S  E  A  S, e.g.: state S1 state S2 Event e1 causing transition S1  S2 Action a1 taken on state transition Event e2 Action a2 Event e3 Action a3 S3

31. Transport Layer3-31 Rdt1.0: reliable transfer over a reliable channel r underlying channel (udt) perfectly reliable m no bit errors m no loss of packets m No need to setup and teardown connection (always up) r separate state machines for sender, receiver: m sender sends data into underlying channel m receiver read data from underlying channel Wait for call from above packet = make_pkt(data) udt_send(packet) rdt_send(data) extract (packet,data) deliver_data(data) Wait for call from below rdt_rcv(packet) sender receiver

32. Transport Layer3-32 Rdt2.0: udt channel with bit errors r underlying channel may flip bits in packet m recall: UDP checksum to detect bit errors m Assume: errors detected, no packet loss / reordering r the question: how to recover from errors: m acknowledgements (ACKs): receiver explicitly tells sender that pkt received OK m negative acknowledgements (NAKs): receiver explicitly tells sender that pkt had errors m sender retransmits pkt on receipt of NAK  new mechanisms in rdt2.0 (beyond rdt1.0 ): m error detection m receiver feedback: control msgs (ACK,NAK) rcvr->sender m `ready` output [why?]

33. Transport Layer3-33 rdt2.0: FSM specification Wait for call from above sndpkt = make_pkt(data, checksum) udt_send(sndpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) rdt_rcv(rcvpkt) && isACK(rcvpkt) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) udt_send(NAK) rdt_rcv(rcvpkt) && corrupt(rcvpkt) Wait for ACK or NAK Wait for call from below sender receiver rdt_send(data) ready

34. Transport Layer3-34 rdt2.0: operation with no errors Wait for call from above sndpkt = make_pkt(data, checksum) udt_send(sndpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) rdt_rcv(rcvpkt) && isACK(rcvpkt) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) udt_send(NAK) rdt_rcv(rcvpkt) && corrupt(rcvpkt) Wait for ACK or NAK Wait for call from below rdt_send(data) ready

35. Transport Layer3-35 rdt2.0: error scenario Wait for call from above sndpkt = make_pkt(data, checksum) udt_send(sndpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) rdt_rcv(rcvpkt) && isACK(rcvpkt) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) udt_send(NAK) rdt_rcv(rcvpkt) && corrupt(rcvpkt) Wait for ACK or NAK Wait for call from below rdt_send(data) ready

36. Transport Layer3-36 Analysis of RDT 2.0 r Goals of RDT2.0: m Delivered messages are prefix of sent messages m Eventually, all messages get delivered, `ready` for more r Assumptions of RDT 2.0: m Every packet sent, is eventually delivered m But: possibly corrupted (always detected) m 1-to-1 mapping from packets delivered to sent r Goals are not met. Why?

37. Transport Layer3-37 rdt2.0 has a fatal flaw! What happens if ACK/NAK corrupted? r 1 st : add checksum… but r sender still doesn’t know what happened at receiver! r can’t just retransmit: possible duplicate What to do? r sender ACKs/NAKs receiver’s ACK/NAK? What if this ACK/NAK garbled? r Retransmit on garbled m Danger: duplicates Handling duplicates: r sender adds sequence number to each pkt r sender retransmits current pkt if ACK/NAK garbled r receiver discards (doesn’t deliver) duplicate pkt Sender sends one packet, then waits for receiver’s response; use (1-bit) sequence number RDT 2.1, aka `stop & wait` protocol

38. Transport Layer3-38 rdt2.1: sender states (handles garbled ACK/NAKs) Wait for call 0 from above sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) rdt_send(data) Wait for ACK or NAK 0 udt_send(sndpkt) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isNAK(rcvpkt) ) sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) rdt_send(data) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt) udt_send(sndpkt) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isNAK(rcvpkt) ) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt) Wait for call 1 from above Wait for ACK or NAK 1  

39. Transport Layer3-39 rdt2.1: receiver states (handles garbled ACK/NAKs) Wait for 0 from below sndpkt = make_pkt(NAK, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq0(rcvpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) Wait for 1 from below rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq0(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq1(rcvpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) sndpkt = make_pkt(NAK, chksum) udt_send(sndpkt) Exercise!

40. Transport Layer3-40 RDT2.1 in pseudo-code… Sender: state=ready; i=0; On rdt_send(m): if state=ready then { p= ; udt_send(p); state=wait; } On rdt_rcv(p’) r If p’= then { i=i+1 mod 2; state=ready; } else udt_send(p); Receiver: i=0; On rdt_rcv(p) r If p= then { c=EDC(“ack”); udt_send(“ack”,c); if i=j then { deliver(m); i=i+1 mod 2; } } else rdt_sent(“nack”); EDC: Error Detection Code (e.g. checksum)

41. Transport Layer3-41 Analysis of RDT 2.1 [sketch] r Goals, Assumptions: same as RDT 2.0 m Every packet sent, is eventually delivered m But: possibly corrupted (always detected) m 1-to-1 mapping from packets delivered to sent r Define `legitimate` states: [E=Even, O=Odd] 1. RE/RO: Ready (to receive E/O message); channel empty 2. ME/MO: Wait for E/O Ack; channel has new E/O message 3. AE/AO: Wait for E/O Ack; channel has E/O Ack 4. MER/MOR: Wait for E/O Ack; channel has E/O message which was already delivered 5. WEAO: Wait for E Ack but channel has O Ack 6. WOAE: Wait for O Ack but channel has E Ack m Prove by induction: system stays in legitimate state!

42. Transport Layer3-42 Analysis of RDT 2.1 [sketch, cont’] m Claim: system always in legitimate state m Base: initial state is (legitimate) RE m Consider moves from legitimate states: 1. RE/RO: only to ME/MO 2. ME/MO: If received Ok, move to AE/AO; otherwise, to WEAO/WOAE 3. AE/AO: If received Ok, move to RO/RE; otherwise, to MER/MOR 4. MER/MOR: same as ME/MO! 5. WEAO/WOAE: move to MER/MOR mIf received correctly… and also if corrupted! m  System always stays in legit state!! □

43. Transport Layer3-43 RDT2.1: Discussion r Nack/Ack, 1 bit counter r Handles (detectable) packet corruptions r Assume: m No processor faults m No connection setup / teardown (always up) m All error in packets detected (by checksum) m No packet loss / reordering / duplication m Duplication of message is no problem m But duplicate ACK can cause loss m RDT2.2: handle duplication: add seq # to ack…

44. Transport Layer3-44 RDT2.2: duplicate-tolerant protocol r Same functionality as rdt2.1, using ACKs only r Instead of NAK, receiver sends ACK for last pkt received OK m Explicitly include seq # of pkt being ACKed m Resilient to packet (incl. Ack) duplication Exercise: why RDT2. 1fails if Ack is duplicated? m Important: allows sender to retransmit… see later! r Duplicate ACK at sender results in same action as NAK: retransmit current pkt

45. Transport Layer3-45 RDT2.2: sender, receiver fragments Wait for call 0 from above sndpkt = make_pkt(0, data, chksum) udt_send(sndpkt) rdt_send(data) udt_send(sndpkt) rdt_rcv(rcvpkt) && ( NOT isACK(rcvpkt,0) ) rdt_rcv(rcvpkt) && isACK(rcvpkt,0) Wait for ACK 0 sender FSM fragment Wait for 0 from below rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) Deliver_data(rcvpkt) sndpkt = make_pkt(ACK1, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt) || has_seq1(rcvpkt)) udt_send(sndpkt) receiver FSM fragment 

46. Transport Layer3-46 RDT2.2: pseudo-code… Sender: state=ready; i=0; On rdt_send(m): if state=ready then { p= ; udt_send(p); state=wait; } On rdt_rcv(p’) r Let c=EDC (“ack”,i); If p’= then { i=i+1 mod 2; state=ready; } else udt_send(p); Receiver: i=0; On rdt_rcv(p’) r If p’= then { p= ; udt_send(p); deliver(m); i=i+1 mod 2; } else rdt_sent(p);

47. Transport Layer3-47 RDT3.0: Alternating Bit Protocol Allow packet loss: channel can also lose packets (data or ACKs) m checksum, seq. #, ACKs, retransmissions are not enough Q: how to deal with loss? m 1 st Idea: sender waits maximal round-trip time (RTT), then retransmits m Pro: simple, no duplicates m Good for fixed, known RTT m What for variable RTT?? Better idea: sender waits “reasonable” amount of time for ACK (<max RTT) r retransmits if no ACK received during this time r if pkt (or ACK) just delayed (not lost): m retransmission will be duplicate, but use of seq. #’s already handles this m Recall: receiver includes seq # of pkt being ACKed r requires countdown timer Handles errors, dup and loss, but no reordering

48. Transport Layer3-48 Alternating Bit Protocol (rdt3.0): sender sndpkt = make_pkt(0, data, chksum) udt_send(sndpkt) start_timer rdt_send(data) Wait for ACK0 rdt_rcv(rcvpkt) && ( NOT isACK(rcvpkt, 0) ) Wait for call 1 from above sndpkt = make_pkt(1, data, chksum) udt_send(sndpkt) start_timer rdt_send(data) rdt_rcv(rcvpkt) && isACK(rcvpkt,0) rdt_rcv(rcvpkt) && ( NOT isACK(rcvpkt,1) ) rdt_rcv(rcvpkt) && isACK(rcvpkt,1) stop_timer udt_send(sndpkt) start_timer timeout udt_send(sndpkt) start_timer timeout rdt_rcv(rcvpkt) Wait for call 0 from above Wait for ACK1  rdt_rcv(rcvpkt)   

49. Transport Layer3-49 Alternating Bit Protocol (RDT3.0 ): pseudo-code for sender… state=ready; i=0; On rdt_send(m): if state=ready then { p= ; udt_send(p); state=wait; sleep(“timeout”,T); } On rdt_rcv(p’) If p’= then { i=i+1 mod 2; state=ready; abort(“timeout”); } On WakeUp(“timeout”): {udt_send(p); sleep(“timeout”,T); } Recipient: as in RDT 2.2!

50. Transport Layer3-50 Alternating Bit Protocol (RDT3.0 ): pseudo-code… Sender: state=ready; i=0; On rdt_send(m): if state=ready then { p= ; udt_send(p); state=wait; sleep(“timeout”,T); } On rdt_rcv(p’) r Let c=chksum(“ack”,i); If p’= then { i=i+1 mod 2; state=ready; abort(“timeout”); } else: resend(); On WakeUp(“timeout”): resend(): resend() {udt_send(p); sleep(“timeout”,T); } Receiver: i=0; On rdt_rcv(p’) r If p’= then { c=chksum(“ack”,i); p= ; udt_send(p); deliver(m); i=i+1 mod 2; } else rdt_sent(p); As in RDT2.2!

51. Transport Layer3-51 Alternating Bit (rdt3.0) in action

52. Transport Layer3-52 Alternating bit (rdt3.0) in action

53. Transport Layer3-53 Alternating bit (rdt 3.0): problems r No pipelining (at most one packet on link) m Performance problem r Assumes FIFO (no reordering) m But datagram networks may not ensure FIFO! r No setup and teardown of connection m Teardown required to allow appl to take corrective/alternate action if not connected m And to avoid keeping state indefinitely m Also: to handle processor faults

54. Transport Layer3-54 Rest of Transport Layer… r TCP Overview r TCP Reliability r TCP Timeouts r TCP Flow Control r 3.6 Principles of congestion control r 3.7 TCP congestion control r TCP Fairness

55. Transport Layer3-55 TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581 r pipelined: m TCP congestion and flow control set window size m flow control: sender will not overwhelm receiver r send & receive buffers r full duplex data: m bi-directional data flow in same connection r point-to-point: m one sender, one receiver r reliable, in-order byte steam: m no “message boundaries” r connection-oriented: m Handshake before data exchange m Teardown (to free resources, detect failure)

56. Transport Layer3-56 TCP segment structure source port # dest port # 32 bits application data (variable length) sequence number acknowledgement number Receive window Urg data pnter checksum F SR PAU head len not used Options (variable length) U (URG): urgent data (generally not used) A (ACK): this is an ack of ack-number P (PSH): push data (don’t aggregate) RST, SYN, FIN: connection estab (setup, teardown commands) # segments rcvr willing to accept counting by bytes of data (not segments!) Internet checksum (as in UDP)

57. Transport Layer3-57 TCP Services r TCP connection-based transport service: m Setup connection m Use connection m Close connection r TCP connection services: m Flow control: don’t send faster than receiver can absorb [later] m Congestion control: slow down if network gets congested [later] m Fairness: fair sharing of Net resources among connections [later] m Reliable, pipelined stream service – next!

58. Transport Layer3-58 TCP reliable data transfer r TCP: reliability on top of IP’s unreliable service m Packet loss / error m Duplicates m Out of order m Setup/teardown m Loss of state in proc. r Pipelined segments m hybrid of GBN & SR m But a single retransmission timer m Substantial flexibility r Cumulative acks m Resend (duplicate) ACK instead of NACK r Retransmissions are triggered by: m timeout events m duplicate ACKs (later) r Initially consider simplified TCP sender: m ignore duplicate acks m ignore flow control, congestion control r Window of N bytes

59. Transport Layer3-59 Reliable (TCP) Connection r What is a reliable (TCP) connection? r Reliable connection management m Setup m Teardown r Reliable communication in connection m Delivery m FIFO… r Connection fails if and only if packets cannot pass

60. Transport Layer3-60 Reliable connection: More Interface… r Connection status at both ends: m Link Up/Down indicators [Sender: also Ready/Wait] m Open/Close Connection commands m rdt_send, deliver only when link Up [sender: and Ready] send side receive side Link up / down (Ok/Fault) Ready / Wait Open/Close

61. Transport Layer3-61 TCP Reliability r Reliable Connection Management m Setup (SYN, SYN-ACK), tear-down (later) r Reliable Communication in Connection m Counters, timeout, retransmit [like RDT3.0] Syn SynAck A (Client) B (Server) Up 122 Ack1 Timeout X

62. Transport Layer3-62 Reliable Connection Management r Three basic states: m Up m Down m Syn (in progress) m Teardown states - later r Send, receive only when connection is Up r Connection setup (SYN): m Completes in finite time m But may fail r Connection closure (FIN): m Completes in finite time

63. Transport Layer3-63 TCP Connection States r Three basic states: m Up m Down m Syn (in progress) r Send, receive only when connection Up Syn A B Up Syn X X X X X Up

64. Transport Layer3-64 TCP Connection Teardown r Ordered and Forced Teardown mechanisms r Forced Teardown: m When `fatal` error detected: m Send RST signal and abort (break) connection m Same when receiving RST signal If sequence number in RST is within `window` [why?] r Ordered Teardown: m Ensure all messages sent are received m Ensure peer will also close connection

65. Transport Layer3-65 TCP Connection Tear-Down Closing a connection: client closes socket: clientSocket.close(); Step 1: client end system sends TCP FIN control segment to server Step 2: server receives FIN, replies with ACK. Closes connection, sends FIN. client FIN server ACK FIN close closing closed timed wait Step 1 Step 2 closed

66. Transport Layer3-66 TCP Connection Tear-Down (cont.) Step 3: client receives FIN, replies with ACK. m Enters “timed wait” - will respond with ACK to received FINs (WHY??) Step 4: server, receives ACK. Connection closed. Exercise: Modify to allow (also) server to initiate TearDown (`simultaneous FINs`) client FIN server ACK FIN closing closed timed wait closed Step 1 Step 2 Step 3 (Step 4)

67. Transport Layer3-67 TCP Reliable Connection Closure r Fin, Fin-Wait: new states m Fin : closure begun; receive OK but don’t send m Fin-Wait: wait (30sec), to ensure peer is done Only by closure initiator (usually client) r Initiator: send FIN, wait for ACK and FIN r Responder: ACK (to FIN), last messages, FIN m Done when receiving ACK to FIN A B Up FIN Ack data Ack FIN Ack Up 30 sec Fin-Wait Fin Down

68. Transport Layer3-68 TCP Connection: client lifecycle RST or timeout; send RST RST

69. Transport Layer3-69 TCP Connection: server lifecycle Receive Ack

70. Transport Layer3-70 Reliable Connection Management r Send, receive only when connection Up r Setup (SYN): complete/fail in finite time r Closure (FIN): completes/fail in finite time r Reset (RST): only due to disconnection r Each Up at A (B) maps to unique Syn at B (A) Syn A B Up Syn X X X X X Up

71. Transport Layer3-71 Reliable Connection: Management r Send, receive only when connection is Up r Setup (SYN): complete/fail in finite time r Closure (FIN): complete/fail in finite time m In both ends r Reset (RST): only due to disconnection m Closed (broken) at both ends, finite time r Monotonous, 1-to-1 mappings MAP A, MAP B m MAP A (x): from A’s Up periods to B’s Syn m MAP B (x): from B’s Up periods to A’s Syn

72. Transport Layer3-72 Mapping Between Connections r Each Up at A (B) maps to unique Syn at B (A) r Use mapping functions MAP A, MAP B r b=MAP A (a): map from A’s Up to B’s Syn r In example: MAP A is identity, i.e. MAP A (a)=a r But: MAP B (1)=1, MAP B (2)=4 ! r In general: MAP is monotonous, one-to-one Syn A B Up(1) Syn (1) Syn (1) X X X X X Syn(2) Syn (3) Syn (3) Syn (4) Up(2) Up (3) Up(2)

73. Transport Layer3-73 Stateful Connection Management r Reliable connection management is easy… r If we count Syn periods: m Each party maintains Syn periods counter m Send your Syn counter with SYN m Echo other party’s Syn counter in SYN-ACK m Ignore SYN-ACK with old echoed counter Syn,1 A B Up(1) Syn (1) Syn (1) X X X X X Syn(2) Syn (3) Syn (3) Syn (4) Up(2) Up (3) Up(2) Syn,1;1 Ack,1 Fin,1 Syn,2 Syn,3 Syn,2;3 Ack,2 Ack,3 Syn,4

74. Transport Layer3-74 Stateless Connection Management r Stateful connection management is easy r But servers, clients may lose state  And… too much state – should cnn.com keep state for each client (forever)? r And… How to identify repeating client? m IP address – which (DHCP, NAPT)? m IP + port - Fails for NAPT; ports are temporary r Need Stateless Connection Management Use random numbers instead of counters!

75. Transport Layer3-75 Stateless Connection Management Use random seq# to identify Syn period m Select, send your seq# with SYN, SYN-ACK m Echo other party’s seq# with SYN-ACK, ACK m Ignore SYN responses with wrong (old) echoed identifier 37 A B Up(1) Syn (1) Syn (1) X X X X X Syn(2) Syn (3) Syn (3) Syn (4) Up(2) Up (3) Up(2) 66;A37 A66 F37 88 42 91;A42 A91 A63 34 13:A37

76. Transport Layer3-76 Stateless Three Way Handshake Setup connection r client: initiator  server: responding r Each choose random seq# m Match SYN, SYNACK m Seq# to ensure no- loss of data r Use flags in TCP header: SYN, ACK, RST, FIN Three way handshake: Step 1: client sends TCP SYN segment to server m Specify client seq# m no data Step 2: server receives SYN, replies with SYN-ACK segment m Allocate buffers m Ack client’s seq# m Send server’s seq# m no data Step 3: client receives SYN-ACK, validates #, Acks server # and (optionally) sends data

77. Transport Layer3-77 Reliable Communication r Whenever a connection terminates (even with failure) m Sequence received is prefix of sequence sent m No gaps m No reordering m No insertions m No duplications r Well-terminated connections: m At one or (usually) both ends Can’t guarantee to always detect at both ends m All bytes delivered Sequence received = sequence sent No truncations

78. Transport Layer3-78 TCP Reliability in Connection r Sequence numbers kept by both parties r 32 bit counters, initialized randomly m When overflow, `wrap` to begin from zero r Send with each packet sent to peer: m Sequence number of first byte sent in this packet m Seq. number of next byte expected from peer m All bytes till this one were received Ok (ACK) SYN,37 A B 66;A37 “Hi”,37,A66 “Ready”,66,A39 “Wait”,39,A71 71;A43

79. Transport Layer3-79 Loss and Retransmissions r Packet or Ack is lost m Often due to congested router r TCP retransmits lost packet r Loss detected by timeout m Another method later SYN,37 A B 66;A37 “Hi”,37,A66 “Ready”,66,A39 “Wait”,39,A71 71;A43 X “Wait”,39,A71 Timeout

80. Transport Layer3-80 Premature Timeout  Duplicates r What if packet is delayed, but not lost? m Often due to congested router… r Delayed too long  TCP retransmits it  duplication r No harm – TCP discards duplicate packets m Send another ACK, in case first one was lost SYN,37 A B 66;A37 “Hi”,37,A66 “Ready”,66,A39 “Wait”,39,A71 71;A43 Timeout

81. Transport Layer3-81 Stop-and-wait [RDT3.0]: inefficiency first packet bit transmitted, t = 0 senderreceiver RTT last packet bit transmitted, t = L / R first packet bit arrives last packet bit arrives, send ACK ACK arrives, send next packet, t = RTT + L / R

82. Transport Layer3-82 Pipeline / Window for Efficiency r Protocol as described is inefficient: m Transmission rate = 10 Mb/sec m Max segment size (MSS) = 1250B= 10000 bits m Round Trip Time (RTT) = 100msec Includes transmit, propagation, queuing m File size = 125KB = 1 million bits = 100 segments m Time to send= 100 segments * 100msec = 10sec r Idea: send file without waiting for ACK? m Transmission time= (1Mb)/(10Mb/sec)=100msec m RTT = 200msec m Send 100 segments in pipeline / window

83. Transport Layer3-83 Pipelined protocols Pipelining: sender allows multiple, “in-flight”, yet-to- be-acknowledged pkts m Need `real` sequence numbers (not 1 bit)  also deals with out-of-order (old) packets  TCP: count bytes, begin with random numbers from setup m buffering at sender and (optionally) receiver Pipelining improves link utilization

84. Transport Layer3-84 Pipelining: increased utilization first packet bit transmitted, t = 0 senderreceiver RTT last bit transmitted, t = L / R first packet bit arrives last packet bit arrives, send ACK ACK arrives, send next packet, t = RTT + L / R last bit of 2 nd packet arrives, send ACK last bit of 3 rd packet arrives, send ACK

85. Transport Layer3-85 TCP seq. #’s and ACKs with Pipeline Seq. #’s: m byte stream “number” of first byte in segment’s data ACKs: m seq # of next byte expected from other side m cumulative ACK Q: how receiver handles out-of-order segments m A: ignore old pkts; buffer or ignore future packets Host A Host B Seq=42, ACK=79, data = ‘Req’ Seq=79, ACK=45, data = ‘Ok’ Seq=45, ACK=81 User sends ‘Req’ Client ACKs receipt of ‘Ok’ host ACKs receipt of ‘Req’, sends back ‘Ok’ time simple telnet scenario

86. Transport Layer3-86 TCP: retransmission scenarios Host A Seq=100, 20 bytes data ACK=100 time premature timeout Host B Seq=92, 8 bytes data ACK=120 Seq=92, 8 bytes data Seq=92 timeout ACK=120 Host A Seq=92, 8 bytes data ACK=100 loss timeout lost ACK scenario Host B X Seq=92, 8 bytes data ACK=100 time Seq=92 timeout SendBase = 100 SendBase = 120 SendBase = 120 Sendbase = 100

87. Transport Layer3-87 TCP retransmission scenarios (more) Host A Seq=92, 8 bytes data ACK=100 loss timeout Cumulative ACK scenario Host B X Seq=100, 20 bytes data ACK=120 time SendBase = 120

88. Transport Layer3-88 TCP sender events (simplified): TCP_send(m): r segment= ; m seq # is byte-stream number of first data byte in segment r start timer m if not already running m Timer is for oldest unacked segment Timeout: r retransmit segment that caused timeout r restart timer Ack rcvd: r If acknowledges previously unacked segments m update what is known to be acked m start timer if there are outstanding segments

89. Transport Layer3-89 TCP sender (simplified) [e.g. no window] NextSeqNum = SendBase = random();Unacked=Φ; On TCP_Send(m) segment = ; If timer(“timeout”)=Φ then SetTimer(“timeout”,T); IP_send (segment) ; NextSeqNum = NextSeqNum + |m|; Unacked = Unacked || m; On wakeup(“timeout”) L=min(MSS, |Unacked|); Segment= ; IP_send(segment); SetTimer(“timeout”,T); On TCP_Rcv(ACK,y) // valid checksum if (y > SendBase) { remove y-SendBase bytes from Unacked; SendBase = y; if (NextSeqNum>SendBase) restart timer; } Comment: SendBase-1: last cumulatively ack’ed byte Example: SendBase-1 = 71; y= 73, so the rcvr wants 73+ ; y > SendBase, so that new data is acked

90. Transport Layer3-90 Duplicate Ack & Fast Retransmit r Time-out period often relatively long: m long delay before resending lost packet r Detect lost segments via duplicate ACKs. m Sender often sends many segments back-to- back m If segment is lost, there will likely be many duplicate ACKs. r If sender receives 3 ACKs for the same data, it supposes that segment after ACKed data was lost: m fast retransmit: resend segment before timer expires m Why not two? Exercise…

91. Transport Layer3-91 On TCP_RCV(ACK,y) // and valid checksum if (y > SendBase) then { remove y-SendBase bytes from Unacked; SendBase = y; if (NextSeqNum>SendBase) then start timer; } else { increment count of dup ACKs received for y if (count of dup ACKs received for y = 3) { resend segment with sequence number y } Fast retransmit algorithm: a duplicate ACK for already ACKed segment fast retransmit

92. Transport Layer3-92 TCP ACK generation [RFC 1122, RFC 2581] 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 higher-than-expected sequence number (gap) TCP Receiver action Delayed ACK. Wait 200ms (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; usually, buffer data

93. Transport Layer3-93 Sender Aggregation of small pkts r Problem: some applications send tiny segments m Telnet: send character by character – as typed r Substantial overhead: 1B data, 40B header! r Solution? m Idea 1: wait Xsec before sending… what’s good X? m `Nagle’s Algorithm` [usually default] : wait for ack! Upon Nagle_TCP_send(m) –Unsent = Unsent || m; –IF |Unsent|  MSS OR Unacked empty Then TCP_Send(Unsent[1..MSS]); // as before… Can be still too slow, if using delayed ack, no response –Use TCP socket `NO_Delay` option to disable Nagle

94. Transport Layer3-94 TCP sender events: On TCP_Send(m): r segment= m seq # is byte-stream number of first data byte in segment r start timer if not already running (think of timer as for oldest unacked segment) timeout: r retransmit segment that caused timeout or all pending r restart timer Ack rcvd: r If acknowledges previously unacked segments m update what is known to be acked m start timer if there are outstanding segments r If repeats last Ack… m Indication of delay m Possibly retransmit m Tell congestion control

95. Transport Layer3-95 Pipelining in TCP: Summary r Cumulative & Delayed Acknowledgements m Ack with seq # n  all bytes up to n received m Send Ack only after receiving 2 MSS or 200msec r Recipient usually buffers out-of-order bytes m As long as they are inside the window m Optional selective-ack mechanism [RFC2018; we ignore] r Sender retransmits m On timeout, or `fast retransmit` (3 dup ack) m Usually: resend only oldest (first) unACKed packet

96. Transport Layer3-96 Rest of Transport Layer… r TCP Overview r TCP Reliability r TCP Flow Control r 3.6 Principles of congestion control r TCP Timeouts r 3.7 TCP congestion control r TCP Fairness

97. Transport Layer3-97 TCP Header: RcvWindow r RcvWindow: m TCP’s flow control m Maximal number of un-acked segments peer can send Source PortDestination Port Sequence Number Acknowledge Number Hdr Len RS V FlagsRcvWindow ChecksumUrgent pointer Options (variable length) Payload (Application Data)

98. Transport Layer3-98 r Problem: application on receiver may be slower than network  no place for incoming data r Flow Control: prevent receiver buffer overflow m By limiting amount of (unacked) segments in transit m Send: RcvWindow = (|buffer|-|used|)/MSS m MSS (Max Segment Size): indicated by initiator at SYN RcvWindow (bytes) TCP Flow Control Receiver Buffer Read by application Received From Net used Ignore segments received out of order

99. Transport Layer3-99 Window Size (1) r Window size is critical for performance m If RcvWindow is too small, performance suffers m Even if network is available, application clears buffers r Example: consider simple network below m Client and server connected by two routers m W = Window size (in bits) m R = Transmission rate of all links m RTT = Round Trip Time (RTT >> MSS/R)

100. Transport Layer3-100 Window Size (2) W/R RTT W/R Ack

101. Transport Layer3-101 W/R RTT W/R Ack Average Rate Average Rate ≤ [R*(W/R)+0*(RTT-W/R)]/RTT = W/RTT Average Rate ≤ [R*(W/R)+0*(RTT-W/R)]/RTT = W/RTT Average Rate ≤ R Average Rate ≤ min(R,W/RTT)

102. Transport Layer3-102 Optimal Receiver Window r Average Rate = min{R, W/RTT} r Flow control is not bottleneck, as long as W  R * RTT r ReceiverBuffer  Bandwidth x Delay r If window too small: slows down connection r Fat links: huge Bandwidth x Delay (e.g. satellite) r Aggressive flow control: send RcvWindow larger than available buffers m By estimating drain rate; risk of buffer overflow m Works well when delay does not change much

103. Transport Layer3-103 TCP Buffers - Critical Resource r TCP Receiver Buffers: critical for performance r But large buffers limit number of connections m 10,000 connections, 10KB each  100 MB m Costs and performance implications m Abused by SYN-flooding DoS attack (Net. Security course) r Servers should minimize open connections m Client should close connection (and wait 30 sec) m Many servers initiate close, but don’t wait 30 sec If Ack is lost, client may timeout (abnormal close)

104. Transport Layer3-104 Large Window… r Requires large buffers at network, recipient m Default, conservative: recipient buffers > window m Aggressive, optimistic flow control: buffers<window (by estimating drain rate; risk of buffer overflow) r Many bytes may be sent into `broken connection` or congested network r Large queues at routers  delay, congestion, loss… not good! r Solution: limit window also by congestion control

105. Transport Layer3-105 Lecture 7 outline r TCP Overview r TCP Flow Control r 3.6 Principles of congestion control r TCP Timeouts r 3.7 TCP congestion control r TCP Fairness

106. Transport Layer3-106 Principles of Congestion Control Congestion: r informally: “too many sources sending too much data too fast for network to handle” m Cf. to flow control (limited by receiver’s buffers) r manifestations: m lost packets (buffer overflow at routers) m long delays (queueing in router buffers) r a top-10 problem! m Main cause for packet loss m Main cause for delay and jitter (changing delay)

107. Transport Layer3-107 Congestion scenario 1: infinite buffers r two senders, two receivers one router  Thruput limit: in-rate, capacity λ out =min(λ in,c/2) r Assume no loss, retransmissions  Congestion: λ in  c/2 m Infinite delays m maximal throughput r What if buffers are finite? unlimited shared output link buffers Host A in : original data Host B out

108. Transport Layer3-108 Congestion scenario 2: finite buffers  one router, finite buffers  λ out =λ in  ' in ≥ in since sender retransmits packet if… m Packet or Ack lost due to buffer overflow (or noise) m Excessive delay: if timeout<|queue| ∙ transmit time + AckTime  c/2 ≥ ' in ≥ ‘ out ≥ out since delivery is only in order, no dups finite shared buffers Host A in : original data Host B out ' in : data+retransmit ‘ out

109. Transport Layer3-109 Congestion scenario 2: finite buffers  one router, finite buffers  λ out =λ in r sender retransmits packet if… m Lost due to buffer overflow (or noise) m Excessive delay (> timeout) r No congestion – queue usually not full  No re-transmission, loss: out = ’ out = ' in = in  Happens if in << C/2 (capacity) – for both senders … r Congestion – queues often/usually full  Packet loss: whenever queue full (i.e., usually…)  ' in ≥ ‘ out  Cannot deliver retransmission, out-of-order  ‘ out > out = in Especially with Go-Back-N ! m Excessive delay (at least |Q|*TransmitTime) m Overhead retransmissions due to loss, time-out

110. Transport Layer3-110 Causes/costs of congestion: scenario 3 r four senders r multihop paths r timeout/retransmit in Q: what happens as and increase ? in finite shared output link buffers Host A in : original data Host B out ' in : original data, plus retransmitted data

111. Transport Layer3-111 Causes/costs of congestion: scenario 3 Another “cost” of congestion: r when packet dropped, any “upstream transmission capacity used for that packet was wasted! r Causes sender to retransmit… vicious cycle! HostAHostA HostBHostB o u t

112. Transport Layer3-112 Approaches towards congestion control End-end congestion control: r no explicit feedback from network r congestion inferred from end-system observed loss, delay r approach taken by TCP Network-assisted congestion control: r routers provide feedback to end systems: m To source, e.g. ICMP Source Quench packet m Or via destination, often piggyback on message; may use flow control r From single `congestion bit` (SNA) to explicit rate (ATM ABR) – in book r Main issue: router efficiency; avoid state Two broad approaches towards congestion control:

113. Transport Layer3-113 Lecture 7 outline r TCP Overview r TCP Timeouts r TCP Flow Control r 3.6 Principles of congestion control r 3.7 TCP congestion control r TCP Fairness

114. Transport Layer3-114 TCP Congestion Control r end-end control (no network assistance) r Assume all senders comply m Protocols must be `TCP friendly` r sender limits transmission: LastByteSent-LastByteAcked  min(CongWin, RcvWin) r Roughly,  CongWin is dynamic, function of perceived congestion How does sender perceive congestion? r loss event = timeout or 3 duplicate acks  Sender reduces rate ( CongWin ) after loss Two modes: m `Slow start` - with exponential build-up m Congestion avoidance (AIMD) rate = CongWin RTT Bytes/sec RTT= Roun d Trip Time

115. Transport Layer3-115 TCP Slow Start  Slow start: When connection begins, CongWin = 1 MSS m Example: MSS = 500 bytes & RTT = 200 msec m initial rate = 20 kbps =(8*500)/0.2 r Available bandwidth may be >> MSS/RTT m Need to increase congestion window (and rate) m By how much? Rapid, exponential build-up m Until we detect possible congestion (by loss)… MSS=Maximal Segment Size

116. Transport Layer3-116 TCP Slow Start r Exponential rate build- up until first loss event:  double CongWin every RTT  by incrementing CongWin for every ACK received  Summary: initial rate is slow ( CongWin = 1MSS) but ramps up rapidly r Loss: Change to Congestion Avoidance (AIMD)… Host A one segment RTT Host B time two segments four segments

117. Transport Layer3-117 TCP Congestion Avoidance (AIMD: Additive Increase, Multiplicative Decrease) Multiplicative Decrease: cut CongWin in half after 3 duplicate Acks (of possibly lost packet) [TimeOut: see later…] Additive Increase: increase CongWin by 1 MSS every RTT in the absence of loss events Long-lived TCP connection

118. Transport Layer3-118 Response to TimeOut vs. 3dupACKs r After 3 dup ACKs:  CongWin is cut in half (multiplicative decrease) m window then grows linearly (additive increase) r After Timeout: m Restart connection  CongWin set to 1 MSS; m Exponential build up m Up to a threshold, then grows linearly (AIMD) Duplicate ACK sent if segments received out of order (maybe some lost)  network delivers some segments Timeout happens if no segments get thru  no connection  need drastic response (restart) Restart is like start except threshold… What’s the threshold? Philosophy:

119. Transport Layer3-119 Restart Threshold Restart is like slow start, except exponential ramp-up ends at threshold (not failure), then switch to congestion avoidance (AIMD) Idea: slow-down before reaching rate (CongWin) which (may have) caused congestion Implementation: r Variable Threshold r At loss event, Threshold is set to 1/2 of CongWin just before loss event

120. Transport Layer3-120 Multiplicative Decrease Refinement r In early (series 1, Tahoe) version of TCP, both 3 dup ACKs and timeout caused re-start  CongWin set to 1 MSS; m window grows exponentially m to threshold, then grows linearly r In newer `Series 2` TCP (Reno), response to 3-dup ACKs is more mild: `only` multiplicative decrease 0 2 4 6 8 10 12 14 123456789101112131415 Transmission round congestion window size (segments) Series1Series2 threshold TCP Tahoe TCP Reno TCP Series 2 (Reno) – 3 Dup Acks `only` halves CongWin TCP Series 1 (Tahoe): Restart after 3 Dup Acks

121. Transport Layer3-121 TCP sender congestion control StateEventTCP Sender ActionCommentary Slow Start (SS) InitiallyCongWin=MSS, Threshold=65KB (or other `large` initial value) Slow Start (SS) ACK receipt for previously unacked data CongWin = CongWin + MSS, If (CongWin > Threshold) set state to “Congestion Avoidance” Resulting in a doubling of CongWin every RTT Congestion Avoidance (CA) ACK receipt for previously unacked data CongWin = CongWin+MSS * (MSS/CongWin) Additive increase, resulting in increase of CongWin by 1 MSS every RTT SS or CALoss event detected by triple duplicate ACK Threshold = CongWin/2, CongWin = Threshold, Set state to “Congestion Avoidance” Fast recovery, implementing multiplicative decrease. CongWin will not drop below 1 MSS. SS or CATimeoutThreshold = CongWin/2, CongWin = 1 MSS, Set state to “Slow Start” Enter slow start SS or CADuplicate ACK Increment duplicate ACK count for segment being acked CongWin and Threshold not changed

122. Transport Layer3-122 TCP Round Trip Time and Timeouts Q: how to set TCP timeout value? r longer than RTT m but RTT varies r too short: premature timeout m unnecessary retransmissions r too long: slow reaction to segment loss Q: how to estimate RTT?  SampleRTT : measured time from segment transmission until ACK receipt m ignore retransmissions  SampleRTT will vary, want estimated RTT “smoother”  average several recent measurements, not just current SampleRTT TimeoutInterval = EstimatedRTT + SafetyMargin RTT= Round Trip Time

123. Transport Layer3-123 Difficulties to `measure delay` r Delayed (accumulated) Acks r For retransmitted segments, can’t tell whether acknowledgement is response to original transmission or retransmission m Don’t estimate delay from retransmissions r Network conditions may change suddenly m Yet don’t overreact to impact of burst traffic r Solution applicable to many situations of estimating dynamic quantities!

124. Transport Layer3-124 TCP Round Trip Time and Timeout EstimatedRTT = (1-  )*EstimatedRTT +  *SampleRTT r Exponential weighted moving average r influence of past sample decreases exponentially fast  typical value:  = 0.125 Usually: symmetric, no queuing delay

125. Transport Layer3-125 TCP Timeout: Safety Margin Setting the timeout  EstimtedRTT plus “safety margin”  large variation in EstimatedRTT -> larger safety margin (usually changes in queuing delay) r First: estimate how much SampleRTT deviates from EstimatedRTT: DevRTT = (1-  )*DevRTT +  *|SampleRTT-EstimatedRTT| (typically,  = 0.25) Then set timeout interval: TimeoutInterval = EstimatedRTT + SafetyMargin = EstimatedRTT + 4*DevRTT

126. Transport Layer3-126 Summary: TCP Congestion Control r Initially: no (or: infinite) Threshold  When CongWin is below Threshold, sender in slow-start, rapid accelerate phase, window grows exponentially (every Ack increments CongWin)  When CongWin is above Threshold, sender is in congestion-avoidance phase, window grows linearly.  When a triple duplicate ACK occurs, Threshold set to CongWin/2 and CongWin set to Threshold (multiplicative decrease).  When timeout occurs, Threshold set to CongWin/2 and CongWin is set to 1 MSS (restart)

127. Transport Layer3-127 Lecture 7 outline r TCP Overview r TCP Timeouts r TCP Flow Control r 3.6 Principles of congestion control r 3.7 TCP congestion control r TCP Fairness

128. Transport Layer3-128 Fairness goal: if K TCP sessions share same bottleneck link of bandwidth R, each should have average rate of R/K TCP connection 1 bottleneck router capacity R TCP connection 2 TCP Fairness New (non-TCP) protocols should be `friendly, well behaved` towards TCP…

129. Transport Layer3-129 Why is TCP fair? Two competing sessions: r Additive increase gives slope of 1, as throughout increases r multiplicative decrease decreases throughput proportionally R R Equal bandwidth share line Connection 1 throughput Connection 2 throughput congestion avoidance: additive increase loss: decrease window by factor of 2 A B C D Total bandwidth limit line

130. Transport Layer3-130 Steady state throughput area Whenever the total bandwidth exceeds R, one or both senders identify congestion (by receiving 3 dup acks), and reduces rate by half. R R Equal bandwidth share line Connection 1 throughput Connection 2 throughput Total bandwidth limit line Threshold line

131. Transport Layer3-131 Fairness (more) Fairness and non-TCP r Multimedia apps often do not use TCP m Admission control instead of fairness r May use UDP: m pump audio/video e.g. at constant rate, tolerate packet loss r Or: new transport protocol (e.g. non- standard TCP) r Many research areas: (e.g. TCP friendly) Fairness and parallel TCP connections r App may open many parallel connections r Web browsers do this m Esp. pipelined, non- persistent r Example: link of rate R with 9 connections; m new app asks for 1 TCP connection, gets rate R/10 m new app asks for 9 TCP connections, gets R/2 !

132. Transport Layer3-132 Summary: TCP Services r Reliable Connection management m Setup, teardown r Reliable connection-based communication r Flow control r Congestion control r Fairness r Efficiency improvements: m Pipelining / Window m Fast retransmit m Others…

133. Transport Layer3-133 Chapter 3: Summary r Transport layer services: m Multiplexing, demultiplexing m Reliable data transfer m Flow control m Congestion control m Fairness r In the Internet m UDP m TCP Next: r Application layer: HTTP, SMTP, DNS