End to End Protocols

1. End to End Protocols

2. End to End Protocols • Last week: • basic protocols • Stop & wait (Correct but low performance) • Today: • Window based protocol. • Go Back N • Selective Repeat • TCP protocol. • UDP protocol. • Next week: Flow control & congestion control

3. rdt3.0: Stop-and-Wait Operation • rdt3.0 works, but performance stinks • example: 1 Gbps link, 15 ms e-e prop. delay, 1KB packet: sender receiver first packet bit transmitted, t = 0 last packet bit transmitted, t = L / R first packet bit arrives RTT last packet bit arrives, send ACK ACK arrives, send next packet, t = RTT + L / R

4. rdt3.0 works, but performance stinks example: 1 Gbps link, 15 ms e-e prop. delay, 1KB packet: fraction of time sender busy sending = = 0.00027 Utilization = U = 8kb/pkt T = 8 microsec = 8 microsec transmit 10**9 b/sec 30.016 msec Last week: Performance of rdt3.0 • 1KB pkt every 30 msec -> 33kB/sec thruput over 1 Gbps link • transport protocol limits use of physical resources!

5. Pipelining: sender allows multiple, “in-flight”, yet-to-be-acknowledged pkts range of sequence numbers must be increased buffering at sender and/or receiver Two generic forms of pipelined protocols: go-Back-N, selective repeat Pipelined protocols

6. Go Back N (GBN)

7. Sender: k-bit seq # in pkt header Unbounded seq. num. “window” of up to N, consecutive unack’ed pkts allowed Go-Back-N • ACK(n): ACKs all pkts up to, including seq # n - “cumulative ACK” • may deceive duplicate ACKs (see receiver) • timer for the packet at base • timeout(n): retransmit pkt n and all higher seq # pkts in window

8. GBN: sender extended FSM /*for the packet at the new base*/

9. receiver simple: ACK-only: always send ACK for correctly-received pkt with highest in-order seq # may generate duplicate ACKs need only remember expectedseqnum out-of-order pkt: discard (don’t buffer) -> no receiver buffering! ACK pkt with highest in-order seq # GBN: receiver extended FSM expectedseqnum=expectedseqnum+1

10. GBN inaction window size = 4

11. GBN: Correctness • Claim I (safety): • The receiver outputs the data in the correct order • Proof: unbounded seq. num. QED • Claim I (seqnum): • In the receiver: • Value of expectedseqnum only increases • In the sender: • The received ACK seqnum only increases. • This is why the sender does not need to test getacknum(rcvpkt) when updating variable base!

12. GBN: correctness - liveness • Let: • base=k; expecetdseqnum=m; nextseqnum=n; • Observation: k ≤ m ≤ n • Claim (Liveness): • If k<m then eventually base ≥ m • If (k=m and m<n) then eventually: • receiver outputs data item m • Expectedseqnum ≥ m+1

13. Ack i<k Seq num only increases Ack i<k Ack k impossible impossible Data i<k-N Data k Data i<k-N Not in window with k GBN - Bounding seq. num. Claim: After receiving Data k no Data i<k-N is received. After receiving ACK k no ACK i<k is received. Clearing a FIFO channel: Corollary: Sufficient to use N+1 seq. num.

14. Selective Repeat

15. receiver individually acknowledges all correctly received pkts buffers pkts, as needed, for eventual in-order delivery to upper layer sender only resends pkts for which ACK not received sender timer for each unACKed pkt sender window N consecutive seq #’s again limits seq #s of sent, unACKed pkts sender timer for each unACKed pkt Selective Repeat

16. Selective repeat: sender, receiver windows

17. data from above : if next available seq # in window, send pkt timeout(n): resend pkt n, restart timer ACK(n) in [sendbase,sendbase+N]: mark pkt n as received if n smallest unACKed pkt, advance window base to next unACKed seq # receiver sender Selective repeat pkt n in [rcvbase, rcvbase+N-1] • send ACK(n) • out-of-order: buffer • in-order: deliver (also deliver buffered, in-order pkts), advance window to next not-yet-received pkt pkt n in [rcvbase-N,rcvbase-1] • ACK(n) otherwise: • ignore

