Can We Multiplex ACKs without Harming the Performance of TCP?

Can We Multiplex ACKs

without Harming the

Performance of TCP?

CCNC 2014, The 11Th Annual IEEE Consumer Communications & Networking Conference

January 10-13 Las Vegas, Nevada USA

Jose Saldana, Julián Fernández-Navajas, José Ruiz-Mas

Can We Multiplex ACKs without Harming the Performance of TCP? - CCNC 2014

Index

1. Introduction

2. Tests and results

3. Conclusions

Introduction


Increase of emerging real-time services

They use small packets

This is modifying the traffic mix present

on the Internet

Inefficiency of the packets

IPv6 makes the problem even worse

VoIP packets

Introduction


TCRTP (RFC4170) improves the efficiency

of VoIP. It uses three layers:

Header compression

Multiplexing

Tunneling

IP network

MUX DEMUX .

.

.

.

.

.

RTP RTP multiplexing RTP

Introduction


Advantage: Bandwidth and pps savings

At the cost of an additional multiplexing delay

Inter - pkt time

. . .

. . .

Native VoIP

traffic

Optimized

traffic

Inter - pkt time Inter - pkt time

. . .

. . .

. . .

. . .

. . .

. . .

Introduction


TCM-TF*: Proposal for multiplexing other traffic

flows, including UDP (non-RTP) and TCP

*draft-saldana-tsvwg-tcmtf-05

IP IP IP

No compr. / ROHC / IPHC / ECRTP

PPPMux / Other

GRE / L2TP

IP

Compression layer

Multiplexing layer

Tunneling layer

a) TCRTP

Network Protocol

UDP

RTP

payload

UDPTCP

payloadpayload

ECRTP

PPPMux

L2TP

IP

IP

UDP

RTP

payload

b) TCMTF

MPLS

Introduction


TCP video traffic: 69% of all consumer Internet traffic

in 2017.

When downloading a video, a computer may

generate some hundreds of ACKs per second, during

some tens of seconds.

In some scenarios (e.g. the aggregation network of an

operator) high numbers of long-term flows of ACKs

share a common path.

Header compression ratio of ACKs: from 40 to 7 or 8

bytes (savings of 80%).

Introduction


Is it a good idea to compress and multiplex these

flows?

Would the multiplexing delay degrade the

performance of TCP?

Sawtooth-shaped delay

PE

PE time

Added

delay


Index

1. Introduction


3. Conclusions

Tests and Results


Dumbbell scenario in ns2

A sawtooth-shaped delay is added to the ACKs B-B’

What is the effect? We use TCP Tahoe (the most

basic one) in order to more clearly see the effect

First tests: separate A-A’ and B-B’

A

B

N M

A’

B’

O

P ACK mux (PE)

FTP

FTP

ACK

Tests and Results


0

2

4

6

8

10

30 35 40 45 50 55 60Ban

dw

idth

[M

bp

s]

simulated time [s]

Throughput (RTT = 80 ms)

0

2

4

6

8

10

30 35 40 45 50 55 60Ba

nd

wid

th [

Mb

ps]

simulated time [s]

Throughput (RTT = 80 ms, mux period 50 ms)

Tests and Results


0

2

4

6

8

10

30 35 40 45 50 55 60Ban

dw

idth

[M

bp

s]

simulated time [s]

Throughput (RTT = 80 ms)

0

2

4

6

8

10

30 35 40 45 50 55 60Ba

nd

wid

th [

Mb

ps]

simulated time [s]

Throughput (RTT = 80 ms, mux period 50 ms)

avg 9.24 Mbps window reset

every ~7 sec

avg 8.04 Mbps

(12% reduction)

window reset

every ~9,5 sec

ACKs arrive

in bursts

Tests and Results


0

50

100

150

200

250

0 10 20 30 40 50 60 70 80

Win

do

w s

ize

simulation time [s]

Window size

no PE

PE=50ms

Tests and Results


0

20

40

60

80

100

120

140

Win

do

w s

ize

Window evolution. One period

no PE

PE=50ms

Slow start

ends later

Window size

increases

more slowly

The period

between

window

resets

increases

Tests and Results


Second tests: A-A’ and B-B’ share the bottleneck

Are multiplexed flows in clear disadvantage?

We will use four different TCP variants:

Tahoe

Reno

New Reno

SACK

Results: Throughput difference between

multiplexed and non-multiplexed flows

A

B

N M

A’

B’

O

P ACK mux (PE)

FTP

FTP

ACK

Tests and Results




Multiplexing Period PE [ms]

TCP 5 10 15 20 25

Tahoe 4.91 % 10.05 % 31.67 % 7.88 % 49.74 %

Reno 5.95 % 17.78 % 48.62 % 24.29 % 61.92 %

New

Reno 4.82 % 12.95 % 30.52 % 16.70 % 52.87 %

SACK 2.27 % 12.70 % 20.62 % 14.75 % 50.90 %

Tests and Results





TCP 5 10 15 20 25

Tahoe 4.91 % 10.05 % 31.67 % 7.88 % 49.74 %

Reno 5.95 % 17.78 % 48.62 % 24.29 % 61.92 %

New

Reno 4.82 % 12.95 % 30.52 % 16.70 % 52.87 %

SACK 2.27 % 12.70 % 20.62 % 14.75 % 50.90 %

With PE=5 ms

the difference

is small

Tests and Results





TCP 5 10 15 20 25

Tahoe 4.91 % 10.05 % 31.67 % 7.88 % 49.74 %

Reno 5.95 % 17.78 % 48.62 % 24.29 % 61.92 %

New

Reno 4.82 % 12.95 % 30.52 % 16.70 % 52.87 %

SACK 2.27 % 12.70 % 20.62 % 14.75 % 50.90 %

With PE=10 ms

the difference

becomes higher

Tests and Results





TCP 5 10 15 20 25

Tahoe 4.91 % 10.05 % 31.67 % 7.88 % 49.74 %

Reno 5.95 % 17.78 % 48.62 % 24.29 % 61.92 %

New

Reno 4.82 % 12.95 % 30.52 % 16.70 % 52.87 %

SACK 2.27 % 12.70 % 20.62 % 14.75 % 50.90 %

Below 10 ms the

difference may

become

unacceptable

Tests and Results


0

2

4

6

8

10

900 910 920 930 940 950 960 970 980 990 1000

Th

rou

gh

pu

t [M

bp

s]

Simulation time

Throughput (SACK) no PE

PE=5 ms

Tests and Results


0

2

4

6

8

10

900 910 920 930 940 950 960 970 980 990 1000

Th

rou

gh

pu

t [M

bp

s]

Simulation time

Throughput (Reno) no PE

PE=25 ms


Index

1. Introduction


3. Conclusions

Conclusions


Suitability of traffic optimization, based on header

compression and multiplexing, to the flows of ACKs

The expected bandwidth savings are huge because of

the absence of payload

Counterpart: throughput reduction when an

optimized flow shares a bottleneck with a non-

optimized one

The impairments can be maintained in tolerable

limits, by setting an upper bound on the period

Further study this trade-off between bandwidth

saving and throughput reduction

Thank you very much!

Jose Saldana, Julián Fernández-Navajas, José Ruiz-Mas

Can We Multiplex ACKs without Harming the Performance of TCP?

Technology

Transcript of Can We Multiplex ACKs without Harming the Performance of TCP?