Subject: [tcmtf] TCMTF: Document B discussion: content and charter

From: "Jose Saldana" <[email-masked]>
Date: Tue, 15 Jan 2013 11:56:27 +0100

Document (B) refers to the informational draft about maximum tolerable
delays, currently in
http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/

1.- Content of the Document

Currently, the Document specifies the maximum added delays for different
services.

However, the discussion has set clear that other things should be added,
mainly methods for identifying the flows:

Michael: “has any detailed thought about how TCMTF might identify which
flows it should NOT attempt to compress?

Considering "the Internet of things" (where virtually every device is
connected via IP) ... we can expect a lot of small packets ... but not
necessarily know if we should compress them or not (e.g., FPS packets) ...
or what the delay bounds on the compression should be.

Should we mention that flows that signal their own traffic class (e.g.,
using "Metadata" describing the flow) is a good thing to differentiate on?
Should we suggest signature analysis (a probabilistic guess for the
application based on its time-domain signature characteristics) might also
be of utility?”

Fernando had another opinion: “On the other hand,  the selection of flows to
be potentially TCMTFed could be something undefined at the beginning (it may
be statically configured for example), but it is something that will NEED to
be defined to be dynamically enforced at the mux from a higher entity
(policy manager). That functionality would be addressed to a different draft
in the future, re-chartering the WG.”

Jose: “Perhaps a "natural" way could be widening the scope of draft (B),
including not only delay limits, but also currently existing traffic
classification methods which could be useful for selecting the packets to
multiplex. Does this sound well?”

Mirko: “I think there is no need to develop something for traffic
classification in the scope of TCMTF WG. There is a large research community
doing traffic classification and some of the already developed techniques
can be applied for our need. It may be feasible to present an overview of
techniques which could be used by TCMTF in draft B.”

Luigi: “There are tons of classification methods out there, developing a new
one does not look very useful to me.”

Michael: “I agree with Luigi and Mirko ... there are more than enough people
working on traffic flow descriptions ... and how to signal/inform networks
of their requirements (e.g., per-hop behaviors and the like). (…) For now, I
would recommend a placeholder in the draft that addresses the concern and
that TCMTF SHOULD consider the traffic class of the flows when such
information is available.”

So perhaps the solution could be widening the scope of the Document (B) in
order to also include:

                - TCMTF SHOULD consider the traffic class of the flows when
such information is available

                - Suggesting traffic classification methods which could be
useful in order to do this 

What do you think? Is everyone ok with this?

2.- Should we include it in the Charter now?

Of course, Document (B) should be included in the Charter.

Best regards,

Jose

Jose Saldana, PhD

Communications Technologies Group (GTC)
Dpt. Electrical Engineering and Communications
EINA, University of Zaragoza.
C/ María de Luna 1, Edif. Ada Byron, D. 2.05
50018 Zaragoza, Spain

Tel: +34 976 76 2698

Ext: 2698

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

 <http://diec.unizar.es/~jsaldana/personal/index.htm>
http://diec.unizar.es/~jsaldana/personal/index.htm

---

From: MANUEL NUÑEZ SANZ <[email-masked]>
Date: Tue, 15 Jan 2013 12:15:38 +0000

Hi,
  I am going to do one´s bit.

It is true there are tons of classification methods, however the issue is that:

1.       It is not common its use, and therefore it is reasonable to suppose a lot of packets/flows will not be classified.

2.       And even when a flow is classified, it is possible than that classification does not identify the delays for that flow.

Therefore under my opinion (quite similar to Fernando) is that it is necessary the MUX "obtain" the configuration to know than flow are TCMTFed. In that line, there are three different approaches:

1.       A static configuration (as an initial state)

2.       A policy manager dynamically enforces the option for each new flow

3.       The MUX asks for instruction for each "new" flow to an "policy manager" or "controller". This last options is fully compatible with the 2 option.

And answering the question about open the scope of document B. I agree.

Regards,
  Manuel Núñez

