Subject: Re: [tcmtf] : New Version Notification for draft-saldana-tsvwg-tcmtf-04.txt

From: "Michael Ramalho (mramalho)" <[email-masked]>
Date: Wed, 9 Jan 2013 17:05:18 +0000

Jose, et. al.,

Sorry for being so quiet recently on this list ... I am just beginning to become unburied from work late last year!

You mention FPS and MMORPGs in the draft ... but 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?

Being silent on this point may lessen the attractiveness to design using it.

Sorry if this point has been raised before.

Best,

Michael Ramalho

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jose Saldana
Sent: Wednesday, January 09, 2013 4:29 AM
To: [email-masked]
Subject: [tcmtf] RV: New Version Notification for draft-saldana-tsvwg-tcmtf-04.txt

I have just uploaded a new version of the tcmtf draft.

Jose

> -----Mensaje original-----
> De: [email-masked] [mailto:[email-masked]] Enviado 
> el: miércoles, 09 de enero de 2013 10:25
> Para: [email-masked]
> CC: [email-masked]; [email-masked]; [email-masked]; [email-masked]
> Asunto: New Version Notification for draft-saldana-tsvwg-tcmtf-04.txt
> 
> 
> A new version of I-D, draft-saldana-tsvwg-tcmtf-04.txt has been 
> successfully submitted by Jose Saldana and posted to the IETF repository.
> 
> Filename:	 draft-saldana-tsvwg-tcmtf
> Revision:	 04
> Title:		 Tunneling Compressed Multiplexed Traffic Flows (TCMTF)
> Creation date:	 2013-01-09
> WG ID:		 Individual Submission
> Number of pages: 19
> URL:             http://www.ietf.org/internet-drafts/draft-saldana-tsvwg-tcmtf-
> 04.txt
> Status:          http://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf
> Htmlized:        http://tools.ietf.org/html/draft-saldana-tsvwg-tcmtf-04
> Diff:            http://www.ietf.org/rfcdiff?url2=draft-saldana-tsvwg-tcmtf-04
> 
> Abstract:
>    This document describes a method to improve the bandwidth utilization
>    of network paths that carry multiple streams in parallel sharing a
>    common path.  The method combines standard protocols that provide
>    compression, multiplexing, and tunneling over a network path for the
>    purpose of reducing the bandwidth used when multiple streams are
>    carried over that path.
> 
> 
> 
> 
> The IETF Secretariat

_______________________________________________
tcmtf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcmtf

---

From: "Jose Saldana" <[email-masked]>
Date: Thu, 10 Jan 2013 11:35:21 +0100

Hi, Michael.

I have been thinking about your mail. The question is how to identify the flows. We can use two examples:

Case 1: You are a network operator and you have an agreement with a networked gaming company. So you are trying to merge flows belonging to the same game, and send them multiplexed to the demux located at the game company. So your network has to be able to identify those flows and send them to the mux. So you would need a sort of "Deep Packet Inspection", I think. One solution: all the packets with a certain destination IP go to the mux. The servers of the game are clearly identified by their IPs.

Case 2: But what happens if you only want to save bandwidth inside your network?: you have to compress traffic before traversing a certain path with scarce bandwidth. So you will have to identify "flows" of packets with a cadence, and some common characteristics. In this case, you may need to use "signature analysis" or something, in order to know the game genre, etc, and thus being able to set a maximum multiplexing period, for example.

But I don't know if the question of identifying the flows has to be solved by TCMTF. There should be other machine that sends to the mux only the packets that have to be multiplexed.... or not?

Jose

> De: Michael Ramalho (mramalho) [mailto:[email-masked]]
> Enviado el: miércoles, 09 de enero de 2013 18:05
> Para: [email-masked]; [email-masked]
> Asunto: RE: [tcmtf] : New Version Notification for draft-saldana-tsvwg-tcmtf-
> 04.txt
> 
> Jose, et. al.,
> 
> You mention FPS and MMORPGs in the draft ... but 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?
>

---

From: FERNANDO PASCUAL BLANCO <[email-masked]>
Date: Thu, 10 Jan 2013 11:15:58 +0000

