Reliable Data Transfer 1 Transport Layer Our goals

Reliable Data Transfer #1

Transport Layer Our goals: r understand principles behind transport layer services: m m Multiplexing / demultiplexing data streams of several applications reliable data transfer flow control congestion control Chapter 6: r rdt principles Chapter 7: r multiplex/ demultiplex r Internet transport layer protocols: m m UDP: connectionless transport TCP: connection-oriented transport • connection setup • data transfer • flow control • congestion control Reliable Data Transfer #2

Transport services and protocols r provide logical communication network data link physical po s an tr rt relies on, enhances, network layer services d en d- m en r al r network data link physical ic r application transport network data link physical g lo r between app’ processes running on different hosts transport protocols run in end systems transport vs network layer services: network layer: data transfer between end systems transport layer: data transfer between processes application transport network data link physical r dataink layer: data transfer between connected NICs m issues similar to those of the transport layer (exc. cong. ctrl) Reliable Data Transfer #3

Internet transport-layer protocols r TCP : reliable, in-order delivery Connection-Oriented m network data link physical po ns rt r services not available (in both protocols): m delay guarantees m bandwidth guarantees network data link physical tra simple extension of “best-effort” IP nd m network data link physical -e Connectionless -to r UDP unreliable, unordered delivery: network data link physical nd le ca m gi m network data link physical lo m connection setup /teardown error correction flow control congestion control application transport network data link physical Reliable Data Transfer application transport network data link physical #4

Reliable data transfer: Setting r highly important networking topic! r here described on the Transport layer r also important in application and link layers r characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt) Reliable Data Transfer #5

Reliable data transfer: dramatis personæ rdt_send(): called from above, (e. g. , by app. ). Passed data to deliver to receiver upper layer send side udt_send(): called by rdt, to transfer packet over unreliable channel to receiver deliver_data(): called by rdt to deliver data to upper receive side rdt_rcv(): called when packet arrives on rcv-side of channel Reliable Data Transfer #6

Unreliable Channel Characteristics r Packet Errors: m packet content modified m Assumption: either no errors or detectable. r Packet loss: m Can packets be lost r Packet duplication: m Can packets be duplicated in channel. r Reordering of packets m Is channel FIFO? r Internet L 3: Error, Loss, Duplication, non-FIFO r PTP Phys. Chan: only Error, Loss possible Reliable Data Transfer #7

Specification r Inputs from application: m sequence of rdt_send(data_ini) r Outputs to destination application: m sequence of deliver_data(data_outj) r Safety: m Assume L deliver_data(data_outj) m For every i L: data_ini = data_outi r Liveness (needs assumptions): m For every i there exists a time T such that data_ini = data_outj Reliable Data Transfer #8

Reliable data transfer: protocol model We’ll: r incrementally develop sender, receiver sides of reliable data transfer protocol (rdt) r consider only unidirectional data transfer m but control info will flow on both directions! r use finite state machine (FSM) notation to specify sender, receiver actions; as follows: event actions state: when in this “state”, next state uniquely determined by next event causing state transition actions taken on state transition state 1 event actions state 2 Reliable Data Transfer #9

Rdt 1. 0: reliable transfer over reliable channel r Assumption : underlying channel perfectly reliable m no bit errors m no loss of packets r separate FSMs for sender, receiver: m sender sends data into underlying channel m receiver reads data from underlying channel & delivers it init Wait for call from above rdt_send( data) packet = make_pkt (data) udt_send (packet) sender Wait for call from below rdt_rcv( packet) extract (packet, data) deliver_data (data) receiver Reliable Data Transfer #10

Rdt 2. 0: channel with bit errors r Assumption : underlying channel may flip bits in packet m but no data packets are lost r add checksum field to detect bit errors r the question: how to recover from errors: m acknowledgements (ACKs) : receiver explicitly tells sender that packet received OK m negative acknowledgements (NAKs) : receiver explicitly tells sender that packet had errors m sender retransmits packet on receipt of NAK r new mechanisms in rdt 2. 0 (beyond rdt 1. 0): m error detection m receiver feedback: control msgs (ACK, NAK) rcvr ->sender m retransmission by sender Reliable Data Transfer #11

uc 2. 0: channel assumptions r Packets are: m Delivered in order (FIFO) m No loss m No duplication r Packets might get corrupt, m and the corruption is detectable. r Liveness assumption: m If continuously sending data packets, udt_send() m eventually, an uncorrupted data packet received. Reliable Data Transfer #12