De: [email-masked] [mailto:[email-masked]] En nombre de Jose Saldana
Enviado el: martes, 15 de enero de 2013 11:56
Para: [email-masked]
Asunto: [tcmtf] TCMTF: Document B discussion: content and charter

Document (B) refers to the informational draft about maximum tolerable delays, currently in http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/

Currently, the Document specifies the maximum added delays for different services.

However, the discussion has set clear that other things should be added, mainly methods for identifying the flows:

Michael: "has any detailed thought about how TCMTF might identify which flows it should NOT attempt to compress?

Considering "the Internet of things" (where virtually every device is connected via IP) ... we can expect a lot of small packets ... but not necessarily know if we should compress them or not (e.g., FPS packets) ... or what the delay bounds on the compression should be.
Should we mention that flows that signal their own traffic class (e.g., using "Metadata" describing the flow) is a good thing to differentiate on? Should we suggest signature analysis (a probabilistic guess for the application based on its time-domain signature characteristics) might also be of utility?"

Fernando had another opinion: "On the other hand,  the selection of flows to be potentially TCMTFed could be something undefined at the beginning (it may be statically configured for example), but it is something that will NEED to be defined to be dynamically enforced at the mux from a higher entity (policy manager). That functionality would be addressed to a different draft in the future, re-chartering the WG."

Jose: "Perhaps a "natural" way could be widening the scope of draft (B), including not only delay limits, but also currently existing traffic classification methods which could be useful for selecting the packets to multiplex. Does this sound well?"

Mirko: "I think there is no need to develop something for traffic classification in the scope of TCMTF WG. There is a large research community doing traffic classification and some of the already developed techniques can be applied for our need. It may be feasible to present an overview of techniques which could be used by TCMTF in draft B."

Luigi: "There are tons of classification methods out there, developing a new one does not look very useful to me."

Michael: "I agree with Luigi and Mirko ... there are more than enough people working on traffic flow descriptions ... and how to signal/inform networks of their requirements (e.g., per-hop behaviors and the like). (...) For now, I would recommend a placeholder in the draft that addresses the concern and that TCMTF SHOULD consider the traffic class of the flows when such information is available."

So perhaps the solution could be widening the scope of the Document (B) in order to also include:

                - TCMTF SHOULD consider the traffic class of the flows when such information is available

                - Suggesting traffic classification methods which could be useful in order to do this

Best regards,

Jose

Jose Saldana, PhD
E-mail: [email-masked]<mailto:[email-masked]>

________________________________

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: FERNANDO PASCUAL BLANCO <[email-masked]>
Date: Tue, 15 Jan 2013 14:05:49 +0000

Hi all,

What if we define both?

  1.  What Manuel explained in points 2 and 3 (dynamic enforcement of the TCMTF optimization): a northbound interface to do that
  2.  To apply TCMTF optimization based on inline signaling (signaling within the data, as Traffic Class or metadata)

Could both things be defined, and give preference to one of them?

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]>>
Date: martes, 15 de enero de 2013 13:15
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [tcmtf] TCMTF: Document B discussion: content and charter

Hi,

Therefore under my opinion (quite similar to Fernando) is that it is necessary the MUX “obtain” the configuration to know than flow are TCMTFed. In that line, there are three different approaches:

3.       The MUX asks for instruction for each “new” flow to an “policy manager” or “controller”. This last options is fully compatible with the 2 option.

Regards,
  Manuel Núñez

De: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] En nombre de Jose Saldana
Enviado el: martes, 15 de enero de 2013 11:56
Para: [email-masked]<mailto:[email-masked]>
Asunto: [tcmtf] TCMTF: Document B discussion: content and charter

Michael: “has any detailed thought about how TCMTF might identify which flows it should NOT attempt to compress?

Considering "the Internet of things" (where virtually every device is connected via IP) ... we can expect a lot of small packets ... but not necessarily know if we should compress them or not (e.g., FPS packets) ... or what the delay bounds on the compression should be.
Should we mention that flows that signal their own traffic class (e.g., using "Metadata" describing the flow) is a good thing to differentiate on? Should we suggest signature analysis (a probabilistic guess for the application based on its time-domain signature characteristics) might also be of utility?”

