Subject: [tcmtf] Next steps with TCMTF

From: "Jose Saldana" <[email-masked]>
Date: Thu, 27 Sep 2012 12:31:18 +0200

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

---

From: FERNANDO PASCUAL BLANCO <[email-masked]>
Date: Thu, 27 Sep 2012 15:08:19 +0000

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:

>_______________________________________________
>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: Gonzalo Camarillo <[email-masked]>
Date: Thu, 27 Sep 2012 18:33:24 +0300

Hi Jose Maria,

if the idea is to create a WG to work on these drafts, what you need to
do is to propose a draft charter, polish it on this list, and then
present it to Wes and Martin at some point so that they can create the WG.

You have many examples of charters on the IETF WG pages, of course.

Cheers,

Gonzalo

---

From: "Jose Saldana" <[email-masked]>
Date: Thu, 27 Sep 2012 17:52:52 +0200

Thanks, Gonzalo. As you suggest, a good approach could be hearing and
discussing people's opinions about the work to be deployed, and build a
charter with that.

 I think that next week I could build a first version of the charter, and
then we could polish it on the list.

Thank you,

Jose

> -----Mensaje original-----
> De: [email-masked] [mailto:[email-masked]] En nombre de
> Gonzalo Camarillo
> Enviado el: jueves, 27 de septiembre de 2012 17:33
> Para: FERNANDO PASCUAL BLANCO
> CC: [email-masked]; Wesley Eddy; Martin Stiemerling; [email-masked]
> Asunto: Re: [tcmtf] Next steps with TCMTF
> 
> Hi Jose Maria,
> 
> if the idea is to create a WG to work on these drafts, what you need to do
is
> to propose a draft charter, polish it on this list, and then present it to
Wes
> and Martin at some point so that they can create the WG.
> 
> >         I absolutely agree with your classification. Nevertheless I
> > miss a draft explaining how to deal with different QoS flows passing
> > through a TCMTF
> >> 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".
> >>
> >> c) "Dynamic Signaling draft": perhaps another one including a
> >> signaling system in order to:
> >>       - 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.
> >>
> > 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: "Jose Saldana" <[email-masked]>
Date: Fri, 28 Sep 2012 11:19:29 +0200

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.

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.

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.

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
 
> FERNANDO PASCUAL BLANCO
> Enviado el: jueves, 27 de septiembre de 2012 17:08
> Para: [email-masked]; [email-masked]
> CC: Wesley Eddy; Martin Stiemerling
> >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:
> >
> >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".
> >
> >related to the selection of the best compression algorithm to use, etc.
> >Some hypothetical examples:
> >don't need to use ROHC. A simpler scheme like IPHC can be enough, and
> >it will not require a lot of processing capacity".
> >
> >send some packets asking other routers if they have some flows in
> >common with them, which could be multiplexed.
> >
> >
> >The main questions are:
> >

---

From: <[email-masked]>
Date: Fri, 28 Sep 2012 15:02:47 +0200

Hello, 

I agree on this approach: to launch a WG.

Thank you.

BR 

Sophie Nachman-Ghnassia
France Telecom  Orange

-----Message d'origine-----
De : Jose Saldana [mailto:[email-masked]] 
Envoyé : jeudi 27 septembre 2012 17:53
À : 'Gonzalo Camarillo'
Cc : [email-masked]
Objet : Re: [tcmtf] Next steps with TCMTF

Thank you,

Jose

is
Wes
> > http://www.tid.es/ES/PAGINAS/disclaimer.aspx

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Mirko Sužnjević <[email-masked]>
Date: Sat, 29 Sep 2012 13:10:18 +0200

Regarding the "Recommendations draft", we are currently in a process of applying a general purpose Quality of Experience model for one type of games (MMORPGs).
We will for sure investigate the influence of delay (among other things) on MMORPGs and can also provide some information regarding other game types. 
We in Zagreb are studying these problems, so we may also participate on the draft or collaborate in this area in general. 

There has been quite a number of papers describing the delay influence on performance in First Person Shooters (FPS), and also other game types.
So as our group has some expertise in this area we can provide you with some numbers, as well as to provide QoE data which supports the numbers.

If i may suggest a table comprising different game types and limits on which significant QoE (or QoS) degradation starts to occur.
Would that be appropriate?

Cheers!
Mirko Suznjevic

-----Original Message-----
From: [email-masked] on behalf of Jose Saldana
Sent: čet 27.9.2012 12:31
To: [email-masked]
Cc: Wesley Eddy; Martin Stiemerling
Subject: [tcmtf] Next steps with TCMTF
 
Hello all,

 

The main questions are:

Thanks in advance,

Jose