Subject: Re: [tcmtf] Next steps with TCMTF

From: MANUEL NUÑEZ SANZ <[email-masked]>
Date: Mon, 01 Oct 2012 14:33:42 +0000

Hi Jose,
    I am going to try to answer you inline with mark [MNS].

 I hope it has sense.

Manuel.

-----Mensaje original-----
De: [email-masked] [mailto:[email-masked]] En nombre de Jose Saldana
Enviado el: viernes, 28 de septiembre de 2012 11:19
Para: FERNANDO PASCUAL BLANCO
CC: [email-masked]
Asunto: Re: [tcmtf] Next steps with TCMTF

Fernando,

I have been thinking about it. There are three questions:

A) Should we map packet marks like DiffServ to different tunnels between the same points?

There is a first question: it does not exist (by now) a universally accepted standard about Diffserv mapping for different services. Perhaps an ISP may have a clear classification, so it can be useful for this, if the tunnel is created inside his aggregation network.

Although marking can be useful, perhaps it would not be enough: if you want to group the packets of a certain game, and establish a tunnel finishing at the game server, you need to identify them by the destination IP. So I think you would need something more than Diffserv.

[MNS] I agree, although marking by ISP o equivalent could be very useful, other options like "IP sources", "specific ports" could be equally valid.

My proposal: including in the draft b) a sentence like "Different mechanisms can be used in order to decide which packets are included into each tunnel.
For example, Diffserv can be useful when doing this. In other cases, the packet flows would have to be identified by their origin and/or destination IP addresses."

[MNS] I also agree with that open way.

Fernando (and people from network operators): please think about this. As network providers, you should have a clearer idea about this.

B) Could we mix some flows and under what conditions?

If the tunnel is only set inside the ISP network, or between two ISPs, then I think there is no problem on grouping packets from different services, or even transport protocols (UDP and TCP flows in the same tunnel). The question is that you have to accomplish the delay requirements of the most delay-sensitive service.

As we have three layers (compressing, multiplexing, tunneling), I think that tunneling and multiplexing layers do not have to know which kind of packet they are carrying. (I am posting another message about this).

Other question is: if you can set up a tunnel covering the whole route (e.g., from the access network to the game server), then you can only group packets of a single game. On the other hand, if you only group packets in your aggregation network, you can group a big number of flows. When the tunnel arrives at the internet router, the packets are rebuilt and sent in their native form.

So the longer the common route you want to cover, the more specific traffic you can tunnel.

[MNS] I think there no problem on grouping packets from different service as long as each grouped services has the same "delay sensitive" level and the same IP destination (internet router, game data center...). In fact, refining this idea... if for example the most delay-sensitive flow has not reached its optimum full it could be complete with the following traffic with should be less delay-sensitive, and so on. In this way always each flow is sent with its optimum payload.

C) Do you think that would be included in your second draft proposal?

 By now, I think this can be issued in draft b). However, we have to further think about it.

Thank you,

Jose

[MNS] Thanks,  Manuel

