11/28/12 The Problem •  Given: Best-effort network in which

advertisement
11/28/12
The Problem
•  Given: Best-effort network in which
–
–
–
–
Packets may be lost arbitrarily
Packets may be reordered arbitrarily
Packet delays are variable (queueing)
Packets may even be duplicated
•  Sender S and receiver R want to communicate reliably
– Application at R wants all data bytes in exactly the same
order that S sent them
– Each byte must be delivered exactly once
6.02 Fall 2012
Lecture #21: Reliable Data Transport
•  These functions are provided by a reliable transport
protocol
•  Redundancy via careful retransmission
•  Sequence numbers & acks
•  Two protocols: stop-and-wait & sliding window
•  Timeouts and round-trip time (RTT) estimation
6.02 Fall 2012
– Application layered above transport protocol
Lecture 21, Slide #1
6.02 Fall 2012
Lecture 21, Slide #2
Proposed Plan
Stop-and-Wait Protocol
Sender
– Each packet includes a sequentially increasing sequence number
– When transmitting, save (xmit time,packet) on un-ACKed list
– When acknowledgement (ACK) is received from the destination
for a particular sequence number, remove the corresponding
entry from un-ACKed list
– Periodically check un-ACKed list for packets sent awhile ago
•  Retransmit, update xmit time in case we have to do it again!
•  “awhile ago”: xmit time < now timeout
•  Receiver
– Send ACK for each received packet, reference sequence number
– Deliver packet payload to application
Receiver
1
RTT
ACK
Lecture 21, Slide #3
R
S
R
Data
1
Data
1
1
X
Data
2
ACK
Timeout
Retransmit
Data
1
ACK
3
ACK
6.02 Fall 2012
X
2
Data
3
Normal behavior
(no losses)
6.02 Fall 2012
S
Data
1
R TT = round-trip time
•  Transmitter
Data
1
1
Data loss +
retransmission
Duplicate
packet reception
Wanted “exactly once”, got “at least once”
Lecture 21, Slide #4
1
11/28/12
Revised Plan
Issues
•  Transmitter
•  Protocol must handle lost packets correctly
– Each packet includes a sequentially increasing sequence number
– When transmitting, save (xmit time,packet) on un-ACKed list
– When acknowledgement (ACK) is received from the destination
for a particular sequence number, remove the corresponding
entry from un-ACKed list
– Periodically check un-ACKed list for packets sent awhile ago
•  Retransmit, update xmit time in case we have to do it again!
•  “awhile ago”: xmit time < now timeout
•  Receiver
– Send ACK for each received packet, reference sequence number
– Deliver packet payload to application in sequence number order
•  By keeping track of next sequence number to be delivered to app, it’s
easy to recognize duplicate packets and not deliver them a second
time.
– Lost data: retransmission will provide missing data
– Lost ACK: retransmission will trigger another ACK from receiver
•  Size of packet buffers
– At transmitter
•  Buffer holds un-ACKed packets
•  Stop transmitting if buffer space an issue
– At receiver
•  Buffer holds packets received out-of-order
•  Stop ACKing if buffer space an issue
•  Choosing timeout value: related to RTT
– Too small: unnecessary retransmissions
– Too large: poor throughput
•  Delivery stalled while waiting for missing packets
6.02 Fall 2012
Lecture 21, Slide #5
6.02 Fall 2012
Throughput of Stop-and-Wait
•  We want to calculate the expected time, T (in seconds)
between successful deliveries of packets. If N data packets
are sent (N large), the time to send them will be N*T, so
Throughput = N/NT = 1/T data packets per second
The Best Case
•  Occurs when RTT is the same for every packet, so
timeout is slightly larger than RTT
L
1
RTT =
RTT
1− L
1− L
(1− L)
Throughput =
RTT
T = RTT +
•  We can’t just assume T = RTT because packets get lost
– E.g.: N links in the round trip between sender and receiver
– If the per-link probability of losing a data/ACK packet is p, then
the probability it’s delivered over the link is (1-p), and thus the
probability it’s delivered over N links is (1-p)N.
–  So the probability a data/ACK packet gets lost is L = 1 – (1-p)N.
•  Now we can write an equation for T in terms of RTT and the
timeout, RTO: T = (1− L)⋅ RTT + L ⋅ ( RTO + T )
= RTT +
6.02 Fall 2012
Lecture 21, Slide #6
•  If bottleneck link can support 100 packets/sec and the RTT
is 100 ms, then, using stop-and-wait, the maximum
throughput is at most only 10 packets/sec.
– Urk! Only 10% utilization
– We need a better reliable transport protocol…
L
RTO
1− L
Lecture 21, Slide #7
6.02 Fall 2012
Lecture 21, Slide #8
2
11/28/12
Idea: Sliding Window Protocol
Sliding Window in Action
window = 1-5
window = 2-6
•  Use a window
SENDER
RECEIVER
–  Allow W packets outstanding (i.e.,
unack’d) in the network at once
(W is called the window size).
–  Overlap transmissions with ACKs
1
2 3 4 5 6
Sndr
a1 a2
•  Sender advances the window by 1 for
each in-sequence ack it receives
– I.e., window slides
– So, idle period reduces
– Pipelining
Rcvr
p1 p2
•  Assume that the window size, W, is
fixed and known
W = 5 in this example
– Later, we will discuss how one might
set it
– W = 3 in the example on the left
6.02 Fall 2012
Lecture 21, Slide #9
Sender1
2
3
4
5
Sliding Window in Action
window = 2-6
window = 3-7
1
6.02 Fall 2012
Sender s window size = 5
TIMEOUT
a1 a2 a3
Rcvr
p1 p2 p3
Window definition: If window is W, then max number of
unacknowledged packets is W
RXMIT
This is a fixed-size sliding window
Lecture 21, Slide #11
6
7
8
9
10
1
1
11
1
12
1
3
13
8
4
14
6.02 Fall 2012
012
2
Receiver
ACKs
1
2
3
4
5
2 3 4 5 6 7
Sndr
6.02 Fall 2012
Lecture 21, Slide #10
XPacket lost
6
7
9
10
1
11
12
13
8
Lecture
Lectu
Lect
L
turre
tu
e 21,
2 Slide #12
3
11/28/12
Data/ACK sequence trace
680
Data/ACK sequence number
Sliding Window Implementation
"trace2-seq"
"trace2-ack"
•  Transmitter
–
–
–
–
Each packet includes a sequentially increasing sequence number
When transmitting, save (xmit time,packet) on un-ACKed list
Transmit packets if len(un-ACKed list) ≤ window size W
When acknowledgement (ACK) is received from the destination
for a particular sequence number, remove the corresponding
entry from un-ACKed list
– Periodically check un-ACKed list for packets sent awhile ago
Window
660
Ks
AC
ta
Da
RTT
640
620
•  Retransmit, update xmit time in case we have to do it again!
•  “awhile ago”: xmit time < now timeout
RTO
600
•  Receiver
ACKs for rxmitted
packets (most probably)
Rxmit
– Send ACK for each received packet, reference sequence number
– Deliver packet payload to application in sequence number order
580
560
800
6.02 Fall 2012
820
840
860
Time (ms)
880
900
Lecture 21, Slide #13
•  Save delivered packets in sequence number order in local buffer
(remove duplicates). Discard incoming packets which have already
been delivered (caused by retransmission due to lost ACK).
•  Keep track of next packet application expects. After each reception,
deliver as many in-order packets as possible.
6.02 Fall 2012
Lecture 21, Slide #14
RTT Measurements
http://nms.csail.mit.edu/papers/index.php?detail=208
Courtesy of the Cooperative Association for Internet Data Analysis. Used with permission.
© Association for Computing Machinery. All rights reserved. This content is excluded from our
Creative Commons license. For more information, see http://ocw.mit.edu/fairuse.
6.02 Fall 2012
Lecture 21, Slide #15
6.02 Fall 2012
Lecture 21, Slide #16
4
11/28/12
RTTs can be highly variable
Ping
latency
mu: 1697.2 ms
stddev: 2346.5 ms
min:155.6 ms
max:12126.6 ms
Data from Verizon Wireless 3G network
mu: 1554.8 ms
stddev: 1563.8 ms
min: 82.5 ms
max: 9912.4 ms
Delay (milliseconds)
AT&T Wireless on iPhone 3G
17
6.02 Fall 2012
Time (s)
Lecture 21, Slide #17
6.02 Fall 2012
CDF of RTT over Verizon Wireless 3G Network
Lecture 21, Slide #18
Estimating RTT from Data
Cumulative probability (CDF)
•  Gather samples of RTT by comparing time when ACK arrives
with time corresponding packet was transmitted
– Sample of random variable with some unknown distribution (not
necessarily Gaussian!)
•  Chebyshev’s inequatility tells us that for a random variable X
with mean µ and finite variance σ2:
Mean > 1.5 seconds
Std dev > 1.5 seconds
2000
6.02 Fall 2012
4000
In this data set,
if we pick a timeout
of 6 seconds, then
P(spurious rxmit) is
about 3%.
6000
P( X − μ ≥ kσ ) ≤
1
k2
– To reduce the chance of a spurious (i.e., unnecessary)
retransmission – packet wasn’t lost, just the round trip time for
packet/ACK was long – we want our timeout to be greater than
most observed RTTs
– So choose a k that makes the chances small…
– We need an estimate for µ and σ
RTT value (ms)
Lecture 21, Slide #19
6.02 Fall 2012
Lecture 21, Slide #20
5
11/28/12
Exponential Weighted Moving Average (EWMA)
[A low-pass filter – see frequency response]
Response to One Long RTT Sample
srtt ← α*rtt_sample + (1-α)*srtt
|H|
α decreases
α = 0.5
α = 0.1
Responds too quickly?
Ω
6.02 Fall 2012
Lecture 21, Slide #21
6.02 Fall 2012
RTT changes from 1 to 2
Lecture 21, Slide #22
Timeout Algorithm
•  EWMA for smoothed RTT (srtt)
– srtt *rtt_sample + (1-)*srtt
– Typically 0.1 ≤ ≤ 0.25 on networks prone to congestion.
TCP uses =0.125.
•  Use another EWMA for smoothed RTT deviation (srttdev)
– Mean linear deviation easy to compute (but could also do std
deviation)
– dev_sample = |rtt_sample – srtt|
– srttdev *dev_sample + (1-)*srttdev
TCP uses = 0.25
•  Retransmit Timeout, RTO
α = 0.1
α = 0.5
Doesn’t respond quickly enough?
6.02 Fall 2012
Lecture 21, Slide #23
–
–
–
–
6.02 Fall 2012
RTO = srtt + k·srttdev
k = 4 for TCP
Makes the tail probability of a spurious retransmission low
On successive retransmission failures, double RTO
(exponential backoff)
Lecture 21, Slide #24
6
MIT OpenCourseWare
http://ocw.mit.edu
6.02 Introduction to EECS II: Digital Communication Systems
Fall 2012
For information about citing these materials or our Terms of Use, visit: http://ocw.mit.edu/terms.
Download