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

["Michael Ramalho (mramalho)" <[e-mail]>]

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