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

"Jose Saldana" <jsaldana@unizar.es> Fri, 22 November 2013 16:35 UTC

Return-Path: <jsaldana@unizar.es>
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 0F83A1AE18D; Fri, 22 Nov 2013 08:35:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.726
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1LvfbGKv11gf; Fri, 22 Nov 2013 08:35:41 -0800 (PST)
Received: from ortiz.unizar.es (ortiz.unizar.es [155.210.1.52]) by ietfa.amsl.com (Postfix) with ESMTP id BB9D91AE057; Fri, 22 Nov 2013 08:35:40 -0800 (PST)
Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) by ortiz.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id rAMGZNv8028259; Fri, 22 Nov 2013 17:35:24 +0100
From: "Jose Saldana" <jsaldana@unizar.es>
To: "'Eggert, Lars'" <lars@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> <03801D31-422D-4F33-9098-B6DE8FC31C77@netapp.com>
In-Reply-To: <03801D31-422D-4F33-9098-B6DE8FC31C77@netapp.com>
Date: Fri, 22 Nov 2013 17:35:31 +0100
Organization: Universidad de Zaragoza
Message-ID: <002301cee7a0$dcb77fc0$96267f40$@unizar.es>
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: tcmtf@ietf.org, "'Reinaldo Penno \(repenno\)'" <repenno@cisco.com>, 'Martin Stiemerling' <mls.ietf@googlemail.com>, tsv-area@ietf.org, '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
Reply-To: jsaldana@unizar.es
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 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,

Jose

> -----Mensaje original-----
> De: tcmtf [mailto:tcmtf-bounces@ietf.org] En nombre de Eggert, Lars
> Enviado el: viernes, 22 de noviembre de 2013 16:42
> Para: jsaldana@unizar.es
> CC: tcmtf@ietf.org; tsv-area@ietf.org; 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 <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