From daniel.schaffrath at mac.com Sun Nov 11 11:25:37 2007 From: daniel.schaffrath at mac.com (Daniel Schaffrath) Date: Sun, 11 Nov 2007 20:25:37 +0100 Subject: [e2e] TCP to exhibit MTU unfairness? Message-ID: Dear Community, I was wondering if there is something like "MTU unfairness"... similar to the probably not existing "RTT unfairness". Maybe you have any pointers? What do you think? Thank you, Daniel From Detlef.Bosau at web.de Mon Nov 12 03:46:46 2007 From: Detlef.Bosau at web.de (Detlef Bosau) Date: Mon, 12 Nov 2007 12:46:46 +0100 Subject: [e2e] TCP to exhibit MTU unfairness? Message-ID: <467215998@web.de> > > Dear Community, > > I was wondering if there is something like "MTU unfairness"... > similar to the probably not existing "RTT unfairness". My basic question is: What is the ressource to be shared? In TCP, the shared ressource is storage capacity along the path. The actual MTU size of a flow does not matter in this context. So, it is not yet clear to me what you mean by "MTU (un)fairness" or "RTT (un)fairness". Detlef From detlef.bosau at web.de Mon Nov 12 09:24:08 2007 From: detlef.bosau at web.de (Detlef Bosau) Date: Mon, 12 Nov 2007 18:24:08 +0100 Subject: [e2e] Ressource fairness of PF scheduling and similar schemes in the presence of asymmetric fading. Message-ID: <47388C38.5060504@web.de> Hi. To my knowledge, PF scheduling etc. encounter fairness problems in case of asymmetric fading, i.e. when there are terminals attached to a cell with low noise channels while other terminals suffer from severe noise. I?m currently pursuing some work on this issue and would very much appreciate to get in touch with some researchers interested in this matter here in Germany. Are there any? Thanks. Detlef -- Detlef Bosau Mail: detlef.bosau at web.de Galileistrasse 30 Web: http://www.detlef-bosau.de 70565 Stuttgart Skype: detlef.bosau Mobile: +49 172 681 9937 From detlef.bosau at web.de Mon Nov 12 11:00:51 2007 From: detlef.bosau at web.de (Detlef Bosau) Date: Mon, 12 Nov 2007 20:00:51 +0100 Subject: [e2e] TCP to exhibit MTU unfairness? In-Reply-To: References: <467215998@web.de> Message-ID: <4738A2E3.6070104@web.de> Lachlan Andrew wrote: > Greetings Detlef and Daniel > > I think Daniel was pointing out that current TCP sets the window in > terms of number of MTUs, ?? Excuse me, if I have something wrong in mind, but isn?t the window given in bytes? Or does this depend on the TCP flavour? > and hence gives bandwidth proportional to the > MTU of a flow. Flows using MTU=100 get roughly 1/15 of the bandwidth > of flows using MTU=1500. > > Some people argue that this is correct behaviour if the actual > bottleneck is the "packet per second" forwarding limit of a router, > rather than the link capacity. However, I think that Daniel is right > Hm. I read the congavoid paper again and again and to my understanding, the fairness issue tackled by congestion control is a _capacity_ issue.... > that it is normally undesirable unfairness. > > If the window is given in MTU size units, I agree. Detlef > Cheers, > Lachlan > > On 12/11/2007, Detlef Bosau wrote: > >>> Dear Community, >>> >>> I was wondering if there is something like "MTU unfairness"... >>> similar to the probably not existing "RTT unfairness". >>> >> My basic question is: What is the ressource to be shared? >> >> In TCP, the shared ressource is storage capacity along the path. The actual MTU size of a flow does not matter in this context. >> So, it is not yet clear to me what you mean by "MTU (un)fairness" or "RTT (un)fairness". >> >> >> Detlef >> >> >> > > > -- Detlef Bosau Mail: detlef.bosau at web.de Galileistrasse 30 Web: http://www.detlef-bosau.de 70565 Stuttgart Skype: detlef.bosau Mobile: +49 172 681 9937 From detlef.bosau at web.de Mon Nov 12 14:58:17 2007 From: detlef.bosau at web.de (Detlef Bosau) Date: Mon, 12 Nov 2007 23:58:17 +0100 Subject: [e2e] TCP to exhibit MTU unfairness? In-Reply-To: References: <467215998@web.de> <4738A2E3.6070104@web.de> Message-ID: <4738DA89.2040007@web.de> Lachlan Andrew wrote: > Greetings Detlev > > On 12/11/2007, Detlef Bosau wrote: > >> Lachlan Andrew wrote: >> >>> Greetings Detlef and Daniel >>> >>> I think Daniel was pointing out that current TCP sets the window in >>> terms of number of MTUs, >>> >> Excuse me, if I have something wrong in mind, but isn?t the window given >> in bytes? >> Or does this depend on the TCP flavour? >> > > The "additive increase" in Tahoe/Reno/NewReno is specified as > increasing the window by one MTU. Yes, I see. I think, it?s intentionally 1 MSS per RTT. So, a flow with large MTU increases faster than one with a small MTU, correct? O.k., than I see the problem. However, I don?t see an easy solution. > It is certainly network capacity. The question is whether it is > mainly limited by link capacity or router capacity. Each occurs in > some parts of the network. Like you, I believe that the link capacity > is more often a problem, but I don't have numbers to back that up. > To my knowledge, it?s common sense the router queues should not grow too large, i.e. one must not worsen the problem by introducing to much router capacity here. I always forget the correct rule of thumb, but isn?t it something like: The router capacity should back up one end to end line capaccity = one latentency throughput product end to end? However, perhaps Daniel?s problem is not really that bad, because TCP congestion control only achieves fairness when competing flows share a common path. And hopefully (with fingers crossed....) in that case, competing flows should negotiate similar MTU / MSS sizes, or what do you think? Detlef > -- Detlef Bosau Mail: detlef.bosau at web.de Galileistrasse 30 Web: http://www.detlef-bosau.de 70565 Stuttgart Skype: detlef.bosau Mobile: +49 172 681 9937 From detlef.bosau at web.de Tue Nov 13 13:32:24 2007 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 13 Nov 2007 22:32:24 +0100 Subject: [e2e] TCP to exhibit MTU unfairness? In-Reply-To: References: <467215998@web.de> <4738A2E3.6070104@web.de> <4738DA89.2040007@web.de> Message-ID: <473A17E8.7090205@web.de> Hi! Lachlan Andrew wrote: > If we're willing to change TCP, we can just specify the rate of change > independently of MTU. Some proposals to get RTT fairness essentially > do that. > > Hm. Just a question on RTT fairness: Is it intended to have the same RTT for competing flows sharing a bottleneck? > We want fairness if we have a common *bottleneck*, rather than > complete common path. The bottleneck could well be a 10G link, which > can support jumbo frames. Absolutely. The bottleneck is the link where packets are dropped. Actually, this can well be the "broadest" link along the whole path. However, when TCP congestion control achieves fairness of capacity usage, I would well accept when two competing flows do not achieve exactly the same throughput although they share a common bottleneck. Do you agree here? Regards Detlef -- Detlef Bosau Mail: detlef.bosau at web.de Galileistrasse 30 Web: http://www.detlef-bosau.de 70565 Stuttgart Skype: detlef.bosau Mobile: +49 172 681 9937 From lachlan.andrew at gmail.com Tue Nov 13 14:10:17 2007 From: lachlan.andrew at gmail.com (Lachlan Andrew) Date: Tue, 13 Nov 2007 14:10:17 -0800 Subject: [e2e] TCP to exhibit MTU unfairness? In-Reply-To: <473A17E8.7090205@web.de> References: <467215998@web.de> <4738A2E3.6070104@web.de> <4738DA89.2040007@web.de> <473A17E8.7090205@web.de> Message-ID: Greetings Detlef, On 13/11/2007, Detlef Bosau wrote: > > Hm. Just a question on RTT fairness: Is it intended to have the same RTT > for competing flows sharing a bottleneck? No, in general flows will have different RTTs. I was just mentioning that some flow control algorithm aim to give them an equal share of the capacity, despite having unequal RTTs. > However, when TCP congestion control achieves fairness of capacity > usage, I would well accept when two competing flows do not achieve > exactly the same throughput although they share a common bottleneck. Do > you agree here? Fairness between heterogeneous flows is complicated. If a flow traverses multiple congested links, it is sensible to give it a lower rate than others using only one of those links. However, I haven't seen any compelling reason that the rates should depend on RTT or packet size. I wasn't meaning to get into a debate about fairness; I was just explaining Daniel's original post. Cheers, Lachlan -- Lachlan Andrew Dept of Computer Science, Caltech 1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA Ph: +1 (626) 395-8820 Fax: +1 (626) 568-3603 http://netlab.caltech.edu/~lachlan From tvpoh at essex.ac.uk Mon Nov 19 11:43:18 2007 From: tvpoh at essex.ac.uk (Tze-Ven Poh) Date: Mon, 19 Nov 2007 19:43:18 -0000 Subject: [e2e] TCP to exhibit MTU unfairness? References: <467215998@web.de><4738A2E3.6070104@web.de><4738DA89.2040007@web.de><473A17E8.7090205@web.de> Message-ID: <012c01c82ae4$6f74e120$cf3df59b@essex.ac.uk> Greetings, ----- Original Message ----- From: "Lachlan Andrew" To: "Detlef Bosau" ; "e2e" Sent: Tuesday, November 13, 2007 10:10 PM Subject: Re: [e2e] TCP to exhibit MTU unfairness? > Fairness between heterogeneous flows is complicated. If a flow > traverses multiple congested links, it is sensible to give it a lower > rate than others using only one of those links. However, I haven't > seen any compelling reason that the rates should depend on RTT or > packet size. If a few users are on a parking-lot type of network and are all paying the same (monetarily) for the access service, is it fair for the fellow who has to go through multiple congestion links to get lower rate? [just a question] From anoop at brocade.com Mon Nov 19 13:48:20 2007 From: anoop at brocade.com (Anoop Ghanwani) Date: Mon, 19 Nov 2007 13:48:20 -0800 Subject: [e2e] TCP to exhibit MTU unfairness? In-Reply-To: <012c01c82ae4$6f74e120$cf3df59b@essex.ac.uk> References: <467215998@web.de><4738A2E3.6070104@web.de><4738DA89.2040007@web.de><473A17E8.7090205@web.de> <012c01c82ae4$6f74e120$cf3df59b@essex.ac.uk> Message-ID: <4C94DE2070B172459E4F1EE14BD2364EAD5981@HQ-EXCH-5.corp.brocade.com> > -----Original Message----- > From: end2end-interest-bounces at postel.org > [mailto:end2end-interest-bounces at postel.org] On Behalf Of Tze-Ven Poh > Sent: Monday, November 19, 2007 11:43 AM > To: l.andrew at ieee.org; Detlef Bosau; e2e > Subject: Re: [e2e] TCP to exhibit MTU unfairness? > > Greetings, > > ----- Original Message ----- > From: "Lachlan Andrew" > To: "Detlef Bosau" ; "e2e" > > Sent: Tuesday, November 13, 2007 10:10 PM > Subject: Re: [e2e] TCP to exhibit MTU unfairness? > > > > Fairness between heterogeneous flows is complicated. If a flow > > traverses multiple congested links, it is sensible to give > it a lower > > rate than others using only one of those links. However, I haven't > > seen any compelling reason that the rates should depend on RTT or > > packet size. > > If a few users are on a parking-lot type of network and are > all paying the > same (monetarily) for the access service, is it fair for the > fellow who has > to go through multiple congestion links to get lower rate? > > [just a question] This can be argued either way. If a connection is going through multiple hops, it is already consuming more resources in the network (regardless of whether or not those hops are congested); so the argument for this case would be that it is probably OK for it to get a lower rate. However, routing policy is often dictated by someone other than the user, possibly forcing the user through more hops than may be needed; in this case, it could be argued that a connection should receive a rate independent of the number of congested links. At this point, I don't think it makes a difference. You get what you get with TCP and it's probably not going to change any time soon. :-) Anoop From detlef.bosau at web.de Tue Nov 20 02:34:14 2007 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 20 Nov 2007 11:34:14 +0100 Subject: [e2e] TCP to exhibit MTU unfairness? In-Reply-To: <012c01c82ae4$6f74e120$cf3df59b@essex.ac.uk> References: <467215998@web.de><4738A2E3.6070104@web.de><4738DA89.2040007@web.de><473A17E8.7090205@web.de> <012c01c82ae4$6f74e120$cf3df59b@essex.ac.uk> Message-ID: <4742B826.2030908@web.de> Tze-Ven Poh wrote: > > If a few users are on a parking-lot type of network and are all paying > the same (monetarily) for the access service, is it fair for the > fellow who has to go through multiple congestion links to get lower rate? > > [just a question] And it?s an interesting question, especially for wireless networks. The question is: "What is fairness?" Apparently, this word has at least ten times as much possible meanings as it has possible spelling errors. The system model used in the congavoid paper focuses a very special situation: Comparable, if not identical, paths and a common bottleneck. And the goal was to share the common ressources equally. If we consider a HSDPA cell, it is necessary to get a common sense which is the shared ressource and what fairness should mean in this context. To make a very long story very short here, the literature up to know focusses at "throughput fairness" here and simply does not take into accout i) ressource fairness and ii) (with one exception, which I?m yet to understand) asymmetric fading. Where "asymmetric fading" itself indicates, that in wireless networks different terminals in one common cell may well face extremely different network conditions. An issue, you?ll never see in wirelined networks. So, "what is fairness"? Didn?t Pontius Pilatus raise the question: "What is truth?" However, this discussion is indeed beyond this little discussion about MTU sizes :-) But with special respect to wireless networks, I think the monetary aspect _is_ important. And particularly in wireless networks, customers pay mainly for wireless ressources (the wireline costs can be neglected in most cases) and therefore, it is extremely important to consider which ressources are given to whom and under which circumstances. Detlef -- Detlef Bosau Mail: detlef.bosau at web.de Galileistrasse 30 Web: http://www.detlef-bosau.de 70565 Stuttgart Skype: detlef.bosau Mobile: +49 172 681 9937 From detlef.bosau at web.de Sun Nov 25 05:11:18 2007 From: detlef.bosau at web.de (Detlef Bosau) Date: Sun, 25 Nov 2007 14:11:18 +0100 Subject: [e2e] Ressource fairness of PF scheduling and similar schemes in the presence of asymmetric fading. In-Reply-To: <47388C38.5060504@web.de> References: <47388C38.5060504@web.de> Message-ID: <47497476.5090901@web.de> Once again me :-) At the moment, I see two areas of interest in opportunistic scheduling as it is used in HSDPA systems. (At least, they are of interest for me. I don?t know the opinion of others people.) For quite some time, proportional fair scheduling was state of the art. Recently, some alternatives have been proposed. The main shortcoming in PF scheduling is its behaviour in the presence of asymmetric fading. Refer to http://perso.rd.francetelecom.fr/bonald/Pub/SB.pdf. Thomas Bonald, "A Score-Based Opportunistic Schedulerfor Fading Radio Channels". Intuitively, the reason for the problem is that SNR values for different UEs may vary on different average values and with different variation. Hence to compare SNR values for different UEs is often comparing peaches and oranges. To my knowledge, we have to approaches to overcome this problem. One was developed within the Eurane Project, * Fair Channel Quality-Based Scheduling Scheme for HSDPA System* Al-Manthari, B.; Nasser, N.; Hassanein, H. Computer Systems and Applications, 2006. IEEE International Conference on. Volume , Issue , March 8, 2006 Page(s): 221 - 227 Digital Object Identifier The idea is to use statistices "(SNR value - average) / standard devation" instead of the original SNR values. So, for any UE the considered statistics share a common expectation (0) and a common variation (1) and are hence comparable. Another approach is the aforementioned one by Thomas Bonald, who basically (please correct me, if I have a misconception here) uses quantiles / ranks as statistics to compare SNR values for different UEs. In fact, quantiles are not mentioned explicitely in Bonald?s work, but practically, this is the idea behind his approach: The actual SNR is ranked within a set of n most recent SNR values. Im not sure yet, whether we achieve comparable statistics here. The other issue is ressource fairness / QoS in opportunistic scheduling. I did some experiements with a token based approach during the last weeks - however, the problem is to achieve stability because of the uncomparable SNR statistics. If we had SNR statistics which are i.i.d., a token based approach could be helpful here, but I?m afraid that?s hardly to achieve. So, at the moment, I plan to investigate some rate based approach. The idea is to have some kind of "modified round roubin" scheduling, which - enforces fair (or if QoS applies: according to contract) ressource usage for any flow in the long run - allows to use higher or lower ressource usage in the short run in order to adapt the system to favourable or poor channel conditions. I?m curious whether there are other people interested in this matter, especially people from Germany. Detlef -- Detlef Bosau Mail: detlef.bosau at web.de Galileistrasse 30 Web: http://www.detlef-bosau.de 70565 Stuttgart Skype: detlef.bosau Mobile: +49 172 681 9937 From liqianluo at live.com Wed Nov 28 18:27:09 2007 From: liqianluo at live.com (Liqian Luo) Date: Wed, 28 Nov 2007 18:27:09 -0800 Subject: [e2e] ACM SenSys 2008 - Call for Papers Message-ID: We apologize if you received multiple copies of this message! ************************************************************* Paper Submissions Deadline: *April 14, 2008* ************************************************************* Call for Papers ACM SenSys 2008 The 6th ACM Conference on Embedded Networked Sensor Systems November 5 - 7, 2008 Raleigh, NC http://sensys.acm.org/2008/ ************************************************************* The 6th ACM Conference on Embedded Networked Sensor Systems (SenSys) is a highly selective, single-track forum for the presentation of research results on systems issues in the area of embedded, networked sensors. Distributed systems based on networked sensors and actuators with embedded computation capabilities enable an instrumentation of the physical world at an unprecedented scale and density, thus enabling a new generation of monitoring and control applications. This conference provides an ideal venue to address the research challenges facing the design, deployment, use, and fundamental limits of these systems. Sensor networks require contributions from many fields, from wireless communication and networking, embedded systems and hardware, distributed systems, data management, and applications, so we welcome cross-disciplinary work. We particularly encourage papers that extend the scope of the conference beyond wireless mote-class sensor networks and we seek contributions from a broad range of sensing-related fields, such as actuator networks, RFID applications, mobile ad-hoc networks, camera networks, and others. We seek technical papers describing original, previously unpublished research results. Topics of interest include, but are not limited to, the following: - Sensor network architecture and protocols - Sensor network algorithms such as localization, routing, time synchronization, clustering, topology control, and coverage control algorithms - Rich sensor systems leveraging RFID, mobile devices (e.g., cell phones), cameras, robotics, etc. - Failure resilience and fault isolation - Analysis of real-world systems and fundamental limits - Energy management - Sensor network planning, provisioning, calibration and deployment - Data, information, and signal processing - Deployment experience and testbeds - Data storage and management - Experimental methods, including measurement, simulation, and emulation infrastructure - Distributed actuation and control - Programming methodology - Applications - Operating systems - Security and privacy - Integration with back-end systems such as web-based information systems, process control, and enterprise software Program Co-Chairs ************************************************************* Margaret Martonosi, Princeton University Adam Wolisz, TU Berlin Sponsored by ************************************************************* ACM SIGCOMM, SIGMOBILE, SIGARCH, SIGOPS, SIGMETRICS and SIGBED; with support from NSF. Important dates ************************************************************* - Paper Registration and Abstract: April 7, 2008, 5pm US Eastern Time - Paper Submission Deadline: April 14, 2008, 5pm US Eastern Time - Notification of Paper Acceptance: July 18, 2008 - Camera Ready Paper Copy: August 25, 2008 All deadlines are firm; we will not honor extensions. Papers must be original, unpublished work not under consideration elsewhere. All submissions will be handled electronically and must be in PDF format, fitting length and formatting guidelines as directed on the submission webpage. All submitted papers will be peer-reviewed. The review process is double-blind and hence, all submissions must be anonymized. Selected papers of particular merit will be proposed for publication in the ACM Transactions on Sensor Networks. For submission details, see the conference web site at http://sensys.acm.org/2008/ Demos ************************************************************* Demonstrations showing innovative research and applications are solicited. SenSys is very interested in demonstrations of technology, platforms, and applications of sensor systems. Abstracts of accepted demos will be published in the SenSys conference proceedings. Submissions from both industry and academia are encouraged. For submission details, see the conference web site. A call for demos with submission dates, etc., will be posted at a later point. Posters ************************************************************* Posters showing exciting early work on sensor systems are solicited. Areas of interest are the same as those listed in the technical call for papers. While the poster need not describe completed work, it should report on research for which at least preliminary results are available. For submission details, see the conference web site. A call for posters with submission dates, etc., will be posted at a later point. Workshops ************************************************************* Workshop proposals are highly encouraged in emerging areas related to sensor networks. A call for workshop proposals will be posted on the SenSys website. Organization ************************************************************* General Chair: Tarek Abdelzaher (University of Illinois, Urbana-Champaign) Program Co-Chairs: Margaret Martonosi (Princeton) Adam Wolisz (TU Berlin) Poster Co-Chairs: Philippe Bonnet (U. Copenhagen) Tian He (U Minnesota) Demo Co-Chairs: Kamin Whitehouse (U Virginia) Yunhao Liu (Hong Kong University of Science and Technology) Local Arrangements Chair: Injong Rhee (North Carolina State University) Publicity Co-Chairs: Thiemo Voigt (Swedish Institute of Computer Science) Liqian Luo (Microsoft Research) Yoshito Tobe (Tokyo Denki University) Sponsorship Chair: Matt Welsh (Harvard) Web Chair: Ying Zhang (PARC) Registration Chair: Peter Corke (CSIRO ICT Centre) Finance Chair: Jie Liu (Microsoft Research) Workshop Chair: Andrew Campbell (Dartmouth) Student Award Chair: Sam Madden (MIT) Publication Chair: Joe Polastre (Sentilla) Steering Committee Chair: Andrew Campbell (Dartmouth) _________________________________________________________________ Put your friends on the big screen with Windows Vista? + Windows Live?. http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_102007 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20071128/e547fd4c/attachment.html