Budapest icc 2013_presentation

Enhancing Throughput Efficiency

via Multiplexing and Header

Compression over LISP Tunnels

Second IEEE Workshop on Telecommunication Standards: From Research to Standards

IEEE ICC 2013, Budapest, Hungary, 9th of June 2013

Jose Saldana

Julián Fernández-Navajas

José Ruiz-Mas

Luigi Iannone Diego R. Lopez

Enhancing Throughput Efficiency with LISP. Budapest Jun 9th 2013

Index

1. Introduction

2. Context and Scenarios of Application

3. Multiplexing/Compression Signaling

4. Expected Bandwidth Savings

5. Conclusions and Future Work


Index

1. Introduction





Introduction


Emerging real-time services

High interactivity requirements

Delay is important, so frequent information

updates are needed

Introduction


Emerging real-time services

High rates (10 to 50 pps)

Small packets (some tens of bytes)

Low efficiency

Packet size and inter-packet time for Counter Strike 1

40 50 60 70 80 90 100 110bytes

0 10 20 30 40 50 60 70ms

Introduction


TCMTF (Tunneling Compressed Multiplexed

Traffic Flows) is a proposal for improving the

efficiency of these flows by:

Header compression

Multiplexing

Tunneling

Status: IETF draft

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

Introduction


TCMTF optimization example

One IPv4/TCP packet 1500 bytes

η=1460/1500=97%

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

η=100/300=33%

savingOne IPv4 TCMTF Packet multiplexing five two sample packets

η=100/161=62%

Introduction


2006: The IAB (Internet Architecture Board)

felt the need for new architectures able to

overcome the scalability of the routing system

LISP: Locator/ID Separation Protocol, is an

architecture designed to this aim

Getting a growing interest from the Industry

Introduction


LISP distinguishes two address spaces:

Routing Locator (RLOC): border routers

Endpoint Identifiers (EID): hosts inside stub

networks

InternetRLOC Address Space

Stub 1

Stub 2

Border routers

EID 1

EID 2

EID 3

EID Address

Space

Stub 3

EID 1

EID 2

EID 2

EID 1

EID Address

Space

EID Address

SpaceRLOC RLOC

RLOC

Introduction


A stub network only routes packets to and

from itself

Internet

Stub 1

Stub 2

Border routers

EID 1

EID 2

EID 3Stub 3

EID 1

EID 2

EID 2

EID 1

Introduction


A stub network only routes packets to and

from itself

Border routers do a “map and encap” process

when sending a packet to other stub network

Internet

Stub 1

Stub 2

Border routers

EID 1

EID 2

EID 3Stub 3

EID 1

EID 2

EID 2

EID 1

Introduction


A tunnel is necessary between stub networks

One IPv4/TCP packet 1500 bytes

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

IP RLOC

20 bytes UDP

8 bytes

LISP

8 bytes

IP stub+UDP+RTP

40 bytes

VoIP: 76 header bytes

for 20 bytes payload

In a MTU-sized packet the extra

overhead is not significant


Index

1. Introduction





Scenarios of application


Services generating high rates of small packets:

VoIP

Multiplexing schemes exist (RFC4170)

First Person Shooter games

MMORPG games

ACKs traveling to:

Content Delivery Networks

TCP-based video streaming web



Can we find simultaneous flows between the

same pair of stub networks?

Internet

RLOC Address Space

Stub 1Stub 3

Stub 2

Border routers

Web server

aggregation network of

a network operator



Can we find simultaneous flows between the

same pair of stub networks?

Internet

RLOC Address Space

Stub 1Stub 3

Stub 2

Border routers

Company headquarters

Office in a country



Let’s group packets in the border router, in

order to share the overhead of the tunnel

Internet

RLOC Address Space

Stub 1Stub 3

Stub 2

Border routers

4 IP/UDP/LISP headers



Let’s group packets in the border router, in

order to share the overhead of the tunnel

Internet

RLOC Address Space

Stub 1Stub 3

Stub 2

Border routers

1 IP/UDP/LISP header


Index

1. Introduction





Multiplexing/Compression Signaling


We have to negotiate different parameters between

mux and demux

Maximum added delay

Header compression scheme

LISP signalling for EID-RLOC mappings can be used

for this aim

Able to carry meta-information

Which flows can be multiplexed, based on (e.g.),

IP addresses

ToS

application

Multiplexing/Compression Signaling


Standard format for signalling

Start or adapt multiplexing on demand, depending

on network traffic status


Index

1. Introduction





Expected Bandwidth Savings


Let’s multiplex packets, avoiding LISP headers

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

