From flavio at cs.bu.edu Tue Aug 5 16:07:54 2014 From: flavio at cs.bu.edu (Flavio Esposito) Date: Tue, 5 Aug 2014 18:07:54 -0500 Subject: [e2e] CFP - IEEE Sixteenth International Symposium on a World of Wireless, Mobile and Multimedia Networks (WowMoM 2015) Message-ID: ------------------------------------------------------------------------ - Our apologies if you receive multiple copies of this CFP - ------------------------------------------------------------------------ CALL FOR PAPERS IEEE WoWMoM 2015 Sixteenth International Symposium on a World of Wireless, Mobile and Multimedia Networks http://csr.bu.edu/wowmom15 sponsored by IEEE Computer Society, IEEE Computer Society TC on Computer Communications (TCCC) June 14-17, 2015 Boston, MA, USA ------------------------------------------------------------------------ **** ******* **** *ABSTRACT SUBMISSION DEADLINE: NOVEMBER 21, 2014* ******* **** *FULL MANUSCRIPT DUE: NOVEMBER 28, 2014* ******* **** ******* ------------------------------------------------------------------------ IEEE WoWMoM 2015 is soliciting original and previously unpublished papers addressing research challenges and advances towards a world of wireless, mobile, and multimedia pervasive communications. The evolution of wireless networking technologies and their key role in future Internet scenarios offer an increasing wealth of opportunities for distributing multimedia contents over wireless networks, enabling dissemination of professional contents to mobile users as well as sharing user-generated contents among them. Users will be able to retrieve, publish, and manage information, communicate with other users or devices, access and author services, create and exploit context- awareness and so on. Papers that present original work, validated by experimentation, simulation, or analysis, are solicited. Practical experiences and experimental efforts from both industry and academy, duly documenting the lessons learned from testbeds, field-trials, or real deployments, are also welcome. Topics of interest include, but are not limited to: - Wireless multimedia systems, services and applications - Opportunistic and delay-tolerant networks - Ad-hoc, sensor, mesh and vehicular wireless networks - Wireless BAN, PAN, LAN, MAN and WAN - Machine-to-machine (M2M) communications and the Internet of Things - Middleware services for wireless, mobile and multimedia networks - Context-awareness in wireless, mobile and multimedia networks - Content-centric architectures, multimedia content management and distribution for mobile networks - Localization mechanisms and services - Participatory and urban sensing - Mobile social networking - Resource management and QoS/QoE provisioning - Multicasting and broadcasting issues - Handoff and mobility management - Network management and control - Dependability, reliability and survivability issues for wireless, mobile and multimedia networks - Security and privacy issues for wireless, mobile and multimedia networks - Energy-efficient protocols and power management - Seamless internetworking and self-organization - System prototypes, measurements, real deployment, and experiences - Modeling, analysis, and performance evaluation AWARDS AND EDITORIAL FOLLOW-UP ------------------------------------------------------------------------ Papers presented at the Symposium will be considered for a Best Paper Award. Papers of particular merit will be considered for a fast track publication in the Elsevier Pervasive and Mobile Computing Journal. PAPER SUBMISSION AND PUBLICATION ------------------------------------------------------------------------ All submissions must describe original research, not published or currently under review for another workshop, conference, or journal. Papers must be submitted electronically through EDAS. You can find detailed submission instructions at: http://csr.bu.edu/wowmom15 ************************************************************************ *Submission implies the willingness of at least one author to attend * *the conference and present the paper. Accepted papers will be included* *in the proceedings of IEEE WoWMoM 2015 and published in the * *IEEE Digital Library. WoWMoM organizers reserve the right to exclude * *a paper from distribution after the conference (e.g., removal from * *IEEE Xplore) if the paper is not presented at the conference. * ************************************************************************ IMPORTANT DATES ------------------------------------------------------------------------ - Abstract submission deadline: November 21, 2014. - Full manuscript due: November 28, 2014. - Acceptance notification: March 13, 2015. CONTACTS ------------------------------------------------------------------------ For further information, please visit the conference website at http://csr.bu.edu/wowmom15, or contact the PC Chairs. WORKSHOPS AND AFFILIATED EVENTS: ------------------------------------------------------------------------ Several workshops will be held in conjunction with the main conference. Workshop papers will be included and indexed in the IEEE Digital Library (Xplore), showing their affiliation with IEEE WoWMoM. WoWMoM 2015 will also feature an Industry Track, PhD Forum and a Demonstrations Session. Please visit the conference website for details. From nichols at pollere.com Wed Aug 20 10:13:21 2014 From: nichols at pollere.com (Kathleen Nichols) Date: Wed, 20 Aug 2014 10:13:21 -0700 Subject: [e2e] Once again buffer bloat and CC. Re: A Cute Story. Or: How to talk completely at cross purposes. Re: [ih] When was Go Back N adopted by TCP In-Reply-To: <53D77F3A.5020100@web.de> References: <20140519150259.35C1E28E137@aland.bbn.com> <537B35D0.9040400@web.de> <538DC307.90101@web.de> <53D77F3A.5020100@web.de> Message-ID: <53F4D731.1020007@pollere.com> If by "Coddle" you mean "codel", then you need to read about it more carefully. Excessive delay is NOT defined as "a packet resides in the local router queue for more than 100 ms". As for the value of the constant, you may wish to read the most recent I-D or watch the video of Van's talk on this at the IETF. Perhaps improving CC will obviate the need for AQM. In the meantime, it is useful to have solutions available for those who need them. On 7/29/14 4:02 AM, Detlef Bosau wrote: > Am 04.06.2014 um 02:01 schrieb Andrew Mcgregor: >> Bufferbloat definitely does impair performance, by slowing down feedback it >> increases the variance of the system workload, which inevitably causes >> either packet drops because there is a finite buffer limit in reach, or by >> causing such large delays that retransmission timers fire for packets that >> are still in flight. In either case, the system is doing excess work. >> > > I thought quite a bit about that during the last weeks and sometimes I > think, we're mixing up cause and effect. > > And we basically rely upon assumptions which may be put in question. > > IIRC, David Reed pointed out some weeks ago what he defines as > "bufferbloat". Simply put: A packet conveyed in a network spends most of > its sojourn time in queues. > > Now the problem is that we cannot determine a packet's "queuing time" a > posteriori. So, sometimes we have criteria for buffer bloat, e.g. > Coddle, where buffer bloat means "a packet resides in the local router > queue for more than 100 ms". (Whether 100 ms is defined by experience or > by divine inspiration is still opaque to me, it will certainly become > clear when this contstant is assigned a name and the Turing Award is > awarded.) > > According to Dave's definition it is no way clear, whether a flow > experiences buffer bloat from this single queueing time. When a packet > experiences 5 seconds of sojourn time - and the 100 ms in the local > router queue are its only queueing delay, anything is fine. If the > 0,1000000000000000000000000000000000000000001 seconds soujourn time > consists of 100 ms queueing delay "and a little rest", this would be > unsatisfactory. > > In other words: Buffer bloat is not a phenomenon for a single flow - but > a symptom of wrong system design. > > Now, there are quite some rules of thumb how buffers should be designed > that buffer bloat is avoided - and all of these miss the problem. > > The problem is: Queues are utilized. And when congestion and resource > control are handled by feedback in a way that a system which does not > drop packets is not fully utilized, queues WILL BE FULLY UTILIZED, > because we offer that much load to a system that it eventually drops > packets. > > That's basically the same af if you don't know the size of your fridge - > and you fill in butter and milk and cheese - until the whole mess > becomes lively and walks out. And then you throw away the whole mess, > clean your fridge - and restart the same procedure from the beginning. > (We call this "probing". In the context of a fridge: Mould cheese probing.) > > My basic question is: Can we avoid probing? Wouldn't it be preferable to > probing to assign known resources by proper scheduling instead? > > Isn't probing the very problem? Hence, CUTE and VJCC basically introduce > the problem which they pretend to solve? > > WRT buffer bloat: When we don't offer inappropriate load to a network > and all packets could be served in reasonable time, there wouldn't be > any buffer bloat at all. > > > > > > From detlef.bosau at web.de Wed Aug 20 11:44:52 2014 From: detlef.bosau at web.de (Detlef Bosau) Date: Wed, 20 Aug 2014 20:44:52 +0200 Subject: [e2e] Once again buffer bloat and CC. Re: A Cute Story. Or: How to talk completely at cross purposes. Re: [ih] When was Go Back N adopted by TCP In-Reply-To: <53F4D731.1020007@pollere.com> References: <20140519150259.35C1E28E137@aland.bbn.com> <537B35D0.9040400@web.de> <538DC307.90101@web.de> <53D77F3A.5020100@web.de> <53F4D731.1020007@pollere.com> Message-ID: <53F4ECA4.8040200@web.de> Am 20.08.2014 um 19:13 schrieb Kathleen Nichols: > If by "Coddle" you mean "codel", then you need to read about it more > carefully. Sorry, I refer to codel. > Excessive delay is NOT defined as "a packet resides in the local router > queue for more than 100 ms". At least that's what you wrote in your own paper. > As for the value of the constant, you may > wish to read the > most recent I-D or watch the video of Van's talk on this at the IETF. Could you help me with a link? The problem however is a bit deeper. The main cause of buffer bloat (and I expect contradiction here) the basic misconception of CC. The purpose of sliding window in TCP is to fully utilize the links. (This is by itself a misconception and mixes up master and slave in a network. >From the OSI model, TCP is the master, the net is the slave. Hence, it is up to the network to convey data as efficient as possible, it is not up to TCP to utilize any links.) However, actually TCP does not probe for link utilization but pumps data into the buffers until the amount of data causes buffer overflow. So the first thing is the purpose of sliding window, the second (completely different) issue is what's actually achieved by VJCC probing. (The more I think about it, probing is a really bad idea. And particularly, probing for the wrong parameters is an even worse idea.) > Perhaps improving CC will obviate the need for AQM. AQM and Codel and VJCC are - sorry for the harsh words - different names for the same kludge. Instead of doing proper ressource assignment, we force networks into congestion. That is, and I thought about this statement a VERY long time, highly questionable. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From detlef.bosau at web.de Wed Aug 20 12:01:31 2014 From: detlef.bosau at web.de (Detlef Bosau) Date: Wed, 20 Aug 2014 21:01:31 +0200 Subject: [e2e] Once again buffer bloat and CC. Re: A Cute Story. Or: How to talk completely at cross purposes. Re: [ih] When was Go Back N adopted by TCP In-Reply-To: <53F4ECA4.8040200@web.de> References: <20140519150259.35C1E28E137@aland.bbn.com> <537B35D0.9040400@web.de> <538DC307.90101@web.de> <53D77F3A.5020100@web.de> <53F4D731.1020007@pollere.com> <53F4ECA4.8040200@web.de> Message-ID: <53F4F08B.2070702@web.de> And in addition, what queue length is concerned, I take the position (which is similar to DPR's, IIRC) that a router should keep no more than one packet per flow at a given time, in the general case. I explicitly state that in wireless scenarios, there might be reasons to accept longer router queues, particularly in the context of opportunistic scheduling. But in the general case, the very first step to be taken is to keep packets out of router queues. I sometimes observed RTTs by 20 ms or more between Stuttart and Karlsruhe, i,e. about 60 kilometers. Perhaps, we have a special "opaque fibre" with reduced speed of light there. However, I'm not convinced that this RTT is caused by the links and processcing delays. I would have a look at the memory graveyards called "router" along the path. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From detlef.bosau at web.de Wed Aug 20 14:09:55 2014 From: detlef.bosau at web.de (Detlef Bosau) Date: Wed, 20 Aug 2014 23:09:55 +0200 Subject: [e2e] Once again buffer bloat and CC. Re: A Cute Story. Or: How to talk completely at cross purposes. Re: [ih] When was Go Back N adopted by TCP In-Reply-To: <1408565008.272912094@apps.rackspace.com> References: <20140519150259.35C1E28E137@aland.bbn.com> <537B35D0.9040400@web.de> <538DC307.90101@web.de> <53D77F3A.5020100@web.de> <53F4D731.1020007@pollere.com> <53F4ECA4.8040200@web.de> <53F4F08B.2070702@web.de> <1408565008.272912094@apps.rackspace.com> Message-ID: <53F50EA3.7000904@web.de> Am 20.08.2014 um 22:03 schrieb dpreed at reed.com: > > [Joe Touch - please pass this on to the e2e list if it is OK with you] > > > > I'd like to amplify Detlef's reference to my position and approach to > end-to-end congestion management, which may or may not be the same > approach he would argue for: > What I have in mind is different in some respect - however the goals are quite compatible, > > > > To avoid/minimize end-to-end queueing delay in a shared internetwork, > we need to change the idea that we need to create substantial queues > in order to measure the queue length we want to reduce. > That's what I talked about, when I argued, we would measure the wrong parameters. Particularly, when you refer to Raj Jain, Jain measures (in his mathematical model) a queueing system's power in order to achieve a workload which would allow the system to work with optimum performance. What we actually measure is: Was the workload too large for the system or not? > This is possible, because of a simple observation: you can detect and > measure the probability that two flows sharing a link will delay each > other before they actually do... call this "pre-congestion avoidance". > In a "hop by hop flow control scenario" this could be achieved by a window based flow control which follows the very simple rule that a packet must not be sent to a hop until it can be processed there without having to wait. > > > Rather than leave that as an exercise for the reader (it's only a > Knuth [20] problem at most, but past suggestions have not been > followed up, and I am working 16 hours per day in a startup), I will > explain how: packets need to wait for each other if the time interval > each spends passing through a particular switch's outbound NIC > "overlaps". If you remember recent flow histories (as fq_codel does, > for example), you can record when each flow recently occupied the > switch's outbound link, and with some robust assumptions of timing > variability, one can estimate the likelihood that a queue might have > built up. This information can be reflected to the destination of all > flows, just as ECN marks are used in Jain's approach. Since > congestion control is necessarily done by having the receiving end > control the sending end (because you want to move end-to-end queues > back to the source entrypoint, where they must exist for > retransmission in any case), the receiver can use that "near > collision" detection notification to slow the sender to a > non-congesting rate that shares all links on the path such that queues > will develop with arbitrarily low probability. > Where we might differ, however I have to think about it, is that I tend to emphasize the asynchronous character of the Internet (where a definition of a term "rate" is not used) while I think you have in mind the model of "optimum rates" which have to be reasonably estimated. (IIRC you mentioned something in that direction some weeks ago.) > > > Call this the "ballistic collision avoidance" model (and cite me if > you don't want to take all the credit). > > -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From touch at isi.edu Wed Aug 20 14:31:55 2014 From: touch at isi.edu (Joe Touch) Date: Wed, 20 Aug 2014 14:31:55 -0700 Subject: [e2e] Fwd: Re: Once again buffer bloat and CC. Re: A Cute Story. Or: How to talk completely at cross purposes. Re: [ih] When was Go Back N adopted by TCP In-Reply-To: <1408565008.272912094@apps.rackspace.com> References: <1408565008.272912094@apps.rackspace.com> Message-ID: <53F513CB.5050700@isi.edu> Forwarded for David Reed. Joe (as list admin) -------- Original Message -------- Subject: Re: [e2e] Once again buffer bloat and CC. Re: A Cute Story. Or: How to talk completely at cross purposes. Re: [ih] When was Go Back N adopted by TCP Date: Wed, 20 Aug 2014 16:03:28 -0400 (EDT) From: dpreed at reed.com To: Detlef Bosau , Kathleen Nichols CC: end2end-interest at postel.org, "Joe Touch" [Joe Touch - please pass this on to the e2e list if it is OK with you] I'd like to amplify Detlef's reference to my position and approach to end-to-end congestion management, which may or may not be the same approach he would argue for: To avoid/minimize end-to-end queueing delay in a shared internetwork, we need to change the idea that we need to create substantial queues in order to measure the queue length we want to reduce. This is possible, because of a simple observation: you can detect and measure the probability that two flows sharing a link will delay each other before they actually do... call this "pre-congestion avoidance". Rather than leave that as an exercise for the reader (it's only a Knuth [20] problem at most, but past suggestions have not been followed up, and I am working 16 hours per day in a startup), I will explain how: packets need to wait for each other if the time interval each spends passing through a particular switch's outbound NIC "overlaps". If you remember recent flow histories (as fq_codel does, for example), you can record when each flow recently occupied the switch's outbound link, and with some robust assumptions of timing variability, one can estimate the likelihood that a queue might have built up. This information can be reflected to the destination of all flows, just as ECN marks are used in Jain's approach. Since congestion control is necessarily done by having the receiving end control the sending end (because you want to move end-to-end queues back to the source entrypoint, where they must exist for retransmission in any case), the receiver can use that "near collision" detection notification to slow the sender to a non-congesting rate that shares all links on the path such that queues will develop with arbitrarily low probability. Call this the "ballistic collision avoidance" model (and cite me if you don't want to take all the credit). It's one way to achieve what Detlef has described as "my position" while retaining a simple model. And if you need a mechanism for tracking packets that have passed through a node in recent times, I suggest studying this paper very carefully: Deng and Rafei, "Approximately detecting duplicaes for streaming data using Stable Bloom Filters". Stable Bloom Filters can use the switch memory not used by excess buffer space to prevent unnecessary queueing, rather than to create queues in order to have something to measure. They can detect the current density of packets on the same flow (they are a version of Counting Bloom Filters that don't need the delete() operation to reduce the "count", only requiring insert() operations). As they say in the patentability literature, that is a description of the concept sufficient for someone skilled in the relevant (protocol engineering) art to fully realize the invention. I view this note as a publication - thus no one can patent this idea from now on. This is "prior art" and a "constructive realization" of the invention. Thus I grant it to the internetworking community to be used freely without a license, which I hope is what will happen, as has happened with all other internetworking concepts. If it is turned into specific source code or silicon design, you may want to copyright it, however, to capture value from your labor in completing the implementation. I'm sure there is also a great paper or two waiting to be written based on exploring the idea's impact on real networking and comparing it with other approaches. On Wednesday, August 20, 2014 3:01pm, "Detlef Bosau" said: > And in addition, what queue length is concerned, I take the position > (which is similar to DPR's, IIRC) that a router should keep no more than > one packet per flow at a given time, in the general case. > > I explicitly state that in wireless scenarios, there might be reasons to > accept longer router queues, particularly in the context of > opportunistic scheduling. But in the general case, the very first step > to be taken is to keep packets out of router queues. I sometimes > observed RTTs by 20 ms or more between Stuttart and Karlsruhe, i,e. > about 60 kilometers. > > Perhaps, we have a special "opaque fibre" with reduced speed of light > there. However, I'm not convinced that this RTT is caused by the links > and processcing delays. I would have a look at the memory graveyards > called "router" along the path. > > > -- > ------------------------------------------------------------------ > Detlef Bosau > Galileistra?e 30 > 70565 Stuttgart Tel.: +49 711 5208031 > mobile: +49 172 6819937 > skype: detlef.bosau > ICQ: 566129673 > detlef.bosau at web.de http://www.detlef-bosau.de > > From detlef.bosau at web.de Thu Aug 21 05:16:18 2014 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 21 Aug 2014 14:16:18 +0200 Subject: [e2e] Fwd: Re: Once again buffer bloat and CC. Re: A Cute Story. Or: How to talk completely at cross purposes. Re: [ih] When was Go Back N adopted by TCP In-Reply-To: <53F513CB.5050700@isi.edu> References: <1408565008.272912094@apps.rackspace.com> <53F513CB.5050700@isi.edu> Message-ID: <53F5E312.6060004@web.de> As far as I see, DPR's idea is to gather congestion information along the path using Bloome Filters. There is one possible problem, which also arises with hopwise credit based flow control: The Internet is basically an overlay network. So an important issue, sometimes gets a bit lost, is that "adjacent" IP nodes are - though being adjacent - not always connected by a point to point link but there may be a more or less complex infrastructure in between. Now, congestion may well occur on nodes BETWEEN the IP nodes. (E.g. Ethernet bridges, think of remote bridging as used in ADSL.) The IP packet's payload is not accessible for those "L2 nodes", hence these nodes cannot stamp packets with any actual congestion information. As a consequence, imminent congestion may not be visible for the IP based overlay network. Detlef From detlef.bosau at web.de Thu Aug 21 13:59:20 2014 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 21 Aug 2014 22:59:20 +0200 Subject: [e2e] FC vs CC Re: Fwd: Re: Once again buffer bloat and CC. Re: A Cute Story. Or: How to talk completely at cross purposes. Re: [ih] When was Go Back N adopted by TCP In-Reply-To: <53F5E312.6060004@web.de> References: <1408565008.272912094@apps.rackspace.com> <53F513CB.5050700@isi.edu> <53F5E312.6060004@web.de> Message-ID: <53F65DA8.7000907@web.de> In this context, my question is: When were the terms congestion control and flow control coined? I intentionally don't ask for the typical definitions in lectures "flow control is between TCP sender and receiver" and "congestion control is somewhat in between". (A definition like this is vague, and in my opinion, exactly this vagueness is the very problem.) Detlef From jnc at mercury.lcs.mit.edu Thu Aug 21 14:27:25 2014 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 21 Aug 2014 17:27:25 -0400 (EDT) Subject: [e2e] [ih] FC vs CC Re: Fwd: Re: Once again buffer bloat and CC. Re: A Cute Story. Or: How to talk completely at cross purposes. Re: When was Go Back N adopted by TCP Message-ID: <20140821212725.9ED4618C0D2@mercury.lcs.mit.edu> > From: Detlef Bosau > When were the terms congestion control and flow control coined? 'Flow control' (in networking - in communications overall, it goes back even further) is pretty old: RFC-36 (March 1970) talks about it in close to the modern sense (although at that point, it was provided by the network, not by the end-host), so its use in data networks dates back basically to the beginning. 'Congestion control' has also been around for a while - see RFC-802 (November 1981), and then Nagle's magnificent RFC-896 (January 1984), where is appears in pretty much its modern meaning. Noel