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

"Jose Saldana" <jsaldana@unizar.es> Fri, 29 November 2013 10:15 UTC

Return-Path: <jsaldana@unizar.es>
X-Original-To: tcmtf@ietfa.amsl.com
Delivered-To: tcmtf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEFED1AD845; Fri, 29 Nov 2013 02:15:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.802
X-Spam-Level:
X-Spam-Status: No, score=-2.802 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uY6PFRMUWl8z; Fri, 29 Nov 2013 02:15:26 -0800 (PST)
Received: from ortiz.unizar.es (ortiz.unizar.es [155.210.1.52]) by ietfa.amsl.com (Postfix) with ESMTP id 89DD41ADBD5; Fri, 29 Nov 2013 02:15:18 -0800 (PST)
Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) by ortiz.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id rATAEx3u017881; Fri, 29 Nov 2013 11:15:05 +0100
From: "Jose Saldana" <jsaldana@unizar.es>
To: "'Eggert, Lars'" <lars@netapp.com>, "'Reinaldo Penno \(repenno\)'" <repenno@cisco.com>
References: <CEBB5AC5.6B9C%repenno@cisco.com> <0E48A0D2-332D-45EF-A7A3-45AA187F76EA@netapp.com>
In-Reply-To: <0E48A0D2-332D-45EF-A7A3-45AA187F76EA@netapp.com>
Date: Fri, 29 Nov 2013 11:15:14 +0100
Message-ID: <00d801ceeceb$e857c920$b9075b60$@unizar.es>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQFcWLedGCIWQD7koPyL7x5R7nIbUgF4vafbmxVdpIA=
Content-Language: es
X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter
Cc: tcmtf@ietf.org, 'Martin Stiemerling' <mls.ietf@googlemail.com>, tsv-area@ietf.org
Subject: Re: [tcmtf] Improved version (v8) of the TCM-TF charter draft
X-BeenThere: tcmtf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Tunneling Compressed Multiplexed Traffic Flows \(TCMTF\) discussion list" <tcmtf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcmtf>, <mailto:tcmtf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcmtf/>
List-Post: <mailto:tcmtf@ietf.org>
List-Help: <mailto:tcmtf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcmtf>, <mailto:tcmtf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Nov 2013 10:15:45 -0000

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:tcmtf-bounces@ietf.org] En nombre de Eggert, Lars
> Enviado el: jueves, 28 de noviembre de 2013 11:53
> Para: Reinaldo Penno (repenno)
> CC: tcmtf@ietf.org; Martin Stiemerling; tsv-area@ietf.org;
> jsaldana@unizar.es
> Asunto: Re: [tcmtf] Improved version (v8) of the TCM-TF charter draft
> 
> Hi,
> 
> On 2013-11-27, at 17:23, Reinaldo Penno (repenno) <repenno@cisco.com>
> 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