Post on 31-Dec-2015
description
transcript
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
3: Transport Layer 3a-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
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 =
3: Transport Layer 3a-5
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
3: Transport Layer 3a-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
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 */
Transport Layer 3-11
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)
Transport Layer 3-12
GBN inaction
Loss of one packets (pkt2) causes retransmission of 4 packets (2-5)
3: Transport Layer 3a-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
Transport Layer 3-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 3-15
Selective repeat: sender, receiver windows
Transport Layer 3-16
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
Transport Layer 3-17
Selective repeat in actionLoss of one pkt causes retransmission of just that pkt
3: Transport Layer 3a-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 3a-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
3: Transport Layer 3a-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 3a-21
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 3a-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