Re: [tcmtf] Traffic classification approach for tcmtf (Draft B)

[FERNANDO PASCUAL BLANCO <[e-mail]>]

Hi,

I fully agree with Michael´s opinion, a guidance on how to achieve an optimal behavior should be enough.

Regards,

Fernando Pascual Blanco
Telefónica Global Resources
Network Automation and Dynamization
TECHNOLOGY PEOPLE GROUP
F [phone]
M [phone]
[e-mail]

From: Mirko Sužnjević <[e-mail]<mailto:[e-mail]>>
Date: miércoles, 27 de febrero de 2013 10:23
To: "'Michael Ramalho (mramalho) '" <[e-mail]<mailto:[e-mail]>>, Fernando Pascual Blanco <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: [tcmtf] Traffic classification approach for tcmtf (Draft B)

Hello,
Thanks for the advices. I will use the suggested terminology in the draft. The procedure you described is how I envisioned it to function as well.
We will make sure that specification is flexible enough to allow to make such optimizations. Thanks again for the help.
Cheers!
Mirko Suznjevic

From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Michael Ramalho (mramalho)
Sent: Tuesday, February 26, 2013 9:07 PM
To: FERNANDO PASCUAL BLANCO; Mirko Sužnjević; [e-mail]<mailto:[e-mail]>
Subject: Re: [tcmtf] Traffic classification approach for tcmtf (Draft B)

Fernando/Mirko,

Please replace your use of the term “priority” with “delay sensitive class”.

Priority is a term usually reserved for packets already CLASSIFIED as belonging to a class in which such packets are delivered to a priority queue (in comparison to, let’s say a WFQ such as a class-based WFQ).

Thus I would have described your technique as TCMTF CLASSIFICATIONS based on their assumed delay sensitivity.

Until you know better, you classify a packet as belonging to the most-stringent delay sensitivity class (Fernando’s “Class A”). That is, you don’t hold it for too long if you know nothing about the flow.

Thus, packets classified as “Class A” in delay sensitivity are either: 1) packets KNOWN to have the highest delay sensitivity, or 2) have not been classified as a lower delay sensitivity class (Fernando’s class B or C) yet.

When it is time that you need to push a not-close-to-MTU size class A compressed payload (because you don’t want to hold it for more than a few milliseconds) – you can always “fill up the class A compression payload” with payloads from the lower classes (if you exhaust all class B possibilities, you could then include any class C payloads).

Ditto for a not-close-to-MTU size class B compressed payload when you approach the time that you need to push it (the oldest data in it is nearing the maximum class B hold time) – you can “fill it up” with any Class C payloads.

Assuming only three delay sensitivity classifications (here A, B and C) – you need to push any class C compression payloads when the oldest data in it is nearing the maximum class C hold time - even if it is not close to MTU-sized yet.

For what it is worth, I always assumed that TCMTF would ALLOW for designers of TCMTF equipment to make such optimizations – as this is especially needed for low speed links. That is, our specification MUST allow for this – the question is if the base specification should provide guidance or example use cases for some of these TCMTF tradeoffs. I am inclined NOT to mandate such behavior and only to provide example guidance on how one could achieve the goal of having a good delay sensitivity architecture.

Michael Ramalho

From:[e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of FERNANDO PASCUAL BLANCO
Sent: Tuesday, February 26, 2013 8:44 AM
To: Mirko Sužnjević; [e-mail]<mailto:[e-mail]>
Cc: Michael Ramalho (mramalho)
Subject: Re: [tcmtf] Traffic classification approach for tcmtf (Draft B)

Hi all,

Regarding the classification approach: I think your approach is valid, nevertheless I would add the following assumption. Imagine the following scenario:

  *   Imagine you have 3 different priorities: A (with the lower multiplexing period) to C (with the higher multiplexing period)
  *   Imagine you have 2 flows: one flow A with priority A and another flow C with priority C
  *   Flow A goes into the priority A, but there is still room in that queue for more flows (flow A does not fill big packets).

Should we apply priority C to flow C? Or should we apply priority A? We have to take into account that the more flows to be multiplexed, the better the TCMTF works. In that case, mixing flows A and C in priority A helps the algorithm to work better and improve the RTT of both flows. Nevertheless, we should only apply that assumption when the highest priority is NOT full of flows, let´s say.

What do you think?

Regards,

Fernando Pascual Blanco
Telefónica Global Resources
Network Automation and Dynamization
TECHNOLOGY PEOPLE GROUP
F [phone]
M [phone]
[e-mail]<mailto:[e-mail]>

From: Mirko Sužnjević <[e-mail]<mailto:[e-mail]>>
Date: jueves, 21 de febrero de 2013 11:48
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "'Michael Ramalho (mramalho) '" <[e-mail]<mailto:[e-mail]>>
Subject: [tcmtf] Traffic classification approach for tcmtf (Draft B)

Hello everybody,
I have been surveying the literature of traffic classification approaches and I need an advice for the next version of draft B. The question is regarding a "suitable" traffic classification algorithm. What should we aim at? Speed or extra accuracy?
I have been thinking about it and I propose a following solution:

1)      Each new traffic flow observed is labeled "highest" priority (shortest multiplexing period) until we classify it. The time spent in this state might get rather long for the flows with low sending rate.

2)      Once classified and then assign it to an appropriate priority (i.e., multiplexing period)?


Also I have a question regarding sampling rate. Do you think it is possible that we will have complete samples of traffic or just partial for the classification? Because on very high speed links it is very hard to obtain all of the traffic for classification.

Cheers!
Mirko Suznjevic


________________________________

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

________________________________

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