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

"Michael Ramalho (mramalho)" <mramalho@cisco.com> Mon, 02 December 2013 16:44 UTC

Return-Path: <mramalho@cisco.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 6E7121ACCFE; Mon, 2 Dec 2013 08:44:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level:
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 LaumDAxMWmX8; Mon, 2 Dec 2013 08:44:43 -0800 (PST)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id A4B681AC828; Mon, 2 Dec 2013 08:44:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3858; q=dns/txt; s=iport; t=1386002681; x=1387212281; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=/rM8A+bjbui7yb4OXFk7nvuqEIvusTsT1I4eRk+gjW0=; b=Z0He/OPn5B2rJy5Tp8z2qJeqFgwDx2Wwo4B5n4v7AZo9IiNGhOM8cRsI rSMqIlaJw9r3BfrbznQ2DxIlr6rT2yPoHPgjmreeWCm/gxi0rSrb0ygo3 x1H8EdjUiujyNpFMIv7OtAbn9Fl3uo1EpaMbKmfLwfhFSzrFG0bonb1ZV I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgQFAFC4nFKtJXG//2dsb2JhbABZgwc4U7hkgSUWdIIlAQEBAwF5BQcEAgEIEQQBAQEKHQcyFAkIAQEEAQ0FCIdzBr9wF45XMQcGgxqBEwOJCqEdgymCKg
X-IronPort-AV: E=Sophos;i="4.93,811,1378857600"; d="scan'208";a="288797321"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-5.cisco.com with ESMTP; 02 Dec 2013 16:44:41 +0000
Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id rB2Gieol009509 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 Dec 2013 16:44:41 GMT
Received: from xmb-rcd-x12.cisco.com ([169.254.2.96]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Mon, 2 Dec 2013 10:44:40 -0600
From: "Michael Ramalho (mramalho)" <mramalho@cisco.com>
To: "Eggert, Lars" <lars@netapp.com>, "Reinaldo Penno (repenno)" <repenno@cisco.com>
Thread-Topic: [tcmtf] Improved version (v8) of the TCM-TF charter draft
Thread-Index: Ac7l26JNd/G0n/QzTnmgW1GPEao+ugAM6JKAAWLBXQD//8PqgIABvCIA//nBL0A=
Date: Mon, 2 Dec 2013 16:44:40 +0000
Message-ID: <D21571530BF9644D9A443D6BD95B910322FE317C@xmb-rcd-x12.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>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.117.125.227]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
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: Mon, 02 Dec 2013 16:44:45 -0000

[Coming back from Thanksgiving Day holiday/vacation in the USA ...]

Comments below with "MAR:".

Michael Ramalho

-----Original Message-----
From: tcmtf [mailto:tcmtf-bounces@ietf.org] On Behalf Of Eggert, Lars
Sent: Thursday, November 28, 2013 5:53 AM
To: Reinaldo Penno (repenno)
Cc: tcmtf@ietf.org; Martin Stiemerling; tsv-area@ietf.org; jsaldana@unizar.es
Subject: 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.

MAR: Yes, but not exactly as you infer Reinaldo. When TCP has "an infinite amount of data to send", then cwnd opens to "engulf the new 20% [BW]" that is available. But that is NOT how Netflix (or other ABR) works.

MAR: Those ABR techniques (e.g., DASH) never attempt to run TCP at its maximum transmit rate LONG-TERM (over more than a few 2 second intervals) ... because it would be sure to stall and cause poor QoE. Thus, over the long-term, the "Netflix TCPs" always run at less than the 20% vacated. If that nuance is what you meant by "mostly back", then I agree. Over the short term (e.g., a given 2 second HTTP get), cwnd can open to absorb the 20% (and perhaps even more by allowing some queues to grow!), but only if the application playout buffers think it is safe to go to a higher BW by requesting higher-rate (typically 2-second) video chunks in the future.

> 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.

MAR: I know of no WAN acceleration that "disables congestion control" on the individual TCP sessions. The WAN acceleration typically has its own congestion control for the tunnel ... and some flavors purposely (and proactively) modify the congestion control of a subset of the individual flows ("oh, my ... you reduced by cwnd without telling me"). Thus even this sin depends on congestion control of the individual TCP sessions to be working.

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.

MAR: Re: "Aggressive, non-IETF congestion control". What exactly do you think WAN acceleration hardware does? The traffic "in the tunnel" is going between points IN THE MIDDLE of an end-to-end connection between the hosts. The tunnel equipment typically has a good idea of the "tunnel RTT" and other parameters (loss rate, loss characteristics, the individual one-way delays, etc.) and makes its own decisions (throttling individual flows, adding appropriate FEC to some flows, etc.) based on those parameters. What "IETF-standardized congestion control" has been standardized for such tunneled traffic?

MAR: And if the "other traffic" can "steal" the bandwidth you just freed up by compressing ... so be it ... it is scavenger service anyway. If there was that much "extra BW" the tunnel could decide NOT to compress the flows that were very delay sensitive and let the "other traffic" have less BW. But that is the prerogative of the tunneling equipment, no?

Lars