Hi Jose,

        I fully agree with you. TCMTF module could be embedded within a router or
not, and the decision to apply TCMTF to a flow (and the way to signal
that) or not is something that under my point of view is out of the scope
of drafts A and B. Once defined the core TCMTF functionality we can build
things around it.

Regards,

Fernando Pascual Blanco
Telefónica Global Resources
Network Automation and Dynamization
TECHNOLOGY PEOPLE GROUP
F +34913128779
M +34682005168
[email-masked]

On 10/01/13 11:35, "Jose Saldana" <[email-masked]> wrote:

>Case 1: You are a network operator and you have an agreement with a
>networked gaming company. So you are trying to merge flows belonging to
>the same game, and send them multiplexed to the demux located at the game
>company. So your network has to be able to identify those flows and send
>them to the mux. So you would need a sort of "Deep Packet Inspection", I
>think. One solution: all the packets with a certain destination IP go to
>the mux. The servers of the game are clearly identified by their IPs.
>
>Case 2: But what happens if you only want to save bandwidth inside your
>network?: you have to compress traffic before traversing a certain path
>with scarce bandwidth. So you will have to identify "flows" of packets
>with a cadence, and some common characteristics. In this case, you may
>need to use "signature analysis" or something, in order to know the game
>genre, etc, and thus being able to set a maximum multiplexing period, for
>example.
>
>But I don't know if the question of identifying the flows has to be
>solved by TCMTF. There should be other machine that sends to the mux only
>the packets that have to be multiplexed.... or not?
>
>Jose
>
>> Sorry for being so quiet recently on this list ... I am just beginning
>>to become
>> unburied from work late last year!
>>
>> Subject: [tcmtf] RV: New Version Notification for
>>draft-saldana-tsvwg-tcmtf-
>> 04.txt
>>
>> > URL:
>>http://www.ietf.org/internet-drafts/draft-saldana-tsvwg-tcmtf-
>> > 04.txt
>> > Status:
>>http://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf
>> > Htmlized:
>>http://tools.ietf.org/html/draft-saldana-tsvwg-tcmtf-04
>> > Diff:
>>http://www.ietf.org/rfcdiff?url2=draft-saldana-tsvwg-tcmtf-04
>> >
>> > Abstract:

________________________________

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: "Michael Ramalho (mramalho)" <[email-masked]>
Date: Thu, 10 Jan 2013 14:48:23 +0000

All,

I'll answer Fernando and Jose at the same time, with "MAR:" below.

Michael Ramalho

-----Original Message-----
From: FERNANDO PASCUAL BLANCO [mailto:[email-masked]] 
Sent: Thursday, January 10, 2013 6:16 AM
To: [email-masked]; Michael Ramalho (mramalho); [email-masked]
Subject: Re: [tcmtf] : New Version Notification for draft-saldana-tsvwg-tcmtf-04.txt

Hi Jose,

        I fully agree with you. TCMTF module could be embedded within a router or not, and the decision to apply TCMTF to a flow (and the way to signal
that) or not is something that under my point of view is out of the scope of drafts A and B.

MAR: First of all, "we" defined drafts A and B ... we can define other drafts or other working group charters/proposals. However ...

MAR: I disagree ... I think this happens to be partially addressed in draft B (http://www.ietf.org/id/draft-suznjevic-tsvwg-mtd-tcmtf-00.pdf ).

<MAR:>
Consider the following ... a potential TCMTF endpoint sees two small UDP packets ... and lets further assume that it cannot tell by inspection the applications the small packets belong to.

One of the packets belong to a First Person Shooter (FPS) game (very low latency desired) and the other from my home thermostat (reporting my nominal house temperature to a service in the cloud).

My home thermostat also previously sent metadata (a traffic class flow identifier) telling all hops on the path that my packet is relatively delay insensitive (maybe via a STUN packet) ... and it doesn't mind if any particular hop adds even 200 ms of per-hop delay.

Wouldn't it make sense that TCMTF assumes my thermostat flow is a strong candidate and the FPS isn't a candidate unless it arrived "just/immediately before" a TCMTF packet creation?

The bottom line is that (deep) packet inspection will only get you so far. Indeed some VXI protocol designs are being modified so that they can be "more easily" identified by routers (by headers early in the packet payloads) - until this point there was no effort to do so and it is very, very difficult (in general) to determine a "delay tolerance" by simply looking at a particular packet. Even more so with packet encryption ;-).

