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

[MANUEL NUÑEZ SANZ <[e-mail]>]

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: [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: [e-mail]<mailto:[e-mail]>
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