Reliable Data Transfer 1 Transport Layer Goals Overview

Reliable Data Transfer 1

Transport Layer Goals: Overview: r understand principles r transport layer services behind transport layer services: m m multiplexing/demultiplexing reliable data transfer flow control congestion control r instantiation and implementation in the Internet r multiplexing/demultiplexing r connectionless transport: UDP r principles of reliable data transfer r connection-oriented transport: TCP m m m reliable transfer flow control connection management r principles of congestion control r TCP 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 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 Similar issues at data link layer Reliable Data Transfer 3

Transport-layer protocols network data link physical rt m network data link physical po m real-time bandwidth guarantees reliable multicast s an m network data link physical tr unordered unicast or multicast delivery: UDP r services not available: d en d- r unreliable (“best-effort”), en m al m congestion flow control connection setup network data link physical ic m application transport network data link physical g lo Internet transport services: r reliable, in-order unicast delivery (TCP) application transport network data link physical Reliable Data Transfer 4

Principles of Reliable data transfer r important in app. , transport, link layers r Highly important networking topic! r characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt) Reliable Data Transfer 5

Reliable data transfer: getting started 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 packet be dropped r Packet duplication: m Can packets be duplicated. r Reordering of packets m Is channel FIFO? r Internet: Errors, Loss, Duplication, non-FIFO Reliable Data Transfer 7

Specification r Inputs: m sequence of rdt_send(data_ini) r Outputs: 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_outi 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 machines (FSM) to specify sender, receiver state: when in this “state” next state uniquely determined by next event state 1 event causing state transition actions taken on state transition event actions state 2 Reliable Data Transfer 9

Rdt 1. 0: reliable transfer over a reliable channel r underlying channel perfectly reliable m no bit erros, no loss or duplication of packets, FIFO m LIVENESS: a packet sent is eventually received. r separate FSMs for sender, receiver: m sender sends data into underlying channel m receiver read data from underlying channel Reliable Data Transfer 10

Rdt 1. 0: correctness r Safety Claim: m After m rdt_send() : m There exists a k ≤ m such that: • k events: deliver_data(data 1) … deliver_data(datak) • In transit (channel): datak+1 … datam r Proof: m Next event rdt_send(datam+1) • one more packet in the channel m Next event rdt_rcv(datak+1) • one more packet received and delivered. • one less packet in the channel r Liveness: if k < m eventually delivery_data() Reliable Data Transfer 11

Rdt 2. 0: channel with bit errors r underlying channel may flip bits in packet m use checksum to detect bit errors r the question: how to recover from errors: m acknowledgements (ACKs): receiver explicitly tells sender that pkt received OK m negative acknowledgements (NACKs): receiver explicitly tells sender that pkt had errors m sender retransmits pkt on receipt of NACK r new mechanisms in rdt 2. 0 (beyond rdt 1. 0): m m error detection receiver feedback: control msgs (ACK, NACK) rcvr->sender Reliable Data Transfer 12

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

rdt 2. 0: FSM specification sender FSM receiver FSM Reliable Data Transfer 14

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

rdt 2. 0: in action (error scenario) sender FSM receiver FSM Reliable Data Transfer 16

Rdt 2. 0: Typical behavior Typical sequence in sender FSM: “wait for call” rdt_send(data) udt_send(data) “wait for Ack/Nack” udt_send(data). . . udt_send(data) “wait for call” udt_send(NACK) udt_send(ACK) Claim A: There is at most one packet in transit. Reliable Data Transfer 17

rdt 2. 0 (correctness) Theorem : rdt 2. 0 delivers packets reliably over channel uc 2. 0. Sketch of Proof: By induction on the events. Inductive Claim I: If sender in state “wait for call” : all data received (at sender) was delivered (once and in order) to the receiver. Inductive Claim II: If sender in state “wait ACK/NACK” (1) all data received (except maybe current packet) is delivered, and (2) eventually move to state “wait for call”. Reliable Data Transfer 18

Rdt 2. 0 (correctness) r Initially the sender is in “wait for call” m Claim I holds. r Assume rdt_snd(data) occurs: m The sender changes state “wait for Ack/Nack”. m Part 1 of Claim II holds (from Claim I). r In “wait for Ack/ Nack” m sender receives rcvpck = NACK m sender performs udt_send(sndpkt). r If sndpkt is corrupted, m the receiver sends NACK, the sender re-sends. Reliable Data Transfer 19

