9: pipelined protocols and rtt

9: Pipelined Protocols and RTT

Transport Layer 3-1

Slides adapted from:J.F Kurose and K.W. Ross, 1996-2010

3: Transport Layer 3a-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


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

Transport Layer 3-4

rdt3.0: stop-and-wait operation

first packet bit transmitted, t = 0

sender receiver

RTT

last packet bit transmitted, t = L / R

first packet bit arriveslast packet bit arrives, send ACK

ACK arrives, send next packet, t = RTT + L / R

U sender

= .008

30.008 = 0.00027

microseconds

L / R

RTT + L / R =


How bad is Stop and Wait? Depends on network conditions example: 1 Gbps link, 15 ms end-to-end prop.

delay, 1KB packet:

Ttransmit=1kb/pkt

10**9 b/sec= 1 microsec

Utilization = U = =1 microsec

30.001 msecUtilization 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

Transport Layer 3-6

Pipelining: increased utilization

first packet bit transmitted, t = 0

sender receiver

RTT

last bit transmitted, t = L / R

first packet bit arriveslast packet bit arrives, send ACK

ACK arrives, send next packet, t = RTT + L / R

last bit of 2nd packet arrives, send ACKlast bit of 3rd packet arrives, send ACK

U sender

= .024

30.008 = 0.0008

microseconds

3 * L / R

RTT + L / R =

Increase utilizationby a factor of 3 with

window size of 3


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

Transport Layer 3-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 3-9

Go-Back-NSender: 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 3-10

GBN: sender extended FSM

Wait start_timer //resend all packets in windowudt_send(sndpkt[base])udt_send(sndpkt[base+1])…udt_send(sndpkt[nextseqnum-1])

timeout

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

base = getacknum(rcvpkt)+1 //cummulative ackIf (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

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)

base=1nextseqnum=1

rdt_rcv(rcvpkt) && corrupt(rcvpkt)

/*don’t do anything if receiver feedback corrupt */


GBN: receiver extended FSM

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 #

Wait

udt_send(sndpkt)

default

rdt_rcv(rcvpkt) && notcurrupt(rcvpkt) && hasseqnum(rcvpkt,expectedseqnum)

extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(expectedseqnum,ACK,chksum)udt_send(sndpkt)expectedseqnum++

expectedseqnum=1sndpkt = make_pkt(expectedseqnum,ACK,chksum)


GBN inaction

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


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


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


Selective repeat: sender, receiver windows


Selective repeat

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 #

senderpkt 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

receiver


Selective repeat in actionLoss of one pkt causes retransmission of just that pkt


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


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


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


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…


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

9: pipelined protocols and rtt

Documents

rfirst packet

n unacked packets

transport layer3a

rtttransport layer3

timetransport layer3

unacked packetwhen timer

retransmit pkt n

oldest unacked packetif