18. Selective repeat in action

19. Selective Repeat - Correctness • Infinite seq. Num. • Safety: immediate from the seq. Num. • Liveness: Eventually data and ACKs get through. • Finite Seq. Num. • Idea: Re-use seq. Num. • Use less bits to encode them. • Number of seq. Num.: • At least N. • Needs more!

20. Example: seq #’s: 0, 1, 2, 3 window size=3 receiver sees no difference in two scenarios! Incorrectly Passes duplicate data as new in (a) or Discards in (b) Q: what relationship between seq # size and window size? Selective repeat: dilemma

21. Choosing the window size • Small window size: • idle link (under-utilization). • Large window size: • Buffer space • Delay after loss • Ideal window size (assuming very low loss) • RTT =Round trip time • C = link capacity • window size = RTT * C • What happens with no loss?

22. End to End Protocols: Multiplexing & Demultiplexing

23. Recall: segment - unit of data exchanged between transport layer entities aka TPDU: transport protocol data unit M M M M application transport network application transport network application transport network H n Multiplexing/demultiplexing Demultiplexing: delivering received segments to correct app layer processes receiver P3 P4 application-layer data segment header P1 P2 segment H t M segment

24. multiplexing/demultiplexing: based on sender, receiver port numbers, IP addresses source, dest port #s in each segment recall: well-known port numbers for specific applications Using IP addresses – layer violation. Multiplexing: Multiplexing/demultiplexing gathering data from multiple app processes, enveloping data with header (later used for demultiplexing) 32 bits source port # dest port # other header fields application data (message) TCP/UDP segment format

25. Source IP: C Dest IP: B source port: x dest. port: 80 Source IP: C Dest IP: B source port: y dest. port: 80 Source IP: A Dest IP: B source port: x dest. port: 80 source port:23 dest. port: x source port: x dest. port: 23 Multiplexing/demultiplexing: examples Web client host C server B host A port use: simple telnet app Web server B Web client host A port use: Web server

26. UDP Protocol

27. “no frills,” “bare bones” Internet transport protocol “best effort” service, UDP segments may be: lost delivered out of order to application connectionless: no handshaking between UDP sender, receiver each UDP segment handled independently of others Why is there a UDP? no connection establishment (which can add delay) simple: no connection state at sender, receiver small segment header no congestion control: UDP can blast away as fast as desired UDP: User Datagram Protocol [RFC 768]

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

29. Sender: treat segment contents as sequence of 16-bit integers checksum: addition (1’s complement sum) of segment contents sender puts checksum value into UDP checksum field Receiver: compute checksum of received segment check if computed checksum equals checksum field value: NO - error detected YES - no error detected. UDP checksum Goal: detect “errors” (e.g., flipped bits) in transmitted segment

30. TCP Protocol

31. full duplex data: bi-directional data flow in same connection MSS: maximum segment size connection-oriented: handshaking (exchange of control msgs) init’s sender, receiver state before data exchange flow controlled: sender will not overwhelm receiver point-to-point: one sender, one receiver reliable, in-order byte steam: no “message boundaries” pipelined: TCP congestion and flow control set window size send & receive buffers TCP: OverviewRFCs: 793, 1122, 1323, 2018, 2581

32. 32 bits source port # dest port # sequence number acknowledgement number head len not used rcvr window size U A P R S F checksum ptr urgent data Options (variable length) application data (variable length) TCP segment structure URG: urgent data (generally not used) counting by bytes of data (not segments!) ACK: ACK # valid PSH: push data now (generally not used) # bytes rcvr willing to accept RST, SYN, FIN: connection estab (setup, teardown commands) Internet checksum (as in UDP)

33. Connection Management: Objective Agree on initial sequence numbers a sender will not reuse a seq# before it is sure that all packets with the seq# are purged from the network the network guarantees that a packet too old will be purged from the network: network bounds the life time of each packet To avoid waiting for the seq# to start a session, use a larger seq# space needs connection setup so that the sender tells the receiver initial seq# Agree on other initial parameters 33

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

