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
- [tcmtf] Improved version (v8) of the TCM-TF chart… Jose Saldana
- Re: [tcmtf] Improved version (v8) of the TCM-TF c… Reinaldo Penno (repenno)
- Re: [tcmtf] Improved version (v8) of the TCM-TF c… Jose Saldana
- Re: [tcmtf] Improved version (v8) of the TCM-TF c… Eggert, Lars
- Re: [tcmtf] Improved version (v8) of the TCM-TF c… Jose Saldana
- Re: [tcmtf] Improved version (v8) of the TCM-TF c… DAVID FLOREZ RODRIGUEZ
- Re: [tcmtf] Improved version (v8) of the TCM-TF c… Julián Fernández-Navajas
- Re: [tcmtf] Improved version (v8) of the TCM-TF c… Eggert, Lars
- Re: [tcmtf] Improved version (v8) of the TCM-TF c… Jose Saldana
- Re: [tcmtf] Improved version (v8) of the TCM-TF c… Julián Fernández-Navajas
- Re: [tcmtf] Improved version (v8) of the TCM-TF c… Reinaldo Penno (repenno)
- Re: [tcmtf] Improved version (v8) of the TCM-TF c… Tim Chown
- Re: [tcmtf] Improved version (v8) of the TCM-TF c… Jose Saldana
- Re: [tcmtf] Improved version (v8) of the TCM-TF c… Jose Saldana
- Re: [tcmtf] Improved version (v8) of the TCM-TF c… Tim Chown
- Re: [tcmtf] Improved version (v8) of the TCM-TF c… Reinaldo Penno (repenno)
- Re: [tcmtf] Improved version (v8) of the TCM-TF c… Jose Saldana
- Re: [tcmtf] Improved version (v8) of the TCM-TF c… Jose Saldana
- Re: [tcmtf] Improved version (v8) of the TCM-TF c… Eggert, Lars
- Re: [tcmtf] Improved version (v8) of the TCM-TF c… Jose Saldana
- Re: [tcmtf] Improved version (v8) of the TCM-TF c… Michael Ramalho (mramalho)
- Re: [tcmtf] Improved version (v8) of the TCM-TF c… Reinaldo Penno (repenno)