Subject: [AVTCORE] Proposal for updating TCRTP (RFC 4170)

From: <[email-masked]>
Date: Tue, 10 Jan 2012 12:34:09 +0100

Hello all.

My name is Jose Saldana, from the University of Zaragoza, in Spain. I am new
here.

I would like to share with AVTCORE Work Group a proposal, in case it could
be considered interesting. The main idea is to update TCRTP. This is a "Best
current practice" RFC (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 talking to other researchers, including some of the authors of
RFC4170, the possible scheme of the proposal could be this one:

G.711.0 payload compression        TCP     UDP   UDP/RTP
                 |                    |      |      |
                 |                     \     |     /
                 |                       \   |   /
                 |               nothing or ROHC or ECRTP
                 |                           |
                  \                         /
                    \                     /
                multiplexing layer (other or PPPMUX)
                           |
                           |
               tunneling layer (other or GRE or L2TP)
                           |
                           |
                          IP

It should be more "open" than TCRTP. I mean, it could be "orthogonal" to
different protocols: different header compression algorithms could be used,
depending on the application and the scenario; also different multiplexing
and tunneling protocols could be included. Finally, we have also included
the G.711.0 "branch": it could be interesting to convert G.711 to G.711.0 (a
lossless encoding of G.711) and back, using a similar tunneling mechanism.
In a similar way to TCRTP, the G.711 to G.711.0 and vice versa conversion
does not involve SIP/SDP/RTSP signaling with the endpoints, since G.711 has
a fixed RTP payload number.

We have not written a draft. This is only the first idea, so we look forward
to hearing the opinion of the Working Group,

Thank you very much, and sorry for writing such a long message,

Jose Saldana
University of Zaragoza

______________

[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=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=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=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=606
9696

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 17 Jan 2012 15:00:45 +0100

Hi,

As you are proposing to go towards a more generic scheme I don't think
this proposal really belongs in the WG, most likely not this area even.

I think this is a topic that primarily are related to Intarea and
Transport. Intarea as the owner of the tunneling work in IETF and
Transport as the actual aggregation and header compression is primarily
transport topics.

A question I would have is where this type of mechanism would make
sense. Where do you have scarce bandwidth capacity and are willing to
pay the downsides of the ingress egress complexities and the impact on
the traffic in regards to additional delay.

Cheers

Magnus

On 2012-01-10 12:34, [email-masked] wrote:
> Hello all.
> 
> My name is Jose Saldana, from the University of Zaragoza, in Spain. I am
> new here.
> 
> I would like to share with AVTCORE Work Group a proposal, in case it
> could be considered interesting. The main idea is to update TCRTP. This
> is a "Best current practice" RFC
> (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].
> 
> avoiding firewalls, the standard IP/ UDP/ RTP protocol stack is
> substituted in many cases by IP/ TCP/ HTTP/ FLV [3].
> 
> 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.
> 
> 
> 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.
> 
> 
> different protocols: different header compression algorithms could be
> used, depending on the application and the scenario; also different
> multiplexing and tunneling protocols could be included. Finally, we have
> also included the G.711.0 "branch": it could be interesting to convert
> G.711 to G.711.0 (a lossless encoding of G.711) and back, using a
> similar tunneling mechanism. In a similar way to TCRTP, the G.711 to
> G.711.0 and vice versa conversion does not involve SIP/SDP/RTSP
> signaling with the endpoints, since G.711 has a fixed RTP payload number.
> 
> We have not written a draft. This is only the first idea, so we look
> forward to hearing the opinion of the Working Group,
> 
> 
> 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>
> 
> 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>
> 

-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: [email-masked]
Date: Tue, 17 Jan 2012 19:01:20 +0100

Magnus,

Thank you very much for your message. I'm going to send the proposal  
to Internet Area and to Transport Area too. We are merging different  
ideas and I think one problem of this proposal is in which area and  
group can it fit.

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.

Some of the publications I cited in my first message have studied the  
impact of multiplexing on network parameters, and even in subjective  
quality. In fact, two days ago I presented in CCNC (Las Vegas) a paper  
about that:

http://diec.unizar.es/~jsaldana/personal/ccnc_2012_july.pdf

Other related papers are:
http://diec.unizar.es/~jsaldana/personal/gamma_CCNC_2011_in_proc.pdf
http://diec.unizar.es/~jsaldana/personal/ciber_SPECTS_2011_in_proc.pdf

We sent the proposal to avt group because the first version was  
developed for real-time services, but perhaps the current proposal has  
become too generic. Nevertheless, the main idea is to use it for  
real-time services.

Thank you very much,

Jose

>> multiplex small TCP packets into one packet - this could be especially
>> [2] P. Svoboda, W Karner and M. Rupp, "Traffic Analysis and Modeling for
>> World of Warcraft," ICC '07. IEEE International Conference on
>> [3] G. Marfia and M. Roccetti, "TCP At Last: Reconsidering TCP's Role
>> for Wireless Entertainment Centers at Home," IEEE Transactions on
>> Viruete and  L. Casadesus, "First Person Shooters: Can a Smarter Network
>> Save Bandwidth without Annoying the Players?," IEEE Communications

---

From: "Jose Saldana" <[email-masked]>
Date: Fri, 20 Jan 2012 10:48:09 +0100

Magnus,

Although I have also sent the proposal to Internet and Transport areas, I have been thinking about your response, and there is some reason for considering this proposal in a real-time workgroup: multiplexing is only interesting when the size of native packets is small, and this mainly happens in real-time services.

Let us make some calculations. We have to take into account the 1500 bytes packet size limit. We will define bandwidth relationship as:

BWR = Multiplexed_BW / Original_BW = Multiplexed_size / Original_size (as the time of native and multiplexed packets is the same)

1) If we consider a header of 28 bytes (IPv4/UDP) and a payload of 60 bytes, then we can multiplex up to └1500 / 60┘ ≈ 23 packets.

