Subject: [tcmtf] TCMTF: two kinds of services

From: "Jose Saldana" <[email-masked]>
Date: Fri, 28 Sep 2012 11:17:17 +0200

This is another thought to be discussed. We can have two different
situations for multiplexing flows:

- delay-sensitive services (e.g., VoIP, online games). In this case, TCMTF
would add some delay, so it should only be used when bandwidth is scarce
(rush hours, new game release, etc.). If your network is working properly,
why do you need to save bandwidth and add a small delay to the clients? So
in rush hours there must be a counterpart in order to add some priority to
the tunneled packets. Otherwise you would penalize them: since they are
small and can be multiplexed, they are delayed.

- services sending small packets but not delay-sensitive (e.g., whatsapp,
m2m packets being generated every second). In this case TCMTF saves
bandwidth while adding some delay, but it is not critical.

Jose

---

From: FERNANDO PASCUAL BLANCO <[email-masked]>
Date: Fri, 28 Sep 2012 11:20:18 +0000

Hi Jose,

You are talking about dynamically apply TCMTF, and yes, this is a very interesting aspect. This is different from the third draft you proposed in order to dynamically negotiate TCMTF parameters between multiplexer and demultiplexer, that would be a higher entity in charge of decide when and where or not to apply TCMTF, and what kind of TCMTF. As operator, we have a lot of knowledge in those kind of policies. I have several colleagues that can talk about that issue.

Regards,

Fernando Pascual Blanco
Telefónica Global Resources
Network Automation and Dynamization
TECHNOLOGY PEOPLE GROUP
F +34913128779
M +34682005168
[email-masked]

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: viernes 28 de septiembre de 2012 11:17
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [tcmtf] TCMTF: two kinds of services

This is another thought to be discussed. We can have two different situations for multiplexing flows:

- delay-sensitive services (e.g., VoIP, online games). In this case, TCMTF would add some delay, so it should only be used when bandwidth is scarce (rush hours, new game release, etc.). If your network is working properly, why do you need to save bandwidth and add a small delay to the clients? So in rush hours there must be a counterpart in order to add some priority to the tunneled packets. Otherwise you would penalize them: since they are small and can be multiplexed, they are delayed.

- services sending small packets but not delay-sensitive (e.g., whatsapp, m2m packets being generated every second). In this case TCMTF saves bandwidth while adding some delay, but it is not critical.

Jose

________________________________

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