End to End Protocols 1 End to End

End to End Protocols 1

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

Last week: Performance of rdt 3. 0 r rdt 3. 0 works, but performance stinks r example: 1 Gbps link, 15 ms e-e prop. delay, 1 KB packet: Ttransmit = 8 kb/pkt =8 microsec 10**9 b/sec 8 microsec fraction of time = =0. 00015 Utilization = U = sender busy sending 30. 016 msec m m 1 KB pkt every 30 msec -> 33 k. B/sec thruput over 1 Gbps link transport protocol limits use of physical resources! 3

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

Go Back N (GBN) 5

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

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

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

GBN in action 9

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

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

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. Ack i<k Clearing a FIFO channel: Seq num only Ack k Ack i<k increases impossible Data i<k-N Data k impossible Data i<k-N Not in window with k Corollary: Sufficient to use N+1 seq. num. 12

Selective Repeat 13

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

Selective repeat: sender, receiver windows 15

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

Selective repeat in action 17

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

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

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

End to End Protocols: Multiplexing & Demultiplexing 21

Multiplexing/demultiplexing Recall: segment - unit of data exchanged between transport layer entities m aka TPDU: transport protocol data unit application-layer data segment header segment Ht M Hn segment P 1 M application transport network P 3 Demultiplexing: delivering received segments to correct app layer processes receiver M M application transport network P 4 M P 2 application transport network 22

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

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

UDP Protocol 25

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

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

UDP checksum Goal: detect “errors” (e. g. , flipped bits) in transmitted segment 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 detected m YES - no error detected. 28

TCP Protocol 29

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

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

TCP seq. #’s and ACKs 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: TCP spec doesn’t say - up to implementor Host B Host A User types ‘C’ Seq=4 2, ACK = 79, da ta ata = d , 3 4 K= C 79, A = q e S host ACKs receipt of echoed ‘C’ = ‘C’ host ACKs receipt of ‘C’, echoes back ‘C’ Seq=4 3, ACK =80 simple telnet scenario time 32

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

TCP: reliable data transfer Simplified TCP sender 00 sendbase = 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 */ 34

TCP ACK generation [RFC 1122, RFC 2581] Event TCP Receiver action in-order segment arrival, no gaps, everything else already ACKed delayed ACK. Wait up to 500 ms for next segment. If no next segment, send ACK in-order segment arrival, no gaps, one delayed ACK pending immediately send single cumulative ACK out-of-order segment arrival higher-than-expect seq. # gap detected send duplicate ACK, indicating seq. # of next expected byte arrival of segment that partially or completely fills gap immediate ACK if segment starts at lower end of gap 35

TCP: retransmission scenarios Host A , 8 byt es dat a X ACK =100 loss Seq=9 2 , 8 byt es dat a Seq= 100, 2 tes da ta 0 byte s data 0 10 = K 120 = C K A AC Seq=9 2, 8 by tes da ta 20 100 lost ACK scenario 2, 8 by K=1 AC = ACK time Host B Seq=9 Seq=100 timeout Seq=92 timeout Seq=9 2 timeout Host A Host B time premature timeout, cumulative ACKs 36

TCP Connection Management Recall: TCP sender, receiver establish “connection” before exchanging data segments r initialize TCP variables: m seq. #s m buffers, flow control info (e. g. Rcv. Window) r client: connection initiator r server: contacted by client Three way handshake: Step 1: client end system sends TCP SYN control segment to server m specifies initial seq # Step 2: server end system receives SYN, replies with SYN-ACK control segment m m m ACKs received SYN allocates buffers specifies server-> receiver initial seq. # 37

TCP Connection Management (cont. ) Step 3: client receives SYN- client ACK and replies with ACK (possibly with data). server Syn se q=100 SYN_sent ck= 30 a 100 eq=3 Ks N-AC SY SYN_rcvd ACK ESTABLISHED 38

TCP Connection Management (cont. ) Closing a connection: client closes socket: client. Socket. close(); client close Step 1: client end system close FIN timed wait FIN, replies with ACK. Closes connection, sends FIN ACK sends TCP FIN control segment to server Step 2: server receives server ACK closed 39

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

TCP Connection Management (cont) TCP server lifecycle TCP client lifecycle 41

TCP state transition diagram 42

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