TCMTF multiplex

multiplex saving

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

multiplex saving

TCMTF multiplex

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

TCP ACK without payload

TCMTF multiplex

multiplex saving

Five IPv4/TCP ACKs

TCMTF multiplex

multiplex saving



What if the router also compresses headers?


TCMTF multiplex and compressmultiplex + compress saving


TCMTF multiplex and compress


multiplex + compress saving



multiplex saving

TCMTF multiplex

TCMTF multiplex

multiplex saving


TCMTF multiplex

multiplex saving



What if the router also compresses headers?


TCMTF multiplex and compressmultiplex + compress saving







multiplex saving

TCMTF multiplex

TCMTF multiplex

multiplex saving


TCMTF multiplex

multiplex saving



Asymptotic savings for each service

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

VoIP FPS MMORPG ACKs

Ba

nd

wid

th S

avin

g

Bandwidth Saving IPv4 on IPv4

IPv6 on IPv4

IPv4 on IPv6

IPv6 on IPv6

No header

compression

UDP/RTP

UDP

TCP



VoIP G.729a

0%

10%

20%

30%

40%

50%

60%

70%

80%

0 5 10 15 20 25 30 35 40 45 50

Ban

dw

idth

savin

g

Number of VoIP flows

Bandwidth saving, VoIP, G729a, 2 samples per packet

IPv4 on IPv4 only Mux

IPv4 on IPv4 Mux + compr

IPv4 on IPv6 Only Mux

IPv4 on IPv6 Mux + Compr



VoIP G.729a

0%

10%

20%

30%

40%

50%

60%

70%

80%

0 5 10 15 20 25 30 35 40 45 50

Ban

dw

idth

savin

g

Number of VoIP flows

Bandwidth saving, VoIP, G729a, 2 samples per packet

IPv4 on IPv4 only Mux

IPv4 on IPv4 Mux + compr

IPv4 on IPv6 Only Mux

IPv4 on IPv6 Mux + Compr

No header

compression

One packet

from each flow



First Person Shooter game (Counter Strike 1)

0%

10%

20%

30%

40%

50%

60%

70%

80%

5 10 15 20 25 30 35 40 45 50

Ba

nd

wid

th S

avin

g

period (ms)

Bandwidth Saving. FPS Game. IPv4 on IPv4

20 players 20 players, no compr






First Person Shooter game (Counter Strike 1)

0%

10%

20%

30%

40%

50%

60%

70%

80%

5 10 15 20 25 30 35 40 45 50

Ba

nd

wid

th S

avin

g

period (ms)

Bandwidth Saving. FPS Game. IPv4 on IPv4





Additional delay

is half the period



MMORPG (World of Warcraft)

0%

10%

20%

30%

40%

50%

60%

70%

80%

10 20 30 40 50 60 70 80 90 100

Ba

nd

wid

th S

avin

g

period (ms)

Bandwidth Saving. MMORPG Game. IPv4 on IPv4

100 players 100 pl, no compr






MMORPG (World of Warcraft)

0%

10%

20%

30%

40%

50%

60%

70%

80%

10 20 30 40 50 60 70 80 90 100

Ba

nd

wid

th S

avin

g

period (ms)

Bandwidth Saving. MMORPG Game. IPv4 on IPv4





56% of the

packets are ACKs



ACKs between stub networks (no compress)

0%

10%

20%

30%

40%

50%

60%

70%

80%

5 10 15 20 25 30 35 40 45 50

Ba

nd

wid

th S

avin

g

period (ms)

Bandwidth Saving. ACKs. IPv4 on IPv4

1000ACK/sec

500ACK/sec

200ACK/sec

100ACK/sec



ACKs between stub networks (no compress)

0%

10%

20%

30%

40%

50%

60%

70%

80%

5 10 15 20 25 30 35 40 45 50

Ba

nd

wid

th S

avin

g

period (ms)

Bandwidth Saving. ACKs. IPv4 on IPv4

1000ACK/sec

500ACK/sec

200ACK/sec

100ACK/sec

Additional delay

has to be limited


Index

1. Introduction





Conclusions and Future Work


Possibility of using TCMTF multiplexing and

compressing in LISP: mutual benefit

Ability of LISP signaling for negotiating

TCMTF parameters

Throughput can be highly improved by packet

grouping

Additional savings by means of compression

Depending on the capacity of the router

Future: TCMTF-able LISP border routers

Thank you very much!

Jose Saldana

Julián Fernández-Navajas

José Ruiz-Mas

Luigi Iannone Diego R. Lopez

Technology

Budapest icc 2013_presentation