Widening the Scope of a Standard: Real Time Flows Tunneling, Compressing and Multiplexing

Widening the Scope of a Standard: Real-Time

Flows Tunneling, Compressing and Multiplexing

Jose Saldana 1

Dan Wing 2

Julián Fernández-Navajas 1

José Ruiz-Mas 1

Muthu A.M. Perumal 2

Gonzalo Camarillo 3

1 University of Zaragoza, Spain

2 Cisco Systems

3 Ericsson Research

INDEX

I. Problem statement and current RFC

II. Proposal of a new RFC

III. Improvements which can be achieved

IV. Conclusions

ICC Workshop “From Research to Standards, Ottawa, 10 Jun 2012

New real-time services have increased their

popularity (e.g. online games)

Some of them do not use RTP (bare UDP, or TCP)

They generate tiny packets

The users are very sensitive to delay

Problem Statement


Problem Statement


http://designcult.org/designcult/2010/08/mmo-subscription-charts.html

Problem Statement


Problem Statement

Problem: Supporting infrastructures are critical.

They MUST work 24/7.

Over-provisioning?


Problem: Inefficiency of real-time flows

High frequency implies small payloads

IPv4/UDP/RTP header: 40 bytes

One IPv4/TCP packet 1500 bytes

η=1460/1500=97%

One IPv4/UDP/RTP VoIP packet with two samples of 10 bytes

η=20/60=33%

Problem Statement


Problem: Inefficiency of real-time flows

High frequency implies small payloads

IPv6/UDP/RTP header: 60 bytes

One IPv6/UDP/RTP packet of VoIP with two samples of 10 bytes

η=20/80=25%

One IPv6/TCP packet 1500 bytes

η=1440/1500=96%

Problem Statement


Problem Statement

Ten years ago: Question in the IETF: Can we

improve efficiency when a number of flows share

the same path?

- Does this scenario exist?

- Are the added delays reasonable?


Does this scenario exist?

An enterprise with different offices

A number of calls share a common path: they can

also share the common header

.

.

.

.

.

.

Context Context

IP Network

MUX+COMP DEMUX+DECOMP

Real-Time Tunneling-Compressing-Multiplexing Real-Time

.

.

.

.

.

.

Problem Statement


Are the added delays reasonable?

1 flow

2 flows

3 flows

Problem Statement


IETF’s answer: TCRTP (RFC 4170) 2005: Best

current practice.

Audio/Video Transport (avt) (concluded WG) of

RAI Area: it was designed for RTP

Problem Statement

PPP

PPP Mux

ECRTP

payload

IP

UDP

RTP...

ECRTP

payload

L2TP

IP


TCRTP for IPv4

One IPv4/UDP/RTP VoIP packet with two samples of 10 bytes

η=20/60=33%

Five IPv4/UDP/RTP VoIP packets with two samples of 10 bytes

η=20/60=33%

saving

VoIP

One IPv4 TCMTF Packet multiplexing five two sample packets

η=100/161=62%

40 to 6-8 bytes compression

Problem Statement


TCRTP for IPv6

One IPv6/UDP/RTP packet of VoIP with two samples of 10 bytes

η=20/80=25%

Four IPv4/UDP/RTP VoIP packets with two samples of 10 bytes

η=20/60=33%

saving

VoIP

One IPv4 TCMTF Packet multiplexing four two sample packets

η=100/161=62%

60 to 6-8 bytes compression

Problem Statement


70%

85%

100%

0%

10%

20%

30%

40%

50%

60%

1234567891011121314151617181920

prob. of reduced headerNumber of calls

TCMTF Bandwidth Saving, RTP/UDP/IPv4 voice G.729a, 2 samples per packet

"Evaluating the Influence of Multiplexing Schemes and Buffer Implementation on Perceived VoIP Conversation Quality,"

Computer Networks, May 2012 (Elsevier). http://dx.doi.org/10.1016/j.comnet.2012.02.004

Problem Statement

http://dx.doi.org/10.1016/j.comnet.2012.02.004


Non-RTP scenarios where we can multiplex?

Proxies of a game-provider or access network

Internet café

Satellite link: Reducing pps: Compressing ACKs of

different flows

A group of users of a remote desktop system

(webRTC)

Central

Server

Multiplexer

TCM

TCM

Multiplexer

.

.

. Game

Server

Players

Access

routerMultiplexer

TCM

Multiplexer Multiplexer

TCM

Problem Statement


Wireless access networks, in which bandwidth is

scarce

Players

Game Server

.

.

.

Wireless link

InternetMultiplexerTCM

Wireless link

Wireless link

TCM

TCM

Multiplexer

Multiplexer

Players

Players

Problem Statement


So…why not widen TCRTP’s scope in order to:

Allow other traffics different from RTP

Allow new developed header compression

techniques (ROHC)

Problem Statement

INDEX




IV. Conclusions


TCMTF proposal

Three layers

1. Tunneling

2. Multiplexing

3. Compressing

IP IP IP

No compr. / ROHC / IPHC / ECRTP

PPPMux / Other

GRE / L2TP / Other

IP

Compression layer

Multiplexing layer

Tunneling layer

Real-time traffic

Network Protocol

UDP

RTP

payload

UDPTCP

payloadpayload


Different traffics

RTP

UDP

TCP

IP IP IP


PPPMux / Other

GRE / L2TP / Other

IP

Compression layer