When the "internet of things" is here ... we will have lots of small packets ... the exact application where TCMTF has its strongest use case. And most of these small packets will have very loose delay bounds (long nominal reporting intervals or periodic keep-alives for firewalls/NATs/etc.).
</MAR:>

Once defined the core TCMTF functionality we can build things around it.

MAR: True. But equally true is that if you DON'T specify useful criteria on how you classify candidate TCMTF flows ... it may not be seriously considered.

MAR: A good example is the "voice communications" item in Table 1 of draft B. If the RTP voice flow was a push-to-talk flow ... then I could agree to up to a 80ms mux delay. For a normal voice call, 80ms is WAY, WAY too much delay (most VoIP calls use ptime of 20ms for a reason!). If you knew a packet was a voice packet (via RTP inspection) ... but additionally knew it belonged for a push-to-talk service ... you could TCMTF it. So you really need to have more knowledge than just "it is a packet of G.722.2 voice" to make a decision. As an aside, the reference for Table 1 (of draft B) is not rigorous enough for the use claimed (you can find hundreds of references that would disagree with the 80 ms maximum recommendation).

Regards,

Fernando Pascual Blanco

On 10/01/13 11:35, "Jose Saldana" <[email-masked]> wrote:

>the same game, and send them multiplexed to the demux located at the 
>game company. So your network has to be able to identify those flows 
>and send them to the mux. So you would need a sort of "Deep Packet 
>Inspection", I think.

MAR: As per my reply to Fernando above, DPI will only get you so far. There are a lot of applications using UDP in which you cannot make a definitive association between the packet and a particular service.

MAR: However, when TCMTF is used on a "high-enough" speed link, the delay can be arbitrarily small. Thus I think some TCMTF guidance is primarily needed for low-speed links (i.e., links where the mux delay could be in excess of some reasonable bound, like 5 ms maximum).

>One solution: all the packets with a certain 
>destination IP go to the mux. The servers of the game are clearly identified by their IPs.

MAR: As an aside, if the network operator had such an agreement ... they would know a priori something about the aggregate flows to the networked game company. They could also determine this from metadata without any "special arrangement".

MAR: However, even this is not general enough. We already have applications that for a particular source and destination IP address/port have different QoS treatment (e.g., SVC video - different packets have different QoS requirements for the same flow).

MAR: I think capabilities negotiation (another thread) should include a notion of "what types of flows" to consider TCMTFing. Without it, I think TCMTF could make some poor decisions (not on efficiency, the dimension upon which it always wins - but on delay) which may, in turn, create impedance for its acceptance.

>need to use "signature analysis" or something, in order to know the 
>game genre, etc, and thus being able to set a maximum multiplexing 
>period, for example.
>
>solved by TCMTF.

MAR: I was not arguing for "solving" the flow identification problem at this stage ... just mentioning it now would make sense ... and that techniques such as exploiting any metadata information for the flow and/or signature analysis could be used for the TCMTF determination. Eventually, I think we need to mention how capabilities negotiation can include flow types too.

>There should be other machine that sends to the mux 
>only the packets that have to be multiplexed.... or not?
>
>Jose
>
>> De: Michael Ramalho (mramalho) [mailto:[email-masked]]  Enviado 
>>el: miércoles, 09 de enero de 2013 18:05
>> Sorry for being so quiet recently on this list ... I am just 
>>beginning to become  unburied from work late last year!
>>
>> You mention FPS and MMORPGs in the draft ... but has any detailed 
>>thought  about how TCMTF might identify which flows it should NOT 
>>attempt to  compress?
>>
>>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?
>>

---

From: "Jose Saldana" <[email-masked]>
Date: Fri, 11 Jan 2013 09:50:24 +0100

Michael,

I think this discussion is getting more and more interesting. Thanks.

