I would agree with Magnus that the TSV Area would be a good place to start with a more detailed discussion of the topic, although the Transport Area Directors would be able to provide a more definitive opinion. The one word of caution I would bring up is that the IETF tends to have a difficult time finding a home for architecture work that spans layers of the stack. I don't know if this aspect is a requirement or a one potential use case scenario of your proposed work, but its something to keep in mind if you end up giving a presentation at the TSV area meeting.
-ken On Jan 17, 2012, at 1:24 PM, [email protected] wrote: > 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> > > >
