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:[email protected]] En nombre de Eggert, Lars > Enviado el: viernes, 22 de noviembre de 2013 16:42 > Para: [email protected] > CC: [email protected]; [email protected]; 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 <[email protected]> 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
