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

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

> -----Mensaje original-----
> De: Michael Ramalho (mramalho) [mailto:mramalho@cisco.com]
> Enviado el: miércoles, 09 de enero de 2013 18:05
> Para: jsaldana@unizar.es; tcmtf@ietf.org
> 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: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] On Behalf
> Of Jose Saldana
> Sent: Wednesday, January 09, 2013 4:29 AM
> To: tcmtf@ietf.org
> 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: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Enviado
> > el: miércoles, 09 de enero de 2013 10:25
> > Para: jsaldana@unizar.es
> > CC: mperumal@cisco.com; navajas@unizar.es; dwing@cisco.com;
> fpb@tid.es
> > 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
> tcmtf@ietf.org
> https://www.ietf.org/mailman/listinfo/tcmtf