rdt 2. 0: FSM specification receiver sender init rdt_send (data) sndpkt = make_pkt (data, checksum) udt_send (sndpkt) rdt_rcv (rcvpkt) && is. NAK (rcvpkt) Wait for call from ACK or udt_send (sndpkt) above NAK rdt_rcv (rcvpkt) && is. ACK (rcvpkt) L Notation: Λ = No Action && = AND || = OR New items written in red rdt_rcv (rcvpkt) && corrupt (rcvpkt) init udt_send (NAK) Wait for call from below rdt_rcv (rcvpkt) && notcorrupt (rcvpkt) extract (rcvpkt, data) deliver_data (data) udt_send (ACK) Reliable Data Transfer #13

rdt 2. 0: in action (no errors) L sender FSM receiver FSM Reliable Data Transfer #14

rdt 2. 0: in action (error scenario) L sender FSM receiver FSM Qn: Can you find a problem rdt 2. 0 ? Reliable Data Transfer #15

rdt 2. 0 has a fatal flaw! What happens if ACK/NAK corrupted? r sender doesn’t know what happened at receiver! r must retransmit: BUT: possible duplicate m in rdt 2, 0 receiver can’t identify the duplication r so: must find a way to handle duplicates Handling duplicates: r sender adds a sequence number to each packet r sender retransmits current pkt if ACK/NAK garbled m with same sequence number r receiver discards (doesn’t deliver up) duplicate pkt r rdt 2. 1 stop and wait Sender sends one packet, then waits for receiver response Reliable Data Transfer #16

rdt 2. 1 handles garbled ACK/NAKs : Sender rdt_send (data) init rdt_rcv (rcvpkt) && notcorrupt (rcvpkt) && is. ACK (rcvpkt) sndpkt = make_pkt (0, data, checksum) udt_send (sndpkt) rdt_rcv (rcvpkt) && Wait for call 0 from above rdt_rcv (rcvpkt) && notcorrupt (rcvpkt) && is. ACK (rcvpkt) L rdt_rcv (rcvpkt) && ( corrupt (rcvpkt) || is. NAK (rcvpkt) ) udt_send (sndpkt) Wait for ACK or NAK 0 L Wait for ACK or NAK 1 Wait for call 1 from above rdt_send (data) sndpkt = make_pkt (1, data, checksum) udt_send (sndpkt) Reliable Data Transfer 17#

rdt 2. 1 handles garbled ACK/NAKs: Receiver rdt_rcv (rcvpkt) && notcorrupt (rcvpkt) && has_seq 0 (rcvpkt) init rdt_rcv (rcvpkt) && corrupt (rcvpkt) extract (rcvpkt, data) deliver_data (data) sndpkt = make_pkt (ACK, chksum) udt_send (sndpkt) rdt_rcv (rcvpkt) && corrupt (rcvpkt) sndpkt = make_pkt (NAK, chksum) udt_send (sndpkt) rdt_rcv (rcvpkt) && not corrupt (rcvpkt) && has_seq 1(rcvpkt) sndpkt = make_pkt( NAK, chksum) udt_send (sndpkt) Wait for 0 from below Wait for 1 from below rdt_rcv (rcvpkt) && not corrupt (rcvpkt) && has_seq 0 (rcvpkt) sndpkt = make_pkt (ACK, chksum) udt_send (sndpkt) udt_send( sndpkt) rdt_rcv (rcvpkt) && notcorrupt (rcvpkt) && has_seq 1(rcvpkt) extract (rcvpkt, data) deliver_data (data) sndpkt = make_pkt (ACK, chksum) udt_send (sndpkt) Reliable Data Transfer 18#

rdt 2. 1: discussion Sender: r seq # added to pkt r two seq. #’s (0, 1) will suffice. Why? r must check if received ACK/NAK corrupted r twice as many states Receiver: r must check if received packet is duplicate m state indicates whether 0 or 1 is the expected packet sequence # r Note: receiver can not know if its last ACK/NAK received OK at sender state must “remember” whether “current” pkt has 0 or 1 seq. # Note: we added sequence number to the data packets but NOT to the ACK/NAK; Ack doesn’t say which packet it acknowledges Why is this sufficient? m Reliable Data Transfer 19#

rdt 2. 2: a NACK-free protocol sender FSM r same functionality as rdt 2. 1, using ACKs only init r instead of NACK, receiver sends ACK for last pkt received OK m receiver must explicitly include in ACK the seq # of pkt being ACKed r duplicate ACK at sender results in same action as NACK: retransmit current pkt 0 Note: L 1 Reliable Data Transfer #20

