Effect of Competing TCP Traffic on Interactive Real-Time - - PowerPoint PPT Presentation

Effect of Competing TCP Traffic on Interactive Real-Time Communication

Ilpo J¨ arvinen∗, Binoy Chemmagate∗, Aaron Yi Ding∗, Laila Daniel∗, Markus Isom¨ aki†, Jouni Korhonen‡, and Markku Kojo∗

∗Department of Computer Science † Nokia ‡Nokia Siemens Networks

University of Helsinki (moved to Renesas Mobile)

March 18, 2013 @ PAM 2013

Outline

1 Introduction 2 Test Arrangements 3 Results 4 Conclusions

March 18, 2013 @ PAM 2013 2

Introduction

Mobile mixed use devices, so called smartphones, have become very common Using Voice over IP (VoIP) in contrast to traditional dedicated voice calls attracts How well interactive VoIP works in presence of competing TCP traffic?

Especially interesting is Web traffic like workload with transients and parallel TCP connections Test the effect of proposed TCP initial window change

March 18, 2013 @ PAM 2013 3

Test Arrangements

Workloads

Emulated interactive audio (CBR, 16kbps payload) alone Emulated interactive audio + bulk TCP connection Emulated interactive audio + emulated Web traffic

Parallel flows used, worst-case assumption

Real HSPA (3.5G) network, fixed server connected over the Internet A few test iterations with wireless issues causing duplicates, reordering, many consecutive losses, and very long delay spikes were rerun With interactive audio content, limited jitter buffer

March 18, 2013 @ PAM 2013 4

TCP Initial Window (IW)

IW specifies the largest burst of segments that can be sent at

• nce when a TCP connection becomes established

Current standard IW is 3 MSS segments (from 2002) IETF proposal to increase TCP IW from 3 to 10 (draft-ietf-tcpm-initcwnd, published soon as Experimental RFC) IW is sent as back-to-back packets, not ACK clocked

Limited congestion control for IW (if SYN loss occurs) More challenging for active queue management (AQM) to respond compared with later TCP phases

Traces suggest larger than IW3 is already being used (e.g., Google, Microsoft)

March 18, 2013 @ PAM 2013 5

Baseline Results with Audio Only

0.2 0.4 0.6 0.8 1 0.02 0.04 0.06 0.08 0.1 CDF One-way delay (s)

Observations One-way delay is good enough for interactive audio conversation Median 18.0 msec Maximum 70.4 msec Very few samples > 40 msec

March 18, 2013 @ PAM 2013 6

Results with Audio + Bulk Data TCP Transfer

0.2 0.4 0.6 0.8 1 1 2 3 4 5 CDF One-way delay (s)

Observations Deep buffering causes delay increase Interactivity is ruined by the excessive delay A few samples in the high end might be due to wireless link problems (but hard to know which)

March 18, 2013 @ PAM 2013 7

Results with Audio + Emulated Web Traffic

0.2 0.4 0.6 0.8 1 0.2 0.4 0.6 0.8 1 CDF Audio flow one-way delay (s) Audio+1 TCP flows, IW=3 Audio+1 TCP flows, IW=10 Audio+2 TCP flows, IW=3 Audio+2 TCP flows, IW=10 Audio+6 TCP flows, IW=3 Audio+6 TCP flows, IW=10

Notes Only samples

• verlapping

with TCP included 1 or 2 TCP flows with IW3 quite ok, 6 flows not so Clearly larger delay with IW10 than IW3

March 18, 2013 @ PAM 2013 8

Jitter Filter and Loss Period Level

Jitter filter “drops” late arriving audio packet

Mimics time-bound playback of media Base delay based on previous 2s prior to TCP flows arrival Not lost physically, only delayed too much to be useful

Loss period level

Loss period level is based on loss periods [RFC3357] the codec encounters due to consecutive packets being “dropped” Value Loss Period Level Description no loss 1 20 ms gap in the stream, no adjacent packet lost 2 40-60 ms of the stream was lost 3 80-100 ms of the stream was lost 4 120-180 ms of the stream was lost 5 200+ ms of the stream was lost

