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

2. 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

3. Pipelined protocols
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
3: Transport Layer

4. How bad is Stop and Wait? Depends on network conditions
example: 1 Gbps link, 15 ms end-to-end prop. delay, 1KB packet: T
transmit =
1kb
10**9 b/sec
= 1 microsec
Utilization = U = =
1 microsec
msec
Utilization of the
channel
= 0.003%
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

5. 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
Transport Layer

6. 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
Transport Layer

7. 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

8. Pipelined Protocols 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
Transport Layer

9. Go-Back-N Sender: k-bit seq # in pkt header
“window” of up to N, consecutive unack’ed pkts allowed
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
Transport Layer

10. 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
Wait
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
Transport Layer

11. GBN: receiver extended FSM
default
udt_send(sndpkt)
rdt_rcv(rcvpkt)
&& notcurrupt(rcvpkt)
&& hasseqnum(rcvpkt,expectedseqnum) L
Wait
expectedseqnum=1
sndpkt =
make_pkt(expectedseqnum,ACK,chksum)
extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(expectedseqnum,ACK,chksum)
udt_send(sndpkt)
expectedseqnum++
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 #
Transport Layer

12. GBN in action
Loss of one packet (pkt2) causes retransmission of 4 packets (2-5)
Transport Layer

13. 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

14. Selective Repeat
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
Transport Layer

15. Selective repeat: sender, receiver windows
Transport Layer

16. Selective repeat receiver sender 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 #
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
Transport Layer

17. Selective repeat in action
Loss of one pkt causes retransmission of just that pkt
Transport Layer

18. 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

19. Pipelined protocols 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
This slide could be clearer example of the problem
3: Transport Layer

20. Sequence Number Space
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
3: Transport Layer

21. TCP? We will discuss TCP specifics next… 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

22. 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