> -----Mensaje original-----
> De: [email-masked] [mailto:[email-masked]] En nombre
> de FERNANDO PASCUAL BLANCO Enviado el: jueves, 27 de septiembre de
> 2012 17:08
> Para: [email-masked]; [email-masked]
> CC: Wesley Eddy; Martin Stiemerling
> Asunto: Re: [tcmtf] Next steps with TCMTF
>
> Hi Jose,
>
>         I absolutely agree with your classification. Nevertheless I
> miss a
draft
> explaining how to deal with different QoS flows passing through a
> TCMTF
> tunnel: Should we map packet marks like DiffServ to different tunnels
> between the same points? Could we mix some flows and under what
> conditions? Do you think that would be included in your second draft
> proposal?
>
> Regards,
>
> Fernando Pascual Blanco
> Telefónica Global Resources
> Network Automation and Dynamization
> TECHNOLOGY PEOPLE GROUP
> F +34913128779
> M +34682005168
> [email-masked]
>
>
>
>
> On 27/09/12 12:31, "Jose Saldana" <[email-masked]> wrote:
>
> >Hello all,
> >
> >I would like to discuss in this list the possibility of creating a
> >small Working Group for TCMTF, as suggested by Wes. It could have the
> >task of making a RFC from TCMTF, or a wider scope. I think that
> >perhaps more than a draft would be necessary. I mean, I have been
> >thinking about it, and perhaps the work could be divided into the next parts:
> >
> > a) "Current draft": the main draft (draft-saldana-tsvwg-tcmtf-03),
> >including the protocol stack of TCMTF. The current proposal has
> >different options, but the concrete one to use is static: in the
> >set-up moment, you decide that "between these two routers a tunnel is
> >set including all the packets with this IP origin and destination".
> >
> >b) "Recommendations draft": another "informational" one, with
> >recommendations of maximum delays to be added to different kinds of
> >services, different multiplexing policies, implementation issues
> >related to the selection of the best compression algorithm to use, etc.
> >Some hypothetical examples:
> >      -  "if you are multiplexing a First Person Shooter, your
> >multiplexer should not retain packets more than 50 ms"
> >- "if you are multiplexing in a low-end router in a wired scenario,
> >you don't need to use ROHC. A simpler scheme like IPHC can be enough,
> >and it will not require a lot of processing capacity".
> >
> >c) "Dynamic Signaling draft": perhaps another one including a
> >signaling system in order to:
> >       - dynamically "negotiate" the concrete options of TCMTF you
> >are going to use
> >       - if two routers notice that a rush hour is arriving, they
> >could send some packets asking other routers if they have some flows
> >in common with them, which could be multiplexed.
> >
> >
> >The main questions are:
> >
> >Is this enough for creating a working group?
> >
> >Do you think the distribution of the work into three draft makes sense?
> >
> >Is there any other issue which should be studied and standardized?
> >Perhaps other people could imagine more things.
> >
> >So let's start the discussion.
> >
> >Thanks in advance,
> >
> >Jose
> >
> >
> >_______________________________________________
> >tcmtf mailing list
> >[email-masked]
> >https://www.ietf.org/mailman/listinfo/tcmtf
>
>
> ________________________________
>
> 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
> _______________________________________________
> tcmtf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcmtf

_______________________________________________
tcmtf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcmtf

________________________________

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: JUAN ANTONIO CASTELL LUCIA <[email-masked]>
Date: Wed, 03 Oct 2012 14:59:14 +0000

Hi all, regarding question A), I would like to comment that I suppose that what Fernando wanted to propose is to include an "additional condition" in the moment to establish a tunnel between the two peers: some criteria that helped to classify the packets in flows with different delay/packet loss requirements in order to have separate tunnels between these two peers, with different policies for multiplexing and compressing (e.g. maximum time before to send a packet, the suggestion of Manuel of completing the payload with packets with the following kind of flow with lower requirements, etc).

But in all of these cases, the destination IP/Port should be part of the criteria.

In this sense, I also agree with the proposal of including it in draft b).

Regards.

-----Mensaje original-----
De: [email-masked] [mailto:[email-masked]] En nombre de MANUEL NUÑEZ SANZ
Enviado el: lunes, 01 de octubre de 2012 16:34
Para: [email-masked]; FERNANDO PASCUAL BLANCO
CC: [email-masked]
Asunto: Re: [tcmtf] Next steps with TCMTF

Hi Jose,

 I hope it has sense.

Manuel.

-----Mensaje original-----
De: [email-masked] [mailto:[email-masked]] En nombre de Jose Saldana Enviado el: viernes, 28 de septiembre de 2012 11:19
Para: FERNANDO PASCUAL BLANCO
CC: [email-masked]
Asunto: Re: [tcmtf] Next steps with TCMTF

Fernando,

Thank you,

Jose

[MNS] Thanks,  Manuel

draft

---

From: FERNANDO PASCUAL BLANCO <[email-masked]>
Date: Thu, 04 Oct 2012 07:21:05 +0000

Hi all,

        Yes Juan Antonio, that was my point. Even, those different tunnels
between the same two peers could be the same tunnel.

Regards,

Fernando Pascual Blanco

On 03/10/12 16:59, "JUAN ANTONIO CASTELL LUCIA" <[email-masked]> wrote:

