Transport Area Working Group (tsvwg)

Per Hurtig (work | 13 Feb 2012 09:51

draft-hurtig-tcpm-rtorestart-01

Hi all,

We've previously presented
http://tools.ietf.org/html/draft-hurtig-tcpm-rtorestart-01 at the tcpm
working group (in Taipei). However, the draft also describes a change
to how SCTP's retransmission timer is managed, and we therefore want
comments/suggestions/reactions from tsvwg as well.

Regards,
Per Hurtig

headers

Jose Saldana | 16 Feb 2012 16:47

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 ) 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

[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

[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

[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

headers

internet-drafts | 20 Feb 2012 17:44

I-D Action: draft-ietf-tsvwg-byte-pkt-congest-06.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item
of the Transport Area Working Group Working Group of the IETF.

	Title           : Byte and Packet Congestion Notification
	Author(s)       : Bob Briscoe
                          Jukka Manner
	Filename        : draft-ietf-tsvwg-byte-pkt-congest-06.txt
	Pages           : 43
	Date            : 2012-02-20

   This memo concerns dropping or marking packets using active queue
   management (AQM) such as random early detection (RED) or pre-
   congestion notification (PCN).  We give three strong recommendations:
   (1) packet size should be taken into account when transports read and
   respond to congestion indications, (2) packet size should not be
   taken into account when network equipment creates congestion signals
   (marking, dropping), and therefore (3) the byte-mode packet drop
   variant of the RED AQM algorithm that drops fewer small packets
   should not be used.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-byte-pkt-congest-06.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-tsvwg-byte-pkt-congest-06.txt

headers

Jose Saldana | 21 Feb 2012 10:40

Proposal for tunneling, compressing and multiplexing flows: A shorter explanation

Hello all,

Last week I sent a (too long) message explaining the idea of TCMTF (http://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/). I will now try to explain it better and briefly.

The idea is quite simple: TCRTP (RFC4170) is used to compress the headers of a number of RTP packets, using ECRTP (RFC 3545). It also multiplexes the packets and sends them using a tunnel. It is able to reduce the 40-byte RTP/UDP/IP header of voice packets to 4 or 5 bytes. So if the payload is 20 bytes (e.g. 2 voice samples), the bandwidth savings are significant. The problem is the added delay, mainly caused by the fact of needing a packet from each flow.

But the question is: there are other real-time applications that do not use RTP. The first example are First Person Shooter games (e.g. Counter Strike, Halo, Call of Duty), which send small UDP packets with high frequency. In these games, delay is critical, and gamers are the most difficult clients to deal with. But perhaps introducing a small delay, packets from different players can be multiplexed. The scenarios can be an Internet café or the proxy of a game provider.

I attach an image (real scale) of the savings that can be achieved for Counter Strike traffic.

Greetings,

Jose

De: tsvwg-bounces <at> ietf.org [mailto:tsvwg-bounces <at> ietf.org] En nombre de Jose Saldana
Enviado el: jueves, 16 de febrero de 2012 16:47
Para: tsvwg <at> ietf.org
Asunto: Proposal for tunneling, compressing and multiplexing flows