Subject: [tcmtf] Proposal for tunneling, compressing and multiplexing flows

From: "Jose Saldana" <[email-masked]>
Date: Wed, 11 Jul 2012 16:38:16 +0200

In order to get an idea of the main aim of the draft, I re-send this message
explaining the idea of the draft. I have slightly modified some parts.

Best regards,

Jose

Abstract: This document describes a method to improve the bandwidth
utilization  of network paths that carry multiple streams in parallel
between two endpoints, as in voice trunking.  The method combines standard
protocols that provide compression, multiplexing, and tunneling over  a
network path for the purpose of reducing the bandwidth used when multiple
streams are carried over that path.

The main idea is to update TCRTP. This is a "Best current practice" RFC (
<http://datatracker.ietf.org/doc/rfc4170/>
http://datatracker.ietf.org/doc/rfc4170 ) which was developed in Audio/Video
Transport working group in 2005-11. It "describes a method to improve the
bandwidth utilization of RTP streams over network paths that carry multiple
Real-time Transport Protocol (RTP) streams in parallel between two
endpoints, as in voice trunking. The method combines standard protocols that
provide compression, multiplexing, and tunneling over a network path for the
purpose of reducing the bandwidth used when multiple RTP streams are carried
over that path." (from the introduction of RFC4170).

The scheme of TCRTP is:

RTP/UDP

   |

   |         ----------------------------

   |              

 ECRTP             compressing layer

   |                   

   |         ----------------------------

   |

PPPMUX            multiplexing layer

   |

   |         ----------------------------

   |

L2TP              tunneling layer

   |

   |         ----------------------------

   |

  IP

However, there exist many real-time flows that do not use RTP:

- Online "First Person Shooter" (FPS) games use UDP datagrams, and they are
one of the most "real-time" applications nowadays. Some examples: Counter
Strike, Halo, Quake, etc.[1].

- Online "Massively Multiplayer Online Role Playing Games" (MMORPG): They
use TCP, but can be considered "real-time", since the actions of the players
have to be transmitted very quickly to the server. It should be taken into
account that player vs player fights are one of the possible activities of
the game. Some examples: World of Warcraft (more than 10 million
subscribers) [2].

- TCP is also getting used for media delivery. For many reasons, such as
avoiding firewalls, the standard IP/ UDP/ RTP protocol stack is substituted
in many cases by IP/ TCP/ HTTP/ FLV [3].

- Another interesting scenario is satellite communication links.
Multiplexing small packets into one packet for transmission would improve
the efficiency. Satellite links would also find it useful to multiplex small
TCP packets into one packet - this could be especially interesting for
compressing TCP ACKs.

In our recent research activities, we have adapted TCRTP scheme for its use
when the traffic is not RTP. The idea is to substitute ECRTP by other
compression scheme which can be used for UDP or TCP headers. In 2006, the
IETF formed the Robust Header Compression (ROHC) working group which created
specifications for header compression over links for RTP, UDP and TCP.
These specifications were extended to compress headers over other networks.
For most RTP flows, ROHC is more bandwidth efficient than ECRTP, at the cost
of implementation complexity. It has a special care of context
synchronization, defining some states at the compressor and decompressor.
Once the effort for designing ROHC has been conducted, it is worth including
it in the compressing and multiplexing RFC.

In a recent paper in Nov. issue of IEEE Communications Magazine, it was
shown that 30% of bandwidth saving can be achieved for 8 FPS different games
using IPv4. If IPv6 is used, savings can be up to 54% [4]. Another recent
study, has estimated 60% bandwidth saving for World of Warcraft
(http://diec.unizar.es/~jsaldana/personal/sergei_SPECTS_2012_in_proc.pdf)
using IPv4.

The scheme of the proposal is this one:

       TCP    UDP  RTP/UDP

        |      |      |

         \     |     /                    ------------------------------

           \   |   /

Nothing or ROHC or ECRTP or IPHC             header compressing layer

               |

               |                          ------------------------------

               |

   PPPMUX or other mux protocols                multiplexing layer

               |

              / \                         ------------------------------

             /   \

            /     \

   GRE or L2TP     \                              tunneling layer

          |        MPLS

          |                               ------------------------------

          IP

It should be more "open" than TCRTP. I the use of different protocols could
be "orthogonal": different header compression algorithms could be used,
depending on the application and the scenario; also different multiplexing
and tunneling protocols could be included.

Regarding the scenarios, we have considered some of them:

- A provider of a real-time service (e.g. game or voip) can have an
infrastructure with a number of proxies that can group traffic from
different users and send it to the server.

- An Internet café, where a number (sometimes big) of players share the same
access link. Bandwidth is scarce in that scenario.

- A satellite link, where the bandwidth and the pps have to be saved.

- Desktop or application sharing where the traffic from the server to the
client typically consists of the delta of screen updates.  Also, the
standard for remote desktop sharing emerging for WebRTC in the RTCWEB
Working  Group is: {something}/SCTP/UDP (Stream Control Transmission
Protocol [SCTP]).  In this scenario, SCTP/UDP could be used in other cases:
chatting, file sharing and applications related to WebRTC peers. There could
be hundreds of clients at a site talking to a server located at a datacenter
over a WAN.

Thank you very much,

Jose Saldana

PS: We have also written a paper, which was presented in ICC conference, in
Ottawa in June. You can read it here:
http://diec.unizar.es/~jsaldana/personal/ottawa_ICC_2012_in_proc.pdf

______________

[1] Ratti, S.; Hariri, B.; Shirmohammadi, S., "A Survey of First-Person
Shooter Gaming Traffic on the Internet," Internet Computing, IEEE , vol.14,
no.5, pp.60-69, Sept.-Oct. 2010. URL:
<http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5445069&isnumber=55
62482>
http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5445069&isnumber=556
2482

[2] P. Svoboda, W Karner and M. Rupp, "Traffic Analysis and Modeling for
World of Warcraft," ICC '07. IEEE International Conference on
Communications, pp.1612-1617, 24-28, Jun. 2007. URL:
<http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4288941&isnumber=42
88671>
http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4288941&isnumber=428
8671

[3] G. Marfia and M. Roccetti, "TCP At Last: Reconsidering TCP's Role for
Wireless Entertainment Centers at Home," IEEE Transactions on Consumer
Electronics, Vol. 56, N. 4, Nov. 2010, pp. 2233-2240. URL:
<http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5681095&isnumber=56
81060>
http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5681095&isnumber=568
1060

[4] J. Saldana, J. Fernández-Navajas, J. Ruiz-Mas, J. I. Aznar, E. Viruete
and  L. Casadesus, "First Person Shooters: Can a Smarter Network Save
Bandwidth without Annoying the Players?," IEEE Communications Magazine,
Consumer Communications and Networking Series, vol. 49, no.

11, pp. 190-198, Nov. 2011. URL:
<http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6069728&isnumber=60
69696>
http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6069728&isnumber=606
9696