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

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

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