Hello all.
My name is Jose Saldana, from the University of Zaragoza, in Spain. I am
new in this area.
I would like to share with Transport Area 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).
I have first sent this proposal to avtcore working group, but Magnus
Westerlund has answered this:
________
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
___________________
So I would like to know if the work can better fit this area.
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.
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.
We have not written a draft. This is only the first idea, so we look
forward to hearing the opinion of the Area.
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=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>
