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

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Mon, 20 Feb 2012 23:48:16 +0530

Any thoughts on how important this is for WebRTC?
 
Muthu
 
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jose Saldana
Sent: Thursday, February 16, 2012 9:17 PM
To: [email-masked]
Subject: Proposal for tunneling, compressing and multiplexing flows
 
Hello all.
 
My name is Jose Saldana, from the University of Zaragoza, in Spain. I am new in this workgroup.
 
Today I have uploaded a new draft: http://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/:
 
                Title           : Tunneling Compressed Multiplexed Traffic Flows (TCMTF)
                Author(s)       : Jose Saldana
                Filename        : draft-saldana-tsvwg-tcmtf-00.txt
                Pages           : 16
                Date            : 2012-02-16
 
I am not the sole author of the draft. In fact, six more people have contributed to build it: Dan Wing (Cisco), Julian Fernandez-Navajas (Univ. of Zaragoza), Jose Ruiz-Mas (Univ. of Zaragoza), Muthu A. M. Perumal (Cisco), Gonzalo Camarillo (Ericsson) and Michael Ramalho(Cisco).
 
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/IP
      |
      |
    ECRTP (compressing layer). Compresses RTP/UDP/IP headers
      |
      |
     PPPMux (multiplexing layer). Includes a number of compressed packets into a bigger one
      |
      |
    L2TP     (tunneling layer). Permits its use end-to-end
      |
      |
      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 standard.
 
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, which is still under review, has estimated 45% bandwidth saving for World of Warcraft.
 
After working with other researchers, we have developed a standard. The possible scheme of the proposal could be this one:
 
        G.711 or other payload
                   |                      ------------------------------
                   |
G.711.0 or other payload compression        payload compression layer
                   |
                   |                      ------------------------------
    TCP    UDP  RTP/UDP
     |      |      |
      \     |     /                       ------------------------------
        \   |   /
Nothing or ROHC or ECRTP or IPHC             header compressing layer
               |
               |                          ------------------------------
               |
   PPPMUX or other mux protocols                multiplexing layer
               |
               |                          ------------------------------
               |
        GRE or L2TP or other                      tunneling layer
               |
               |                          ------------------------------
               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. Finally, another option has been considered: A payload compression layer.  When the payload is G.711 this layer can runs G.711.0, a  lossless and stateless compression/decompression of the payload  [I.711].  This operations can be deployed by network elements like   routers/switches, without the endpoints having to signal it using   RTSP/SDP/SIP, since G.711 has a fixed RTP payload number.
 
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, and sorry for writing such a long message,
 
Jose Saldana
University of Zaragoza
 
PS: We have also written a paper, which will be presented in next ICC conference, in Ottawa in June. You can read a draft here: http://diec.unizar.es/~jsaldana/personal/widening_scope_draft.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=5562482 <http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5445069&isnumber=5562482> 
 
[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=4288671 <http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4288941&isnumber=4288671> 
 
[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=5681060 <http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5681095&isnumber=5681060> 
 
[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=6069696 <http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6069728&isnumber=6069696>

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 27 Feb 2012 16:18:18 +0100

> Any thoughts on how important this is for WebRTC?
I'd say that it is not a problem WebRTC needs to solve - definitely not 
before getting its basic stuff out the door.

> Muthu
>
> *From:[email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Jose Saldana
> *Sent:* Thursday, February 16, 2012 9:17 PM
> *To:* [email-masked]
> *Subject:* Proposal for tunneling, compressing and multiplexing flows
>
> Hello all.
>
> Today I have uploaded a new draft: 
> http://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/:
>
> I am not the sole author of the draft. In fact, six more people have 
> contributed to build it: Dan Wing (Cisco), Julian Fernandez-Navajas 
> (Univ. of Zaragoza), Jose Ruiz-Mas (Univ. of Zaragoza), Muthu A. M. 
> Perumal (Cisco), Gonzalo Camarillo (Ericsson) and Michael Ramalho(Cisco).
>
> *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/IP
>
>       |
>
>       |
>
> - 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 standard.
>
> 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, which is still under review, has estimated 
> 45% bandwidth saving for World of Warcraft.
>
> After working with other researchers, we have developed a standard. 
> The possible scheme of the proposal could be this one:
>
>         G.711 or other payload
>
> 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. Finally, 
> another option has been considered: A payload compression layer.  When 
> the payload is G.711 this layer can runs G.711.0, a  lossless and 
> stateless compression/decompression of the payload  [I.711].  This 
> operations can be deployed by network elements like   
> routers/switches, without the endpoints having to signal it using   
> RTSP/SDP/SIP, since G.711 has a fixed RTP payload number.
>
> - 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.
>
> - 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.
>
> PS: We have also written a paper, which will be presented in next ICC 
> conference, in Ottawa in June. You can read a draft here: 
> http://diec.unizar.es/~jsaldana/personal/widening_scope_draft.pdf 
> <http://diec.unizar.es/%7Ejsaldana/personal/widening_scope_draft.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=5562482 
> <http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5445069&isnumber=5562482>
>
> [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=4288671 
> <http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4288941&isnumber=4288671>
>
> [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=5681060 
> <http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5681095&isnumber=5681060>
>
> [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=6069696 
> <http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6069728&isnumber=6069696>
>
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb