The low efficiency caused by the high amount of small packets present in the network can be alleviated by means of packet aggregation. There are some situations in which multiplexing a number of small packets into a bigger one is desirable. For example, a number of small packets can be sent together between a pair of machines if they share a common network path. Thus, the traffic profile can be shifted from small to larger packets, reducing the network overhead and the number of packets per second to be managed by intermediaterouters. This presentation describes Simplemux, a protocol able to encapsulate a number of packets belonging to different protocols into a single packet. It includes the "Protocol" field on each multiplexing header, thus allowing the inclusion of a number of packets belonging to different protocols (multiplexed packets) on a packet of another protocol (tunneling protocol). In order to reduce the overhead, the size of the multiplexing headers is kept very low (it may be a single byte when multiplexing small packets).

1. Jose Saldana (jsaldana@unizar.es) Simplemux 2016
Simplemux optimization
(By Tunneling, Compressing and Multiplexing, TCM)
I. Problem statement
II. Scenarios
III. In detail
IV. Achievable savings
V. Related links

2. Problem statement
Small packets in the public Internet
0
10000
20000
30000
40000
50000
60000
70000
0 100 200 300 400 500 600 700 800 900 1000 1100 1200 1300 1400 1500
Numberofpackets
Packet size [bytes]
Packet size histogram Chicago 2015
Source: https://data. caida.org/datasets/passive-2015/equinix-chicago/20150219-130000.UTC/equinix-
chicago.dirA.20150219-125911.UTC.anon.pcap.gz. Only first 200,000 packets used
44% packets are
1440 bytes or more
33% packets
are 60 bytes
or less
Average: 782 bytes

3. Problem statement
Real-time services have increased their popularity (e.g.,
online games, VoIP, etc.)
 Many of them do not use RTP, but bare UDP
 They generate tiny packets (20-40 bytes payload)
 Users are very sensitive to delay

4. Problem statement
Inefficiency of small-packet flows
 High frequency implies:
 Small payloads
 IPv4/UDP/RTP headers: 40 bytes
 IPv6/UDP/RTP headers: 60 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%
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%

5. Problem statement
Inefficiency of small-packet flows in Ethernet
0
100
200
300
400
500
600
700
800
900
1,000
64 264 464 664 864 1064 1264 1464
MaximumThroughput[Mbps]
Frame size [bytes]
Maximum Ethernet Throughput (link speed 1Gbps)
TCP Payload efficiency
Eth payload efficiency
Source: Small Packet Traffic Performance Optimization for 8255x and 8254x Ethernet Controllers,
http://www.intel.com/content/dam/doc/application-note/8255x-8254x-ethernet-controllers-small-packet-traffic-performance-appl-note.pdf
Average: 782 bytes

6. Problem statement
Inefficiency of small-packet flows in Wi-Fi
Source: Model developed by Ginzburg, B.; Kesselman, A., "Performance analysis of A-MPDU and A-MSDU aggregation in IEEE
802.11n," Sarnoff Symposium, 2007 IEEE , vol., no., pp.1,5, April 30 2007-May 2 2007
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
0 250 500 750 1000 1250 1500 1750 2000 2250 2500
Efficiency(datarate/PHYrate)
Packet size [bytes]
Efficiency (PHY rate=54 Mbps)
1 MPDU, UDP
1 MPDU, TCP
Average: 782
bytes

7. Problem statement
So…why not compressing and multiplexing packets in
order to
 save bandwdith
 reduce the amount of packets per second
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%
Four IPv6/UDP/RTP VoIP packets with two samples of 10 bytes
η=80/240=33%
savingOne IPv6 TCMTF Packet multiplexing four two sample packets
η=80/161=49%

8. Native
Simplemux
ingress egress
Common network segment
The basic idea

9. Jose Saldana (jsaldana@unizar.es) Simplemux 2016
Simplemux optimization
(By Tunneling, Compressing and Multiplexing, TCM)
I. Problem statement
II. Scenarios
III. In detail
IV. Achievable savings
V. Related links

10. Simplemux scenarios
Multi-domain scenario
- Network devices optimize flows with the same destination.
- A server in the network of the service provider demultiplexes them.
- Other option: The Internet Router does the multiplexion
ISP
network Internet
ENodeB
Internet Router
(ISP)
BRAS
Network of
the service
provider
Internet Router
(Service provider)
Application
Server 1
DSLAM
aggregation
network
Serving
Gateway
aggregation network
TCM-demux
Application
Server 2
Native
TCM optimized

