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

"Jose Saldana" <> Fri, 22 November 2013 16:35 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0F83A1AE18D; Fri, 22 Nov 2013 08:35:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.726
X-Spam-Status: No, score=-4.726 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1LvfbGKv11gf; Fri, 22 Nov 2013 08:35:41 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id BB9D91AE057; Fri, 22 Nov 2013 08:35:40 -0800 (PST)
Received: from usuarioPC ( []) by (8.13.8/8.13.8/Debian-3) with ESMTP id rAMGZNv8028259; Fri, 22 Nov 2013 17:35:24 +0100
From: "Jose Saldana" <>
To: "'Eggert, Lars'" <>
References: <008c01cee5e1$9caa4590$d5fed0b0$> <> <01ee01cee6da$b05eb9a0$111c2ce0$> <> <01da01cee768$42926af0$c7b740d0$> <>
In-Reply-To: <>
Date: Fri, 22 Nov 2013 17:35:31 +0100
Organization: Universidad de Zaragoza
Message-ID: <002301cee7a0$dcb77fc0$96267f40$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQI/pFXgt4LgH+pyHEEB6KKfTqM8zAIc4popAgX21NgA+hAoBAKlUkKdAQjDHtSZCZvUAA==
Content-Language: es
X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter
Cc:, "'Reinaldo Penno \(repenno\)'" <>, '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: Fri, 22 Nov 2013 16:35:44 -0000

Hi, Lars.

Just the required citations about energy in routers, and about skype:

[1]  R. Bolla, R. Bruschi, F. Davoli,  F .Cucchietti, "Energy Efficiency in
the Future Internet: A Survey of Existing Approaches and Trends in
Energy-Aware Fixed Network Infrastructures", Communications Surveys &
Tutorials, IEEE, vol.13, no.2, pp.223,244, Second Quarter 2011.

[2] J. Chabarek, J. Sommers, P. Barford, C. Estan, D. Tsiang, S. Wright,
"Power Awareness in Network Design and Routing", INFOCOM 2008. The 27th
Conference on Computer Communications. IEEE , vol., no., pp.457,465, 13-18
Apr. 2008

According to [1] internal packet processing engines and switching fabric
require 60% and 18% of the power consumption of high-end routers
respectively. Thus, reducing the number of packets to be managed and
switched will reduce the overall energy consumption.

The measurements deployed in [2] on commercial routers corroborate this: a
study using different packet sizes was presented, and the tests with big
packets made the energy consumption get reduced, since a certain amount of
energy is associated to header processing tasks, and not only to the sending
of the packet itself.

Obviously, as you say, we should also measure the tradeoff:

a) energy consumption is increased in the two extremes (mux-demux)
b) energy consumption is reduced in the intermediate nodes

The two references only talk about b), so the tradeoff should be explored
more deeply.

Regarding Skype, I have just run a test with the echo tool and captured with
Wireshark. If the video is disabled, the packet size (only UDP packets) is
roughly 100 data bytes + headers.

Uplink 153 bytes average
Downlink 149 bytes

[3] Bonfiglio, D., Mellia, M., Meo, M., Ritacca, N., & Rossi, D. (2008,
April). Tracking down skype traffic. In INFOCOM 2008. The 27th Conference on
Computer Communications. IEEE (pp. 261-265). 

[4] Rossi, D., Mellia, M., & Meo, M.. A detailed measurement of skype
network traffic. In IPTPS (p. 12), Feb. 2008.

This is valid if you only use Voice. If you activate video, packets become
larger, as you say. I should have specified this. Sorry.

Best regards,


> -----Mensaje original-----
> De: tcmtf [] En nombre de Eggert, Lars
> Enviado el: viernes, 22 de noviembre de 2013 16:42
> Para:
> CC:;; Martin Stiemerling; Reinaldo Penno
> (repenno); Spencer Dawkins
> Asunto: Re: [tcmtf] Improved version (v8) of the TCM-TF charter draft
> Hi,
> On 2013-11-22, at 4:50, Jose Saldana <> 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
> 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?
> are not small.
> Lars