>Hi all, regarding question A), I would like to comment that I suppose
>that what Fernando wanted to propose is to include an "additional
>condition" in the moment to establish a tunnel between the two peers:
>some criteria that helped to classify the packets in flows with different
>delay/packet loss requirements in order to have separate tunnels between
>these two peers, with different policies for multiplexing and compressing
>(e.g. maximum time before to send a packet, the suggestion of Manuel of
>completing the payload with packets with the following kind of flow with
>lower requirements, etc).
>
>De: [email-masked] [mailto:[email-masked]] En nombre de
>Jose Saldana Enviado el: viernes, 28 de septiembre de 2012 11:19
>There is a first question: it does not exist (by now) a universally
>accepted standard about Diffserv mapping for different services. Perhaps
>an ISP may have a clear classification, so it can be useful for this, if
>the tunnel is created inside his aggregation network.
>
>Although marking can be useful, perhaps it would not be enough: if you
>want to group the packets of a certain game, and establish a tunnel
>finishing at the game server, you need to identify them by the
>destination IP. So I think you would need something more than Diffserv.
>
>
>[MNS] I agree, although marking by ISP o equivalent could be very useful,
>other options like "IP sources", "specific ports" could be equally valid.
>
>My proposal: including in the draft b) a sentence like "Different
>mechanisms can be used in order to decide which packets are included into
>each tunnel.
>For example, Diffserv can be useful when doing this. In other cases, the
>packet flows would have to be identified by their origin and/or
>destination IP addresses."
>
>Fernando (and people from network operators): please think about this. As
>network providers, you should have a clearer idea about this.
>
>If the tunnel is only set inside the ISP network, or between two ISPs,
>then I think there is no problem on grouping packets from different
>services, or even transport protocols (UDP and TCP flows in the same
>tunnel). The question is that you have to accomplish the delay
>requirements of the most delay-sensitive service.
>
>As we have three layers (compressing, multiplexing, tunneling), I think
>that tunneling and multiplexing layers do not have to know which kind of
>packet they are carrying. (I am posting another message about this).
>
>Other question is: if you can set up a tunnel covering the whole route
>(e.g., from the access network to the game server), then you can only
>group packets of a single game. On the other hand, if you only group
>packets in your aggregation network, you can group a big number of flows.
>When the tunnel arrives at the internet router, the packets are rebuilt
>and sent in their native form.
>
>[MNS] I think there no problem on grouping packets from different service
>as long as each grouped services has the same "delay sensitive" level and
>the same IP destination (internet router, game data center...). In fact,
>refining this idea... if for example the most delay-sensitive flow has
>not reached its optimum full it could be complete with the following
>traffic with should be less delay-sensitive, and so on. In this way
>always each flow is sent with its optimum payload.
>
>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:

---

From: Mirko Sužnjević <[email-masked]>
Date: Tue, 23 Oct 2012 10:14:19 +0200

Hello all,

Regarding the b) "Recommendations draft" I have created a first summary of real-time services suitable for multiplexing.

In short I have analyzed the literature regarding:
1) 2-way audio video communications
2) Multiplayer gaming
3) Remote control

I will shortly just summarize the results without listing all sources.
Note: Under term latency one way delay is considered.

For 2-way audio and video communication ITU.T recommendations state that 150ms latency is needed for completely unimpaired communication. Latencies up to 400ms can be tolerated, but their impact is noticeable.

Multiplayer gaming differs significantly on the genre. 
The most demanding games are First Person Shooter (FPS) games which require between 80ms and 100ms delay for unimpaired experience.
Some studies claim that Thrid Person Avatar games from which the most common are Role Playing Games (RPGs) and Massively Multiplayer Role-Playing Games MMORPGs tolerate latencies up to 500ms, but other studies state that a more realistic values for unimpaired MMORPG experience is between 120 and 200ms.
As for omnipresent games such as Real Time Strategies (RTS) it is stated that latencies up to 500ms and even up to 1000ms do not impair user performance on objective metrics, but the evidence from RTS game forums suggests that users are quite unsatisfied with latencies above 300ms.

Remote control has different values of latency for different services as well. Remote surgery is stated that 330ms latency is acceptable, but for controlling a robot in scope of end-to-end tele-echography showed that only latencies under 150ms are acceptable.

What do you think is there a possibility to make an extended version of such a document and submit it as a draft?

Thanks for any feedback!

Mirko Suznjevic

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jose Saldana
Sent: Thursday, September 27, 2012 12:31 PM
To: [email-masked]
Cc: Wesley Eddy; Martin Stiemerling
Subject: [tcmtf] Next steps with TCMTF

Hello all,

I would like to discuss in this list the possibility of creating a small Working Group for TCMTF, as suggested by Wes. It could have the task of making a RFC from TCMTF, or a wider scope. I think that perhaps more than a draft would be necessary. I mean, I have been thinking about it, and perhaps the work could be divided into the next parts:

 a) "Current draft": the main draft (draft-saldana-tsvwg-tcmtf-03), including the protocol stack of TCMTF. The current proposal has different options, but the concrete one to use is static: in the set-up moment, you decide that "between these two routers a tunnel is set including all the packets with this IP origin and destination".
 