11. Simplemux scenarios
Single-domain scenario
Network devices multiplex all the real-
time flows going to the Internet Router
Operator
network
Aggregation
network
Aggregation
network
Internet
EnodeB
Internet Router
BRAS
DSLAM
Serving
Gateway

12. Simplemux scenarios
Private solutions (e.g. optimization between two VoIP PBX)
IP network
Central server
Remote desktop
VoIP
VoIP
TCM
TCM Software PBX
Software PBX

13. Simplemux scenarios
IoT scenario
Internet
Satellite link
Data Center 3
IP sensors
Data Center 2
Data Center 1
Satellite
Terminal
Gateway
Satellite
Terminal
Satellite
Terminal

14. Simplemux scenarios
Community network
Internet gateway
Internet
Village with
public Wi-Fi
xDSL router
Without multiplexer
Wi-Fi
Wi-Fi
Wi-Fi
Wi-Fi
Wi-Fi
W
i-Fi
Operator
3G femtocell
Remote village
3G
Operator PoP

15. Jose Saldana (jsaldana@unizar.es) Simplemux 2016
Simplemux optimization
(By Tunneling, Compressing and Multiplexing, TCM)
I. Problem statement
II. Scenarios
III. In detail
IV. Achievable savings
V. Related links

16. Simplemux details
Comparison with other solutions:
TMux [RFC1692] multiplexes a number of TCP segments between the
same pair of machines.
PPPMux [RFC3153] is able to multiplex complete IP packets, using
separators. It requires the use of PPP and L2TP.
Simplemux:
IP
IP TCP payload IP TCP payload
TCP payload TCP payload
TMux TMux
IP IP
IP TCP payload IP TCP payload
TCP payload IP TCP payload
tunnel
L2TP
PPP PPPMux PPPMux
IP IP
IP TCP payload IP TCP payload
TCP payload IP TCP payload
tunnel First Simplemux header Non-first Simplemux header

17. 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
Simplemux details
One posible solution: TCRTP (RFC4170) only considers one option for
VoIP (ECRTP, PPPMux, L2TP)
PPP
PPP Mux
ECRTP
payload
IP
UDP
RTP
...
ECRTP
payload
L2TP
IP

18. Simplemux details
Simplemux: Using three layers
1. Header compression
2. Multiplexing
3. Tunneling
IP IP
No compr. / ROHC / IPHC / ECRTP
Simplemux
UDP
IP
UDP
RTP
payload
UDP
payload
IP

19. IP IP
No compr. / ROHC / IPHC / ECRTP
Simplemux
UDP
IP
UDP
RTP
payload
UDP
payload
IP
Simplemux details
Different traffics: UDP, RTPDifferent header compression algorithms.
The most adequate one can be selected
according to kind of traffic, scenario (loss,
delay), processing capacity, etc.
Simplemux
Different tunneling algorithms.
IP or IP/UDP, or even other
tunneling protocols can be used

20. Simplemux details
Very simple separators (1-3 bytes): two flags, the packet length and the
Protocol Number
First separator:
Non-first separators (may or may not include Protocol Number field):
0
SPB LXT LEN (6 bits)
packet length < 64 bytes
1
SPB LXT LEN (14 bits)
packet length ≥ 64 bytes
Protocol (8 bits)
Protocol (8 bits)
0
LXT LEN (7 bits)
packet length < 128 bytes
1
LXT LEN (15 bits)
packet length ≥ 128 bytes
0
LXT LEN (7 bits)
packet length < 128 bytes
1
LXT LEN (15 bits)
packet length ≥ 128 bytes
Protocol (8 bits)
Protocol (8 bits)
First Simplemux header Non-first Simplemux headers
Tunneling header

