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

"Reinaldo Penno (repenno)" <> Wed, 27 November 2013 16:23 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 923B91AD7C0; Wed, 27 Nov 2013 08:23:35 -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 GhnKnQHOlanx; Wed, 27 Nov 2013 08:23:34 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 0A5B61ACCE7; Wed, 27 Nov 2013 08:23:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2012; q=dns/txt; s=iport; t=1385569413; x=1386779013; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=h7DhG/iBeI2FGkWQlpctflpZweaM3sBfVBWp5f9X8PA=; b=MZSCnOmgW/UsoX+HubUczZhexdCMRm5zV/lzLtLct+N92Hqb3JDEMYrP a3YejPNO1A/smn72kzibF8sUC8b+995GtUgpMaCWApca7IluebCkMlOzr +S2W0V8+hYe1d8sTHLdfhW2WkNtbgJnNOAGjSXpR0s+ueeXVZRtAO4j1s U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiMFABgcllKtJV2a/2dsb2JhbABZgweBC7hTgR8WdIIsbQwSAQh4JQEBBAENBRuHZsBDF44VbQeEMwOUMYNjkhODKYIq
X-IronPort-AV: E=Sophos;i="4.93,783,1378857600"; d="scan'208";a="2687498"
Received: from ([]) by with ESMTP; 27 Nov 2013 16:23:33 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id rARGNXkI005352 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Nov 2013 16:23:33 GMT
Received: from ([]) by ([]) with mapi id 14.03.0123.003; Wed, 27 Nov 2013 10:23:32 -0600
From: "Reinaldo Penno (repenno)" <>
To: "" <>, "" <>, "" <>
Thread-Topic: [tcmtf] Improved version (v8) of the TCM-TF charter draft
Thread-Index: Ac7l26JNd/G0n/QzTnmgW1GPEao+ugAM6JKAAWLBXQD//8PqgA==
Date: Wed, 27 Nov 2013 16:23:32 +0000
Message-ID: <>
In-Reply-To: <001001ceeb67$fffe2e50$fffa8af0$>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: 'Martin Stiemerling' <>, 'Spencer Dawkins' <>
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: Wed, 27 Nov 2013 16:23:35 -0000

HI Jose,

None of my objections in this case are purely technical. The problem with
these solution is that although technical feasible, it leaves out the one
person that should have some saying on which traffic gets compressed or
not: the user.

I really do not expect users configuring access lists so that traffic from
a certain port eta compressed. Or trusting a DPI with some pre‹configured
policies that could be hit and miss. It would be good if user or app could
have a way to convey preference of which app should be compressed.

This brings me to an interesting point:

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?

On 11/27/13, 3:58 AM, "Jose Saldana" <> wrote:

>One question about this. Our idea is to list some possibilities to be used
>for a TCM optimizer in order to select the flows to optimize. Some
>- DPI. However, some people would say that it is against network
>and it may also be difficult if the flow is encrypted.
>- Selecting according to IPs and port numbers. For example, if a flow has
>destination IP belonging to a game company, it is a clear candidate. This
>would be possible if there is an agreement between the ISP and the game
>- The packets include specific diffserv values.
>- Automatic detection based on statistics of Inter-packet time and packet
>size have also been proposed. They are not against neutrality:
>T. T. Nguyen, G. Armitage, P. Branch, S. Zander, ³Timely and continuous
>machine-learning-based classification for interactive IP traffic,²
>Trans. on Networking, 20(6), pp 1880-1894, 2012.
>What do you think about these possibilities?