Fernando had another opinion: “On the other hand,  the selection of flows to be potentially TCMTFed could be something undefined at the beginning (it may be statically configured for example), but it is something that will NEED to be defined to be dynamically enforced at the mux from a higher entity (policy manager). That functionality would be addressed to a different draft in the future, re-chartering the WG.”

Jose: “Perhaps a "natural" way could be widening the scope of draft (B), including not only delay limits, but also currently existing traffic classification methods which could be useful for selecting the packets to multiplex. Does this sound well?”

Mirko: “I think there is no need to develop something for traffic classification in the scope of TCMTF WG. There is a large research community doing traffic classification and some of the already developed techniques can be applied for our need. It may be feasible to present an overview of techniques which could be used by TCMTF in draft B.”

Luigi: “There are tons of classification methods out there, developing a new one does not look very useful to me.”

Michael: “I agree with Luigi and Mirko ... there are more than enough people working on traffic flow descriptions ... and how to signal/inform networks of their requirements (e.g., per-hop behaviors and the like). (…) For now, I would recommend a placeholder in the draft that addresses the concern and that TCMTF SHOULD consider the traffic class of the flows when such information is available.”

Best regards,

Jose

Jose Saldana, PhD

---

From: "Michael Ramalho (mramalho)" <[email-masked]>
Date: Tue, 15 Jan 2013 18:38:45 +0000

All,

My comments are in-line below (with "MAR:").

Michael Ramalho

From: [email-masked] [mailto:[email-masked]] On Behalf Of MANUEL NUÑEZ SANZ
Sent: Tuesday, January 15, 2013 7:16 AM
To: [email-masked]; [email-masked]
Subject: Re: [tcmtf] TCMTF: Document B discussion: content and charter

Hi,

MAR: True. But, given the move to the "Internet of [Things|Everything]" as I mentioned previously, the industry will soon send some type of "traffic class indication" to the network to help the network optimize itself. Until that day occurs, if you know: 1) NOTHING about the flow, AND 2) but believe it may be a "real-time flow" AND 3) to TCMTF a packet from that flow would add more than a few milliseconds of delay ... you probably should not TCMTF it.

MAR: "Real-time" is defined here as a packet relating to some human response time type of application (e.g., remote desktop virtualization sent over TCP might be considered "real-time").

MAR: Most real-time traffic classifiers DO NOT specify a hard limit on the "per-hop" added delay. But would you delay a TCP flow that said it was a "Voice packet" by 1000 milliseconds by TCMTFing it? Before you think that wouldn't ever  happen, there a lot of real time packets sent over TCP to get through firewals after all attempts to send such a packet over UDP fails. As an aside, signature analysis could help in these cases.

MAR: Note that most of my concern is moot when TCMTF is operating on high rate output links - as most compressions will result in TCMTF delays of less than a few milliseconds.

MAR: A "good TCMTF tunneling function" should make an intelligent decision regarding what flows it thinks is acceptable to TCMTF and which it should not. We need to allow room for products to differentiate themselves. Thus, I think we ought to provide some guidance without being overly prescriptive. I think we should error on the side of acknowledging the issue and providing guidance to implementers via a "SHOULD strength" requirement in the draft.

Regards,
  Manuel Núñez