Multiplexing layer

Tunneling layer

Real-time traffic

Network Protocol

UDP

RTP

payload

UDPTCP

payloadpayload

TCMTF proposal


Backwards

compatibility:

TCRTP is this

“branch”

IP IP IP


PPPMux / Other

GRE / L2TP / Other

IP

Compression layer

Multiplexing layer

Tunneling layer

Real-time traffic

Network Protocol

UDP

RTP

payload

UDPTCP

payloadpayload

TCMTF proposal


Different header

compression

algorithms.

The most adequate one

can be selected

according to:

Kind of traffic

Scenario: loss, delay

Processing capacity

Etc.

IP IP IP


PPPMux / Other

GRE / L2TP / Other

IP

Compression layer

Multiplexing layer

Tunneling layer

Real-time traffic

Network Protocol

UDP

RTP

payload

UDPTCP

payloadpayload

TCMTF proposal


Different mux

algorithms

Currently: PPPMux

New developed ones

IP IP IP


PPPMux / Other

GRE / L2TP / Other

IP

Compression layer

Multiplexing layer

Tunneling layer

Real-time traffic

Network Protocol

UDP

RTP

payload

UDPTCP

payloadpayload

TCMTF proposal


Is TCMTF a solution to the problem?

Different tunneling

algorithms

Currently: L2TPv3

GRE

others

IP IP IP


PPPMux / Other

GRE / L2TP / Other

IP

Compression layer

Multiplexing layer

Tunneling layer

Real-time traffic

Network Protocol

UDP

RTP

payload

UDPTCP

payloadpayload


Since inter-packet time is not fixed, we would

need a policy to select the packets to multiplex.

PE

. . .

. . .

. . .

. . .

Native

traffic

Multiplexed

traffic

PE PE T<PE PE

TCMTF proposal

INDEX



III.Improvements which can be achieved

IV. Conclusions


First Person Shooter game (UDP)

MMORPG (TCP)

TCMTF proposal

Seven IPv4/TCP client-to-server packets of World of Warcraft. E[P]=20bytes

One IPv4/TCM packet multiplexing seven client-to-server W. of Warcraft packets

η=20/60=33%

η=120/187=64%

saving

TCP ACKs without payload

Four IPv4/UDP client-to-server packets of Counter Strike

One IPv4/TCM packet multiplexing four client-to-server Counter Strike packets

η=61/89=68%

η=244/293=83%

saving


UDP First Person Shooter

50 ms

40 ms

30 ms

20 ms

10 ms

0%

5%

10%

15%

20%

25%

30%

35%

23

45

67

8910

11121314151617181920

multiplexingperiod

B

W

R

number of players

TCMTF Bandwidth Saving, UDP/IPv4 Counter Strike

First Person Shooters: Can a Smarter Network Save Bandwidth without Annoying the Players?," IEEE Communications

Magazine, vol. 49, no.11, pp. 190-198, November 2011

Improvements

http://diec.unizar.es/~jsaldana/personal/commag_nov_2011_jsaldana.pdf


0%

10%

20%

30%

40%

50%

60%

Quake 2 UnrealTournament

Counter Strike1

Quake 3 EnemyTerritory

Counter Strike2

Halo 2 Quake 4

Bandwidth saving IPv4 IPv4 10 ms 5 players

IPv4 10 ms 20 players

IPv4 reached

IPv4 theoretical

Improvements


0%

10%

20%

30%

40%

50%

60%

Quake 2 UnrealTournament

Counter Strike1

Quake 3 EnemyTerritory

Counter Strike2

Halo 2 Quake 4

Bandwidth saving IPv6 IPv6 10 ms 5 players

IPv6 10 ms 20 players

IPv6 reached

IPv6 theoretical

Improvements


TCP MMORPG (World of Warcraft)

0%

10%

20%

30%

40%

50%

60%

70%

10 20 30 40 50 60 70 80 90 100

BS

period (ms)

Bandwidth Saving, Client-Server, IPv4

100 players

50 players

20 players

10 players

Improvements

"Traffic Optimization for TCP-based Massive Multiplayer Online Games," Proc. International Symposium on

Performance Evaluation of Computer and Telecommunication Systems SPECTS 2012, July 8-11, 2012, Genoa, Italy.

http://diec.unizar.es/~jsaldana/personal/sergei_SPECTS_2012_in_proc.pdf


















Improvements

0%

10%

20%

30%

40%

50%

60%

70%

80%

10 20 30 40 50 60 70 80 90 100

BS

period (ms)

Bandwidth Saving WoW, Client-Server, IPv6

100 players

50 players

20 players

10 players



0

100

200

300

400

500

600

700

800

900

1000

native 10 20 30 40 50 60 70 80 90 100

period (ms)

Packets per second

100 players

50 players

20 players

10 players

Improvements

INDEX




IV.Conclusions


The current standard was designed for RTP

VoIP flows

Last years: new services generating traffic with

similar characteristics have appeared

Existence of scenarios where a number of flows

share a path

Bandwidth and pps savings are significant

Why not thinking on the possibility of

multiplexing and compressing these flows?

Conclusions

Thank you very much

IETF 83, Paris, Mar 2012

Questions

https://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/

Widening the Scope of a Standard: Real Time Flows Tunneling, Compressing and Multiplexing

Education

Transcript of Widening the Scope of a Standard: Real Time Flows Tunneling, Compressing and Multiplexing