b) "Recommendations draft": another "informational" one, with recommendations of maximum delays to be added to different kinds of services, different multiplexing policies, implementation issues related to the selection of the best compression algorithm to use, etc. Some hypothetical examples:
      -  "if you are multiplexing a First Person Shooter, your multiplexer should not retain packets more than 50 ms"
- "if you are multiplexing in a low-end router in a wired scenario, you don't need to use ROHC. A simpler scheme like IPHC can be enough, and it will not require a lot of processing capacity".
 
c) "Dynamic Signaling draft": perhaps another one including a signaling system in order to:
 	- dynamically "negotiate" the concrete options of TCMTF you are going to use
 	- if two routers notice that a rush hour is arriving, they could send some packets asking other routers if they have some flows in common with them, which could be multiplexed.

The main questions are:

Is there any other issue which should be studied and standardized? Perhaps other people could imagine more things.

Thanks in advance,

Jose

---

From: "Jose Saldana" <[email-masked]>
Date: Tue, 23 Oct 2012 10:25:54 +0200

Mirko,

This sounds really good!. This was the idea of "draft b)".

Do you think you have included all the services which can be multiplexed
with TCMTF? I mean: small packets and high overhead. Some ideas: sensor
networks sending a sample, video-surveillance, whatsapp-like applications?
Although some of them are not real-time, perhaps they can also be
multiplexed if the number of packets per second is big.

So perhaps a section enumerating non real-time applications with small
packets could also be interesting: for example "instant messaging
applications can tolerate up to 5 seconds of delay" (I have just invented
the figure, it's only an example).

I could help you with this, if you agree, of course.

Thanks,

Jose

> Mirko Sužnjevic
> Enviado el: martes, 23 de octubre de 2012 10:14
> Para: [email-masked]
> Regarding the b) "Recommendations draft" I have created a first summary of
> real-time services suitable for multiplexing.
> 
> For 2-way audio and video communication ITU.T recommendations state that
> 150ms latency is needed for completely unimpaired communication.
> Latencies up to 400ms can be tolerated, but their impact is noticeable.
> 
> The most demanding games are First Person Shooter (FPS) games which
> require between 80ms and 100ms delay for unimpaired experience.
> Some studies claim that Thrid Person Avatar games from which the most
> common are Role Playing Games (RPGs) and Massively Multiplayer Role-
> Playing Games MMORPGs tolerate latencies up to 500ms, but other studies
> state that a more realistic values for unimpaired MMORPG experience is
> between 120 and 200ms.
> As for omnipresent games such as Real Time Strategies (RTS) it is stated
that
> latencies up to 500ms and even up to 1000ms do not impair user
> performance on objective metrics, but the evidence from RTS game forums
> suggests that users are quite unsatisfied with latencies above 300ms.
> 
> Remote control has different values of latency for different services as
well.
> Remote surgery is stated that 330ms latency is acceptable, but for
controlling
> a robot in scope of end-to-end tele-echography showed that only latencies
> under 150ms are acceptable.
> 
> What do you think is there a possibility to make an extended version of
such
> a document and submit it as a draft?
> 
> Thanks for any feedback!
> 
> Mirko Suznjevic
> 
> I would like to discuss in this list the possibility of creating a small
Working
> Group for TCMTF, as suggested by Wes. It could have the task of making a
> RFC from TCMTF, or a wider scope. I think that perhaps more than a draft
> would be necessary. I mean, I have been thinking about it, and perhaps the
> work could be divided into the next parts:
> 
including
> the protocol stack of TCMTF. The current proposal has different options,
but
> the concrete one to use is static: in the set-up moment, you decide that
> "between these two routers a tunnel is set including all the packets with
this
> IP origin and destination".
> 
> services, different multiplexing policies, implementation issues related
to the
> selection of the best compression algorithm to use, etc. Some hypothetical
> examples:
>       -  "if you are multiplexing a First Person Shooter, your multiplexer
should
> not retain packets more than 50 ms"
> - "if you are multiplexing in a low-end router in a wired scenario, you
don't
> need to use ROHC. A simpler scheme like IPHC can be enough, and it will
not
> require a lot of processing capacity".
> 
>  	- if two routers notice that a rush hour is arriving, they could
send
> some packets asking other routers if they have some flows in common with
> them, which could be multiplexed.
> 
> 
> The main questions are:
>

---

From: Mirko Sužnjević <[email-masked]>
Date: Tue, 23 Oct 2012 10:40:52 +0200