You talk about methods for identifying the different packets, and it is
interesting, since it would make things work really better: the multiplexer
would know which packets can and which ones can not be multiplexed.

One question here is that perhaps the developer of the application to be
multiplexed wouldn't want to add anything to its protocol. I mean, if I am
the network provider and I want to save bandwidth in my network, I only have
the packets as they have been sent by the final application.

So the question is: are you proposing that we should develop something
within TCMTF WG in order to classify packets? Perhaps this is too much,
since there will be other people thinking about traffic classification with
other objectives.

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?

Jose

> Enviado el: jueves, 10 de enero de 2013 15:48
> Para: FERNANDO PASCUAL BLANCO; [email-masked]; [email-masked]
>         I fully agree with you. TCMTF module could be embedded within a
router
> or not, and the decision to apply TCMTF to a flow (and the way to signal
of
> drafts A and B.
> 
> MAR: First of all, "we" defined drafts A and B ... we can define other
drafts or
> other working group charters/proposals. However ...
> 
> MAR: I disagree ... I think this happens to be partially addressed in
draft B
> (http://www.ietf.org/id/draft-suznjevic-tsvwg-mtd-tcmtf-00.pdf ).
> 
> <MAR:>
> Consider the following ... a potential TCMTF endpoint sees two small UDP
> packets ... and lets further assume that it cannot tell by inspection the
> applications the small packets belong to.
> 
> One of the packets belong to a First Person Shooter (FPS) game (very low
> latency desired) and the other from my home thermostat (reporting my
> nominal house temperature to a service in the cloud).
> 
> My home thermostat also previously sent metadata (a traffic class flow
> identifier) telling all hops on the path that my packet is relatively
delay
> insensitive (maybe via a STUN packet) ... and it doesn't mind if any
particular
> hop adds even 200 ms of per-hop delay.
> 
> Wouldn't it make sense that TCMTF assumes my thermostat flow is a strong
> candidate and the FPS isn't a candidate unless it arrived
"just/immediately
> before" a TCMTF packet creation?
> 
> The bottom line is that (deep) packet inspection will only get you so far.
> Indeed some VXI protocol designs are being modified so that they can be
> "more easily" identified by routers (by headers early in the packet
payloads)
> - until this point there was no effort to do so and it is very, very
difficult (in
> general) to determine a "delay tolerance" by simply looking at a
particular
> packet. Even more so with packet encryption ;-).
> 
> When the "internet of things" is here ... we will have lots of small
packets ...
> the exact application where TCMTF has its strongest use case. And most of
> these small packets will have very loose delay bounds (long nominal
> reporting intervals or periodic keep-alives for firewalls/NATs/etc.).
> </MAR:>
> 
> MAR: True. But equally true is that if you DON'T specify useful criteria
on how
> you classify candidate TCMTF flows ... it may not be seriously considered.
> 
> MAR: A good example is the "voice communications" item in Table 1 of draft
> B. If the RTP voice flow was a push-to-talk flow ... then I could agree to
up to
> a 80ms mux delay. For a normal voice call, 80ms is WAY, WAY too much delay
> (most VoIP calls use ptime of 20ms for a reason!). If you knew a packet
was a
> voice packet (via RTP inspection) ... but additionally knew it belonged
for a
> push-to-talk service ... you could TCMTF it. So you really need to have
more
> knowledge than just "it is a packet of G.722.2 voice" to make a decision.
As an
> aside, the reference for Table 1 (of draft B) is not rigorous enough for
the use
> claimed (you can find hundreds of references that would disagree with the
> 80 ms maximum recommendation).
> 
> Regards,
> 
> Fernando Pascual Blanco
> MAR: As per my reply to Fernando above, DPI will only get you so far.
There
> are a lot of applications using UDP in which you cannot make a definitive
> association between the packet and a particular service.
> 
> MAR: However, when TCMTF is used on a "high-enough" speed link, the
> delay can be arbitrarily small. Thus I think some TCMTF guidance is
primarily
> needed for low-speed links (i.e., links where the mux delay could be in
> excess of some reasonable bound, like 5 ms maximum).
> 
> >One solution: all the packets with a certain destination IP go to the
> >mux. The servers of the game are clearly identified by their IPs.
> 
> MAR: As an aside, if the network operator had such an agreement ... they
> would know a priori something about the aggregate flows to the networked
> game company. They could also determine this from metadata without any
> "special arrangement".
> 
> MAR: However, even this is not general enough. We already have
> applications that for a particular source and destination IP address/port
have
> different QoS treatment (e.g., SVC video - different packets have
different
> QoS requirements for the same flow).
> 
> MAR: I think capabilities negotiation (another thread) should include a
notion
> of "what types of flows" to consider TCMTFing. Without it, I think TCMTF
> could make some poor decisions (not on efficiency, the dimension upon
> which it always wins - but on delay) which may, in turn, create impedance
for
> its acceptance.
> MAR: I was not arguing for "solving" the flow identification problem at
this
> stage ... just mentioning it now would make sense ... and that techniques
> such as exploiting any metadata information for the flow and/or signature
> analysis could be used for the TCMTF determination. Eventually, I think we
> need to mention how capabilities negotiation can include flow types too.
> 
> >There should be other machine that sends to the mux only the packets
> >that have to be multiplexed.... or not?
> >
> >Jose
> >
> 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:

---

From: Mirko Sužnjević <[email-masked]>
Date: Fri, 11 Jan 2013 11:06:42 +0100

Hello all,
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.
Mirko

-----Original Message-----
From: Jose Saldana [mailto:[email-masked]] 
Sent: Friday, January 11, 2013 9:50 AM
To: 'Michael Ramalho (mramalho)'; 'FERNANDO PASCUAL BLANCO'; [email-masked]
Cc: Mirko Sužnjević
Subject: RE: [tcmtf] : New Version Notification for draft-saldana-tsvwg-tcmtf-04.txt

Michael,

You talk about methods for identifying the different packets, and it is interesting, since it would make things work really better: the multiplexer would know which packets can and which ones can not be multiplexed.

One question here is that perhaps the developer of the application to be multiplexed wouldn't want to add anything to its protocol. I mean, if I am the network provider and I want to save bandwidth in my network, I only have the packets as they have been sent by the final application.

So the question is: are you proposing that we should develop something within TCMTF WG in order to classify packets? Perhaps this is too much, since there will be other people thinking about traffic classification with other objectives.

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?

Jose

> De: Michael Ramalho (mramalho) [mailto:[email-masked]] Enviado el: 
> jueves, 10 de enero de 2013 15:48
> Subject: Re: [tcmtf] : New Version Notification for 
> draft-saldana-tsvwg- tcmtf-04.txt
> 
> Hi Jose,
> 
router
of
drafts or
draft B
> Consider the following ... a potential TCMTF endpoint sees two small 
> UDP packets ... and lets further assume that it cannot tell by 
> inspection the applications the small packets belong to.
> 
> One of the packets belong to a First Person Shooter (FPS) game (very 
> low latency desired) and the other from my home thermostat (reporting 
> my nominal house temperature to a service in the cloud).
> 
delay
particular
> Wouldn't it make sense that TCMTF assumes my thermostat flow is a 
> strong candidate and the FPS isn't a candidate unless it arrived
"just/immediately
> Indeed some VXI protocol designs are being modified so that they can 
> be "more easily" identified by routers (by headers early in the packet
payloads)
difficult (in
particular
packets ...
> the exact application where TCMTF has its strongest use case. And most 
> of these small packets will have very loose delay bounds (long nominal 
on how
> MAR: A good example is the "voice communications" item in Table 1 of 
> draft B. If the RTP voice flow was a push-to-talk flow ... then I 
> could agree to
up to
> a 80ms mux delay. For a normal voice call, 80ms is WAY, WAY too much 
> delay (most VoIP calls use ptime of 20ms for a reason!). If you knew a 
> packet
was a
for a
more
As an
the use
> >networked gaming company. So you are trying to merge flows belonging 
> >to the same game, and send them multiplexed to the demux located at 
> >the game company. So your network has to be able to identify those 
> >flows and send them to the mux. So you would need a sort of "Deep 
> >Packet Inspection", I think.
> 
There
> are a lot of applications using UDP in which you cannot make a 
> definitive association between the packet and a particular service.
> 
primarily
> needed for low-speed links (i.e., links where the mux delay could be 
> in excess of some reasonable bound, like 5 ms maximum).
> 
> MAR: As an aside, if the network operator had such an agreement ... 
> they would know a priori something about the aggregate flows to the 
> networked game company. They could also determine this from metadata 
> without any "special arrangement".
> 
have
different
notion
> of "what types of flows" to consider TCMTFing. Without it, I think 
> TCMTF could make some poor decisions (not on efficiency, the dimension 
> upon which it always wins - but on delay) which may, in turn, create 
> impedance
for
> >network?: you have to compress traffic before traversing a certain 
> >path with scarce bandwidth. So you will have to identify "flows" of 
> >packets with a cadence, and some common characteristics. In this 
> >case, you may need to use "signature analysis" or something, in order 
> >to know the game genre, etc, and thus being able to set a maximum 
> >multiplexing period, for example.
> >
this
> stage ... just mentioning it now would make sense ... and that 
> techniques such as exploiting any metadata information for the flow 
> and/or signature analysis could be used for the TCMTF determination. 
> Eventually, I think we need to mention how capabilities negotiation can include flow types too.
> 
> >> 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.
> >>
> >>application based  on its time-domain signature characteristics) 
> >>might also be of utility?
> >>
> >> >    compression, multiplexing, and tunneling over a network path 
> >> > for
> >>the
> 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:

---

From: Luigi Iannone <[email-masked]>
Date: Fri, 11 Jan 2013 11:45:48 +0100

> 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…

+1

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

Luigi

---

From: "Michael Ramalho (mramalho)" <[email-masked]>
Date: Fri, 11 Jan 2013 13:34:37 +0000

All,

Regarding Jose's comment: " So the question is: are you proposing that we should develop something within TCMTF WG in order to classify packets? "

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).

My point below is that you SHOULD NOT decide whether or not to TCMTF packets from a flow simply by looking at the individual packets themselves (e.g., the G.722.2 "voice" example I provided).

In my opinion, "non-secure" flows with less stringent transport characteristics SHOULD tell the network - so that the network can optimize itself for temporary peaks in load, efficiency and so on.

There will always be corner cases (e.g., secure communications) where a flow will not want to signal that type of information to the network - so applying TCMTF techniques to such flows is a difficult decision.

Service providers are often measured as to the transport performance of their network. Excepting the cases where TCMTF saves enough bandwidth to lower packet drop percentages, TCMTF will (in general) cause added delay in the backbone portion of the flows. I desire TCMTF to be of interest to these service providers, so I believe it is wise to address their concern "up-front" while defining TCMTF.

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.

Michael Ramalho

-----Original Message-----
From: Luigi Iannone [mailto:[email-masked]] 
Sent: Friday, January 11, 2013 5:46 AM
To: Mirko Sužnjević
Cc: [email-masked]; Michael Ramalho (mramalho); FERNANDO PASCUAL BLANCO; [email-masked]
Subject: Re: [tcmtf] : New Version Notification for draft-saldana-tsvwg-tcmtf-04.txt

+1

Luigi

>> the exact application where TCMTF has its strongest use case. And 
>> most of these small packets will have very loose delay bounds (long 
>> nominal reporting intervals or periodic keep-alives for firewalls/NATs/etc.).
>> </MAR:>
>> 
>> delay (most VoIP calls use ptime of 20ms for a reason!). If you knew 
>> a packet
> was a
>>> I have been thinking about your mail. The question is how to 
>>> identify the flows. We can use two examples:
>>> 
>>> One solution: all the packets with a certain destination IP go to 
>> TCMTF could make some poor decisions (not on efficiency, the 
>> dimension upon which it always wins - but on delay) which may, in 
>> turn, create impedance
> for
>> its acceptance.
>> 
>>> 
>>> case, you may need to use "signature analysis" or something, in 
>>> order to know the game genre, etc, and thus being able to set a 
>>> maximum multiplexing period, for example.
>>>