[MAR: Does anyone know how I tell MSFT Outlook that I don't want to reply in Spanish ... it keeps "correcting" my American English reply with incorrect Spanish words!]

Best regards,

Jose

Jose Saldana, PhD

---

From: "Jose Saldana" <[email-masked]>
Date: Wed, 16 Jan 2013 11:15:04 +0100

Hi all,

I think we agree on this (if not, please report it):

#1 Document B has to be in the Charter

#2 Document B has to specify maximum delays for different services

#3 Document B has to include some recommendations about the use of traffic
classification methods

So the question is now related to #3:

How to include that recommendations about traffic classification methods:
putting a SHOULD or not, etc.

But my question:

Do we need to decide this now? Is this decision necessary in order to write
the Charter? Perhaps it is not, and we can go ahead with it. My proposal for
the paragraph about Document (B) in the Charter: 

6. In addition, TCMTF may save bandwidth but, as a counterpart, some delay
and jitter will be added. This is not a problem for the services which are
not sensitive to delay. However, regarding delay-sensitive services, the
Working Group will also develop a document (B) with recommendations which
can be useful in order to decide which packet flows can or can not be
multiplexed: recommendations about the use of available traffic
classification methods; the maximum delay and jitter to be added to each
kind of service or application; other recommendations can be included if
necessary. Empirical research studies with real users will be necessary in
order to establish this set of recommendations.

What do you think? Do you like this paragraph for the Charter? Improvement
suggestions will be welcome.

Best reards,

Jose

De: Michael Ramalho (mramalho) [mailto:[email-masked]] 
Enviado el: martes, 15 de enero de 2013 19:39
Para: MANUEL NUÑEZ SANZ; [email-masked]; [email-masked]
Asunto: RE: [tcmtf] TCMTF: Document B discussion: content and charter

All,

My comments are in-line below (with “MAR:“).

Michael Ramalho

From: [email-masked] [mailto:[email-masked]] On Behalf Of
MANUEL NUÑEZ SANZ
Sent: Tuesday, January 15, 2013 7:16 AM
To: [email-masked]; [email-masked]
Subject: Re: [tcmtf] TCMTF: Document B discussion: content and charter

Hi, 

It is true there are tons of classification methods, however the issue is
that:

1.       It is not common its use, and therefore it is reasonable to suppose
a lot of packets/flows will not be classified.

MAR: True. But, given the move to the “Internet of [Things|Everything]” as I
mentioned previously, the industry will soon send some type of “traffic
class indication” to the network to help the network optimize itself. Until
that day occurs, if you know: 1) NOTHING about the flow, AND 2) but believe
it may be a “real-time flow” AND 3) to TCMTF a packet from that flow would
add more than a few milliseconds of delay … you probably should not TCMTF
it.

MAR: “Real-time” is defined here as a packet relating to some human response
time type of application (e.g., remote desktop virtualization sent over TCP
might be considered “real-time”).

2.       And even when a flow is classified, it is possible than that
classification does not identify the delays for that flow.

MAR: Most real-time traffic classifiers DO NOT specify a hard limit on the
“per-hop” added delay. But would you delay a TCP flow that said it was a
“Voice packet” by 1000 milliseconds by TCMTFing it? Before you think that
wouldn’t ever  happen, there a lot of real time packets sent over TCP to get
through firewals after all attempts to send such a packet over UDP fails. As
an aside, signature analysis could help in these cases.

MAR: Note that most of my concern is moot when TCMTF is operating on high
rate output links – as most compressions will result in TCMTF delays of less
than a few milliseconds.

Therefore under my opinion (quite similar to Fernando) is that it is
necessary the MUX “obtain” the configuration to know than flow are TCMTFed.
In that line, there are three different approaches:

3.       The MUX asks for instruction for each “new” flow to an “policy
manager” or “controller”. This last options is fully compatible with the 2
option.

MAR: A “good TCMTF tunneling function” should make an intelligent decision
regarding what flows it thinks is acceptable to TCMTF and which it should
not. We need to allow room for products to differentiate themselves. Thus, I
think we ought to provide some guidance without being overly prescriptive. I
think we should error on the side of acknowledging the issue and providing
guidance to implementers via a “SHOULD strength” requirement in the draft.

Regards, 

  Manuel Núñez

[MAR: Does anyone know how I tell MSFT Outlook that I don’t want to reply in
Spanish … it keeps “correcting” my American English reply with incorrect
Spanish words!] 

De: [email-masked] [mailto:[email-masked]] En nombre de Jose
Saldana
Enviado el: martes, 15 de enero de 2013 11:56
Para: [email-masked]
Asunto: [tcmtf] TCMTF: Document B discussion: content and charter

 

 

Best regards,

Jose

Jose Saldana, PhD

Tel: +34 976 76 2698

