When small payloads are transmitted through a packet-switched network, the resulting overhead may result significant. This is stressed in the case of LISP, where a number of headers are prepended to a packet, as new headers have to be added to each packet. This presentation proposes to send together a number of small packets, which are in the buffer of a ITR, having the same ETR as destination, into a single packet. Therefore, they will share a single LISP header, and therefore bandwidth savings can be obtained, and a reduction in the overall number of packets sent to the network can be achieved.

1. Header compression and multiplexing in LISP
Jose Saldana, Julián Fernández-Navajas, José Ruiz-Mas {jsaldana, navajas, jruiz}@unizar.es
Proposal: draft-saldana-lisp-compress-mux
This document proposes to send together a number of small LISP
packets into a single one.
They will share a single LISP header, resulting in bandwidth savings and
packet per second reduction.
Header compression can also be applied to the EID headers (ROHC)
It relies on Simplemux: draft-saldana-tsvwg-Simplemux (submitted to
tsvwg). A paper about it: Improving Network Efficiency with Simplemux

2. Internet
RLOC Address Space
Stub 1
Stub 3
Stub 2
Border routers
Header compression and multiplexing in LISP
• Packets are grouped by the border router, in order to share the
overhead of the tunnel
4 IP/UDP/LISP headers

3. Header compression and multiplexing in LISP
• Packets are grouped by 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

4. Two 100 byte payload-UDP packets. No IPSec
IPv4 EID header: 20 bytes
UDP header: 8 bytes Simpleux header: 2 bytes
ROHC header: 4 /8 bytes
Payload
Native vs Multiplex with IPv4 over LISP
IPv4 RLOC header: 20 bytes
LISP header: 8 bytes
Two LISP IPv4/UDP packets with 100 bytes payload
Simplemux with header compression (ROHC)
saving
UDP100bytes
Simplemux separators between the packets
Header compression
Basic multiplexing: sharing a single LISP header
saving
saving

5. IPv4 EID header: 20 bytes
UDP header: 8 bytes Simpleux header: 1-3 bytes
ROHC header: 4-8 bytes
Payload
Native vs Multiplex with IPSec over LISP
IPv4 RLOC header: 20 bytes
LISP header: 8 bytes
Two LISP IPv4/UDP packets with 100 bytes payload
Simplemux with header compression (ROHC)
saving
IPSecTransportmode
UDP100bytes
Simplemux separators between the packets
saving
IPSec
AH+ESP header: 32 bytes
ESP payload
IPsec
IPSec
Two 100 byte payload-UDP packets. IPSec

6. Tests with iPerf and tc
Header compression and multiplexing in LISP

7. iPerf tests
Source
IPerf
xTR xTR Destination
IPerf
MSMR
Virtual Machines and
switches
External switch
tc limit
IPSec
Traffic sent 1,5 Mbps of UDP packets with UDP payload 100 bytes
(saturated link) (128 bytes at IP level)
With LISP tunnel 128 + 36 (LISP) =178 bytes per packet
Traffic limit 1 Mbps at Eth level, using Linux tc
Limit 702 pps => (x100 x8) 576 kbps at application level
Implementation based on lispmob: https://github.com/Simplemux/lispmob-with-simplemux

8. 400
500
600
700
800
900
1000
1 2 3 4 5 6 7 8 9 10
Throughput[kbps]
Number of multiplexed packets
Obtained throughput (application level)
Native
ROHC
Traffic traversing the 1Mbps link. No IPSec
We multiplex a fixed number of packets together. We multiplex based on a multiplexing period.
If we compress headers with ROHC, higher savings are achieved.
400
500
600
700
800
900
1000
0 1 2 3 4 5
Throughput[kbps]
Multiplexing period [ms]
Obtained throughput (application level)
Native
ROHC

9. 400
500
600
700
800
900
1000
1 2 3 4 5 6 7 8 9 10
Throughput[kbps]
Number of multiplexed packets
Obtained throughput (application level)
Native
ROHC
Traffic traversing the 1Mbps link. No IPSec
We multiplex a fixed number of packets together. We multiplex based on a multiplexing period.
If we compress headers with ROHC, higher savings are achieved.
400
500
600
700
800
900
1000
0 1 2 3 4 5
Throughput[kbps]
Multiplexing period [ms]
Obtained throughput (application level)
Native
ROHC
181 bytes
690pps
552 kbps
1346 bytes
92 pps
742 kbps
1100 bytes
113 pps
909 kbps

10. Traffic traversing the 1Mbps link. IPSec is used
We multiplex based on a multiplexing period.
IPSec is running between both xTRs.
The multiplexed bundle goes through the IPSec tunnel.
If we compress headers with ROHC, higher savings are
achieved.
400
500
600
700
800
900
1000
0 1 2 3 4 5
Throughput[kbps]
Multiplexing period [ms]
Obtained throughput (application level, IPSec)
Native
ROHC

11. Backward compatibility
Header compression and multiplexing in LISP

12. Backward compatibility (1)
The "Basic multiplexing method" may probably have some backward
compatibility issues. The draft proposes this (as a preliminary idea):
One of the free bits in the LISP header should be
used to flag the fact that more than a single packet
is included in the encapsulated one.
Two LISP IPv4/UDP packets with 100 bytes payload
Basic multiplexing: sharing a single LISP header
saving

13. Backward compatibility (2)
The Simplemux methoe would also need some tweaks:
In this case, a port number different from 4341
should be used in the UDP header preceding the LISP
header, in order to indicate that the protocol
inside the LISP header is not IP but Simplemux.
Two LISP IPv4/UDP packets with 100 bytes payload
Simplemux separators between the packets
saving