Hello,

Well I have not included all the services. Mostly I have focused on the real-time ones.
I think that TCMTF can be used to improve other services which do not require low latencies, but have required properties of the traffic.
In that case it is just easier, as no hard limits on the latency exists and therefore TCMTF usage does not interrupt the QoS or QoE.

Yes I agree with your suggestion, it would also be nice to add the section about non-real time services and their tolerated delays (even if we talk in time frames of seconds or even minutes). Again if you can aggregate on a longer time period the aggregation results will be better, so TCMTF could be useful for bandwidth savings in such applications for a wide array of  examples.

Cheers!
Mirko Suznjevic

-----Original Message-----
From: Jose Saldana [mailto:[email-masked]] 
Sent: Tuesday, October 23, 2012 10:26 AM
To: Mirko Sužnjević
Cc: [email-masked]
Subject: RE: [tcmtf] Next steps with TCMTF

Mirko,

Do you think you have included all the services which can be multiplexed with TCMTF? I mean: small packets and high overhead. Some ideas: sensor networks sending a sample, video-surveillance, whatsapp-like applications?
Although some of them are not real-time, perhaps they can also be multiplexed if the number of packets per second is big.

So perhaps a section enumerating non real-time applications with small packets could also be interesting: for example "instant messaging applications can tolerate up to 5 seconds of delay" (I have just invented the figure, it's only an example).

Thanks,

Jose

> de Mirko Sužnjevic Enviado el: martes, 23 de octubre de 2012 10:14
> Para: [email-masked]
> Regarding the b) "Recommendations draft" I have created a first 
> summary of real-time services suitable for multiplexing.
> 
> For 2-way audio and video communication ITU.T recommendations state 
> that 150ms latency is needed for completely unimpaired communication.
> Playing Games MMORPGs tolerate latencies up to 500ms, but other 
> studies state that a more realistic values for unimpaired MMORPG 
> experience is between 120 and 200ms.
that
> performance on objective metrics, but the evidence from RTS game 
> forums suggests that users are quite unsatisfied with latencies above 300ms.
> 
well.
controlling
> a robot in scope of end-to-end tele-echography showed that only 
> latencies under 150ms are acceptable.
> 
such
> small
Working
> Group for TCMTF, as suggested by Wes. It could have the task of making 
> a RFC from TCMTF, or a wider scope. I think that perhaps more than a 
> draft would be necessary. I mean, I have been thinking about it, and 
> perhaps the work could be divided into the next parts:
> 
including
but
> the concrete one to use is static: in the set-up moment, you decide 
> that "between these two routers a tunnel is set including all the 
> packets with
this
> related
to the
> multiplexer
should
> you
don't
not
send
> some packets asking other routers if they have some flows in common 
> with them, which could be multiplexed.
> 
> 
> The main questions are:
>

---

From: Luigi Iannone <[email-masked]>
Date: Tue, 23 Oct 2012 10:45:20 +0200

Hi,

> 1) 2-way audio video communications

May I ask whether or not one way audio video communications should have their own category?

May be it falls already in 1), but I was thinking that Internet is the more and more used for live events (think about the olympics).
So a broadcaster may have agreements with other ISPs to use TCMTF to reduce bandwidth while transmitting these live events (that cannot be "downloaded" like other streaming videos, they just need to be "constantly" streamed as long as the event goes on).

Could be this something to add?

Luigi

---

From: Mirko Sužnjević <[email-masked]>
Date: Tue, 23 Oct 2012 10:45:38 +0200

I concur with this. Bandwidth limitations are a huge issue in any type of large scale streaming events, although properties of the streaming traffic should be taken into account (not that many small packets).

I might have said this earlier but the world record on the fastest Internet connection for a certain event was set by Dreamhack 2011 a large LAN party with a lot of streaming and a lot of players playing different games (though the info may be a bit outdated).
http://www.dreamhack.se/dhw11/2011/11/22/120-gigabit-at-dhw11/

Cheers!
Mirko

-----Original Message-----
From: Luigi Iannone [mailto:[email-masked]] 
Sent: Tuesday, October 23, 2012 10:44 AM
To: Mirko Sužnjević
Cc: [email-masked]
Subject: Re: [tcmtf] Next steps with TCMTF

Luigi

---

From: "Jose Saldana" <[email-masked]>
Date: Tue, 23 Oct 2012 11:12:27 +0200

Luigi,

I think the question is that only small packets can be multiplexed. Video broadcast uses 1500 bytes packets (just checked with Youtube and Wireshark)

