Subject: [tsvwg] A possible improvement for draft-saldana-tsvwg-tcmtf-02: asking for feedback

From: "Jose Saldana" <[email-masked]>
Date: Wed, 16 May 2012 09:42:06 +0200

Hello all. I would like to discuss an idea that somebody suggested me in
IETF83 Paris: the current draft considers one tunnel including a number of
flows, but all these flows are of the same protocol, i.e.: one tunnel for
multiplexing a number of VoIP flows using RTP; another tunnel for a number
of UDP flows which belong to FPS games; another tunnel for a number of TCP
flows of an MMORPG game, etc.

But perhaps it could be possible to include in the same tunnel packets
belonging to flows of different protocols. An access provider could use the
same tunnel for services with similar delay constraints (e.g. a tunnel
including VoIP and FPS games traffic). The advantage is clear: the bigger
the number of flows, the bigger the bandwidth saving and the smaller the
added multiplexing delays.

However, on the other hand, maybe some problems would arise (signaling
issues, etc.).

So I would appreciate to receive some ideas about this:

-          Do you think it could be useful?

-          Some other scenarios in which different protocols (RTP, bare UDP,
TCP) could be tunneled together?

-          Problems that could arise?

Thank you,

Jose Saldana

PS: If you have not read the draft, the ideas are also included in a paper
that is going to be presented in IEEE ICC, in Ottawa, next June 10th. A
preliminary version of the paper can be found in
http://diec.unizar.es/~jsaldana/personal/widening_scope_draft.pdf

It has a good explanation and also includes (color) graphs of the savings
obtained for VoIP, FPS and MMORPG games

The current draft is in
http://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/

---

From: Mirko Sužnjević <[email-masked]>
Date: Fri, 18 May 2012 11:49:06 +0200

Hello,

As I am new to this group just a short introduction, my name is Mirko Suznjevic, I am from University of Zagreb, Faculty of Electrical Engineering and Computing, and my research is mainly in the area of network games.

Just regarding the applicability of a such solution.

As more from the perspective of a typical "gamer" or the extensive user of games,  I can tell that there is high concurrency of gaming and VoIP flows, especially in multiplayer games.

While a significant part of the gaming community which uses VoIP tends to use external VoIP tools such as Ventrilo, Skype, TeamSpeak, and Mumble, more and more recently published games have VoIP support  built in the client application.

As an example of recent very popular games with inbuilt VoIP features  we can take Battlefield 3, World of Warcraft, Heroes of Newerth etc.

While the gaming traffic does not end at the same server as the voice traffic (example from my World of Warcraft measurements is 80.239.179.39 for game traffic and 80.239.179.18 for VoIP traffic), it is evident that the majority of the network path will be the same.

Also, as a real world application in which bandwidth savings are significant we can take big LAN parties, or big gaming events such as DreamHack (last event had around 20,000 players and over 1,6 million stream viewers, therefore organizers needed to upgrade their connection to 120 GB/s breaking the world record).

Regards,

Mirko Suznjevic

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jose Saldana
Sent: Wednesday, May 16, 2012 9:42 AM
To: [email-masked]
Subject: [tsvwg] A possible improvement for draft-saldana-tsvwg-tcmtf-02:asking for feedback

Hello all. I would like to discuss an idea that somebody suggested me in IETF83 Paris: the current draft considers one tunnel including a number of flows, but all these flows are of the same protocol, i.e.: one tunnel for multiplexing a number of VoIP flows using RTP; another tunnel for a number of UDP flows which belong to FPS games; another tunnel for a number of TCP flows of an MMORPG game, etc.

But perhaps it could be possible to include in the same tunnel packets belonging to flows of different protocols. An access provider could use the same tunnel for services with similar delay constraints (e.g. a tunnel including VoIP and FPS games traffic). The advantage is clear: the bigger the number of flows, the bigger the bandwidth saving and the smaller the added multiplexing delays.

