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

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

Hi. I am not sure I understand the problem. Let's use two examples.

a) You have a bottleneck of 1 Mbps, and the offered traffic is:

- UDP 1.1 Mbps
- TCP. It will take as much as it can, using its mechanisms.

In this case, UDP flows will have a lot of delay and packet loss, since they
do not react against congestion. TCP flows will get nothing, since there is
no place for them.

If we use ROHC (for a single hop) or TCM-TF (for more than a hop) and
compress UDP flows to (let's say) 800 kbps, then we will have:

- UDP 800 kbps
- TCP will take the other 200 kbps


b) You have a bottleneck of 1 Mbps, and the offered traffic is:

- UDP 700 kbps
- TCP: It will take the other 300 kbps.

In this case, if we compress UDP to 500 kbps, then TCP will take 500 kbps
instead of 300 kbps.


TCP always takes the bandwidth that UDP leaves. So if you compress UDP, TCP
will have more bandwidth. (I am talking about TCP for FTP or for downloading
a movie. If we talk about TCP for an MMORPG game, the story will be
different)

What do you think?

Jose

> -----Mensaje original-----
> De: tcmtf [mailto:[e-mail]] En nombre de Eggert, Lars
> Enviado el: jueves, 28 de noviembre de 2013 11:53
> Para: Reinaldo Penno (repenno)
> CC: [e-mail]; Martin Stiemerling; [e-mail];
> [e-mail]
> Asunto: Re: [tcmtf] Improved version (v8) of the TCM-TF charter draft
> 
> Hi,
> 
> On 2013-11-27, at 17:23, Reinaldo Penno (repenno) <[e-mail]>
> wrote:
> > 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?
> 
> this is a key point.
> 
> WAN acceleration works, because all traffic goes through the tunnel, and
> the tunnel endpoints prioritize flows. Well, and because they basically
> disable congestion control, so they can grab max bandwidth for the tunnel.
> 
> If you only tunnel some of the packets and let others flow past the
tunnel,
> you have the issue Reinaldo raises. Even if you tunnel everything, unless
> you use aggressive non-IETF-standardized congestion control for the
tunnel,
> other cross traffic can steal the bandwidth you just freed up by
compressing.
> 
> Lars