SlideShare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.
SlideShare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.
Successfully reported this slideshow.
Activate your 14 day free trial to unlock unlimited reading.
1.
RTT matters
Matsuzaki ‘maz’ Yoshinobu
<maz@iij.ad.jp>
Internet Initiative Japan Inc. (IIJ/AS2497) 12015/11/10
2.
Round Trip Time (RTT)
RTT
t0
t1
Internet Initiative Japan Inc. (IIJ/AS2497) 22015/11/10
3.
TCP 3 way handshake and RTT
RTT
RTT
Internet Initiative Japan Inc. (IIJ/AS2497) 32015/11/10
4.
TCP and RTT
RTT
window size
= TCP RX buffer
RTT
RTT
Internet Initiative Japan Inc. (IIJ/AS2497) 42015/11/10
5.
packet loss and RTT
RTO
RTO is computed based on RTT -- see rfc6298
retransmission
timeout
Internet Initiative Japan Inc. (IIJ/AS2497) 52015/11/10
6.
RTT
• the lower, the better
– faster TCP handshake
– better TCP throughput
– faster TCP recovery from a packet loss
• There are various efforts to improve TCP
performance even in a high latency situation
Internet Initiative Japan Inc. (IIJ/AS2497) 62015/11/10
7.
Wi-Fi is getting popular
wirelesswired
Internet
server 2
server 1
Internet Initiative Japan Inc. (IIJ/AS2497) 72015/11/10
8.
I faced a trouble
wirelesswired
• RTT was not stable from a wireless client to
the server 2. L
64 bytes time=398.122 ms
64 bytes time=316.330 ms
64 bytes time=337.251 ms
64 bytes time=358.155 ms
64 bytes time=299.480 ms
64 bytes time=387.789 ms
server 2
server 1
Internet Initiative Japan Inc. (IIJ/AS2497) 82015/11/10
9.
let’s try to isolate the problem
wireless
64 bytes time=169.588 ms
64 bytes time=170.666 ms
64 bytes time=169.793 ms
64 bytes time=168.185 ms
64 bytes time=169.783 ms
64 bytes time=169.957 ms
server 1
64 bytes time=3.757 ms
64 bytes time=3.789 ms
64 bytes time=3.768 ms
64 bytes time=3.718 ms
64 bytes time=3.644 ms
64 bytes time=3.762 ms
1) the local wifi network
looks pretty stable
2) RTT to server 1
looks also stable
server 2
Internet Initiative Japan Inc. (IIJ/AS2497) 92015/11/10
10.
hmmm...
wirelesswired
server 2
server 1
Internet Initiative Japan Inc. (IIJ/AS2497) 10
64 bytes time=296.040 ms
64 bytes time=296.105 ms
64 bytes time=296.442 ms
64 bytes time=296.186 ms
64 bytes time=296.103 ms
64 bytes time=296.070 ms
3) from the wired host in the
same network, RTT to the
server 2 looks stable
2015/11/10
11.
so...
wireless
server 1
server 2
wired
• this strange behavior happens only for this
combination L
Internet Initiative Japan Inc. (IIJ/AS2497) 112015/11/10
12.
RTT distribution to server 1
from wired host to server 1 from wifi host to server 1
wired wifi
Internet Initiative Japan Inc. (IIJ/AS2497) 122015/11/10
13.
RTT distribution to server 2
from wired host to server 2 from wifi host to server 2
wired wifi
Internet Initiative Japan Inc. (IIJ/AS2497) 132015/11/10
14.
the wifi AP was buffering packets
wirelesswired
Internet
server 2
server 1
Internet Initiative Japan Inc. (IIJ/AS2497) 14
• and this caused the unstable RTT L
2015/11/10
15.
My wifi adapter does sleep
• to reduce battery usage
• before sleeping, the client send a notification
to the wifi AP, and the AP keeps packets until
the client wake up
• so, my PC was asking the buffering!
Internet Initiative Japan Inc. (IIJ/AS2497) 152015/11/10
16.
wifi AP sends beacon
• beacon interval
– time interval between beacon transmissions
– usually 100msec, but it’s configurable
• TIM (Traffic Indication Map)
– to tell any sleeping clients if the AP has any buffered
frames present for it
• wifi adapter can sleep between beacons, and
wake up to check a beacon (TIM can indicate if
the adapter need to receive data or not)
Internet Initiative Japan Inc. (IIJ/AS2497) 162015/11/10
17.
the scenario
• My wifi adapter went to sleep after 200msec
of no traffic
– that’s why the unstable RTT happens only when I
was communicating with server 2 (average RTT is
300msec)
• Based on the beacon interval information
(which was 100msec in my case), it woke up
and received a response
– that’s why most RTT distribution is within
100msec
Internet Initiative Japan Inc. (IIJ/AS2497) 172015/11/10
18.
sleeping and buffering
Internet Initiative Japan Inc. (IIJ/AS2497) 18
200msec no traffic
goes to sleep until
the next beacon buffered
2015/11/10
19.
Summary
• Strange RTT behavior happens if your communication
is between:
– a host connected to a wifi network and
– a far end host (RTT>200msec)
• Your wifi adapter goes to sleep
– “200msec of no traffic” seems a common trigger
• The sleep duration is manageable by setting beacon
interval of your wifi AP
– 100msec would be reasonable
– You might be able to reduce battery usage by setting it as
1000msec, but this could introduce more RTT penalty
Internet Initiative Japan Inc. (IIJ/AS2497) 192015/11/10