35. Three Way Handshake (TWH) [Tomlinson 1975] To ensure that the other side does want to send a request Host A Host B REJECT(seq=y) DATA(seq=x+1) SYN(seq=x) ACK(seq=z) SYN(seq=x) ACK(seq=y) accept? ACK(seq=x), SYN(seq=y) ACK(seq=x), SYN(seq=y) no suchrequest reject Host A Host B 35

36. Connection Close Objective of closure handshake: each side can release resource and remove state about the connection I am done. Are you done too? client server init. close release resource? close release resource? I am done too. Goodbye! close release resource? 36

37. TCP: reliable data transfer event: data received from application above simplified sender, assuming • one way data transfer • no flow, congestion control create, send segment wait for event event: timer timeout for segment with seq # y wait for event retransmit segment event: ACK received, with ACK # y ACK processing

38. TCP: reliable data transfer 00sendbase = initial_sequence number 01 nextseqnum = initial_sequence number 02 03 loop (forever) { 04 switch(event) 05 event:data received from application above 06 create TCP segment with sequence number nextseqnum 07 start timer for segment nextseqnum 08 pass segment to IP 09 nextseqnum = nextseqnum + length(data) 10 event:timer timeout for segment with sequence number y 11 retransmit segment with sequence number y 12 compue new timeout interval for segment y 13 restart timer for sequence number y 14 event:ACK received, with ACK field value of y 15 if (y > sendbase) { /* cumulative ACK of all data up to y */ 16 cancel all timers for segments with sequence numbers < y 17 sendbase = y 18 } 19 else { /* a duplicate ACK for already ACKed segment */ 20 increment number of duplicate ACKs received for y 21 if (number of duplicate ACKS received for y == 3) { 22 /* TCP fast retransmit */ 23 resend segment with sequence number y 24 restart timer for segment y 25 } 26 } /* end of loop forever */ Simplified TCP sender

39. 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 send duplicate ACK, indicating seq. # of next expected byte immediate ACK if segment starts at lower end of gap Event in-order segment arrival, no gaps, everything else already ACKed in-order segment arrival, no gaps, one delayed ACK pending out-of-order segment arrival higher-than-expect seq. # gap detected arrival of segment that partially or completely fills gap

40. Host A Host B Seq=92, 8 bytes data ACK=100 timeout X loss Seq=92, 8 bytes data ACK=100 time time lost ACK scenario TCP: retransmission scenarios Host A Host B Seq=92, 8 bytes data Seq=100, 20 bytes data Seq=92 timeout ACK=100 ACK=120 Seq=100 timeout Seq=92, 8 bytes data ACK=120 premature timeout, cumulative ACKs

41. Recall:TCP sender, receiver establish “connection” before exchanging data segments initialize TCP variables: seq. #s buffers, flow control info (e.g. RcvWindow) client: connection initiator server: contacted by client TCP Connection Management

42. Three way handshake: Step 1: client end system sends TCP SYN control segment to server specifies initial seq # Step 2: server end system receives SYN, replies with SYN-ACK control segment ACKs received SYN allocates buffers specifies server-> receiver initial seq. # Step 3:client receives SYN-ACK and replies with ACK (possibly with data). TCP Connection Management (cont.) client server Syn seq=100 SYN_sent SYN-ACK seq=330 ack=100 SYN_rcvd ACK ESTABLISHED ESTABLISHED

43. 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 server close FIN ACK close FIN ACK timed wait closed TCP Connection Management (cont.)

44. Step 3:client receives FIN, replies with ACK. Enters “timed wait” - will respond with ACK to received FINs Step 4:server, receives ACK. Connection closed. Note:with small modification, can handle simultaneous FINs. TCP Connection Management (cont.) client server closing FIN ACK closing FIN ACK timed wait closed closed

45. TCP Connection Management (cont) TCP server lifecycle TCP client lifecycle

46. TCP state transition diagram

47. SYN Seq=100 SYN-ACK Seq=331 Ack=100 SYN-ACK Seq=101 Ack=330 SYN_RCVD Simultaneous open SYN_SENT SYN Seq=330 ESTABLISHED ACK+Data ACK+Data