Radio broadcast may use 250bytes packets, so perhaps you could multiplex 4 o 5 packets, but the saving is not very significant (just checked in http://www.cope.es/player/id=2011122307520001 <http://www.cope.es/player/id=2011122307520001&activo=5> &activo=5)

In one-way broadcasts, 5 seconds are not critical, I think. But only small packets are interesting for TCMTF.

Thanks,

Jose

De: [email-masked] [mailto:[email-masked]] En nombre de Luigi Iannone
Enviado el: martes, 23 de octubre de 2012 10:45
Para: Mirko Sužnjević
CC: [email-masked]
Asunto: Re: [tcmtf] Next steps with TCMTF

Hi,

Hello all,

2) Multiplayer gaming
3) Remote control

Luigi

Thanks for any feedback!

Mirko Suznjevic

-----Original Message-----

To: [email-masked]

Hello all,

The main questions are:

Thanks in advance,

Jose 

tcmtf mailing list

[email-masked]

tcmtf mailing list

[email-masked]

---

From: FERNANDO PASCUAL BLANCO <[email-masked]>
Date: Tue, 23 Oct 2012 14:29:24 +0000

Hi all,

Maybe in the 2-way audio-video case video is also out of scope: packets are not very small. They usually use different RTP flows, 4 flows in total for a 2-way audio video communications (2 flows in every direction). So, should be focused in audio?

Regards from Darmstadt,

Fernando Pascual Blanco

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Organization: Universidad de Zaragoza
Reply-To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: martes, 23 de octubre de 2012 11:12
To: Luigi Iannone <[email-masked]<mailto:[email-masked]>>, 'Mirko Sužnjević' <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [tcmtf] Next steps with TCMTF

Luigi,

Radio broadcast may use 250bytes packets, so perhaps you could multiplex 4 o 5 packets, but the saving is not very significant (just checked in http://www.cope.es/player/id=2011122307520001&activo=5)

Thanks,

Jose

De: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] En nombre de Luigi Iannone
Enviado el: martes, 23 de octubre de 2012 10:45
Para: Mirko Sužnjević
CC: [email-masked]<mailto:[email-masked]>
Asunto: Re: [tcmtf] Next steps with TCMTF

Hi,

On 23 Oct. 2012, at 10:14 , Mirko Sužnjević <[email-masked]<mailto:[email-masked]>> wrote:

Hello all,

2) Multiplayer gaming
3) Remote control

Luigi

Thanks for any feedback!

Mirko Suznjevic

-----Original Message-----

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Jose Saldana

To: [email-masked]<mailto:[email-masked]>

Hello all,

The main questions are:

Thanks in advance,

Jose

tcmtf mailing list

[email-masked]<mailto:[email-masked]>

tcmtf mailing list

