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

"Reinaldo Penno (repenno)" <> Tue, 03 December 2013 15:14 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 071561AE15C; Tue, 3 Dec 2013 07:14:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.502
X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WKOxvetjb4ML; Tue, 3 Dec 2013 07:14:10 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 25DB11AE12A; Tue, 3 Dec 2013 07:14:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=6520; q=dns/txt; s=iport; t=1386083647; x=1387293247; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=5GzuBDPUdF9cKLtkKpkCaZhRtLDVtajSp1nahtyeOJ0=; b=DQQQuCHZB8bjKibfQVSHV333y9dW0wzjF4YNzfjdnLOY+9ZoyS+oaURW U3OTLhtmEct3E9GF1K/lSmmalSM+cfJ3DVtHQ2XB8WtCAMypPUzqs9YaY EHJ9EEj9Tpy2GCxWd38aL9KJ8orJ2WTVJ+t4qBoAO5LZJ1GZku9exi8pW g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.93,818,1378857600"; d="scan'208";a="3967345"
Received: from ([]) by with ESMTP; 03 Dec 2013 15:14:07 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id rB3FE74v020350 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Dec 2013 15:14:07 GMT
Received: from ([]) by ([]) with mapi id 14.03.0123.003; Tue, 3 Dec 2013 09:14:07 -0600
From: "Reinaldo Penno (repenno)" <>
To: "Michael Ramalho (mramalho)" <>, "Eggert, Lars" <>
Thread-Topic: [tcmtf] Improved version (v8) of the TCM-TF charter draft
Thread-Index: Ac7l26JNd/G0n/QzTnmgW1GPEao+ugAM6JKAAWLBXQD//8PqgIABvCIA//nBL0CADdq4gA==
Date: Tue, 3 Dec 2013 15:14:06 +0000
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="euc-kr"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "" <>, Martin Stiemerling <>, "" <>, "" <>
Subject: Re: [tcmtf] Improved version (v8) of the TCM-TF charter draft
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Tunneling Compressed Multiplexed Traffic Flows \(TCMTF\) discussion list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 03 Dec 2013 15:14:13 -0000

I agree with your assessment about "long-term" but I believe one of the
goals of TCM-TF is to improve user-experience in the short term. If I’m
playing real-time games (through the tunnel) and a playback, torrent
download, backup, or others that are not in the tunnel probe for more
bandwidth, it will adversely affect tunneled and non-tunneled flows alike
in the short term. 

But anyway, I have to admit that such dynamics are just my back of the
envelope assessment based on the functionality found in WAN accelerators:
some of them incorporate a full TCP proxy on one end, others tweak TCP
window to slow down certain flows as you put it.

Do you (or anybody) happen to have some references handy on such dynamics
when an end device compress some of the flows and not others?



On 12/2/13, 8:44 AM, "Michael Ramalho (mramalho)" <>

>[Coming back from Thanksgiving Day holiday/vacation in the USA ...]
>Comments below with "MAR:".
>Michael Ramalho
>-----Original Message-----
>From: tcmtf [] On Behalf Of Eggert, Lars
>Sent: Thursday, November 28, 2013 5:53 AM
>To: Reinaldo Penno (repenno)
>Cc:; Martin Stiemerling;;
>Subject: Re: [tcmtf] Improved version (v8) of the TCM-TF charter draft
>On 2013-11-27, at 17:23, Reinaldo Penno (repenno) <>
>> 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?