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

"Eggert, Lars" <lars@netapp.com> Thu, 28 November 2013 10:53 UTC

Return-Path: <lars@netapp.com>
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 A8A731ADFDB; Thu, 28 Nov 2013 02:53:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 wUlTeGRkW-jz; Thu, 28 Nov 2013 02:53:09 -0800 (PST)
Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id A55A01ACCDA; Thu, 28 Nov 2013 02:53:09 -0800 (PST)
X-IronPort-AV: E=Sophos; i="4.93,790,1378882800"; d="asc'?scan'208"; a="80581649"
Received: from vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) by mx11-out.netapp.com with ESMTP; 28 Nov 2013 02:53:09 -0800
Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.244]) by vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) with mapi id 14.03.0123.003; Thu, 28 Nov 2013 02:53:09 -0800
From: "Eggert, Lars" <lars@netapp.com>
To: "Reinaldo Penno (repenno)" <repenno@cisco.com>
Thread-Topic: [tcmtf] Improved version (v8) of the TCM-TF charter draft
Thread-Index: Ac7l26JNd/G0n/QzTnmgW1GPEao+ugAM6JKAAWbyPwAACUD9AAAmwCaA
Date: Thu, 28 Nov 2013 10:53:08 +0000
Message-ID: <0E48A0D2-332D-45EF-A7A3-45AA187F76EA@netapp.com>
References: <CEBB5AC5.6B9C%repenno@cisco.com>
In-Reply-To: <CEBB5AC5.6B9C%repenno@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.106.53.51]
Content-Type: multipart/signed; boundary="Apple-Mail=_4C36DD66-9EF9-4E5F-9EB8-5CEB0BC7FECA"; protocol="application/pgp-signature"; micalg="pgp-sha1"
MIME-Version: 1.0
Cc: "tcmtf@ietf.org" <tcmtf@ietf.org>, Martin Stiemerling <mls.ietf@googlemail.com>, "tsv-area@ietf.org" <tsv-area@ietf.org>, "jsaldana@unizar.es" <jsaldana@unizar.es>
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: Thu, 28 Nov 2013 10:53:10 -0000

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