0% found this document useful (0 votes)
56 views

Sliding Window: Handling P Acket Loss

Uploaded by

Peter
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
56 views

Sliding Window: Handling P Acket Loss

Uploaded by

Peter
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 5

12/3/12

Sliding Window: Handling Packet Loss


window = 1-5
window = 2-6

1 2 3 4 5 6
Sndr
a1 a3

x
6.02 Fall 2012
Rcvr
Lecture #22 p1 p3

• Sliding window protocol analysis


•  Bandwidth-delay product & queues
•  Packet loss performance
• Little’s law
6.02 Fall 2012 Lecture 22, Slide #1 6.02 Fall 2012 Lecture 22, Slide #2

Data/ACK sequence trace


Sliding Window: Handling Packet Loss
"trace2-seq"
"trace2-ack"
680
Timeout

Data/ACK sequence number


1 2 3 4 5 6 7 8 9 10 11 12 2
660
Sndr Window
a1 a3 a4 a5 a6 a7 a8 a9 a10 a11 a12 a2
ta
Da
640

RTT Ks
x AC
620
RTO
Rcvr
p1 p3 p4 p5 p6 p7 p8 p9 p10 p11 p12 p2 600
Rxmit ACKs for rxmitted
Data packet 2 is lost. The receiver must save packets all later packets (most probably)
packets until packet 2 arrives, to deliver them to the application in 580
proper order. Note that with our definition of the window, there’s
no limit to the number of packets that might arrive out of order.
560
Q: Can the receiver discard these later packets (3, 4, …, 12?) 800 820 840 860 880 900

Time (ms)
6.02 Fall 2012 Lecture 22, Slide #3 6.02 Fall 2012 Lecture 22, Slide #5

1
12/3/12

Sliding Window Implementation Littles Law


•  Transmitter n(t) = # pkts at time t in queue
–  Each packet includes a sequentially increasing sequence number H
–  When transmitting, save (xmit time,packet) on un-ACKed list
G H
D F G H
–  Transmit packets if len(un-ACKed list) ≤ window size W C D E F G H
–  When acknowledgement (ACK) is received from the destination B C D E F G H
A B C D E F GH
for a particular sequence number, remove the corresponding E F GH
A B C D
entry from un-ACKed list 0 T t
–  Periodically check un-ACKed list for packets sent awhile ago
•  Retransmit, update xmit time in case we have to do it again! •  P packets are forwarded in time T (assume T large)
•  “awhile ago”: xmit time < now  timeout •  Rate =  = P/T
•  Receiver •  Let A = area under the n(t) curve from 0 to T
–  Send ACK for each received packet, reference sequence number •  Mean number of packets in queue = N = A/T
–  Deliver packet payload to application in sequence number order •  A is aggregate delay weighted by each packet’s time in queue.
•  Save delivered packets in sequence number order in local buffer
So, mean delay D per packet = A/P
(remove duplicates). Discard incoming packets which have already
been delivered (caused by retransmission due to lost ACK). •  Therefore, N = D  Little’s Law
•  Keep track of next packet application expects. After each reception, •  For a given link rate, increasing queue size increases delay
deliver as many in-order packets as possible.

6.02 Fall 2012 Lecture 22, Slide #6 6.02 Fall 2012 Lecture 22, Slide #7

How to Set the Window Size to Maximize Throughput? Throughput of Sliding Window Protocol
Apply Little’s Law •  If there are no lost packets, protocol delivers W packets every
RTT seconds, so throughput is W/RTT
Host A Host B •  Goal: to achieve high utilization, select W so that the
•  If we can get Idle to 0, will achieve goal
bottleneck link is never idle due to lack of packets
•  Without packet losses:
•  W = #packets in window
–  Throughput = W/RTTmin if W ≤ B·RTTmin,
•  B = rate of slowest (bottleneck) link in
Time

= B otherwise
packets/second
–  If W > B·RTTmin, then W = B·RTTmin + Q, where Q is the queue
•  RTTmin= Min RTT along path, in the
occupancy
Idle absence of any queueing (in seconds)
•  With packet losses:
–  Pick W > B·RTTmin to ensure bottleneck link is busy even if there
•  If W = B·RTTmin, then path is fully
are packet losses
utilized (if no losses occur)
–  Expected # of transmissions, T, for successful delivery of pkt and
–  B·RTTmin is the bandwidth-delay
ACK satisfies: T = (1-L) ·1 + L·(1 + T), so T = 1/(1L),
product
where L = Prob(either packet OR its ACK is lost)
–  A key concept in the performance of
–  Therefore, throughput = (1L)*B
windowed transport protocols
•  If W >> B·RTTmin, then delays too large, timeout too big, and
other connections may suffer
6.02 Fall 2012 Lecture 22, Slide #8 6.02 Fall 2012 Lecture 22, Slide #9

2
12/3/12

Example Example (cont.)

Q: You would like to roughly


double the throughput of our
sliding window transport protocol.
To do so, you can apply one of the
following techniques:
a.  Double window size W
b.  Halve the propagation delay of
the links
c.  Double the rate of the link
between the Switch and
Q: The sender’s window size is 10 packets. At what
Receiver
approximate rate (in packets per second) will the protocol
deliver a multi-gigabyte file from the sender to the receiver?
Assume that there is no other traffic in the network and Q: For each of the following sender window sizes (in packets),
packets can only be lost because the queues overflow. list which of the above technique(s), if any, can approximately
double the throughput: W=10, W=50, W=30.
A: 10 packets / 21 ms, = 476 packets/second

6.02 Fall 2012 Lecture 22, Slide #10 6.02 Fall 2012 Lecture 22, Slide #11

Solutions to Example RTT Measurements


•  Note that BW-delay product on given path = 20 packets
•  W=10
–  Doubling window size ~doubles throughput (BW-delay product is
20 on path)
–  Halving RTT ~doubles throughput (since now BW-delay product
would be 10, equal to window size)
–  Doubling bottleneck link rate won’t change throughput much!
•  W=50
–  Doubling window size won’t change throughput (we’re already
saturating the bottleneck link)
–  Halving RTT won’t change throughput (same reason)
–  Doubling bottleneck link speed will ~double throughput because
new bw-delay product doubles to 40, and W=50 > 40
•  W=30 (trickiest case)
–  Doubling window size or halving RTT: no effect
–  Doubling bottleneck link changes BW-delay product to 40. W is
Courtesy of the Cooperative Association for Internet Data Analysis. Used with permission.
still lower than 40, so throughput won’t double. But it’ll certainly
increase, by perhaps about 50% more from before
6.02 Fall 2012 Lecture 22, Slide #12 6.02 Fall 2012 Lecture 22, Slide #13

3
12/3/12

AT&T Wireless on iPhone 3G Ping


latency
mu: 1697.2 ms
stddev: 2346.5 ms
min:155.6 ms
max:12126.6 ms

Delay (milliseconds)
http://nms.csail.mit.edu/papers/index.php?detail=208
15 Time (s)
© 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 22, Slide #15
6.02 Fall 2012 Lecture 22, Slide #14

CDF of RTT over Verizon Wireless 3G Network


Cumulative probability (CDF)

Mean > 1.5 seconds


Std dev > 1.5 seconds
In this data set,
if we pick a timeout
of 6 seconds, then
P(spurious rxmit) is
about 3%.

2000 4000 6000 RTT value (ms)

6.02 Fall 2012 Lecture 22, Slide #16

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

You might also like