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

[Mirko Sužnjević <[e-mail]>]

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:[e-mail]] 
Sent: Friday, January 11, 2013 9:50 AM
To: 'Michael Ramalho (mramalho)'; 'FERNANDO PASCUAL BLANCO'; [e-mail]
Cc: Mirko Sužnjević
Subject: RE: [tcmtf] : New Version Notification for draft-saldana-tsvwg-tcmtf-04.txt

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

> -----Mensaje original-----
> De: Michael Ramalho (mramalho) [mailto:[e-mail]] Enviado el: 
> jueves, 10 de enero de 2013 15:48
> Para: FERNANDO PASCUAL BLANCO; [e-mail]; [e-mail]
> Asunto: RE: [tcmtf] : New Version Notification for
draft-saldana-tsvwg-tcmtf-
> 04.txt
> 
> All,
> 
> I'll answer Fernando and Jose at the same time, with "MAR:" below.
> 
> Michael Ramalho
> 
> -----Original Message-----
> From: FERNANDO PASCUAL BLANCO [mailto:[e-mail]]
> Sent: Thursday, January 10, 2013 6:16 AM
> To: [e-mail]; Michael Ramalho (mramalho); [e-mail]
> 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
> Telefónica Global Resources
> Network Automation and Dynamization
> TECHNOLOGY PEOPLE GROUP
> F [phone]
> M [phone]
> [e-mail]
> 
> 
> 
> 
> On 10/01/13 11:35, "Jose Saldana" <[e-mail]> wrote:
> 
> >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.
> 
> 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.
> 
> >
> >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.
> 
> 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
> >
> >> -----Mensaje original-----
> >> De: Michael Ramalho (mramalho) [mailto:[e-mail]]  Enviado
> >>el: miércoles, 09 de enero de 2013 18:05
> >> Para: [e-mail]; [e-mail]
> >> Asunto: RE: [tcmtf] : New Version Notification for
> >>draft-saldana-tsvwg-tcmtf-
> >> 04.txt
> >>
> >> 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: [e-mail] [mailto:[e-mail]] On 
> >>Behalf  Of Jose Saldana
> >> Sent: Wednesday, January 09, 2013 4:29 AM
> >> To: [e-mail]
> >> 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: [e-mail] [mailto:[e-mail]] 
> >> > Enviado
> >> > el: miércoles, 09 de enero de 2013 10:25
> >> > Para: [e-mail]
> >> > CC: [e-mail]; [e-mail]; [e-mail];
> >> [e-mail]
> >> > 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
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/tcmtf
> >
> >_______________________________________________
> >tcmtf mailing list
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/tcmtf
> 
> 
> ________________________________
> 
> 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