Rdt 2. 0 (correctness) r Liveness assumption: m Eventually sndpkt is delivered uncorrupted. r The receiver delivers the current data m all data delivered (Claim I holds) m receiver sends Ack. r The sender receives ACK m moves to “wait for call” m Part 2 Claim II holds. r When sender is in “wait for call” m all data was delivered (Claim I holds). Reliable Data Transfer 20

rdt 2. 0 - garbled ACK/NACK What happens if ACK/NACK corrupted? r sender doesn’t know what happened at receiver! r If ACK was corrupt: m m Data was delivered Needs to return to “wait for call” r If NACK was corrupt: m m Data was not delivered. Needs to re-send data. What to do? r Assume it was a NACK - retransmit, but this might cause retransmission of correctly received pkt! Duplicate. r Assume it was an ACK - continue to next data, but this might cause the data to never reach the receiver! Missing. r Solution: sender ACKs/NACKs receiver’s ACK/NACK. What if sender ACK/NACK corrupted? Reliable Data Transfer 21

rdt 2. 0 - garbled ACK/NACK Handling duplicates: r sender adds sequence number to each packet r sender retransmits current packet if ACK/NACK garbled receiver discards (doesn’t deliver up) duplicate packet stop and wait Sender sends one packet, then waits for receiver response Reliable Data Transfer 22

rdt 2. 1: sender, handles garbled ACK/NAKs Reliable Data Transfer 23

rdt 2. 1: receiver, handles garbled ACK/NAKs Reliable Data Transfer 24

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/NACK corrupted r twice as many states m state must “remember” whether “current” pkt has 0 or 1 seq. # Receiver: r must check if received packet is duplicate m state indicates whether 0 or 1 is expected pkt seq # r note: receiver can not know if its last ACK/NACK received OK at sender Reliable Data Transfer 25

Rdt 2. 1: correctness r Claim A: There is at most one packet in transit. r Inductive Claim I: In state wait for call b m all data received (at sender) was delivered r Inductive Claim II: In state wait ACK/NAK b m all data received (except maybe last packet b) was delivered, and m eventually move to state “wait for call [1 -b]”. r Inductive Claim III: In state wait for b below m all data, ACK received (except maybe the last data) m Eventually move to state wait for 1 -b below Reliable Data Transfer 26

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

rdt 3. 0: channels with errors and loss New assumption: underlying channel can also lose packets (data or ACKs) m checksum, seq. #, ACKs, retransmissions will be of help, but not enough Q: how to deal with loss? m m sender waits until certain data or ACK lost, then retransmits feasible? Approach: sender waits “reasonable” amount of time for ACK r retransmits if no ACK received in 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 receiver must specify seq # of pkt being ACKed r requires countdown timer Reliable Data Transfer 28

Channel uc 3. 0 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 29

rdt 3. 0 sender Reliable Data Transfer 30

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 31

rdt 3. 0 in action Reliable Data Transfer 32

rdt 3. 0 in action Reliable Data Transfer 33

Rdt 3. 0: Claims r Claim I: In state “wait call 0” (sender) m all ACK in transit have seq. num. 1 r Claim II: In state “wait for ACK 0” (sender) m ACK in transit have seq. num. 1 m followed by (possibly) ACK with seq. num. 0 r Claim III: In state “wait for 0” (receiver) m packets in transit have seq. num. 1 m followed by (possibly) packets with seq. num. 0 Reliable Data Transfer 34

Rdt 3. 0: Claims r Corollary II: In state “wait for ACK 0” (sender) m when received ACK with seq. num. 0 m only ACK with seq. num. 0 in transit r Corollary III: In state “wait for 0” (receiver) m when received packet with seq. num. 0 m all packets in transit have seq. num. 0 Reliable Data Transfer 35

rdt 3. 0 - correctness rdt_send(data) udt_send(data, seq 0) rdt_rcv(ACK 1) Wait call 0 wait for 0 Wait Ack 0 wait for 0 rdt_rcv(data, seq 1) rdt_rcv(data, seq 0) Wait Ack 0 wait for 1 rdt_rcv(ACK 0) Wait Ack 1 wait for 0 Wait Ack 1 wait for 1 Wait call 1 wait for 1 rdt_send(data) udt_send(data, seq 1) Reliable Data Transfer 36

rdt 3. 0 - correctness Wait Ack 0 wait for 0 rdt_rcv(data, seq 0) All packets in transit have seq. Num. 0 Wait Ack 0 wait for 1 rdt_rcv(ACK 0) All ACK in transit are ACK 0 Wait call 1 wait for 1 Reliable Data Transfer 37

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