The common header at the beginning of a multiplexed packet will be of 25 bytes (IPv4 / L2TP / PPPMux).

The compressed header for each packet would be 4 bytes.

Then Multiplexed_size =  25 + 23*(4+60) = 1497 bytes
And Original_size = 23 * (28+60) = 2024 bytes

So BWR = 0.73 . We are saving 27% of bandwidth. If IPv6 is used, the saving grows up to 39%.

2) If header size is 40 bytes (IPv4 /UDP/RTP or IPv4/TCP), we obtain an original size of 23 * (40 + 60) = 2300 bytes, so BWR = 0.65 (35% saving). With IPv6 it grows to 45%.

3) But on the other hand, if we consider bigger payloads of e.g. 250 bytes, multiplexing is not interesting:

We can multiplex 5 packets, so:

Multiplexed_size = 25 + 5*(4+250) =1295
Original_size = 5*(40+250)=1450

So BWR = 0.89. We are saving 11% of bandwidth. With IPv6 it is 15%.

_______________

As a conclusion, we see that multiplexing is only interesting for (very) small packets. I think the typical applications that use these packets are VoIP, FPS games, MMORPG games. I do not know if there are some others using tiny packets while not being real-time.

Please consider this argument and tell me your opinion. I have not yet received any response from Internet and Transport areas.

Thank you for your attention,

Jose Saldana

-----Mensaje original-----
De: Magnus Westerlund [mailto:[email-masked]] 
Enviado el: martes, 17 de enero de 2012 15:01
Para: [email-masked]
CC: [email-masked]
Asunto: Re: [AVTCORE] Proposal for updating TCRTP (RFC 4170)

Hi,

As you are proposing to go towards a more generic scheme I don't think this proposal really belongs in the WG, most likely not this area even.

I think this is a topic that primarily are related to Intarea and Transport. Intarea as the owner of the tunneling work in IETF and Transport as the actual aggregation and header compression is primarily transport topics.

A question I would have is where this type of mechanism would make sense. Where do you have scarce bandwidth capacity and are willing to pay the downsides of the ingress egress complexities and the impact on the traffic in regards to additional delay.

