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

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 110
bytes
0 10 20 30 40 50 60 70
ms

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
Internet
RLOC 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 3
Stub 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 3
Stub 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

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 1
Stub 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 1
Stub 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 1
Stub 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 1
Stub 3
Stub 2
Border routers
1 IP/UDP/LISP header

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

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?
Three IPv4/UDP client-to-server packets of Counter Strike
TCMTF multiplex and compress
multiplex + compress saving
Four IPv4/UDP/RTP VoIP packets with two samples of 10 bytes
Four IPv4/TCP client-to-server packets of World of Warcraft. E[P]=20bytes
TCP ACK without payload
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
BandwidthSaving
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
Bandwidthsaving
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
Bandwidthsaving
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
BandwidthSaving
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
BandwidthSaving
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
BandwidthSaving
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
BandwidthSaving
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
BandwidthSaving
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
BandwidthSaving
period (ms)
Bandwidth Saving. ACKs. IPv4 on IPv4
1000ACK/sec
500ACK/sec
200ACK/sec
100ACK/sec
Additional delay
has to be limited

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

Budapest icc 2013_presentation

Recommended

Recommended

More Related Content

What's hot

What's hot (18)

Viewers also liked

Viewers also liked (20)

Similar to Budapest icc 2013_presentation

Similar to Budapest icc 2013_presentation (20)

More from Jose Saldana

More from Jose Saldana (20)

Recently uploaded

Recently uploaded (20)

Budapest icc 2013_presentation