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

["Jose Saldana" <[e-mail]>]

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:[e-mail]] 
Enviado el: martes, 15 de enero de 2013 19:39
Para: MANUEL NUÑEZ SANZ; [e-mail]; [e-mail]
Asunto: RE: [tcmtf] TCMTF: Document B discussion: content and charter

 

All,

 

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

 

Michael Ramalho

 

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

 

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.

 

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:

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.

 

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.

 

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

 

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: [e-mail] [mailto:[e-mail]] En nombre de Jose
Saldana
Enviado el: martes, 15 de enero de 2013 11:56
Para: [e-mail]
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/

 

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: [phone]

Ext: 2698

E-mail:  <mailto:[e-mail]> [e-mail]

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

 

 

  _____  


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