Ext: 2698

 

  _____  

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: FERNANDO PASCUAL BLANCO <[email-masked]>
Date: Wed, 16 Jan 2013 10:46:02 +0000

Hi Jose,

I think it should be enough. The paragraph address the added delay issue y proposes recommendations on how to deal with it. In addition, the sentence "available traffic classification methods" is wide enough to let us propose very different suggestions about traffic classification.

Regards,

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: miércoles, 16 de enero de 2013 11:15
To: "'Michael Ramalho (mramalho) '" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Fernando Pascual Blanco <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [tcmtf] TCMTF: Document B discussion: content and charter

Hi all,

#1 Document B has to be in the Charter
#2 Document B has to specify maximum delays for different services
#3 Document B has to include some recommendations about the use of traffic classification methods

How to include that recommendations about traffic classification methods: putting a SHOULD or not, etc.

But my question:

Do we need to decide this now? Is this decision necessary in order to write the Charter? Perhaps it is not, and we can go ahead with it. My proposal for the paragraph about Document (B) in the Charter:

6. In addition, TCMTF may save bandwidth but, as a counterpart, some delay and jitter will be added. This is not a problem for the services which are not sensitive to delay. However, regarding delay-sensitive services, the Working Group will also develop a document (B) with recommendations which can be useful in order to decide which packet flows can or can not be multiplexed: recommendations about the use of available traffic classification methods; the maximum delay and jitter to be added to each kind of service or application; other recommendations can be included if necessary. Empirical research studies with real users will be necessary in order to establish this set of recommendations.

What do you think? Do you like this paragraph for the Charter? Improvement suggestions will be welcome.

Best reards,

Jose

De: Michael Ramalho (mramalho) [mailto:[email-masked]]
Enviado el: martes, 15 de enero de 2013 19:39
Para: MANUEL NUÑEZ SANZ; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Asunto: RE: [tcmtf] TCMTF: Document B discussion: content and charter

All,

Michael Ramalho

From:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of MANUEL NUÑEZ SANZ
Sent: Tuesday, January 15, 2013 7:16 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [tcmtf] TCMTF: Document B discussion: content and charter

Hi,

MAR: True. But, given the move to the “Internet of [Things|Everything]” as I mentioned previously, the industry will soon send some type of “traffic class indication” to the network to help the network optimize itself. Until that day occurs, if you know: 1) NOTHING about the flow, AND 2) but believe it may be a “real-time flow” AND 3) to TCMTF a packet from that flow would add more than a few milliseconds of delay … you probably should not TCMTF it.

MAR: “Real-time” is defined here as a packet relating to some human response time type of application (e.g., remote desktop virtualization sent over TCP might be considered “real-time”).

MAR: Most real-time traffic classifiers DO NOT specify a hard limit on the “per-hop” added delay. But would you delay a TCP flow that said it was a “Voice packet” by 1000 milliseconds by TCMTFing it? Before you think that wouldn’t ever  happen, there a lot of real time packets sent over TCP to get through firewals after all attempts to send such a packet over UDP fails. As an aside, signature analysis could help in these cases.

MAR: Note that most of my concern is moot when TCMTF is operating on high rate output links – as most compressions will result in TCMTF delays of less than a few milliseconds.

MAR: A “good TCMTF tunneling function” should make an intelligent decision regarding what flows it thinks is acceptable to TCMTF and which it should not. We need to allow room for products to differentiate themselves. Thus, I think we ought to provide some guidance without being overly prescriptive. I think we should error on the side of acknowledging the issue and providing guidance to implementers via a “SHOULD strength” requirement in the draft.

Regards,
  Manuel Núñez

[MAR: Does anyone know how I tell MSFT Outlook that I don’t want to reply in Spanish … it keeps “correcting” my American English reply with incorrect Spanish words!]

De:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]] En nombre de Jose Saldana
Enviado el: martes, 15 de enero de 2013 11:56
Para: [email-masked]<mailto:[email-masked]>
Asunto: [tcmtf] TCMTF: Document B discussion: content and charter

Best regards,

Jose

Jose Saldana, PhD