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

"Eggert, Lars" <lars@netapp.com> Fri, 22 November 2013 15:42 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 1449A1ADFC6; Fri, 22 Nov 2013 07:42:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.427
X-Spam-Level:
X-Spam-Status: No, score=-7.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, 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 eC-hrDhx-f5n; Fri, 22 Nov 2013 07:41:58 -0800 (PST)
Received: from mx1.netapp.com (mx1.netapp.com [216.240.18.38]) by ietfa.amsl.com (Postfix) with ESMTP id 96E541ADFE8; Fri, 22 Nov 2013 07:41:58 -0800 (PST)
X-IronPort-AV: E=Sophos; i="4.93,752,1378882800"; d="asc'?scan'208"; a="293585535"
Received: from vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) by mx1-out.netapp.com with ESMTP; 22 Nov 2013 07:41:52 -0800
Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.244]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.03.0123.003; Fri, 22 Nov 2013 07:41:51 -0800
From: "Eggert, Lars" <lars@netapp.com>
To: "jsaldana@unizar.es" <jsaldana@unizar.es>
Thread-Topic: [tcmtf] Improved version (v8) of the TCM-TF charter draft
Thread-Index: Ac7l26JNd/G0n/QzTnmgW1GPEao+ugAM6JKAAEOdowAAAG6RAAAi9L4AAAxIcgA=
Date: Fri, 22 Nov 2013 15:41:50 +0000
Message-ID: <03801D31-422D-4F33-9098-B6DE8FC31C77@netapp.com>
References: <008c01cee5e1$9caa4590$d5fed0b0$@unizar.es> <CEB23B7B.663B%repenno@cisco.com> <01ee01cee6da$b05eb9a0$111c2ce0$@unizar.es> <6639F5EC-B9AE-471A-BEAA-D25D21526F21@netapp.com> <01da01cee768$42926af0$c7b740d0$@unizar.es>
In-Reply-To: <01da01cee768$42926af0$c7b740d0$@unizar.es>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.104.60.115]
Content-Type: multipart/signed; boundary="Apple-Mail=_A800C4F6-3730-469B-8FD4-78E336E5894A"; protocol="application/pgp-signature"; micalg=pgp-sha1
MIME-Version: 1.0
Cc: "tcmtf@ietf.org" <tcmtf@ietf.org>, "tsv-area@ietf.org" <tsv-area@ietf.org>, Martin Stiemerling <mls.ietf@googlemail.com>, "Reinaldo Penno \(repenno\)" <repenno@cisco.com>, Spencer Dawkins <spencerdawkins.ietf@gmail.com>
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, 22 Nov 2013 15:42:03 -0000

Hi,

On 2013-11-22, at 4:50, Jose Saldana <jsaldana@unizar.es> wrote:
> This is a very interesting point: we cannot assume that we will have ample
> resource capacity everywhere and always. There are situations in which a
> traffic rush occurs, and in these situations there are a number of congested
> links. I am not only thinking on emerging countries, but also in a traffic
> rush anywhere.

I'm with you so far.

> The idea is that TCM-TF is dormant, and it only gets activated when network
> capacity becomes scarce.

Here is where I start to disagree. I don't buy the idea that we should be deploying TCM-TF boxes everywhere that get activated when capacity is scarce. I believe in simply adding more capacity where needed when needed. And even when doing the deployment on-demand, why would we not instead simply deploy more bandwidth?

Yes, in specific cases that is not possible, such as when you are running out of capacity on a wireless hop of some sort where you can't get more spectrum. But I believe we have sufficient mechanisms available for these cases.

> As Dan said in the BoF, TCM-TF provides a degree of
> flexibility: you can exchange processing power and bandwidth when required.

But first you need to deploy that processing power. When you have the choice of deploying processing power or deploying capacity, why wouldn't you deploy capacity?

> In these situations, when a traffic rush occurs, why not activating TCM
> optimization, and reducing the amount of pps and the bandwidth requirements
> by optimizing the small-packet flows?

Because the TCM optimization is not free. You need to deploy if before you can use it. I fundamentally believe in deploying bandwidth instead of deploying boxes that manage bandwidth scarcity.

And yes, in some scenarios PEPs make sense, but as I said above, I don't think we're lacking any technology in this space.

> Network operators have to transport
> lots of small-packet flows, and this is not efficient (even in terms of
> energy consumption, since header processing accounts for the majority of the
> power requirements of a router).

Citation please?

Also, if we're talking energy, you need to account for he processing that TCM requires.

> Regarding the village example: community networks are really challenging
> scenarios where VoIP and real-time services have a lot of problems to work
> properly, so perhaps traffic optimization can be needed frequently (e.g. in
> the afternoon when everyone is trying to use skype at home).

OK, I'll bite. Have you looked at the size of packets that Skype uses? They are not small.

Lars