From sergey.gorinsky at imdea.org Thu Nov 10 02:46:28 2011 From: sergey.gorinsky at imdea.org (Sergey Gorinsky) Date: Thu, 10 Nov 2011 11:46:28 +0100 Subject: [e2e] INFOCOM 2012 workshops: joint call for papers Message-ID: Dear all, IEEE INFOCOM 2012 has an impressive set of affiliated workshops: NOMEN 2012, Smart Grids 2012, GI 2012, NetEcon 2012, NetSciCom 2012, and N2Women 2012 (http://www.ieee-infocom.org/2012/workshops.html). The information about the workshops' websites, paper submission and author notification deadlines is included below. Please consider contributing to INFOCOM 2012 by submitting your work to the relevant workshops. Thank you, Sergey ------------------------------------------------------------------------- NOMEN 2012: 1st Workshop on Emerging Design Choices in Name-Oriented Networking Website: http://www.ieee-infocom.org/2012/nomen Submission: 1 December Notification: 1 January Program chairs: Giovanna Carofiglio (Bell Labs - Alcatel Lucent, France) Lixia Zhang (UCLA, USA) ------------------------------------------------------------------------- Smart Grids 2012: 1st Workshop on Green Networking and Smart Grids Website: http://csl.uiuc.edu/smart-grid Submission: 1 December Notification: 2 January Program chairs: Michela Meo (Polytechnic University of Turin, Italy) F. Richard Yu (Carleton University, Canada) Merouane Debbah (SUPELEC, France) Walid Saad (University of Miami, USA) Quanyan Zhu (University of Illinois at Urbana-Champaign, USA) ------------------------------------------------------------------------- GI 2012: 15th Global Internet Symposium Website: http://www.netlab.tkk.fi/gi-2012 Submission: 16 December Notification: 16 January Program chairs: Dan Massey (Colorado State University, USA) Joerg Ott (Aalto University, Finland) ------------------------------------------------------------------------- NetEcon 2012: 7th Workshop on the Economics of Networks, Systems, and Computation Website: http://www.stanford.edu/~ashishg/netecon12 Submission: 16 December Notification: 20 January Program chairs: Ashish Goel (Stanford University, USA) Arvind Krishnamurthy (University of Washington, USA) ------------------------------------------------------------------------- NetSciCom 2012: 4th Workshop on Network Science for Communication Networks Website: http://www.ieee-infocom.org/2012/netscicom Submission: 20 December Notification: 24 January Program chairs: Arun Sen (Arizona State University, USA) Michalis Faloutsos (University of California, Riverside, USA) Yuval Shavitt (Tel Aviv University, Israel) ------------------------------------------------------------------------- N2Women 2012: 2nd Networking Networking Women Workshop Website: http://www.ieee-infocom.org/2012/n2women Submission: 6 January Notification: 3 February Program chair: Damla Turgut (University of Central Florida, USA) ------------------------------------------------------------------------- From valerio.arnaboldi at iit.cnr.it Fri Nov 18 05:06:39 2011 From: valerio.arnaboldi at iit.cnr.it (Valerio Arnaboldi) Date: Fri, 18 Nov 2011 14:06:39 +0100 Subject: [e2e] Pervasive and Mobile Computing journal: Special Issue on Pervasive Urban Applications Message-ID: <3d0836d62d5d0552fc715800a86e9031@iit.cnr.it> ======================== CALL FOR PAPERS ========================= Elsevier - Pervasive and Mobile Computing Special Issue on Pervasive Urban Applications ================================================================== Over the past decade, the development of digital networks and operations has produced an unprecedented wealth of information. Handheld electronics, location devices, telecommunications networks, and a wide assortment of tags and sensors are constantly producing a rich stream of data reflecting various aspects of urban life. For urban planners and designers, these accumulations of digital traces are valuable sources of data in capturing the pulse of the city in an astonishing degree of temporal and spatial detail. Yet this condition of the hybrid city - which operates simultaneously in the digital and physical realms - also poses difficult questions about privacy, scale, and design, among many others. These questions must be addressed as we move toward achieving an augmented, fine-grained understanding of how the city functions - socially, economically and yes, even psychologically. This special issue aims to advance understanding of research challenges and opportunities in applying the pervasive computing paradigm to urban spaces. We are seeking multi-disciplinary contributions that reveal interesting aspects about urban life and exploit the digital traces to create novel urban applications that benefit citizens, urban planners, and policy makers. In this special issue, we are seeking high quality papers reporting original research results on Pervasive Urban Applications with a preference for works including evaluation studies based on empirical data of actual urban environments. Relevant topics include (but are not limited to): - Pervasive computing applications for urban planning and design - Mining of data collected from urban networks e.g. transportation, energy - Urban mobility and geo-localization - Multi-source urban information integration - Real-time urban information processing - Knowledge representation and reasoning on city data - Case studies and applications of mixed urban sensing and mining - Analysis of social networks in urban space - Middleware for mobile urban computing - Context-aware systems for urban space - Pervasive urban applications for smart cities - Intelligent urban transportation systems - Empirical evaluation of pervasive urban applications - Wireless sensor networks, and social network sensing for pervasive urban applications - Security, privacy, reputation, and trust issues in urban computing - Impact of pervasive technologies in urban space e.g. social, economical, and psychological. Submission process: All submissions must be prepared according to the Guide for Authors as published in the Journal website at http://www.ees.elsevier.com/pmc/. Authors should select SI: Pervasive Urban Applications, from the pull-down menu during the submission process. All contributions must not have been previously published or be under consideration for publication elsewhere. A submission based on one or more papers that appeared elsewhere must have major value-added extensions over what appeared previously (at least 33% new material). Authors are requested to submit their relevant, previously published articles and a summary document explaining the enhancements made in the journal version. Important Dates: Paper submission deadline: December 14, 2011 (Extended deadline) First Notification: March 31, 2012 Final Notification: June 15, 2012 Guest Editors of the Special Issue: Francesco Calabrese, IBM Research, Dublin, Ireland, fcalabre at ie.ibm.com Marco Conti, IIT-CNR, Pisa, Italy, marco.conti at iit.cnr.it Dominik Dahlem, MIT, USA, dahlem at mit.edu Giusy Di Lorenzo, IBM Research, Dublin, Ireland, giusydil at ie.ibm.com Santi Phithakkitnukoon, Newcastle University, UK, santi at newcastle.ac.uk From mascolo at poliba.it Wed Nov 30 03:10:50 2011 From: mascolo at poliba.it (mascolo@poliba.it) Date: Wed, 30 Nov 2011 12:10:50 +0100 Subject: [e2e] Reasons not to deply TCP BIC/Cubic Message-ID: <20111130121050.82277480c9hefp4w@mail.poliba.it> Dear all, we know that TCP BIC/Cubic is default in Linux and as a consequence 50% of servers employs TCP BIC/Cubic. Our measurements say that there could be reasons not to deploy TCP BIC/Cubic. These reasons are in our opinion rooted in its more aggressive probing phase. In particular, in common network conditions, TCP BIC/CUBIC exhibits: 1. a larger RTT average wrt to TCP NewReno or TCP Westwood+; 2. a larger number of retransmission wrt to TCP NewReno or TCP Westwood+; 3 larger throughput but same goodput wrt to TCP NewReno or Westwood+. In other terms, it seems that its more aggressive probing increases both throughput and retransmissions but leaving unchanged the goodput. This is neutral for the users but negative for the network. I appreciate your views. Thanks for the attention and best regards, Saverio Mascolo ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From mascolo at poliba.it Wed Nov 30 03:10:31 2011 From: mascolo at poliba.it (mascolo@poliba.it) Date: Wed, 30 Nov 2011 12:10:31 +0100 Subject: [e2e] Reasons not to deploy TCP BIC/Cubic Message-ID: <20111130121031.11271d9maorxuh48@mail.poliba.it> Dear all, we know that TCP BIC/Cubic is default in Linux and as a consequence 50% of servers employs TCP BIC/Cubic. Our measurements say that there could be reasons not to deploy TCP BIC/Cubic. These reasons are in our opinion rooted in its more aggressive probing phase. In particular, in common network conditions, TCP BIC/CUBIC exhibits: 1. a larger RTT average wrt to TCP NewReno or TCP Westwood+; 2. a larger number of retransmission wrt to TCP NewReno or TCP Westwood+; 3 larger throughput but same goodput wrt to TCP NewReno or Westwood+. In other terms, it seems that its more aggressive probing increases both throughput and retransmissions but leaving unchanged the goodput. This is neutral for the users but negative for the network. I appreciate your views. Thanks for the attention and best regards, Saverio Mascolo ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From michawe at ifi.uio.no Wed Nov 30 03:56:46 2011 From: michawe at ifi.uio.no (Michael Welzl) Date: Wed, 30 Nov 2011 12:56:46 +0100 Subject: [e2e] Reasons not to deply TCP BIC/Cubic In-Reply-To: <20111130121050.82277480c9hefp4w@mail.poliba.it> References: <20111130121050.82277480c9hefp4w@mail.poliba.it> Message-ID: <4ED619FE.9090904@ifi.uio.no> This should really go to ICCRG, I'd say (added to recipients). May I ask to continue this (interesting!) discussion there? On 11/30/11 12:10 PM, mascolo at poliba.it wrote: > Dear all, > > we know that TCP BIC/Cubic is default in Linux and as a consequence > 50% of servers employs TCP BIC/Cubic. > > Our measurements say that there could be reasons not to deploy TCP > BIC/Cubic. These reasons are in our opinion rooted in its more > aggressive probing phase. In particular, in common network conditions, > TCP BIC/CUBIC exhibits: 1. a larger RTT average wrt to TCP NewReno or > TCP Westwood+; 2. a larger number of retransmission wrt to TCP NewReno > or TCP Westwood+; 3 larger throughput but same goodput wrt to TCP > NewReno or Westwood+. > > In other terms, it seems that its more aggressive probing increases > both throughput and retransmissions but leaving unchanged the goodput. > This is neutral for the users but negative for the network. > > I appreciate your views. > > Thanks for the attention and best regards, > > Saverio Mascolo > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > From Barry.Constantine at jdsu.com Wed Nov 30 04:23:44 2011 From: Barry.Constantine at jdsu.com (Barry Constantine) Date: Wed, 30 Nov 2011 04:23:44 -0800 Subject: [e2e] Reasons not to deply TCP BIC/Cubic In-Reply-To: <20111130121050.82277480c9hefp4w@mail.poliba.it> References: <20111130121050.82277480c9hefp4w@mail.poliba.it> Message-ID: <71DE5E2C0ADA26429D102DEAC78AF5110B043A7356@MILEXCH3.ds.jdsu.net> Hi Saverio, Does Windows 7 use this TCP implementation as well? Thank you, Barry Constantine -----Original Message----- From: end2end-interest-bounces at postel.org [mailto:end2end-interest-bounces at postel.org] On Behalf Of mascolo at poliba.it Sent: Wednesday, November 30, 2011 6:11 AM To: end2end-interest at postel.org Subject: [e2e] Reasons not to deply TCP BIC/Cubic Dear all, we know that TCP BIC/Cubic is default in Linux and as a consequence 50% of servers employs TCP BIC/Cubic. Our measurements say that there could be reasons not to deploy TCP BIC/Cubic. These reasons are in our opinion rooted in its more aggressive probing phase. In particular, in common network conditions, TCP BIC/CUBIC exhibits: 1. a larger RTT average wrt to TCP NewReno or TCP Westwood+; 2. a larger number of retransmission wrt to TCP NewReno or TCP Westwood+; 3 larger throughput but same goodput wrt to TCP NewReno or Westwood+. In other terms, it seems that its more aggressive probing increases both throughput and retransmissions but leaving unchanged the goodput. This is neutral for the users but negative for the network. I appreciate your views. Thanks for the attention and best regards, Saverio Mascolo ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From mascolo at poliba.it Wed Nov 30 04:31:22 2011 From: mascolo at poliba.it (Saverio Mascolo) Date: Wed, 30 Nov 2011 13:31:22 +0100 Subject: [e2e] Reasons not to deply TCP BIC/Cubic In-Reply-To: <71DE5E2C0ADA26429D102DEAC78AF5110B043A7356@MILEXCH3.ds.jdsu.net> References: <20111130121050.82277480c9hefp4w@mail.poliba.it> <71DE5E2C0ADA26429D102DEAC78AF5110B043A7356@MILEXCH3.ds.jdsu.net> Message-ID: i think windows uses tcp compund (that we have not investigated...) -sm On Wed, Nov 30, 2011 at 1:23 PM, Barry Constantine < Barry.Constantine at jdsu.com> wrote: > Hi Saverio, > > Does Windows 7 use this TCP implementation as well? > > Thank you, > Barry Constantine > > -----Original Message----- > From: end2end-interest-bounces at postel.org [mailto: > end2end-interest-bounces at postel.org] On Behalf Of mascolo at poliba.it > Sent: Wednesday, November 30, 2011 6:11 AM > To: end2end-interest at postel.org > Subject: [e2e] Reasons not to deply TCP BIC/Cubic > > Dear all, > > we know that TCP BIC/Cubic is default in Linux and as a consequence > 50% of servers employs TCP BIC/Cubic. > > Our measurements say that there could be reasons not to deploy TCP > BIC/Cubic. These reasons are in our opinion rooted in its more > aggressive probing phase. In particular, in common network conditions, > TCP BIC/CUBIC exhibits: 1. a larger RTT average wrt to TCP NewReno or > TCP Westwood+; 2. a larger number of retransmission wrt to TCP NewReno > or TCP Westwood+; 3 larger throughput but same goodput wrt to TCP > NewReno or Westwood+. > > In other terms, it seems that its more aggressive probing increases > both throughput and retransmissions but leaving unchanged the goodput. > This is neutral for the users but negative for the network. > > I appreciate your views. > > Thanks for the attention and best regards, > > Saverio Mascolo > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > -- Prof. Saverio Mascolo Dipartimento di Elettrotecnica ed Elettronica Politecnico di Bari Via Orabona 4, 70125 Bari Italy Tel. +39 080 5963621 Fax. +39 080 5963410 email:mascolo at poliba.it http://c3lab.poliba.it ================================= This message may contain confidential and/or legally privileged information. If you are not the intended recipient of the message, please destroy it. Any unauthorized dissemination, distribution, or copying of the material in this message, and any attachments to the message, is strictly forbidden. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20111130/e042df97/attachment.html From neil.davies at pnsol.com Wed Nov 30 06:43:07 2011 From: neil.davies at pnsol.com (Neil Davies) Date: Wed, 30 Nov 2011 14:43:07 +0000 Subject: [e2e] Reasons not to deply TCP BIC/Cubic In-Reply-To: <20111130121050.82277480c9hefp4w@mail.poliba.it> References: <20111130121050.82277480c9hefp4w@mail.poliba.it> Message-ID: Saverio Do you have an idea of the sensitivity of the implementation to burst loss? Is this something that you captured/measured? Is this a condition that this implementation of TCP exacerbates? The reason I ask this is that we have experience of measuring large scale networks in some detail (down to the contribution to the loss and delay at different components in the system) and we are observing that there burst loss is occurring - under some circumstances the loss can be a complete window size (which then appears to cause the sender to wait for a timeout). I could understand that more aggression would lead to greater RTT (and greater RTT leads to longer recover times from certain events) - it is filling the critical bottleneck with more packets, hence more delay. Although TCP BIC/Cubic may appear neutral when measuring throughput - is it neutral when that TCP session is being used for other purposes other than simple bulk data transfer? (e.g. a block transfer of video content) Cheers Neil On 30 Nov 2011, at 11:10, mascolo at poliba.it wrote: > Dear all, > > we know that TCP BIC/Cubic is default in Linux and as a consequence > 50% of servers employs TCP BIC/Cubic. > > Our measurements say that there could be reasons not to deploy TCP > BIC/Cubic. These reasons are in our opinion rooted in its more > aggressive probing phase. In particular, in common network > conditions, TCP BIC/CUBIC exhibits: 1. a larger RTT average wrt to > TCP NewReno or TCP Westwood+; 2. a larger number of retransmission > wrt to TCP NewReno or TCP Westwood+; 3 larger throughput but same > goodput wrt to TCP NewReno or Westwood+. > > In other terms, it seems that its more aggressive probing increases > both throughput and retransmissions but leaving unchanged the > goodput. This is neutral for the users but negative for the network. > > I appreciate your views. > > Thanks for the attention and best regards, > > Saverio Mascolo > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > From muraris at microsoft.com Wed Nov 30 13:31:44 2011 From: muraris at microsoft.com (Murari Sridharan) Date: Wed, 30 Nov 2011 21:31:44 +0000 Subject: [e2e] [Iccrg] Re: Reasons not to deply TCP BIC/Cubic In-Reply-To: <258203e4a6674a05196eefc450e7b8c7@cs.karelia.ru> References: <20111130121050.82277480c9hefp4w@mail.poliba.it> <4ED619FE.9090904@ifi.uio.no> <258203e4a6674a05196eefc450e7b8c7@cs.karelia.ru> Message-ID: NIST did a very comprehensive study along these lines comparing and documenting different congestion algorithms. http://www.nist.gov/itl/antd/Congestion_Control_Study.cfm Thanks Murari -----Original Message----- From: iccrg-bounces at cs.ucl.ac.uk [mailto:iccrg-bounces at cs.ucl.ac.uk] On Behalf Of sannikov Sent: Wednesday, November 30, 2011 6:56 AM To: Saverio Mascolo Cc: iccrg; end2end-interest Subject: Re: [Iccrg] Re: [e2e] Reasons not to deply TCP BIC/Cubic Hello. I'm not so familiar with CUBIC, but it is really aggressive. And as far as I know Linux implementation is little bit differ from the original. Did have original version same problems? -- With best regards, Alexander Sannikov. On Wed, 30 Nov 2011 13:08:05 +0100, Saverio Mascolo wrote: > yes! > > On Wed, Nov 30, 2011 at 12:56 PM, Michael Welzl wrote: > This should really go to ICCRG, I'd say (added to recipients). May I ask > to continue this (interesting!) discussion there? > > On 11/30/11 12:10 PM, mascolo at poliba.it [2] wrote: > Dear all, > > we know that TCP BIC/Cubic is default in Linux and as a consequence > 50% of servers employs TCP BIC/Cubic. > > Our measurements say that there could be reasons not to deploy TCP > BIC/Cubic. These reasons ?are in our opinion rooted in its more > aggressive probing phase. In particular, in common network conditions, > TCP BIC/CUBIC exhibits: 1. a larger RTT average wrt to TCP NewReno or TCP > Westwood+; 2. a larger number of retransmission wrt to TCP NewReno or TCP > Westwood+; 3 larger throughput but same goodput wrt to TCP NewReno or > Westwood+. > > In other terms, it seems that its more aggressive probing increases both > throughput and retransmissions but leaving unchanged the goodput. This is > ?neutral for the users but negative for the network. > > I appreciate your views. > > Thanks for the attention and best regards, > > Saverio Mascolo > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > _______________________________________________ > Iccrg mailing list > Iccrg at cs.ucl.ac.uk [3] > http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg [4] _______________________________________________ Iccrg mailing list Iccrg at cs.ucl.ac.uk http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg