Re: [tcmtf] Improved version (v8) of the TCM-TF charter draft

Hi, Reinaldo. This is an interesting point.

My idea is that TCM-TF only makes sense when a number of flows share a
bottleneck and its bandwidth gets scarce. So it is not a problem of a user
but a problem of the network. The end user (or the X-Box) in this case would
only perceive an additional (limited) delay and jitter, but this is
something that is done deeply in the network, when links get congested. And
sometimes network operators have different connections for best-effort and
for online game traffic. So if the online games connection gets clogged at a
certain point or moment, TCM-TF would then activate only there.

The network operator is the one who has to grant the user a good connection
when he is playing. This includes:

1- Always working in an acceptable way
2- Low delay, jitter and packet loss

When (1) becomes difficult because of congestion, you may optimize the
traffic (sacrifice a bit of (2) in order to maintain (1).

Was this your idea?

Jose

> -----Mensaje original-----
> De: tcmtf [mailto:tcmtf-bounces@ietf.org] En nombre de Reinaldo Penno
> (repenno)
> Enviado el: miércoles, 27 de noviembre de 2013 17:24
> Para: jsaldana@unizar.es; tcmtf@ietf.org; tsv-area@ietf.org
> CC: 'Martin Stiemerling'; 'Spencer Dawkins'
> Asunto: Re: [tcmtf] Improved version (v8) of the TCM-TF charter draft
> 
> HI Jose,
> 
> None of my objections in this case are purely technical. The problem with
> these solution is that although technical feasible, it leaves out the one
> person that should have some saying on which traffic gets compressed or
> not: the user.
> 
> I really do not expect users configuring access lists so that traffic from
a
> certain port eta compressed. Or trusting a DPI with some preconfigured
> policies that could be hit and miss. It would be good if user or app could
> have a way to convey preference of which app should be compressed.
> 
> This brings me to an interesting point:
> 
> Let¹s suppose XBOX gaming traffic compressed and bandwidth is reduced by
> 20%. Netflix detects there is much more bandwidth and TCP opens its
> window to engulf that new 20% available.  You are mostly back to where
> you were.
> So, if you go throughout the trouble of compressing some traffic, would
that
> need to be couple with some protection?
> 
> 
> On 11/27/13, 3:58 AM, "Jose Saldana" <jsaldana@unizar.es> wrote:
> 
> >One question about this. Our idea is to list some possibilities to be
> >used for a TCM optimizer in order to select the flows to optimize. Some
> >examples:
> >
> >- DPI. However, some people would say that it is against network
> >neutrality, and it may also be difficult if the flow is encrypted.
> >
> >- Selecting according to IPs and port numbers. For example, if a flow
> >has a destination IP belonging to a game company, it is a clear
> >candidate. This would be possible if there is an agreement between the
> >ISP and the game company.
> >
> >- The packets include specific diffserv values.
> >
> >- Automatic detection based on statistics of Inter-packet time and
> >packet size have also been proposed. They are not against neutrality:
> >T. T. Nguyen, G. Armitage, P. Branch, S. Zander, ³Timely and continuous
> >machine-learning-based classification for interactive IP traffic,²
> >IEEE/ACM Trans. on Networking, 20(6), pp 1880-1894, 2012.
> >
> >What do you think about these possibilities?
> 
> _______________________________________________
> tcmtf mailing list
> tcmtf@ietf.org
> https://www.ietf.org/mailman/listinfo/tcmtf