[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tcmtf

---

From: Julián Fernández-Navajas <[email-masked]>
Date: Wed, 24 Oct 2012 11:00:30 +0200

hello all,
Regarding the real-time services suitable for multiplexing, i have a 
question about the third of them, remote control. I can't think a use 
case that transmits little packets in order to be multiplexed. Mirko 
suggests tele-echography but it no seems a use case that traffic needs 
multiplexion because there are not a lot of users simultaneusly.
Let us thinking about remote control and the possible use cases that can 
be presented here.

Julián

---

From: FERNANDO PASCUAL BLANCO <[email-masked]>
Date: Wed, 24 Oct 2012 09:37:32 +0000

Hi all,

        As a first thinking, RTSP protocol have a connection control layer that
let clients to remotely control streaming servers: they can remotely play
or pause the media… I don´t know if that would be an interesting use case
when multiplexing users consuming media under demand.

Regards,

Fernando Pascual Blanco

On 24/10/12 11:00, "Julián Fernández-Navajas" <[email-masked]> wrote:

>>>summary of
>>>a

---

From: JUAN ANTONIO CASTELL LUCIA <[email-masked]>
Date: Wed, 24 Oct 2012 10:02:04 +0000

Hi all, although is not a strictly remote control topic, regarding media consumption, a possible use case of TCMTF application with multiplexing IMHO could be interactive television programs. For example, programs with a voting scheme (let's do a more fair Eurovision song contest ;o)). That supposes that during certain concrete period of time program watchers would be simultaneously sending small (I guess) packets. The latency requirements wouldn't be very high.

Smart TVs are coming...

What do you think?

Regards,
Juan Antonio

-----Mensaje original-----
De: [email-masked] [mailto:[email-masked]] En nombre de FERNANDO PASCUAL BLANCO
Enviado el: miércoles, 24 de octubre de 2012 11:38
Para: Julián Fernández-Navajas; [email-masked]
Asunto: Re: [tcmtf] Next steps with TCMTF

Hi all,

        As a first thinking, RTSP protocol have a connection control layer that let clients to remotely control streaming servers: they can remotely play or pause the media… I don´t know if that would be an interesting use case when multiplexing users consuming media under demand.

Regards,

Fernando Pascual Blanco

On 24/10/12 11:00, "Julián Fernández-Navajas" <[email-masked]> wrote:

>Let us thinking about remote control and the possible use cases that
>can be presented here.
>
>Julián
>
>
>
>
>> Do you think you have included all the services which can be
>>multiplexed  with TCMTF? I mean: small packets and high overhead. Some
>>ideas: sensor  networks sending a sample, video-surveillance,
>>whatsapp-like applications?
>> So perhaps a section enumerating non real-time applications with
>>small  packets could also be interesting: for example "instant
>>messaging  applications can tolerate up to 5 seconds of delay" (I have
>>just invented  the figure, it's only an example).
>>
>>> Some studies claim that Thrid Person Avatar games from which the
>>>most  common are Role Playing Games (RPGs) and Massively Multiplayer
>>>Role-  Playing Games MMORPGs tolerate latencies up to 500ms, but
>>>other studies  state that a more realistic values for unimpaired
>>>MMORPG experience is  between 120 and 200ms.
>>> Group for TCMTF, as suggested by Wes. It could have the task of
>>>making a  RFC from TCMTF, or a wider scope. I think that perhaps more
>>>than a draft  would be necessary. I mean, I have been thinking about
>>>it, and perhaps the  work could be divided into the next parts:
>>>

---

From: "Jose Saldana" <[email-masked]>
Date: Wed, 24 Oct 2012 12:18:48 +0200

We are thinking a lot, and this is good.

My opinion: the optimization is only interesting for services with:

- small packets
- a place where a number of flows can be multiplexed
- the multiplexing saving is interesting. One example is a service with sudden and huge traffic bursts.

In this sense, I think that the voting scheme for a TV program can be interesting. Your network is dimensioned for a normal performance, and in 10 seconds you have millions of people sending messages: just when the program host says: "who is the one you want to ban from the program? Send your votes just now"

And a whatsapp-like application has the same problem:
- after a football match, you may like to pester the one whose team has lost, or to congratulate the winner (less frequent).
- in the minutes around 0:00 of New Year's day, there are lots of people sending short messages.

Regarding RTSP, I don't clearly see a place where a big number of messages can be grouped. Some help?

And regarding tele-ecography, I think that the number of ecography devices in a place will always be small. In addition, doctors always have money to spare, so they don't need to save bandwidth.

Thanks,

Jose

> JUAN ANTONIO CASTELL LUCIA
> Enviado el: miércoles, 24 de octubre de 2012 12:02
> Para: FERNANDO PASCUAL BLANCO; Julián Fernández-Navajas;
> [email-masked]
> Hi all, although is not a strictly remote control topic, regarding media
> consumption, a possible use case of TCMTF application with multiplexing
> IMHO could be interactive television programs. For example, programs with a
> voting scheme (let's do a more fair Eurovision song contest ;o)). That
> supposes that during certain concrete period of time program watchers
> would be simultaneously sending small (I guess) packets. The latency
> requirements wouldn't be very high.
> 
> Smart TVs are coming...
> 
> What do you think?
> 
> Regards,
> Juan Antonio
> 
> 
> 
> FERNANDO PASCUAL BLANCO Enviado el: miércoles, 24 de octubre de 2012
> 11:38
>         As a first thinking, RTSP protocol have a connection control layer that let
> clients to remotely control streaming servers: they can remotely play or
> pause the media… I don´t know if that would be an interesting use case

---

From: MANUEL NUÑEZ SANZ <[email-masked]>
Date: Wed, 24 Oct 2012 10:48:16 +0000

Hi,

Only to add my two cents. In RTSP case you also could have a new flow from server to  users, if the TV needs  add personalized text under your show  program. For example: RSS news, RSS personalized advertising.... In this case, again the number of small packet seems high.

Regards,
     Manuel

-----Mensaje original-----
De: [email-masked] [mailto:[email-masked]] En nombre de Jose Saldana
Enviado el: miércoles, 24 de octubre de 2012 12:19
Para: JUAN ANTONIO CASTELL LUCIA; FERNANDO PASCUAL BLANCO; 'Julián Fernández-Navajas'
CC: [email-masked]
Asunto: Re: [tcmtf] Next steps with TCMTF

- small packets

Thanks,

Jose

> de JUAN ANTONIO CASTELL LUCIA Enviado el: miércoles, 24 de octubre de
> 2012 12:02
> Hi all, although is not a strictly remote control topic, regarding
> media consumption, a possible use case of TCMTF application with
> multiplexing IMHO could be interactive television programs. For
> example, programs with a voting scheme (let's do a more fair
> Eurovision song contest ;o)). That supposes that during certain
> concrete period of time program watchers would be simultaneously
> sending small (I guess) packets. The latency requirements wouldn't be very high.
>
> Smart TVs are coming...
>
> What do you think?
>
> Regards,
> Juan Antonio
>
>
>
> de FERNANDO PASCUAL BLANCO Enviado el: miércoles, 24 de octubre de
> 2012
> 11:38
>         As a first thinking, RTSP protocol have a connection control
> layer that let clients to remotely control streaming servers: they can
> remotely play or pause the media… I don´t know if that would be an
> interesting use case when multiplexing users consuming media under demand.
>
> Regards,
>
> Fernando Pascual Blanco
> >suggests tele-echography but it no seems a use case that traffic
> >needs multiplexion because there are not a lot of users simultaneusly.
> >>messaging  applications can tolerate up to 5 seconds of delay" (I
> >>have just invented  the figure, it's only an example).
> >>
> >>> For 2-way audio and video communication ITU.T recommendations
> >>>state that  150ms latency is needed for completely unimpaired
> >>>communication.
> >>> The most demanding games are First Person Shooter (FPS) games
> >>>which require between 80ms and 100ms delay for unimpaired experience.
> >>> forums suggests that users are quite unsatisfied with latencies
> >>> above
> 300ms.
> >>>
> >>>making a  RFC from TCMTF, or a wider scope. I think that perhaps
> >>>more than a draft  would be necessary. I mean, I have been thinking
> >>>about it, and perhaps the  work could be divided into the next parts:
> >>>
> >>> the concrete one to use is static: in the set-up moment, you
> >>>decide that  "between these two routers a tunnel is set including
> >>>all the packets with
> >> this
> >>> could
> >>> some packets asking other routers if they have some flows in
> >>>common with  them, which could be multiplexed.
> >>>
> >>>
> >>> The main questions are:
> >>>

---

From: Mirko Sužnjević <[email-masked]>
Date: Fri, 26 Oct 2012 11:17:05 +0200

Hello all,

Yes this is true,
This was just an example of remote control services for which I found data regarding latency values in the literature.
I think that the most used remote control real time services would be remote desktop. If a whole company accesses one server on which the virtualized PCs are hosted shared network path is very long (especially if you take into consideration clouds). And remote desktop packets are quite small in terms of packet size and therefore good for TCMTF.

Sadly, I have not yet found any data regarding QoS or QoE for those services, but I am sure that there exist somewhere in the literature.

Cheers!
Mirko

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Julián Fernández-Navajas
Sent: Wednesday, October 24, 2012 11:01 AM
To: [email-masked]
Subject: Re: [tcmtf] Next steps with TCMTF

hello all,
Regarding the real-time services suitable for multiplexing, i have a question about the third of them, remote control. I can't think a use case that transmits little packets in order to be multiplexed. Mirko suggests tele-echography but it no seems a use case that traffic needs multiplexion because there are not a lot of users simultaneusly.
Let us thinking about remote control and the possible use cases that can be presented here.

Julián

El 23/10/2012 10:25, Jose Saldana escribió:
> ideas: sensor networks sending a sample, video-surveillance, whatsapp-like applications?
> applications can tolerate up to 5 seconds of delay" (I have just 
> invented the figure, it's only an example).
>

---

From: "Diego R. Lopez" <[email-masked]>
Date: Sat, 27 Oct 2012 08:38:00 +0000

Hi,

Indeed, remote desktop is one of the use cases we have been discussing
internally. We can think of a couple of scenarios in addition to a
pure cloud one. Irrespectively of were the RD server is located, workers
in remote branches could benefit form TCMTF, especially when we think about
heavily distributed organizations (banks, insurance companies, government
agencies, to name a few). Another one could any off-site gathering, requesting
a many temporary simultaneous connection from an otherwise unusual location.

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