21. Simplemux details
An implementation has been built combining (TCM):
 Header Compression: ROHC (https://rohc-lib.org/)
 Multiplexing: Simplemux (https://github.com/TCM-TF/simplemux)
 Tunneling: IPv4 (raw sockets) or UDP
An upper bound for the delay can be set
Processing delay:
Commodity PC (i3): 0.25 ms (N=10 packets)
Low-cost wireless AP (OpenWRT): 3.5 ms (N=10packets)
2700 lines of code

22. Jose Saldana (jsaldana@unizar.es) Simplemux 2016
Simplemux optimization
(By Tunneling, Compressing and Multiplexing, TCM)
I. Problem statement
II. Scenarios
III. In detail
IV. Achievable savings
V. Related links

23. Simplemux savings
5 VoIP calls sharing an Ethernet link (RTP with different codecs)
Jose Saldana, Ignacio Forcen, Julian Fernandez-Navajas, Jose Ruiz-Mas, "Improving Network Efficiency with
Simplemux,'' IEEE CIT 2015, International Conference on Computer and Information Technology, pp. 446-453, 26-28
10%
15%
20%
25%
30%
35%
40%
45%
50%
20 40 60 80 100 120 140 160 180
BWsaving
Multiplexing period [ms]
Bandwidth Saving. 5 RTP calls
GSM
iLBC20ms
iLBC30ms
PCM-A, PCM-U

24. Simplemux savings
VoIP
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 (Elsevier). http://dx.doi.org/10.1016/j.comnet.2012.02.004

25. Simplemux savings
UDP First Person Shooter (Counter Strike)
50 ms
40 ms
30 ms
20 ms
10 ms
0%
5%
10%
15%
20%
25%
30%
35%
2
3
4
5
6
7
8
910
11121314151617181920
multiplexing
periodnumber 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

26. Simplemux savings
0%
10%
20%
30%
40%
50%
60%
Quake 2 Unreal
Tournament
Counter Strike
1
Quake 3 Enemy
Territory
Counter Strike
2
Halo 2 Quake 4
Bandwidth saving IPv4 IPv4 10 ms 5 players
IPv4 10 ms 20 players
IPv4 reached
IPv4 theoretical

27. Simplemux savings
0%
10%
20%
30%
40%
50%
60%
Quake 2 Unreal
Tournament
Counter Strike
1
Quake 3 Enemy
Territory
Counter Strike
2
Halo 2 Quake 4
Bandwidth saving IPv6 IPv6 10 ms 5 players
IPv6 10 ms 20 players
IPv6 reached
IPv6 theoretical

28. Simplemux savings
Packet loss reduction in a saturated 802.11 link:
Link: 802.11ac. 5.56GHz. 9Mbps. Offered traffic (IP level): 15,000 pps * 60 bytes = 7.2
Mbps
Jose Saldana, Ignacio Forcen, Julian Fernandez-Navajas, Jose Ruiz-Mas, "Improving Network Efficiency with
Simplemux,'' IEEE CIT 2015, International Conference on Computer and Information Technology, pp. 446-453, 26-28
0%
10%
20%
30%
40%
50%
60%
70%
80%
native 1 2 3 4 5 10 15 20 25 30
Packetlosspercentage
Number of multiplexed packets
Packet Loss in a Saturated 802.11 Link (60-byte packets)
no ROHC
ROHC

29. Jose Saldana (jsaldana@unizar.es) Simplemux 2016
Simplemux optimization
(By Tunneling, Compressing and Multiplexing, TCM)
I. Problem statement
II. Scenarios
III. In detail
IV. Achievable savings
V. Related links

30. Simplemux related links
 IETF drafts:
 Simplemux. A generic multiplexing protocol
 Tunneling Compressing and Multiplexing (TCM) Traffic Flows. Reference Model
 Delay Limits for Real-Time Services
 Related publications:
 Improving Network Efficiency with Simplemux, IEEE CIT 2015, International Conference on Computer
and Information Technology, pp. 446-453, 26-28 October 2015, Liverpool, UK.
 Emerging Real-time Services: Optimizing Traffic by Smart Cooperation in the Network," IEEE
Communications Magazine, Vol. 51, n. 11, pp 127-136, Nov. 2013.
 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
 Widening the Scope of a Standard: Real Time Flows Tunneling, Compressing and Multiplexing," IEEE
ICC 2012, Workshop on Telecommunications: from Research to Standards, June 10-11, 2012, Ottawa,
Canada.
 Evaluating the Influence of Multiplexing Schemes and Buffer Implementation on Perceived VoIP
Conversation Quality," Computer Networks (Elsevier), Volume 56, Issue 7, Pages 1893-1919, May 2012.
http://dx.doi.org/10.1016/j.comnet.2012.02.004