However, on the other hand, maybe some problems would arise (signaling issues, etc.).

-        Some other scenarios in which different protocols (RTP, bare UDP, TCP) could be tunneled together?

Thank you,

Jose Saldana

PS: If you have not read the draft, the ideas are also included in a paper that is going to be presented in IEEE ICC, in Ottawa, next June 10th. A preliminary version of the paper can be found in http://diec.unizar.es/~jsaldana/personal/widening_scope_draft.pdf

It has a good explanation and also includes (color) graphs of the savings obtained for VoIP, FPS and MMORPG games

The current draft is in http://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/

---

From: "Diego R. Lopez" <[email-masked]>
Date: Thu, 24 May 2012 15:07:27 +0000

Hi,

> -          Problems that could arise?

My concern is about the size of the context information you'll have to send to
reconstruct the multiplexed flows at the other end, in addition with the complexity
of dealing with such a richer context. Do you have figures about the required size?
I guess that evaluating complexity could come later...

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at.
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

---

From: "Jose Saldana" <[email-masked]>
Date: Fri, 25 May 2012 10:03:41 +0200

Diego,

In my opinion, there are three questions related to your concern:

(1) The size of the "context" for each flow (the information for re-building the headers, which is shared by the origin and destination)
(2) Sending the "context" from the origin and destination
(3) Processing capacity issues (complexity, as you say) at the origin (compression) and destination (decompression)

The TCMTF draft has three layers: header compression, multiplexing and tunneling.

Questions (1) and (2) are problems related to the header compression standards (IPHC, ECRTP, ROHC), since they only involve the compression layer of the draft. Header compression avoids the sending of many fields, and also uses delta compression to reduce the number of bits required for other fields (typically sequence number fields which increase by one for each packet of the flow). Thus, the size of the "context" for each flow is more or less the header size, i.e. some tens of bytes. ROHC has some other things to save, namely the synchronization status, etc., but it is not a high amount of data. So question (1) is not difficult to solve.

Regarding question (2), the context is sent from the origin to the destination by the packets of the flow: the first packets are sent in its native form and, when the context has been established, header compression starts. Full headers are sent periodically, and also when synchronization problems appear. So this question is not a problem, in my opinion.

Question (3) is the most difficult to solve by now: 
- origin side: a TCMTF multiplexer has to 
	- compress the headers of a number of flows
	- store the packets in a queue and decide which ones are multiplexed at the end of each period
	- add the PPPMux headers
	- build the whole tunneled bundle packet (L2TP-PPPMux-compressed header)
	- send the bundle to the destination

- destination side: a TCMTF demultiplexer has to "open" the bundle, separate the packets, and decompress and rebuild them in their native form

I think the most complex part may be the header compression-decompression. So we have to look for studies which have deployed tests of this. By the moment, I have read these (by the way, Gorry is the author of the first one, so he may have something to say):

- C. S. Tye and D. Gorry Fairhurst, “A review of IP packet compression techniques, in PGNet, (Liverpool, UK), June 2003.

- A. Couvreur, L. M. Le-Ny, A. Minaburo, G. Rubino, B. Sericola, and L. Toutain, “Performance analysis of a header compression protocol: The ROHC unidirectional mode,” Telecommunication Systems, vol. 31, no. 6, pp. 85–98, 2006.

- E. Ertekin and C. Christou, “Internet Protocol Header Compression, Robust Header Compression, and Their Applicability in the Global Information Grid,” IEEE Commun. Mag., vol. 42, 2004, pp. 106–16.

- H. P. Sze, S. C. Liew, J. Y. B. Lee, and D. C. S. Yip, “A multiplexing scheme for H.323 voice-over-IP applications,” IEEE J. Select. Areas Commun., vol. 20, pp. 1360–1368, Sept. 2002.