Cheers

Magnus

On 2012-01-10 12:34, [email-masked] wrote:
> Hello all.
> 
> My name is Jose Saldana, from the University of Zaragoza, in Spain. I 
> am new here.
> 
> could be considered interesting. The main idea is to update TCRTP. 
> This is a "Best current practice" RFC
> 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
> 
>      |
> 
>      |
> 
>     PPPMux (multiplexing layer). Includes a number of compressed 
> packets into a bigger one
> 
>      |
> 
>      |
> 
> - Online "First Person Shooter" (FPS) games use UDP datagrams, and 
> they are one of the most "real-time" applications nowadays. Some examples:
> 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 
> 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.
> 
> 
> It should be more "open" than TCRTP. I mean, it could be "orthogonal" 
> to different protocols: different header compression algorithms could 
> be used, depending on the application and the scenario; also different 
> multiplexing and tunneling protocols could be included. Finally, we 
> have also included the G.711.0 "branch": it could be interesting to 
> convert
> [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:
> [2] P. Svoboda, W Karner and M. Rupp, “Traffic Analysis and Modeling 
> for World of Warcraft,” ICC '07. IEEE International Conference on 
> 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.

-- 

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 20 Jan 2012 11:15:50 +0100

Jose,

Yes, I fully agree with your conclusions that to get substantial benefit
from an mechanism that aggregates and compresses headers you need to
operate on small packets.

The reason I am pushing back on this WG being the right place for
discussion is the fact that you focus on packet streams that aren't RTP.
This WG is chartered for the core extensions and maintenance of RTP.
Based on that we are clearly the right place for RTP related discussion.
However, my understanding of the goal is to generalize the mechanism to
handle flows that uses other protocols that RTP in addition to RTP. Thus
I think the generalized goal is the most important aspect of the work.
When you want input on RTP related aspects then is when this WG really
should be involved.

Sending this WG an occasional pointer to where discussion happens is
fine, but I think you do need to find another place to discuss details
on this.

Cheers

Magnus

On 2012-01-20 10:48, Jose Saldana wrote:
> Magnus,
> 
> Although I havealsosent the proposal to Internet and Transport areas,I
> have been thinking aboutyour response, and there is some reason for
> consideringthis proposalinareal-time workgroup: multiplexing is only
> interesting when the size of native packets is small, and this mainly
> happens in real-time services.
> 
> Let us make some calculations.We have to take into account the1500
> bytespacket sizelimit.We willdefinebandwidth relationshipas:
> 
> BWR =Multiplexed_BW /Original_BW= Multiplexed_size / Original_size(as
> the time of native and multiplexed packets is the same)
> 
> 1)If we consider a header of 28 bytes (IPv4/UDP) and a payload of60
> bytes, thenwe can multiplex up to└1500 /60┘≈23packets.
> 
> ThenMultiplexed_size = 25 +23*(4+60)=1497bytes
> 
> And Original_size =23* (28+60) =2024bytes
> 
> So BWR = 0.73. We are saving 27% of bandwidth. If IPv6 is used, the
> saving grows up to 39%.
> 
> 2)If header size is 40 bytes (IPv4/UDP/RTP orIPv4/TCP), we obtain an
> original size of 23 * (40 + 60) =2300 bytes, so BWR = 0.65 (35% saving).
> With IPv6 it grows to45%.
> 
> 
> 3)But on the other hand, if we consider bigger payloads of e.g.250
> bytes, multiplexing is not interesting:
> 
> So BWR = 0.89. We are saving 11% of bandwidth.With IPv6 it is 15%.
> 
> _______________
> 
> As a conclusion, we see thatmultiplexingis only interesting
> for(very)small packets. I think the typical applications that use these
> packets are VoIP, FPS games, MMORPG games. I do not know if there are
> some others using tiny packetswhilenot being real-time.
> 
> Please consider this argument and tell me your opinion.I have
> notyetreceived any response from Internet and Transport areas.
> 

-- 

Magnus Westerlund