rdt 3. 0: channels with errors and loss New assumption: underlying channel can also lose packets (data or ACKs) Approach: sender waits “reasonable” amount of time for ACK r retransmits if no ACK received in this time checksum, seq. #, ACKs, retransmissions will be of r if pkt (or ACK) just delayed help, but not enough (not lost): m retransmission will be Qn: how to deal with loss? duplicate, but use of seq. Proposal: #’s already handles this m sender waits until it’s m receiver must specify seq certain that data or ACK # of pkt being ACKed is lost, then retransmits r requires countdown timer m Qn: Is this feasible? on the sender side m Reliable Data Transfer #21

rdt 3. 0 assumptions on uc r FIFO: m Data packets and Ack packets are delivered in order. r Errors and Loss: m Data and ACK packets might get corrupt or lost r No duplication: but can handle it! r Liveness: m If continuously sending packets, eventually, an uncorrupted packet received. Reliable Data Transfer #22

rdt 3. 0 sender 0 1 Reliable Data Transfer #23

rdt 3. 0 receiver rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq 0(rcvpkt) rdt_rcv(rcvpkt) && corrupt(rcvpkt) Extract(rcvpkt, data) deliver_data(data) udt_send(ACK[0]) udt_send(ACK[1]) Wait for 0 rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq 1(rcvpkt) udt_send(ACK[1]) rdt_rcv(rcvpkt) && corrupt(rcvpkt) Wait for 1 rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq 1(rcvpkt) Extract(rcvpkt, data) deliver_data(data) udt_send(ACK[1]) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq 0(rcvpkt) udt_send(ACK[0]) Reliable Data Transfer #24

rdt 3. 0 in action Reliable Data Transfer #25

rdt 3. 0 in action Reliable Data Transfer #26

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. 00027 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! Reliable Data Transfer #27

rdt 3. 0: Stop-and-Wait Operation 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 arrives, send next packet, t = RTT + L / R Reliable Data Transfer #28

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 Reliable Data Transfer #29

Pipelining: increased utilization sender receiver first packet bit transmitted, t = 0 last bit transmitted, t = L / R RTT first packet bit arrives last bit of packet arrives, send ACK last bit of 2 nd packet arrives, send ACK last bit of 3 rd packet arrives, send ACK arrives, send next packet, t = RTT + L / R Increase utilization by a factor of 3 (!) 3 = “window size” here Reliable Data Transfer 30#

Go Back N (GBN) Reliable Data Transfer #31

Go-Back-N Sender: r unbounded seq. num, starting at 0 r window size = N : up to N consecutive unack’ed pkts allowed Initialization r Receiver knows when to expect packet 0 r ACK(n): ACKs all pkts up to, including seq # n - “cumulative ACK” may receive duplicate ACKs (see receiver) r timer points to the packet at base r timeout(n): retransmit pkt n and all higher seq # pkts in window m Reliable Data Transfer #32

GBN: extended FSM - sender /*for the packet at the new base*/ Reliable Data Transfer #33

GBN: extended FSM - receiver expectedseqnum = expectedseqnum+1 receiver simple: = highest received seq. num 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 # Reliable Data Transfer #34

GBN in action Start timer 0 window size = 4 Stop timer 0, start timer 1 Stop timer 1, start timer 2 Reliable Data Transfer #35

Selective Repeat Reliable Data Transfer #36

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 individual 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 Reliable Data Transfer #37

Selective repeat: sender, receiver windows Reliable Data Transfer #38

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

Selective repeat in action Reliable Data Transfer #40

Choosing the window size r Small window size: m idle link (under-utilization). r Large window size: m Buffer space m Delay after loss (only with GBN version) r Ideal window size (assuming very low loss) m RTT =Round trip time m C = link capacity [bits/s] m window size = RTT * C [bits/RTT] r Qn: What happens with no loss? Reliable Data Transfer #41

Optional: Correctness Discussion Lecture #42 3

GBN: Correctness r Claim I (safety): m The receiver delivers 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 (in broad sense) m In the sender: • The received ACK seqnum only increases (in broad sense). m This is why the sender does not need to test getacknum(rcvpkt) when updating variable base! Reliable Data Transfer #43

GBN: correctness - liveness r Let: m base=k; expectedseqnum=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 Reliable Data Transfer #44

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. (ass. FIFO) 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 send window with k Corollary: Sufficient to use N+1 seq. num. Reliable Data Transfer #45

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! Reliable Data Transfer #46

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? Reliable Data Transfer #47