March 18, 2013 @ PAM 2013 9

Loss Rate after Applying Jitter Filter

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 4 m s 6 m s 8 m s 1 m s 1 5 m s 2 m s 4 m s 6 m s 8 m s 1 m s 1 5 m s 2 m s 4 m s 6 m s 8 m s 1 m s 1 5 m s 2 m s 4 m s 6 m s 8 m s 1 m s 1 5 m s 2 m s 4 m s 6 m s 8 m s 1 m s 1 5 m s 2 m s 4 m s 6 m s 8 m s 1 m s 1 5 m s 2 m s Loss rate (median, 25th-75th percentile) Audio+1 short TCP flow Audio+2 short TCP flows Audio+6 short TCP flows IW3 IW10 March 18, 2013 @ PAM 2013 10

Loss Period Level, Audio + Web Traffic, 40 ms Jitter Buf

IW3

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 1.1 1.2 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2 Number of packets (normalized) Time (s) Loss Period Level for Audio with 1 short TCP flow, Jitter Buffer of 40 ms Best - 0 1 2 3 4 Worst - 5

IW10

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 1.1 1.2 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2 Number of packets (normalized) Time (s) Loss Period Level for Audio with 1 short TCP flow, Jitter Buffer of 40 ms Best - 0 1 2 3 4 Worst - 5

IP Packet Delay Variation confirmed that worst delays spikes

• ccurred during initial window

March 18, 2013 @ PAM 2013 11

Conclusions

Packets of the media flow are heavily delayed when competing TCP is present Using parallel TCP flows with IW3 causes significant delay for the media flow Worst effects occur during TCP initial window transmissions

IW10 is much worse than IW3 for the competing media flow

March 18, 2013 @ PAM 2013 12

Backup Slides

March 18, 2013 @ PAM 2013 13

Backup Slides - Paper Figures

Audio+2 TCP flows, IW3

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 1.1 1.2 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2 Number of packets (normalized) Time (s) Loss Period Level for Audio with 2 short TCP flows, Jitter Buffer of 40 ms Best - 0 1 2 3 4 Worst - 5

Audio+6 TCP flows, IW3

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 1.1 1.2 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2 Number of packets (normalized) Time (s) Loss Period Level for Audio with 6 short TCP flows, Jitter Buffer of 40 ms Best - 0 1 2 3 4 Worst - 5

March 18, 2013 @ PAM 2013 14

Backup Slides - Paper Figures

IW3

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 1.1 1.2 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2 Number of packets (normalized) Time (s) 200ms 150ms 100ms 80ms 60ms 40ms

IW10

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 1.1 1.2 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2 Number of packets (normalized) Time (s) 200ms 150ms 100ms 80ms 60ms 40ms

March 18, 2013 @ PAM 2013 15

Loss Period Level, Audio + Web Traffic, 100 ms Jitter Buf

IW3

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 1.1 1.2 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2 Number of packets (normalized) Time (s) Loss Period Level for Audio with 1 short TCP flow, Jitter Buffer of 100 ms Best - 0 1 2 3 4 Worst - 5

IW10

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 1.1 1.2 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2 Number of packets (normalized) Time (s) Loss Period Level for Audio with 1 short TCP flow, Jitter Buffer of 100 ms Best - 0 1 2 3 4 Worst - 5

March 18, 2013 @ PAM 2013 16

Loss Period Level, Audio + Web Traffic, 100 ms Jitter Buf

Audio+2 TCP flows, IW3

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 1.1 1.2 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2 Number of packets (normalized) Time (s) Loss Period Level for Audio with 2 short TCP flows, Jitter Buffer of 100 ms Best - 0 1 2 3 4 Worst - 5

Audio+6 TCP flows, IW3

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 1.1 1.2 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2 Number of packets (normalized) Time (s) Loss Period Level for Audio with 6 short TCP flows, Jitter Buffer of 100 ms Best - 0 1 2 3 4 Worst - 5

March 18, 2013 @ PAM 2013 17