In this last paper, the authors did implement a software prototype in Linux, and the processing delay was below 1ms (by the way, using computers of year 2002): 
"A software prototype is built to demonstrate the feasibility of our scheme and its compatibility with H.323. Our software runs under the Linux OS. (...) We also observe that the processing times of MUX/DEMUX due to header manipulation and packet transmission are negligible and generally below 1 ms".

Finally, it must be taken into account that in these scenarios (at least in games), we are dealing with servers with high processing capacity, since they have to receive all the inputs of the players movements, calculate the next status of the game, and send it to the players. And this is done with a very high frequency.

Sorry for this long message. Best regards and thank you for your feedback,

Jose

-----Mensaje original-----
De: Diego R. Lopez [mailto:[email-masked]] 
Enviado el: jueves, 24 de mayo de 2012 17:07
Para: Jose Saldana
CC: <[email-masked]>
Asunto: Re: [tsvwg] A possible improvement for draft-saldana-tsvwg-tcmtf-02: asking for feedback

Hi,

> -          Problems that could arise?

My concern is about the size of the context information you'll have to send to reconstruct the multiplexed flows at the other end, in addition with the complexity of dealing with such a richer context. Do you have figures about the required size?
I guess that evaluating complexity could come later...

Be goode,

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091

---

From: "Diego R. Lopez" <[email-masked]>
Date: Fri, 25 May 2012 14:02:34 +0000

Hi Jose,

> Sorry for this long message. Best regards and thank you for your feedback,

Great reply, thanks, but I may be misunderstood. My concern was precisely about the
*additional* complexity that we could incur if going beyond "classic TCMTF"
(multiplexing flows of equal nature) into "aggressive TCMTF" (attempting to multiplex
all flows). Do you have any evidence or figures about that?

Be goode,

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091

---

From: "Jose Saldana" <[email-masked]>
Date: Tue, 29 May 2012 10:23:26 +0200

Hi Diego,

Currently we have not done any test regarding "aggressive" TCMTF (i.e. multiplexing flows of different protocols). All the tests we have done employ the same kind of traffic for all the flows of a single tunnel:  a tunnel of VoIP flows, a tunnel of FPS flows, etc.

The question here is that every compressed flow needs its own context. So I think the first question is that the "protocol used" would have to be included in the context shared by MUX and DEMUX. This is not a problem: a small amount of bytes would suffice to store the different possibilities: e.g. "IPHC compressing TCP/IPv4" or "ROHC compressing UDP/IPv6" or "ECRTP compressing RTP/UDP/IPv4".

Some signaling should be implemented when adding a new compressed flow to a tunnel; and it should include, of course, the protocol to compress. The advantage is that the three layers of TCMTF are "orthogonal", i.e. the Multiplexing and the Tunneling layers do not need to know anything about the protocol used by each Compressed packet they are carrying.

Some scenarios where this could be interesting (more cases would be appreciated):

- An office which simultaneously uses remote desktop and a centralized VoIP system, located at a server in the central office: the same tunnel (remote office-central office) could be used for carrying voice packets and remote desktop ones.

- An ISP may use a single tunnel for aggregating flows belonging to different kinds of games: FPS using UDP or MMORPG using TCP

Thank you for your feedback. Best regards,

Jose
PS: Be goode

-----Mensaje original-----
De: Diego R. Lopez [mailto:[email-masked]] 
Enviado el: viernes, 25 de mayo de 2012 16:03
Para: Jose Saldana
CC: Gorry Fairhurst; <[email-masked]>
Asunto: Re: [tsvwg] A possible improvement for draft-saldana-tsvwg-tcmtf-02: asking for feedback

Hi Jose,

Great reply, thanks, but I may be misunderstood. My concern was precisely about the
*additional* complexity that we could incur if going beyond "classic TCMTF"
(multiplexing flows of equal nature) into "aggressive TCMTF" (attempting to multiplex all flows). Do you have any evidence or figures about that?

Be goode,

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091