9: Pipelined Protocols and RTT

9: Pipelined Protocols and RTT Slides adapted from: J.F Kurose and K.W. Ross, 1996-2010 Transport Layer

Stop and Wait • Rdt3.0 also called Stop and Wait • Sender sends one packet, then waits for receiver response • What is wrong with stop and wait? • Slow!! Must wait full round trip time between each send • Obvious Fix? • Instead send lots, then stop and wait • Call this a pipelined protocol because many packets in the pipeline at the same time 3: Transport Layer

Pipelining: sender allows multiple, “in-flight” yet-to-be-acknowledged packets range of sequence numbers must be increased to be able to distinguish them all Additional buffering at sender and/or receiver Once allow multiple “in-flight” consider that channel may reorder the packets Pipelined protocols 3: Transport Layer

rdt3.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 ACK arrives, send next packet, t = RTT + L / R TransportLayer

Depends on network conditions example: 1 Gbps link, 15 ms end-to-end prop. delay, 1KB packet: Utilization of the channel = = 0.003% Utilization = U = 1kb/pkt T = 1 microsec = 1 microsec transmit 10**9 b/sec 30.001 msec How bad is Stop and Wait? • 1KB pkt every 30 msec -> 33kB/sec throughput over 1 Gbps link • network protocol limits use of physical resources! • In general, smaller packets, longer RTT and higher maximum bandwidth, all make the situation worse 3: Transport Layer

Pipelining: increased utilization sender receiver first packet bit transmitted, t = 0 last bit transmitted, t = L / R first packet bit arrives RTT last packet bit arrives, send ACK last bit of 2nd packet arrives, send ACK last bit of 3rd packet arrives, send ACK ACK arrives, send next packet, t = RTT + L / R Increase utilization by a factor of 3 with window size of 3 TransportLayer

Filling the pipeline • How much in-flight data is needed to “fill the pipeline”? • Similar to question of how much water needed to fill a pipe (area of crosssection * length of pipe) • For networks, it is bandwidth*delay 3: Transport Layer

Go-back-N: big picture: sender can have up to N unacked packets in pipeline rcvr only sends cumulative acks doesn’t ack packet if there’s a gap sender has timer for oldest unacked packet if timer expires, retransmit all unack’ed packets Selective Repeat: big pic sender can have up to N unack’ed packets in pipeline rcvr sends individual ack for each packet sender maintains timer for each unacked packet when timer expires, retransmit only unack’ed packet Pipelined Protocols TransportLayer

Sender: k-bit seq # in pkt header “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 receive duplicate ACKs (see receiver) • timer for window of packets • timeout(n): retransmit pkt n and all higher seq # pkts in window TransportLayer

Wait GBN: sender extended FSM rdt_send(data) if (nextseqnum < base+N) { sndpkt[nextseqnum] = make_pkt(nextseqnum,data,chksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) //one timer per window start_timer nextseqnum++ } else refuse_data(data) //or just block the caller L base=1 nextseqnum=1 timeout start_timer //resend all packets in window udt_send(sndpkt[base]) udt_send(sndpkt[base+1]) … udt_send(sndpkt[nextseqnum-1]) rdt_rcv(rcvpkt) && corrupt(rcvpkt) /*don’t do anything if receiver feedback corrupt */ rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) base = getacknum(rcvpkt)+1 //cummulative ack If (base == nextseqnum) stop_timer //have acked all outstanding else //send any data this allows us room in window to send start_timer //start timer for remaining base to nextseqnum TransportLayer

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) ->receiver buffering is not required but can help if want to! Re-ACK pkt with highest in-order seq # GBN: receiver extended FSM default udt_send(sndpkt) rdt_rcv(rcvpkt) && notcurrupt(rcvpkt) && hasseqnum(rcvpkt,expectedseqnum) L Wait extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(expectedseqnum,ACK,chksum) udt_send(sndpkt) expectedseqnum++ expectedseqnum=1 sndpkt = make_pkt(expectedseqnum,ACK,chksum) TransportLayer

GBN inaction Loss of one packets (pkt2) causes retransmission of 4 packets (2-5) TransportLayer

Selective Repeat • GBN forces sender to retransmit all packets in window even if some have been correctly received • To avoid that we need a finer granularity of acknowledgement • individual acknowledgements vs cumulative acknowledgements 3: Transport Layer

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, unACK’ed pkts Selective Repeat TransportLayer

Selective repeat: sender, receiver windows TransportLayer

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 TransportLayer

Selective repeat in action Loss of one pkt causes retransmission of just that pkt TransportLayer

Selective Repeat vs GBN • Selective Repeat requires individual acknowledgements rather than chance for cumulative acknowledgements • GBN results in unnecessary retransmission of data correctly received • Sender can choose to buffer out of order and avoid unnecessary retransmission (but not required) – in selective repeat receiver can acknowledge these out of order packets 3: Transport Layer

Sequence Number Dilemma 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) Similar to the problem we saw in stop and wait until we added seq 0 and 1 Pipelined protocols 3: Transport Layer

Q: what relationship between seq # size and window size? A: sequence number space >= 2 * window size True for Stop and Wait (1 <= ½*2) need old and new version of every sequence # Still one problem, packets could conceivably delayed for arbitrarily long in the network so could get an old packet N even after the sequence number space has wrapped around Solution? Not really. In practice, assume a maximum time a packet could live in the network Sequence Number Space 3: Transport Layer

TCP? • TCP is most like GBN • But many TCP implementations will buffer correctly received but out of order segments and senders use duplicate acknowledgments to infer which segment dropped .. This is sort of like Selective Repeat • TCP uses cumulative acknowledgements but counts bytes not packets and receiver ACKS what it wants not last thing it received • Window size is not fixed like N in GBN • TCP allows receiver to set a maximum (dynamically) • Effective window size also changed over time in response to signs of congestion in the network • We will discuss TCP specifics next… 3: Transport Layer

Roadmap • Discussed general principles of reliable message delivery over unreliable channel • Lots of it is common sense (like with our flaky fax machine) • But there is a significant degree of subtlety in getting it right! • We are going to move on to talking specifically about TCP • Flow control? Congestion control? • We have most of the tools we need now: receiver feedback, checksums, sequence numbers, cumulative acknowledgments and retransmission timers 3: Transport Layer

9: Pipelined Protocols and RTT