From detlef.bosau at web.de Wed Feb 1 13:24:50 2012 From: detlef.bosau at web.de (Detlef Bosau) Date: Wed, 01 Feb 2012 22:24:50 +0100 Subject: [e2e] [Iccrg] Re: Reasons not to deply TCP BIC/Cubic In-Reply-To: <201201311722.34168.mirja.kuehlewind@ikr.uni-stuttgart.de> References: <20111130121050.82277480c9hefp4w@mail.poliba.it> <4ED619FE.9090904@ifi.uio.no> <201201311722.34168.mirja.kuehlewind@ikr.uni-stuttgart.de> Message-ID: <4F29ADA2.5080505@web.de> On 01/31/2012 05:22 PM, Mirja Kuehlewind wrote: > Hi everybody, > > I know I'm quite late to enter this discussion, but I would like to raise > another question. I guess there was already a lot explanation on the e2e list > saying (more or less) that Cubic is more aggressive but it is also able to > react more quickly on network changes (mainly sudden increases in bandwidth). First of all, I would really like to avoid the term "bandwidth" in our context. To make a long story short and come to the point: Bandwidth is given in Hertz, throughput is given bin bit per second. At least in papers, I've read so far, this "sloppiness" has lead to much confusion and in some cases to simply wrong results. We should acknowledge the fact, that there are e.g. wireless networks around, where this difference is absolutely crucial. > With e.g. TCP Reno the time between two loss events is increasing with the > network capacity. So it might take a long time to actually detect that there > is more bandwidth available in a network with large capacity. If we want to It is not a bandwidth, what we detect, but it is network capacity. And a tcp flow may share this capacity with others. So, at least one issue is the coexistence of different TCP schemes. > speed up this probing process we would need more frequent loss events causing > a higher loss rate...? I guess one solution to this problem would be ECN. > That means having a high probing rate but no losses. I'm wondering if there > is any other solutions? > To my understanding, even an ECN is respected only "once a round". Please correct me, if I'm wrong. The more I think about BIC and CUBIC, the more I ask for the appropriate problem for this nice solution. I'm not quite sure whether there exists a suitable problem for just more aggressive probing. And perhaps we should clearly focus the problem - afterwards we may propose and discuss suitable solutions. -- ------------------------------------------------------------------ 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 dhavey at yahoo.com Wed Feb 1 14:20:13 2012 From: dhavey at yahoo.com (Daniel Havey) Date: Wed, 1 Feb 2012 14:20:13 -0800 (PST) Subject: [e2e] [Iccrg] Re: Reasons not to deply TCP BIC/Cubic In-Reply-To: <4F29ADA2.5080505@web.de> Message-ID: <1328134813.10478.YahooMailClassic@web130102.mail.mud.yahoo.com> Hehe ;^) I agree with Detlef. We have to be more careful with our terminology, and we have to be specific about the network conditions that we are talking about. For instance we were talking about delay. Lachlan said, something to the effect of Cubic causes large delays. I don't think it does. We are both right. Lachlan sees Cubic's delay as larger than Reno. Therefore it is large. I see the delay as insignificant compared to the 30 second playout buffer that I am working with. Soooo, I have an issue with the term "quickly". I see TCP as a control system with a delayed feedback loop. The feedback is an ACK or a dupAck. How quickly a TCP reacts is completely dependent on RTT (how long it takes for the feedback signal to return to the sender). If I send a packet and it is lost, I will not know it until the ACK from the next packet reaches me. If the packet is received, I should know about it slightly sooner. This is how quickly a TCP can react to changes in the network. I think what Mirja is talking about is the aggressiveness of the response to a feedback signal. This is determined by the congestion control algorithm. Cubic tends to be more aggressive than Reno. ...Daniel PS...It's a lot of work to define the scenario, and the terminology. However, once we have done that, we might actually solve a problem ;^) --- On Wed, 2/1/12, Detlef Bosau wrote: > From: Detlef Bosau > Subject: Re: [e2e] [Iccrg] Re: Reasons not to deply TCP BIC/Cubic > To: end2end-interest at postel.org > Date: Wednesday, February 1, 2012, 1:24 PM > On 01/31/2012 05:22 PM, Mirja > Kuehlewind wrote: > > Hi everybody, > > > > I know I'm quite late to enter this discussion, but I > would like to raise > > another question. I guess there was already a lot > explanation on the e2e list > > saying (more or less) that Cubic is more aggressive but > it is also able to > > react more quickly on network changes (mainly sudden > increases in bandwidth). > > First of all, I would really like to avoid the term > "bandwidth" in our context. > > To make a long story short and come to the point: Bandwidth > is given in Hertz, throughput is given bin bit per second. > At least in papers, I've read so far, this "sloppiness" has > lead to much confusion and in some cases to simply wrong > results. > > We should acknowledge the fact, that there are e.g. wireless > networks around, where this difference is absolutely > crucial. > > With e.g. TCP Reno the time between two loss events is > increasing with the > > network capacity. So it might take a long time to > actually detect that there > > is more bandwidth available in a network with large > capacity. If we want to > > It is not a bandwidth, what we detect, but it is network > capacity. And a tcp flow may share this capacity with > others. So, at least one issue is the coexistence of > different TCP schemes. > > > speed up this probing process we would need more > frequent loss events causing > > a higher loss rate...? I guess one solution to this > problem would be ECN. > > That means having a high probing rate but no losses. > I'm wondering if there > > is any other solutions? > > > > To my understanding, even an ECN is respected only "once a > round". Please correct me, if I'm wrong. > > The more I think about BIC and CUBIC, the more I ask for the > appropriate problem for this nice solution. > I'm not quite sure whether there exists a suitable problem > for just more aggressive probing. > > And perhaps we should clearly focus the problem - afterwards > we may propose and discuss suitable solutions. > > > -- > ------------------------------------------------------------------ > 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 davehart at gmail.com Wed Feb 1 20:21:00 2012 From: davehart at gmail.com (Dave Hart) Date: Thu, 2 Feb 2012 04:21:00 +0000 Subject: [e2e] [Iccrg] Re: Reasons not to deply TCP BIC/Cubic In-Reply-To: <4F29ADA2.5080505@web.de> References: <20111130121050.82277480c9hefp4w@mail.poliba.it> <4ED619FE.9090904@ifi.uio.no> <201201311722.34168.mirja.kuehlewind@ikr.uni-stuttgart.de> <4F29ADA2.5080505@web.de> Message-ID: On Wed, Feb 1, 2012 at 21:24, Detlef Bosau wrote: > The more I think about BIC and CUBIC, the more I ask for the appropriate > problem for this nice solution. > I'm not quite sure whether there exists a suitable problem for just more > aggressive probing. Hypothetical: "I am sharing throughput with others via a network I don't control. I am greedy and want all the throughput I can get, fairness and inefficiency be damned." Perhaps I'm missing something, or less gracious than I should be, but I've always assumed this is the motivation for Linux using more aggressive TCP replacements. Cheers, Dave Hart From dhavey at yahoo.com Thu Feb 2 00:04:31 2012 From: dhavey at yahoo.com (Daniel Havey) Date: Thu, 2 Feb 2012 00:04:31 -0800 (PST) Subject: [e2e] [Iccrg] Re: Reasons not to deply TCP BIC/Cubic In-Reply-To: Message-ID: <1328169871.30260.YahooMailClassic@web130103.mail.mud.yahoo.com> Haha ;^) Just gracious enough. Let me add, the pig-hearted service provider who silently drops non-TCP packets. ...No offence to pigs or service providers ;^) Suppose we have three users, they have RTTs of .01, .1, and 1 seconds. User 1 can compete fairly and get it's fair share of the bottleneck capacity. Users 2 and 3 would have more difficulty. If there is a little packet loss from a poor connection then the situation is even worse. Users 2 and especially 3 would have much improved chances of competing for their fair share if they used Cubic rather than Reno. I understand that RTT fairness, and lossy connections aren't part of the TCP design and perhaps they shouldn't be. However, I think that Cubic is more fair to disadvantaged users. These users will get closer to their fair share of the bottleneck capacity with Cubic than with Reno. ...Daniel > Hypothetical:? "I am sharing throughput with others via > a network I > don't control.? I am greedy and want all the throughput > I can get, > fairness and inefficiency be damned." > > Perhaps I'm missing something, or less gracious than I > should be, but > I've always assumed this is the motivation for Linux using > more > aggressive TCP replacements. > > Cheers, > Dave Hart > From detlef.bosau at web.de Thu Feb 2 03:51:40 2012 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 02 Feb 2012 12:51:40 +0100 Subject: [e2e] [Iccrg] Re: Reasons not to deply TCP BIC/Cubic In-Reply-To: <1328134813.10478.YahooMailClassic@web130102.mail.mud.yahoo.com> References: <1328134813.10478.YahooMailClassic@web130102.mail.mud.yahoo.com> Message-ID: <4F2A78CC.40200@web.de> On 02/01/2012 11:20 PM, Daniel Havey wrote: > Hehe ;^) I agree with Detlef. We have to be more careful with our terminology, and we have to be specific about the network conditions that we are talking about. > > For instance we were talking about delay. Lachlan said, something to the effect of Cubic causes large delays. I don't think it does. Unfortunately, I don't see Lachlan's post yet. However, what shall be the reason for the delay? It's hardly a propagation delay on the path, neither a serialization delay, which may cause grief here. If ever, the problem is likely to be caused by queuing delays. Do you agree here? > Soooo, I have an issue with the term "quickly". Actually, the term is precisely determined :-) > I see TCP as a control system with a delayed feedback loop. This is an always interesting analogy - however, at least to me, not a very helpful one. (And I well expect criticism by Saverio here. IIRC, Saverio did quite a lot of work on analytical models for TCP. However, all these analytical discussions which are necessary for doing control theoretical considerations, did not yet convince me.) > The feedback is an ACK or a dupAck. How quickly a TCP reacts is completely dependent on RTT (how long it takes for the feedback signal to return to the sender). If I send a packet and it is lost, I will not know it until the ACK from the next packet reaches me. If the packet is received, I should know about it slightly sooner. This is how quickly a TCP can react to changes in the network. Exactly. And if you introduce queuing delay into the network, you will slow down the reaction significantly. > I think what Mirja is talking about is the aggressiveness of the response to a feedback signal. This is determined by the congestion control algorithm. Cubic tends to be more aggressive than Reno. And "more aggressive" does not necessarily mean "better". So, I repeat my statement: We should rather spend some time talking about the problem then perhaps waste time talking about appealing solutions which are yet to find a problem. Detlef -- ------------------------------------------------------------------ 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 Feb 2 04:13:40 2012 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 02 Feb 2012 13:13:40 +0100 Subject: [e2e] [Iccrg] Re: Reasons not to deply TCP BIC/Cubic In-Reply-To: References: <20111130121050.82277480c9hefp4w@mail.poliba.it> <4ED619FE.9090904@ifi.uio.no> <201201311722.34168.mirja.kuehlewind@ikr.uni-stuttgart.de> <4F29ADA2.5080505@web.de> Message-ID: <4F2A7DF4.20507@web.de> On 02/02/2012 05:21 AM, Dave Hart wrote: > > Perhaps I'm missing something, or less gracious than I should be, but > I've always assumed this is the motivation for Linux using more > aggressive TCP replacements. I'm Linux user myself. And at the moment, I _USE_ Linux. Therefore, I was not amused when I detected that Linux uses TCP/BIC by default. (Sent to the list in order to salvage the reputation of Linux users.) -- ------------------------------------------------------------------ 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 Feb 2 06:09:14 2012 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 02 Feb 2012 15:09:14 +0100 Subject: [e2e] Google seeks to tweak TCP In-Reply-To: References: <20120123211831.9518128E137@aland.bbn.com> Message-ID: <4F2A990A.8060201@web.de> On 01/24/2012 12:01 PM, Jon Crowcroft wrote: > well, perhaps - sometimes, i just wish TCP would simply get out of the way... Jon, as science is usually thinking in alternatives: What is your alternative for TCP? Anybody is free to propose one. In addition, I wonder, why we need Science at all. We already have Google and Wikipedia and obviously, research is no longer being done by academics or by some huge companies but by Google. Brave new world. Lloyd pointed out some criticism, and we should well remember the Hippocratic oath: "First do no harm." And thoughtlessly increasing initial windows or other "parameter changes" _may_ do harm. On the quoted blog, we find comments like this one: > Rich Jones Jan > 23, 2012 12:14 PM > > > This is awesome work. I'm glad that Google is putting their vast > engineering resources to such good use. > > Rich, Gun.io > > Reply > Clemens Harten > Jan 23, 2012 > 12:24 PM > > > It is impressive to see how simple changes (justified by extensive > research) can lead to a great improvement of the protocol. Well done! > > Reply And whenever people are exited by simple recipes which save the world, we always should keep in mind RFC 1925. > (6) It is easier to move a problem around (for example, by moving > the problem to a different part of the overall network > architecture) than it is to solve it. > > and of course: > (7a) (corollary). Good, Fast, Cheap: Pick any two (you can't > have all three). Or, as H. L. Mencken said: > "For every complex problem there is a solution that is simple, neat > and wrong" -- ------------------------------------------------------------------ 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 sergey.gorinsky at imdea.org Thu Feb 2 06:16:09 2012 From: sergey.gorinsky at imdea.org (Sergey Gorinsky) Date: Thu, 02 Feb 2012 15:16:09 +0100 Subject: [e2e] Reasons not to deply TCP BIC/Cubic In-Reply-To: Message-ID: Arguing about which TCP version is better is mostly irrelevant because there exists no such thing as an ideal TCP. Different applications have different transport needs, and no single transport protocol can satisfy all these needs at the same time. For me, an eye-opening illustration of this is the following work on bulk-data transfers where the main metric is message delay (i.e., delivery time for the entire message, rather than its individual packets or bits): S. Gorinsky, E. J. Friedman, S. Henderson, and C. Jechlitschek, "Efficient Fair Algorithms for Message Communication", Simulation Modelling Practice and Theory, 17(3), pp. 513-527, March 2009 http://fourier.networks.imdea.org/~sergey_gorinsky/pdf/Fair_Efficiency_SMPT _2008.pdf This paper presents algorithms allocating the whole bottleneck capacity to one message at a time and compares them with the instantaneously fair PS (Processor Sharing). These algorithms reduce average message delay significantly (e.g., 2-3 times faster delivery on average) and guarantee that no individual message experiences a larger delay than under PS. This result could be intuitively understood through the following simple analogy: if 10 people want to go through a 1-person door, doing so 1 person at a time is more efficient from both collective and individual perspectives than trying to fairly squeeze all 10 people through the door at the same time. The moral of the study is that short-term fairness should not be treated as a sacred cow in TCP design. Being unfair/aggressive on short timescales can be socially beneficial. Best regards, Sergey On 2/2/12 5:21 AM, "Dave Hart" wrote: >On Wed, Feb 1, 2012 at 21:24, Detlef Bosau wrote: >> The more I think about BIC and CUBIC, the more I ask for the appropriate >> problem for this nice solution. >> I'm not quite sure whether there exists a suitable problem for just more >> aggressive probing. > >Hypothetical: "I am sharing throughput with others via a network I >don't control. I am greedy and want all the throughput I can get, >fairness and inefficiency be damned." > >Perhaps I'm missing something, or less gracious than I should be, but >I've always assumed this is the motivation for Linux using more >aggressive TCP replacements. > >Cheers, >Dave Hart From arjuna.sathiaseelan at gmail.com Thu Feb 2 07:51:36 2012 From: arjuna.sathiaseelan at gmail.com (Arjuna Sathiaseelan) Date: Thu, 2 Feb 2012 15:51:36 +0000 Subject: [e2e] Google seeks to tweak TCP Message-ID: Dear Deltef, Even Matt mathis who came up with the notion of TCP-friendliness has had a change of mind on how TCP should be ;) - and he is in Google now :).. TCP is OK - but the way TCP works can be changed IMO...The ICCRG was exactly looking at this... I dont see any reason why TCP shouldnt be aggressive - being aggressive for a few RTTs is ok IMHO - but it should respond well to any congestion signal...with better network response (ECN, Re-ECN etc) - TCP could well change its behaviour.. Regards Arjuna > ? 7. Re: Google seeks to tweak TCP (Detlef Bosau) > Date: Thu, 02 Feb 2012 15:09:14 +0100 > From: Detlef Bosau > Subject: Re: [e2e] Google seeks to tweak TCP > To: end2end-interest at postel.org > Message-ID: <4F2A990A.8060201 at web.de> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 01/24/2012 12:01 PM, Jon Crowcroft wrote: >> well, perhaps - sometimes, i just wish TCP would simply get out of the way... > > > Jon, > > as science is usually thinking in alternatives: What is your alternative > for TCP? Anybody is free to propose one. > > In addition, I wonder, why we need Science at all. We already have > Google and Wikipedia and obviously, research is no longer being done by > academics or by some huge companies but by Google. > > Brave new world. > > Lloyd pointed out some criticism, and we should well remember the > Hippocratic oath: "First do no harm." And thoughtlessly increasing > initial windows or other "parameter changes" _may_ do harm. > > On the quoted blog, we find comments like this one: > >> Rich Jones Jan >> 23, 2012 12:14 PM >> >> >> ? ? This is awesome work. I'm glad that Google is putting their vast >> ? ? engineering resources to such good use. >> >> ? ? Rich, Gun.io >> >> Reply >> Clemens Harten >> Jan 23, 2012 >> 12:24 PM >> >> >> ? ? It is impressive to see how simple changes (justified by extensive >> ? ? research) can lead to a great improvement of the protocol. Well done! >> >> Reply > > And whenever people are exited by simple recipes which save the world, > we always should keep in mind RFC 1925. >> ? ? (6) ?It is easier to move a problem around (for example, by moving >> ? ? ? ? ?the problem to a different part of the overall network >> ? ? ? ? ?architecture) than it is to solve it. >> >> > > and of course: > >> ? ? ? ? ?(7a) (corollary). Good, Fast, Cheap: Pick any two (you can't >> ? ? ? ? ? ? ?have all three). > > Or, as H. L. Mencken said: > >> "For every complex problem there is a solution that is simple, neat >> and wrong" > > -- > ------------------------------------------------------------------ > 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 > ------------------------------------------------------------------ > > > > > ------------------------------ > > _______________________________________________ > end2end-interest mailing list > end2end-interest at postel.org > http://mailman.postel.org/mailman/listinfo/end2end-interest > > > End of end2end-interest Digest, Vol 95, Issue 1 > *********************************************** -- http://about.me/arjuna.sathiaseelan From detlef.bosau at web.de Thu Feb 2 09:06:49 2012 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 02 Feb 2012 18:06:49 +0100 Subject: [e2e] Google seeks to tweak TCP In-Reply-To: References: Message-ID: <4F2AC2A9.8060503@web.de> On 02/02/2012 04:51 PM, Arjuna Sathiaseelan wrote: > Dear Deltef, > Even Matt mathis who came up with the notion of TCP-friendliness has > had a change of mind on how TCP should be ;) - and he is in Google now > :).. Google is a search engine. Neither God nor the government of the world. And TCP is something to exchange data with. No more, no less. And although it's completely off topic here, I would like to state that in my opinion Google has by far too much influence in politics, administration and even science. > TCP is OK - but the way TCP works can be changed IMO...The ICCRG was > exactly looking at this... Anything can be changed - when there are valid reasons for doing so. > I dont see any reason why TCP shouldnt be aggressive - being I see billions of reasons. They are called users. > aggressive for a few RTTs is ok IMHO - but it should respond well to And for how many RTTs aggressiveness is acceptable? As I was told by a Telco guy, the first and main duty of a customer of the "Deutsche Bundespost" was not to disturb the system and not to disturb other customers. In times of "social skill" and "EQ", this is sometimes referred to as living in a well behaved community. And in that, Google plays _one_ role. Like any other people in the world. Google is not alone on this planet. > any congestion signal...with better network response (ECN, Re-ECN etc) > - TCP could well change its behaviour.. > Everyone is free to do research in this field and to discuss his results within the community - and when changes make sense, everyone is free to contact the IETF and to convince them by compelling work. However, care should be taken not to let any unrecognized genius mistake the world as his private playground. -- ------------------------------------------------------------------ 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 arjuna.sathiaseelan at gmail.com Thu Feb 2 12:50:40 2012 From: arjuna.sathiaseelan at gmail.com (Arjuna Sathiaseelan) Date: Thu, 2 Feb 2012 20:50:40 +0000 Subject: [e2e] end2end-interest Digest, Vol 95, Issue 2 In-Reply-To: References: Message-ID: Deltef - I wish rest of the world is good as you :)..In a fair world, TCP as it is perfectly fine to exist..But in a selfish world, are people really following the principles that was laid by TCP in the first place? Otherwise BIC, CUBIC and Compound TCP wouldnt have found their way onto the OSs... So for google to say increase the window rather than use multiple parallel TCP connections seem to be a rather fair argument - give the app designers to use better CC rather than find methods to circumvent it.. You know better :).. Regards Arjuna > As I was told by a Telco guy, the first and main duty of a customer of > the "Deutsche Bundespost" was not to disturb the system and not to > disturb other customers. > > In times of "social skill" and "EQ", this is sometimes referred to as > living in a well behaved community. And in that, Google plays _one_ > role. Like any other people in the world. Google is not alone on this > planet. > > >> any congestion signal...with better network response (ECN, Re-ECN etc) >> - TCP could well change its behaviour.. >> > > Everyone is free to do research in this field and to discuss his results > within the community - and when changes make sense, everyone is free to > contact the IETF and to convince them by compelling work. > > However, care should be taken not to let any unrecognized genius mistake > the world as his private playground. > > > -- > ------------------------------------------------------------------ > 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 > ------------------------------------------------------------------ > > > > > ------------------------------ > > _______________________________________________ > end2end-interest mailing list > end2end-interest at postel.org > http://mailman.postel.org/mailman/listinfo/end2end-interest > > > End of end2end-interest Digest, Vol 95, Issue 2 > *********************************************** -- http://about.me/arjuna.sathiaseelan From sgros at zemris.fer.hr Thu Feb 2 13:33:01 2012 From: sgros at zemris.fer.hr (Stjepan =?UTF-8?Q?Gro=C5=A1?=) Date: Thu, 02 Feb 2012 22:33:01 +0100 Subject: [e2e] end2end-interest Digest, Vol 95, Issue 2 In-Reply-To: References: Message-ID: <1328218381.14935.7.camel@w510.sistemnet.hr> On ?et, 2012-02-02 at 20:50 +0000, Arjuna Sathiaseelan wrote: > Deltef - I wish rest of the world is good as you :)..In a fair world, > TCP as it is perfectly fine to exist..But in a selfish world, are > people really following the principles that was laid by TCP in the > first place? Otherwise BIC, CUBIC and Compound TCP wouldnt have found > their way onto the OSs... I couldn't resist but to give a comment on the introductory part of this paragraph: http://en.wikipedia.org/wiki/Tragedy_of_the_commons Regards, SG > So for google to say increase the window rather than use multiple > parallel TCP connections seem to be a rather fair argument - give the > app designers to use better CC rather than find methods to circumvent > it.. > > You know better :).. > > Regards > Arjuna > > > As I was told by a Telco guy, the first and main duty of a customer of > > the "Deutsche Bundespost" was not to disturb the system and not to > > disturb other customers. > > > > In times of "social skill" and "EQ", this is sometimes referred to as > > living in a well behaved community. And in that, Google plays _one_ > > role. Like any other people in the world. Google is not alone on this > > planet. > > > > > >> any congestion signal...with better network response (ECN, Re-ECN etc) > >> - TCP could well change its behaviour.. > >> > > > > Everyone is free to do research in this field and to discuss his results > > within the community - and when changes make sense, everyone is free to > > contact the IETF and to convince them by compelling work. > > > > However, care should be taken not to let any unrecognized genius mistake > > the world as his private playground. > > > > > > -- > > ------------------------------------------------------------------ > > 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 > > ------------------------------------------------------------------ > > > > > > > > > > ------------------------------ > > > > _______________________________________________ > > end2end-interest mailing list > > end2end-interest at postel.org > > http://mailman.postel.org/mailman/listinfo/end2end-interest > > > > > > End of end2end-interest Digest, Vol 95, Issue 2 > > *********************************************** > > > From lachlan.andrew at gmail.com Thu Feb 2 14:22:01 2012 From: lachlan.andrew at gmail.com (Lachlan Andrew) Date: Fri, 3 Feb 2012 09:22:01 +1100 Subject: [e2e] Google seeks to tweak TCP In-Reply-To: <4F2AC2A9.8060503@web.de> References: <4F2AC2A9.8060503@web.de> Message-ID: On 3 February 2012 04:06, Detlef Bosau wrote: > Everyone is free to do research in this field and to discuss his results > within the community - and when changes make sense, everyone is free to > contact the IETF and to convince them by compelling work. When the IETF started, the founders were told that everything should go through the ISO. The IETF community found the ISO too slow, and just experimented for themselves. The same applied to the ITU-T and the ATM forum. Is it possible that the "TCP innovators" are now just finding the IETF too slow, and doing exactly as the founders of the IETF did? Some argue that the Internet is more vital infrastructure now, and so this isn't a fair comparison. However the telephone infrastructure was already vital when the ATM forum took matters into their own hands. To remain relevant for congestion control, the IETF needs to balance responsibility with responsiveness. $0.02, Lachlan (Speaking of being too slow, one day I will finish the TCP evaluation test suite that I started five years ago...) -- Lachlan Andrew? Centre for Advanced Internet Architectures (CAIA) Swinburne University of Technology, Melbourne, Australia Ph +61 3 9214 4837 From lachlan.andrew at gmail.com Thu Feb 2 14:45:09 2012 From: lachlan.andrew at gmail.com (Lachlan Andrew) Date: Fri, 3 Feb 2012 09:45:09 +1100 Subject: [e2e] [Iccrg] Re: Reasons not to deply TCP BIC/Cubic In-Reply-To: <4F2A78CC.40200@web.de> References: <1328134813.10478.YahooMailClassic@web130102.mail.mud.yahoo.com> <4F2A78CC.40200@web.de> Message-ID: Greetings Detlef, On 2 February 2012 22:51, Detlef Bosau wrote: > On 02/01/2012 11:20 PM, Daniel Havey wrote: >> >> For instance we were talking about delay. ?Lachlan said, something to the >> effect of Cubic causes large delays. ?I don't think it does. > > Unfortunately, I don't see Lachlan's post yet. However, what shall be the > reason for the delay? It's hardly a propagation delay on the path, neither a > serialization delay, which may cause grief here. If ever, the problem is > likely to be caused by queuing delays. Do you agree here? That post was ages ago, before Mirja reopened the thread. Yes, it was saying that CUBIC induces excessive queueing delays. >> ?I see TCP as a control system with a delayed feedback loop. > > This is an always interesting analogy - however, at least to me, not a very > helpful one. It isn't an analogy. Congestion control *is* a control system. It is just not a simple one, and all tractable analyses have to model it as something much simpler than it is. >> The feedback is an ACK or a dupAck. ?How quickly a TCP reacts is >> completely dependent on RTT (how long it takes for the feedback signal to >> return to the sender). ?If I send a packet and it is lost, I will not know >> it until the ACK from the next packet reaches me. > > Exactly. And if you introduce queuing delay into the network, you will slow > down the reaction significantly. No. With loss-based TCP, the feedback delay is of the order of the interval between packet losses, which is very much larger than the RTT. (To see why that is the feedback delay, consider how the network signals "increase your rate"; it has to withhold the next expected packet loss.) Although increasing queueing delays makes the RTT much higher, algorithms like CUBIC actually make the feedback delay much less, by causing more frequent losses. A better solution is provided by Compound TCP, which doesn't wait for losses. By monitoring the delay, it does get feedback on the fastest possible timescale (an RTT). It doesn't need to increase the loss rate in order to allow responses to congestion. However, it does still take a long time to converge to a fair rate, because the underlying loss-based CWND still only responds on the same timescale as Reno does. In my understanding, Compound is a strict improvement over Reno when there is one big flow (long-lasting and high-BDP) sharing with occasional cross-traffic, but reverts to Reno when there are just two or more big flows, if the buffers are large. In contrast, in all cases, CUBIC has some benefits (mostly for the flow deploying CUBIC) and some drawbacks (mostly for the cross traffic) over Reno. Cheers, Lachlan -- Lachlan Andrew? Centre for Advanced Internet Architectures (CAIA) Swinburne University of Technology, Melbourne, Australia Ph +61 3 9214 4837 From detlef.bosau at web.de Fri Feb 3 04:12:42 2012 From: detlef.bosau at web.de (Detlef Bosau) Date: Fri, 03 Feb 2012 13:12:42 +0100 Subject: [e2e] [Iccrg] Re: Reasons not to deply TCP BIC/Cubic In-Reply-To: References: <1328134813.10478.YahooMailClassic@web130102.mail.mud.yahoo.com> <4F2A78CC.40200@web.de> Message-ID: <4F2BCF3A.3050505@web.de> On 02/02/2012 11:45 PM, Lachlan Andrew wrote: > > That post was ages ago, before Mirja reopened the thread. Yes, it was > saying that CUBIC induces excessive queueing delays. > Perfect ;-) So I can ask the author himself: Why? >>> I see TCP as a control system with a delayed feedback loop. >> This is an always interesting analogy - however, at least to me, not a very >> helpful one. > It isn't an analogy. Congestion control *is* a control system. It is > just not a simple one, and all tractable analyses have to model it as > something much simpler than it is. > O.k., "not a simple one" is the correct view. Obviously, a simple view into the congavoid paper will help us here: Look at the footnote on page 2: > A conservative flow means that for any given time, the integral of the > packet density around the sender? > receiver?sender loop is a constant. Since packets have to ?diffuse? > around this loop, the integral is sufficiently > continuous to be a Lyapunov function for the system. A constant > function trivially meets the conditions for > Lyapunov stability so the system is stable and any superposition of > such systems is stable. (See [3], chap. 11? > 12 or [21], chap. 9 for excellent introductions to system stability > theory.) I would never dare tallking about Lyapunov stability, particularly not in an interview for a job. These are things where you either have been appointed the Nobel-prize for physics - or you simply stay quiet. However, it clearly exhibits, which mathematical effort must be done to apply control theory to our problem. And perhaps, the message of this footnote is nothing else then "with sufficient effort, it can be shown that at least VJCC and the well known control theory do not contradict." And from what I've read so far in papers, which try to figure out differential equations and the like for TCP, I'm even more convinced that an analytical approach to TCP stability can hardly be achieved with reasonable effort. > >> Exactly. And if you introduce queuing delay into the network, you will slow >> down the reaction significantly. > No. With loss-based TCP, the feedback delay is of the order of the > interval between packet losses, which is very much larger than the > RTT. (To see why that is the feedback delay, consider how the network > signals "increase your rate"; it has to withhold the next expected > packet loss.) Although increasing queueing delays makes the RTT much > higher, algorithms like CUBIC actually make the feedback delay much > less, by causing more frequent losses. More frequent losses cause more frequent retransmissions. And regarding the queuing delay: A larger buffer will drop incoming packets later than a smaller one. Hence, it obviously defers a packet loss. > A better solution is provided by Compound TCP, which doesn't wait for > losses. By monitoring the delay, it does get feedback on the > fastest possible timescale (an RTT). Loss detection by delay observation is a topic, I dealt with myself about a decade ago. A very good paper on this one is: > @article{martin, > journal = " IEEE/ACM TRANSACTIONS ON NETWORKING", > volume ="11", > number = "3", > month = "June", > year = "2003", > title = "Delay--Based Congestion Avoidance for TCP", > author = "Jim Martin and Arne Nilsson and Injong Rhee", > } The major point of this paper is that delay changes and load changes take place on incomparable time scales. What made me leave this approach eventually was the simple fact, that this approach does what scientists call "ratio ex post". We observe a phenomenon, which may be caused by different reasons, e.g. we observe increasing delay which may be caused by increasing load _OR_ increasing service time for instance on a wireless link, and then we get out the crystall ball to guess that one, which applies here. A more hilarious illustration my be the following: (Taken from http://yoursuccessfulchild.com/?p=95) > I am reminded of a story I heard years ago which underscores the need > to rebuild trust by letting go of our assumptions. There was a woman > who was walking in the busy streets of New York City and she noticed > something that she thought was very peculiar. A man standing on a > street corner was clapping his hands every 3 seconds. As the woman > watched in amazement at this man?s consistent, yet odd behavior she > suddenly had the need to approach the man. As he continued to clap his > hands every 3 seconds she asked him why he was committed to this > unusual behavior. While continuing to clap, he explained that this > ritual kept the elephants away. ?But there are no elephants in New > York City? she retorted. ?Exactly, that?s why I continue to do this!? And in that very sense, congestion detection by delay observation is a mixture of clairvoyance and hand clapping against Elephants. Unfortunately, "ratio ex post" is one of the most common mistakes made in science, and I made this several times in my life. Congestion may be signaled by ECN, which can get lost, or by loss, which cannot get lost. It's that simple as that. > It doesn't need to increase the > loss rate in order to allow responses to congestion. Correct. You may send ECN to slow down the sender. > However, it does > still take a long time to converge to a fair rate, because the > underlying loss-based CWND still only responds on the same timescale > as Reno does. I did not spend that much time on reading the original papers on BIC and CUBIC, but at least it was not obvious to me, how these approaches achieve fairness. Whereas in VJCC this becomes clear quite easy. > In my understanding, Compound is a strict improvement > over Reno when there is one big flow (long-lasting and high-BDP) > sharing with occasional cross-traffic, but reverts to Reno when there > are just two or more big flows, if the buffers are large. In > contrast, in all cases, CUBIC has some benefits (mostly for the flow > deploying CUBIC) and some drawbacks (mostly for the cross traffic) > over Reno. Do you happen to have a paper on Compound? Up to now, I only know Compound als "M$ rocket science" - and hardly anyone knows the details. However, in summary we try to tackle large BDP, don't we? And perhaps, we should try to focus on the problem here - and not on the (felt) ten thousandth botch to "improve" TCP/Reno etc. Not to be misunderstood: TCP/Reno and the like _IS_ outstanding work. (I don't know, whether VJ was already awarded the ACM Turing Award, however, his groundbreaking work deserves it.)(And we should keep in mind both, the time passed since the congavoid paper, which has seen improvements since then but up to know no fundamental changes, and the growth of the Internet from about 50 nodes in that time to about 500 millions nodes up to know, i.e. 7 orders of magnitude, and the principles of the congavoid paper still hold as well. I think that should be kept in mind to give this work adequate appreciation.) However, it's in some sense a "one size fits all" work. (Where the range of sizes is outstanding, indeed.) However, there may exist better solutions for particular cases. And perhaps, it may be worthwhile to have a look in that direction. -- ------------------------------------------------------------------ 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 Fri Feb 3 05:54:31 2012 From: detlef.bosau at web.de (Detlef Bosau) Date: Fri, 03 Feb 2012 14:54:31 +0100 Subject: [e2e] Google seeks to tweak TCP In-Reply-To: References: <4F2AC2A9.8060503@web.de> Message-ID: <4F2BE717.7060209@web.de> On 02/02/2012 11:22 PM, Lachlan Andrew wrote: > On 3 February 2012 04:06, Detlef Bosau wrote: > >> Everyone is free to do research in this field and to discuss his results >> within the community - and when changes make sense, everyone is free to >> contact the IETF and to convince them by compelling work. > When the IETF started, the founders were told that everything should > go through the ISO. The IETF community found the ISO too slow, and > just experimented for themselves. The same applied to the ITU-T and > the ATM forum. Research does not happen arbitrarily fast. > Is it possible that the "TCP innovators" are now just finding the IETF > too slow, and doing exactly as the founders of the IETF did? Some Then they are free to develop their "brandndew powerful Internet 21" and to sell it to the public. > argue that the Internet is more vital infrastructure now, and so this > isn't a fair comparison. However the telephone infrastructure was > already vital when the ATM forum took matters into their own hands. > > To remain relevant for congestion control, the IETF needs to balance > responsibility with responsiveness. > The important word is "balance". And you know, I know what I'm talking about. You were perhaps the only one in the world not to know of our little train station problem here in Stuttgart. And exactly there, our government, the authorities, the public and the "Deutsche Bahn" have a matter of responsibility and responsiveness ;-) -- ------------------------------------------------------------------ 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 davehart at gmail.com Fri Feb 3 10:24:33 2012 From: davehart at gmail.com (Dave Hart) Date: Fri, 3 Feb 2012 18:24:33 +0000 Subject: [e2e] [Iccrg] Re: Reasons not to deply TCP BIC/Cubic In-Reply-To: <4F2BCF3A.3050505@web.de> References: <1328134813.10478.YahooMailClassic@web130102.mail.mud.yahoo.com> <4F2A78CC.40200@web.de> <4F2BCF3A.3050505@web.de> Message-ID: On Fri, Feb 3, 2012 at 12:12, Detlef Bosau wrote: > Do you happen to have a paper on Compound? Up to now, I only know Compound > als "M$ rocket science" - and hardly anyone knows the details. Using "M$" to refer to Microsoft says more about you than it does about Microsoft, and it's not flattering. Let me google that for you: http://tools.ietf.org/html/draft-sridharan-tcpm-ctcp-02 (expired) http://research.microsoft.com/apps/pubs/default.aspx?id=70189 If you can't manage to pierce that nonexistent veil of secrecy, it's only because of your own bias, not for lack of public information. Cheers, Dave Hart From dhavey at yahoo.com Fri Feb 3 10:36:44 2012 From: dhavey at yahoo.com (Daniel Havey) Date: Fri, 3 Feb 2012 10:36:44 -0800 (PST) Subject: [e2e] Google seeks to tweak TCP In-Reply-To: <4F2BE717.7060209@web.de> Message-ID: <1328294204.81082.YahooMailClassic@web130105.mail.mud.yahoo.com> > well, perhaps - sometimes, i just wish TCP would simply > get out of the way... > > Jon, > I like this ;^) > as science is usually thinking in alternatives: What is your > alternative for TCP? Anybody is free to propose one. > Hmmm, not really. If a service provider drops non-TCP packets then my TCP alternative will never have a chance to get off the ground. I could build it, but, what is the point if nobody will use it? I believe that any new solution must not only play nice with TCP, but be indistinguishable from TCP. Otherwise the packets may be dropped. > In addition, I wonder, why we need Science at all. We > already have Google and Wikipedia and obviously, research is > no longer being done by academics or by some huge companies > but by Google. > > Brave new world. Hehe ;^) I wish I would have known that before I started this PhD! We still do research at UCSB anyways ;^) > And whenever people are exited by simple recipes which save > the world, we always should keep in mind RFC 1925. > > (6) It is easier to move a problem around (for example, by moving the problem to a different part of the overall network architecture) than it is to solve it. This is getting interesting. So the goal of Cubic (from the paper) is to provide more RTT fairness. It does this. I don't think that queuing delay is the only cause of large RTTs. Sometimes a link is just slow and sketchy. Happens all the time. maybe 802.11n has negotiated a slow rate or there are lots of retransmissions. There will probably be a lot of packets in the queue because of this, but, the link is slow and that is why the RTTs are large. I'm thinking of projects like "Wireless Africa" where links are slow and lossy. Such links have difficulty even reaching their tiny capacity with Reno. They do much better with Cubic. Soooo, if Cubic causes more delay for the faster stations, perhaps it is moving the problem? The disadvantaged stations are happy, because they are getting their little bit of throughput, and the advantaged stations have to live with a few more tens milliseconds of delay? Is Cubic causing more of the problem that it solves? Finally: If Google is God, then I am an atheist ;^) That being said, if Google decides to use Cubic on their youtube servers, then I have to live with that choice. It doesn't really matter what we do with our little receiving stations, because, Google has chosen. If I want to watch a youtube video then I will comply with their choice. Even if it is not a good choice for me. ...Daniel It really would be nice if TCP would just get out of the way... From detlef.bosau at web.de Fri Feb 3 11:22:27 2012 From: detlef.bosau at web.de (Detlef Bosau) Date: Fri, 03 Feb 2012 20:22:27 +0100 Subject: [e2e] [Iccrg] Re: Reasons not to deply TCP BIC/Cubic In-Reply-To: References: <1328134813.10478.YahooMailClassic@web130102.mail.mud.yahoo.com> <4F2A78CC.40200@web.de> <4F2BCF3A.3050505@web.de> Message-ID: <4F2C33F3.8010600@web.de> On 02/03/2012 07:24 PM, Dave Hart wrote: > On Fri, Feb 3, 2012 at 12:12, Detlef Bosau wrote: >> Do you happen to have a paper on Compound? Up to now, I only know Compound >> als "M$ rocket science" - and hardly anyone knows the details. > Using "M$" to refer to Microsoft says more about you than it does > about Microsoft, and it's not flattering. Let me google that for you: Surely. > http://tools.ietf.org/html/draft-sridharan-tcpm-ctcp-02 (expired) > http://research.microsoft.com/apps/pubs/default.aspx?id=70189 Thanks. > If you can't manage to pierce that nonexistent veil of secrecy, it's > only because of your own bias, not for lack of public information. It might be very personal experience. But my professional experience with Microsoft (and business environment) during the last two decades was "somewhat special" on some occasions. Frankly spoken: My impression is that the first interest of Microsoft is commercial success. And academic research is, if at all, a means to this end. May be, this is a very personal experience. However, my personal interest is research. To make a living is a necessary evil. From my experience, for commercial business, the priority is simply the other way round. Detlef > Cheers, > Dave Hart -- ------------------------------------------------------------------ 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 lachlan.andrew at gmail.com Fri Feb 3 18:58:36 2012 From: lachlan.andrew at gmail.com (Lachlan Andrew) Date: Sat, 4 Feb 2012 13:58:36 +1100 Subject: [e2e] [Iccrg] Re: Reasons not to deply TCP BIC/Cubic In-Reply-To: <4F2BCF3A.3050505@web.de> References: <1328134813.10478.YahooMailClassic@web130102.mail.mud.yahoo.com> <4F2A78CC.40200@web.de> <4F2BCF3A.3050505@web.de> Message-ID: Greetings Detlef, On 3 February 2012 23:12, Detlef Bosau wrote: > On 02/02/2012 11:45 PM, Lachlan Andrew wrote: >> >> it was saying that CUBIC induces excessive queueing delays. > > Perfect ;-) So I can ask the author himself: Why? CUBIC induces high queueing delay because it aims to increase the window rapidly until just before the point when the buffer is full, then increases slowly so that the window stays at that buffer-filling size for as long as possible. > O.k., "not a simple one" is the correct view. Obviously, a simple view into > the congavoid paper will help us here: > > Look at the footnote on page 2: >> >> A conservative flow means that for any given time, the integral of the >> packet density around the sender? >> receiver?sender loop is a constant. Since packets have to ?diffuse? around >> this loop, the integral is sufficiently >> continuous to be a Lyapunov function for the system. A constant function >> trivially meets the conditions for >> Lyapunov stability so the system is stable and any superposition of such >> systems is stable. (See [3], chap. 11? >> 12 or [21], chap. 9 for excellent introductions to system stability >> theory.) > > However, it clearly exhibits, which mathematical effort must be done to > apply control theory to our problem. And perhaps, the message of this > footnote is nothing else then "with sufficient effort, it can be shown that > at least VJCC and the well known control theory do not contradict." That passage is justifying using window-based rate control. It argues that having a *constant* sliding window causes the rate to be stable. Most studies of TCP stability take this as a starting point, and assume that "stable window implies stable rates". They then study the stability of the dynamics of the window size (with varying conclusions). > And from what I've read so far in papers, which try to figure out > differential equations and the like for TCP, I'm even more convinced that an > analytical approach to TCP stability can hardly be achieved with reasonable > effort. There is plenty that can be known, and plenty that can't. The main problem isn't lack of understanding of AIMD, but the fact that so much traffic is in the form of short flows that don't follow AIMD. >> No. ?With loss-based TCP, the feedback delay is of the order of the >> interval between packet losses, which is very much larger than the >> RTT. ?(To see why that is the feedback delay, consider how the network >> signals "increase your rate"; it has to withhold the next expected >> packet loss.) ?Although increasing queueing delays makes the RTT much >> higher, algorithms like CUBIC actually make the feedback delay much >> less, by causing more frequent losses. > > More frequent losses cause more frequent retransmissions. Of course. However, our aim isn't usually to avoid retransmissions, but to allow each flow to get a reasonable throughput. By allowing faster feedback, it is in principle possible to cause established flows to back off faster when a new flow starts up. (Of course, the authors of H-TCP will point out that this isn't an automatic consequence of more frequent feedback, and early versions of CUBIC were slower to converge to fairness than Reno was.) [As another aside, Steven Low pointed out off-list that my comment on Reno inducing high feedback delay was imprecise. I should have said that AIMD performs a filtering of the feedback with a time constant of the order of the inter-loss time, and a filter imposes a delay of the order of its time constant. An alternative view is that Reno gets rapid but very imprecise feedback, with the information content of each (N)ACK decaying with the interval between NACKs.] > Loss detection by delay observation is a topic, I dealt with myself about a > decade ago. > delay changes and load changes take > place on incomparable time scales. That probably depends on how we define "load". A load in the form of a burst of packetswill cause a burst of queueing delay on the same timescale. If you mean that delay changes on a faster timescale than the arrival of flows, that is true. We want the feedback to occur on a timescale faster than our reactions to it. > What made me leave this approach eventually was the simple fact, that this > approach does what scientists call "ratio ex post". We observe a phenomenon, > which may be caused by different reasons, e.g. we observe increasing delay > which may be caused by increasing load _OR_ increasing service time for > instance on a wireless link, and then we get out the crystall ball to guess > that one, which applies here. As you often argue, loss can also be due to wireless links rather than congestion. Neither loss nor delay is a guarantee that there is congestion, but both are indications. A congestion control algorithm should consider both, and react to both in a way consistent with either being a false alarm. Doug Leith's group did some work on testing whether increased delay is sufficiently correlated with congestion to be useful. From memory, they found that it is. > And in that very sense, congestion detection by delay observation is a > mixture of clairvoyance and hand clapping against Elephants. > Not to be misunderstood: TCP/Reno and the like _IS_ outstanding work. > (I don't know, whether VJ was already awarded the ACM Turing Award, however, > his groundbreaking work deserves it.) I agree that the insight that loss can be used as a sign of congestion, rather than simply a trigger for retransmission, was outstanding. The robustness of Reno is largely that it uses AIMD, which wasn't new to Reno. Cheers, Lachlan -- Lachlan Andrew? Centre for Advanced Internet Architectures (CAIA) Swinburne University of Technology, Melbourne, Australia Ph +61 3 9214 4837 From detlef.bosau at web.de Sat Feb 4 05:30:01 2012 From: detlef.bosau at web.de (Detlef Bosau) Date: Sat, 04 Feb 2012 14:30:01 +0100 Subject: [e2e] [Iccrg] Re: Reasons not to deply TCP BIC/Cubic In-Reply-To: References: <1328134813.10478.YahooMailClassic@web130102.mail.mud.yahoo.com> <4F2A78CC.40200@web.de> <4F2BCF3A.3050505@web.de> <4F2C38F8.4090702@web.de> <4F2C5B6B.4030709@web.de> Message-ID: <4F2D32D9.6090607@web.de> On 02/04/2012 06:00 AM, Dave Hart wrote: > I apologize, I thought I had deleted my crude final comment before > sending, but I failed. > Unfortunately, you did not delete that comment before I read it. Perhaps, we have different views in this point. However, I woud appreciate if you avoid indecent comments like the (intentionally) not quoted one in the future. If people are scared to present their proposals and results to the scientific community, this speaks for itself. -- ------------------------------------------------------------------ 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 Sat Feb 4 05:35:19 2012 From: detlef.bosau at web.de (Detlef Bosau) Date: Sat, 04 Feb 2012 14:35:19 +0100 Subject: [e2e] [Iccrg] Re: Reasons not to deply TCP BIC/Cubic In-Reply-To: References: <1328134813.10478.YahooMailClassic@web130102.mail.mud.yahoo.com> <4F2A78CC.40200@web.de> <4F2BCF3A.3050505@web.de> Message-ID: <4F2D3417.5080104@web.de> On 02/04/2012 03:58 AM, Lachlan Andrew wrote: >> >> However, it clearly exhibits, which mathematical effort must be done to >> apply control theory to our problem. And perhaps, the message of this >> footnote is nothing else then "with sufficient effort, it can be shown that >> at least VJCC and the well known control theory do not contradict." > That passage is justifying using window-based rate control. Only very short, my fridge is empty ;-) I just talked to Michael Welzl (bcc:) about this passage some months ago. And I think, we shared the view that the remark on Lyapunov functions (I cannot even spell this....) are an argument for the stability of the control system. VJCC is a pure window based control. Only window based. Nothing said about rates. And I'm extremely careful to make a clear difference between both. -- ------------------------------------------------------------------ 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 lachlan.andrew at gmail.com Sat Feb 4 18:40:56 2012 From: lachlan.andrew at gmail.com (Lachlan Andrew) Date: Sun, 5 Feb 2012 13:40:56 +1100 Subject: [e2e] [Iccrg] Re: Reasons not to deply TCP BIC/Cubic In-Reply-To: <4F2D3417.5080104@web.de> References: <1328134813.10478.YahooMailClassic@web130102.mail.mud.yahoo.com> <4F2A78CC.40200@web.de> <4F2BCF3A.3050505@web.de> <4F2D3417.5080104@web.de> Message-ID: On 5 February 2012 00:35, Detlef Bosau wrote: > On 02/04/2012 03:58 AM, Lachlan Andrew wrote: >> >> That passage is justifying using window-based rate control. > > I just talked to Michael Welzl (bcc:) about this passage some months ago. > And I think, we shared the view that the remark on Lyapunov functions (I > cannot even spell this....) are an argument for the stability of the control > system. The line "the integral of the packet density around the sender? receiver?sender loop is a constant" says that the window is constant. > VJCC is a pure window based control. Only window based. Nothing said about > rates. And I'm extremely careful to make a clear difference between both. "packet density" = rate. Cheers, Lachlan -- Lachlan Andrew? Centre for Advanced Internet Architectures (CAIA) Swinburne University of Technology, Melbourne, Australia Ph +61 3 9214 4837 From detlef.bosau at web.de Sun Feb 5 05:33:54 2012 From: detlef.bosau at web.de (Detlef Bosau) Date: Sun, 05 Feb 2012 14:33:54 +0100 Subject: [e2e] [Iccrg] Re: Reasons not to deply TCP BIC/Cubic In-Reply-To: References: <1328134813.10478.YahooMailClassic@web130102.mail.mud.yahoo.com> <4F2A78CC.40200@web.de> <4F2BCF3A.3050505@web.de> <4F2D3417.5080104@web.de> Message-ID: <4F2E8542.4070505@web.de> On 02/05/2012 03:40 AM, Lachlan Andrew wrote: > > The line "the integral of the packet density around the sender? > receiver?sender loop is a constant" says that the window is constant. > Isn't this a rationale for stability here? >> VJCC is a pure window based control. Only window based. Nothing said about >> rates. And I'm extremely careful to make a clear difference between both. > "packet density" = rate. > The "packet density" or "rate" does not even appear explicitly in TCP/Reno. And actually, it does not make sense here. Anaylitcal work, as far as I have seen them, assumes continuous functions here where continuous functions even do not exist. The whole thing is done with the only purpose to apply the apparatus of differential equations on discrete processes. This is not impossible per se, however it is a difficult task. And I'm not sure, whether we learn that much new by doing so. > Cheers, > Lachlan > -- ------------------------------------------------------------------ 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 Sun Feb 5 07:15:01 2012 From: detlef.bosau at web.de (Detlef Bosau) Date: Sun, 05 Feb 2012 16:15:01 +0100 Subject: [e2e] [Iccrg] Re: Reasons not to deply TCP BIC/Cubic In-Reply-To: References: <1328134813.10478.YahooMailClassic@web130102.mail.mud.yahoo.com> <4F2A78CC.40200@web.de> <4F2BCF3A.3050505@web.de> <4F2D3417.5080104@web.de> Message-ID: <4F2E9CF5.8070606@web.de> On 02/05/2012 03:40 AM, Lachlan Andrew wrote: > > The line "the integral of the packet density around the sender? > receiver?sender loop is a constant" says that the window is constant. > Isn't this a rationale for stability here? >> VJCC is a pure window based control. Only window based. Nothing said about >> rates. And I'm extremely careful to make a clear difference between both. > "packet density" = rate. > The "packet density" or "rate" does not even appear explicitly in TCP/Reno. And actually, it does not make sense here. Anaylitcal work, as far as I have seen them, assumes continuous functions here where continuous functions even do not exist. The whole thing is done with the only purpose to apply the apparatus of differential equations on discrete processes. This is not impossible per se, however it is a difficult task. And I'm not sure, whether we learn that much new by doing so. > Cheers, > Lachlan > -- ------------------------------------------------------------------ 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 Mon Feb 6 06:51:12 2012 From: detlef.bosau at web.de (Detlef Bosau) Date: Mon, 06 Feb 2012 15:51:12 +0100 Subject: [e2e] Google seeks to tweak TCP In-Reply-To: <1328294204.81082.YahooMailClassic@web130105.mail.mud.yahoo.com> References: <1328294204.81082.YahooMailClassic@web130105.mail.mud.yahoo.com> Message-ID: <4F2FE8E0.9030003@web.de> On 02/03/2012 07:36 PM, Daniel Havey wrote: > > Hmmm, not really. If a service provider drops non-TCP packets then my TCP alternative will never have a chance to get off the ground. I could build it, but, what is the point if nobody will use it? > > I believe that any new solution must not only play nice with TCP, but be indistinguishable from TCP. Otherwise the packets may be dropped. > However, this is implementation and development and not primarily research. >> And whenever people are exited by simple recipes which save >> the world, we always should keep in mind RFC 1925. >>> (6) It is easier to move a problem around (for example, by moving the problem to a different part of the overall network architecture) than it is to solve it. > This is getting interesting. So the goal of Cubic (from the paper) is to provide more RTT fairness. It does this. Oh, I should better not look at the Cubic paper. Why shall we pursue "RTT fairness"? Particularly, when wireless networks are included, this is no longer RTT fairness but fate sharing instead. > I don't think that queuing delay is the only cause of large RTTs. Sometimes a link is just slow and sketchy. Happens all the time. maybe 802.11n has negotiated a slow rate or there are lots of retransmissions. There will probably be a lot of packets in the queue because of this, but, the link is slow and that is why the RTTs are large. I'm thinking of projects like "Wireless Africa" where links are slow and lossy. According to my experience, it is difficult to sell lossy links in papers. However, being lossy and being slow are often just two sides of the same mountain. > Such links have difficulty even reaching their tiny capacity with Reno. They do much better with Cubic. What's the very reason for this behaviour? Is it because Reno cannot deal well with losses? -- ------------------------------------------------------------------ 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 craig at aland.bbn.com Mon Feb 6 09:26:36 2012 From: craig at aland.bbn.com (Craig Partridge) Date: Mon, 06 Feb 2012 12:26:36 -0500 Subject: [e2e] Google seeks to tweak TCP Message-ID: <20120206172636.F048A28E1E4@aland.bbn.com> > On 3 February 2012 04:06, Detlef Bosau wrote: > > > Everyone is free to do research in this field and to discuss his results > > within the community - and when changes make sense, everyone is free to > > contact the IETF and to convince them by compelling work. > > When the IETF started, the founders were told that everything should > go through the ISO. The IETF community found the ISO too slow, and > just experimented for themselves. The same applied to the ITU-T and > the ATM forum. We're deviating from E2E to history but I think this point matters, so a brief comment from one of the IETF founders. We were never told to go through ISO. But the broad issue of speed is entirely right. IETF was a split off from INARCH (the Internet Architecture Task Force) and was motivated by a bunch of folks, largely ISPs and campus network operators, who desperately needed a bunch of nitty-gritty operational problems solved and documented -- problems that seemed to be falling through the cracks between the various Internet Task Forces of the time (there were several). As a result, the mode of operation was "find a working solution, document it in an RFC, and move to the next problem." Note that most TCP work was NOT done in IETF but was done in the End-to-End Task Force (which created this mailing list). > Is it possible that the "TCP innovators" are now just finding the IETF > too slow, and doing exactly as the founders of the IETF did? Some > argue that the Internet is more vital infrastructure now, and so this > isn't a fair comparison. However the telephone infrastructure was > already vital when the ATM forum took matters into their own hands. > > To remain relevant for congestion control, the IETF needs to balance > responsibility with responsiveness. Always a killer problem -- indeed, within a few years of the IETF getting going, Steve Crocker (an IESG member) noted we were beginning to develop the processes that tend to stymie standards organizations such as the ability to appeal decisions and copious mechansisms to ensure fairness over effectiveness. These, incidentally, were in response to the arrival of corporate representatives at IETF -- in the early years, folks showed up to solve problems and didn't worry if the solution was optimal vis-a-vis their corporate market strategy. Thanks! Craig From dhavey at yahoo.com Mon Feb 6 11:29:41 2012 From: dhavey at yahoo.com (Daniel Havey) Date: Mon, 6 Feb 2012 11:29:41 -0800 (PST) Subject: [e2e] Google seeks to tweak TCP In-Reply-To: <4F2FE8E0.9030003@web.de> Message-ID: <1328556581.26405.YahooMailClassic@web130103.mail.mud.yahoo.com> > > Hmmm, not really.? If a service provider drops > non-TCP packets then my TCP alternative will never have a > chance to get off the ground.? I could build it, but, > what is the point if nobody will use it? > > > > I believe that any new solution must not only play nice > with TCP, but be indistinguishable from TCP.? Otherwise > the packets may be dropped. > > > > However, this is implementation and development and not > primarily research. > IMHO, a complete research work would includes the possibility of implementation. Even though the process may be long and arduous. > >> And whenever people are exited by simple recipes > which save > >> the world, we always should keep in mind RFC 1925. > >>>? ? ? (6)? It is easier to > move a problem around (for example, by moving the problem to > a different part of the overall network architecture) than > it is to solve it. > > This is getting interesting.? So the goal of Cubic > (from the paper) is to provide more RTT fairness.? It > does this. > > Oh, I should better not look at the Cubic paper. Why shall > we pursue "RTT fairness"? Particularly, when wireless > networks are included, this is no longer RTT fairness but > fate sharing instead. > > > I don't think that queuing delay is the only cause of > large RTTs.? Sometimes a link is just slow and > sketchy.? Happens all the time.? maybe 802.11n has > negotiated a slow rate or there are lots of > retransmissions.? There will probably be a lot of > packets in the queue because of this, but, the link is slow > and that is why the RTTs are large.? I'm thinking of > projects like "Wireless Africa" where links are slow and > lossy. > > According to my experience, it is difficult to sell lossy > links in papers. However, being lossy and being slow are > often just two sides of the same mountain. > True, because the MAC will twist itself into a pretzel before allowing a packet to drop. At the transport layer we will experience these losses as increased delay. We shouldn't ignore them because we can feel their effects, even if we don't see the actual loss. As conditions become poor, you will see the actual loss combined with the delay from trying to prevent that loss. IMHO, these packets are probably not worth so much trouble. Reliability is expensive, and 100% reliability is even more expensive. But, this is the viewpoint of a person who just wants to stream video. I don't really need "all" of the packets, just an adequate number of them and a few losses are really not a big deal for my applications. It sounds like I need a non-TCP solution, but, see above. I just take it as a starting point for my research that transport must be TCP. Without this as a starting point then the work will not be "implementable". > > > Such links have difficulty even reaching their tiny > capacity with Reno.? They do much better with Cubic. > > What's the very reason for this behaviour? Is it because > Reno cannot deal well with losses? > Haha! Yeah, good point. I don't actually know. My experiments just used Cubic as a baseline, because it is the default. I suspect that Reno would have more difficulty with false congestion signals then Cubic, provided the false signals occurred on a time scale larger than the amount of time required for Cubic to return to it's exponential probing phase. Otherwise both protocols would be toast. > -- > ------------------------------------------------------------------ > 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 dhavey at yahoo.com Mon Feb 6 11:58:03 2012 From: dhavey at yahoo.com (Daniel Havey) Date: Mon, 6 Feb 2012 11:58:03 -0800 (PST) Subject: [e2e] Google seeks to tweak TCP In-Reply-To: <20120206172636.F048A28E1E4@aland.bbn.com> Message-ID: <1328558283.58874.YahooMailClassic@web130104.mail.mud.yahoo.com> > We're deviating from E2E to history but I think this point > matters, so > a brief comment from one of the IETF founders.? We were > never told to go > through ISO.? But the broad issue of speed is entirely > right.? IETF was > a split off from INARCH (the Internet Architecture Task > Force) and was > motivated by a bunch of folks, largely ISPs and campus > network operators, > who desperately needed a bunch of nitty-gritty operational > problems solved > and documented -- problems that seemed to be falling through > the cracks > between the various Internet Task Forces of the time (there > were several). > As a result, the mode of operation was "find a working > solution, document it in an RFC, and move to the next > problem." > > Note that most TCP work was NOT done in IETF but was done in > the End-to-End > Task Force (which created this mailing list). > This is pretty interesting, but, I had better get back to work ;^) BTW...Is this history recorded anywhere besides in your memories? > Always a killer problem -- indeed, within a few years of the > IETF getting > going, Steve Crocker (an IESG member) noted we were > beginning to develop the > processes that tend to stymie standards organizations such > as the ability > to appeal decisions and copious mechansisms to ensure > fairness over > effectiveness.? These, incidentally, were in response > to the arrival of > corporate representatives at IETF -- in the early years, > folks showed up > to solve problems and didn't worry if the solution was > optimal vis-a-vis > their corporate market strategy. > > Thanks! > > Craig > Hmmmm, so let me see if I understand what happened. The End-to-End Task Force was created to speed up the process, then over time in response to the influx of corporate interests developed methods that slow it back down? (Sorry for the oversimplification. I hate to gloss over decades of history in one or two sentences, but, I really do have to finish preparing homework for my students) I think that the point is important too. The corporate interests are not going to go away and they are not going to suddenly become altruistic (except as it agrees with the bottom line). They are doing what they are supposed to do and that is that. This begs for a solution that is both fair enough to weigh the needs of all the different players, but, still fast enough to keep new minds from growing frustrated and deciding to do something else less political ;^) A KILLER problem indeed ;^) This is really interesting. How would I find out more about the process and history? Do I just have to sit on this list and wait for the story to work it's way to light? ...Daniel From detlef.bosau at web.de Mon Feb 6 12:30:57 2012 From: detlef.bosau at web.de (Detlef Bosau) Date: Mon, 06 Feb 2012 21:30:57 +0100 Subject: [e2e] Google seeks to tweak TCP In-Reply-To: <1328556581.26405.YahooMailClassic@web130103.mail.mud.yahoo.com> References: <1328556581.26405.YahooMailClassic@web130103.mail.mud.yahoo.com> Message-ID: <4F303881.9080607@web.de> On 02/06/2012 08:29 PM, Daniel Havey wrote: >> However, this is implementation and development and not >> primarily research. >> > IMHO, a complete research work would includes the possibility of implementation. Even though the process may be long and arduous. It may be a cultural difference here. But in Germany, we have a distinction between research and development. Of course, development is necessary. But the main focus of research should be to identify and to solve the structural problems. Development is not only arduous, it is - part of arduous ;-) - expensive. And not anyone, who does fundamental research has the money to develop a product for the market. >> According to my experience, it is difficult to sell lossy >> links in papers. However, being lossy and being slow are >> often just two sides of the same mountain. >> >> > > True, because the MAC will twist itself into a pretzel before allowing a packet to drop. Hang on here. I considered this topic for several years now. And I started from a "pure end to end view" and thought, corruption recovery should be done only at the end point. I thought so even in a paper of mine. (I did not publish very much so far and the more I think about this work, I put it into question.) One point is, that even recovery from corruption is moving around a problem. It is particularly moving load along the network path. When I, e.g., request a page from a WWW server from New York, myself sitting in Stuttgart, and use some wireless connection. Why, the hell, should it bother the whole world and Tier 1 Internet links etc., that there is a corruption on a wireless link here in Stuttgart? So, we need convincing reasons to drop a packet. Without giving the whole rationale here, we should choose reasonable line codings and channel codings here and then do one, perhaps two transmission attempts. In most cases, this we either be successful - or even 100 attempts wouldn't help. So, in a situation like that, we should drop the packet. However, if we do so, the change in the service time would be due to the coding and not due to the retransmission. And particularly the choice of appropriate codes - or even making the decision that a wireless connection is suspended for a moment, should be a local one because the information to make a decision is readily available at the local link - and not at the communication end points. > At the transport layer we will experience these losses as increased delay. Absolutely. > We shouldn't ignore them because we can feel their effects, even if we don't see the actual loss. Absolutely. > As conditions become poor, you will see the actual loss combined with the delay from trying to prevent that loss. > However, you may hardly see the actual loss. Although this is quite implementation dependent. In GSM, you may see actual loss because AFAIK GSM has no means of channel assessment. In HSDPA, you will hardly see a lost packet because there _is_ a means of channel assessment and a poor channel may be suspended for a certain time, or (more sophisticated) a better channel will be preferred. > IMHO, these packets are probably not worth so much trouble. Reliability is expensive, and 100% reliability is even more expensive. 100 % reliability is not realistic especially in limited time. > But, this is the viewpoint of a person who just wants to stream video. Which is not reliable. And I still suffer from a failed project (10 years ago) where I was held responsible for the poor results and the very reason was, that the project partners wanted to do streaming with packet switching and simply did not realize (that time: me too, I have to admit this) that line switching and packet switching in mobile networks are simply two completely different stories and no way comparable. Therefore, I make a very clear distinction between these. And I'm afraid, I'm one of the very few ones to do so. And rather a pig will fly (and, please, not overhead!) than I will ever mix up these two worlds again. It took me years to understand this point. > I don't really need "all" of the packets, just an adequate number of them and a few losses are really not a big deal for my applications. And even that is highly technology dependent. My project was about WWAN that time. And I frequently heard that saying that e.g. voice is loss resilient. Excuse me, for WWAN, this is not that simple. A tar ball may survive loss, a .tgz file not. When voice is conveyed via WWAN, it is compressed as much as possible, so it is nearly inevitable for loss to decrease the perceived quality of speech to the listener. This is certainly no concern when sufficient throughput is available and you can spare the extreme compression. In data transfer, and TCP is concerned with data transfer, the situation is completely different. > It sounds like I need a non-TCP solution, but, see above. For streaming? By all means! For streaming, TCP is simply the wrong protocol. However, in mobile networks, for TCP you will need a packet switching API, for streaming you will need a line switching API. And this could not be overemphasized. Any other approach is likely to fail. > I just take it as a starting point for my research that transport must be TCP. Without this as a starting point then the work will not be "implementable". > I beg you pardon? Did you ever hear of (my apologies to the list, as this is a "TCP list" according to Craigs historical remarks ;-)) ) UDP? Although, even UDP is a packet switching protocol. And to my understanding, packet switching is anything but well suited for doing streaming. >>> Such links have difficulty even reaching their tiny >> capacity with Reno. They do much better with Cubic. >> >> What's the very reason for this behaviour? Is it because >> Reno cannot deal well with losses? >> > Haha! Yeah, good point. I don't actually know. My experiments just used Cubic as a baseline, because it is the default. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ a convincing scientific rationale :-) O.k., for a baseline you can take whatever you prefer. It's a baseline, nothing else. -- ------------------------------------------------------------------ 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 craig at aland.bbn.com Mon Feb 6 12:57:06 2012 From: craig at aland.bbn.com (Craig Partridge) Date: Mon, 06 Feb 2012 15:57:06 -0500 Subject: [e2e] Google seeks to tweak TCP Message-ID: <20120206205706.9858028E1D9@aland.bbn.com> > > We're deviating from E2E to history but I think this point > > matters, so > > a brief comment from one of the IETF founders.  We were > > never told to go > > through ISO.  But the broad issue of speed is entirely > > right.  IETF was > > a split off from INARCH (the Internet Architecture Task > > Force) and was > > motivated by a bunch of folks, largely ISPs and campus > > network operators, > > who desperately needed a bunch of nitty-gritty operational > > problems solved > > and documented -- problems that seemed to be falling through > > the cracks > > between the various Internet Task Forces of the time (there > > were several). > > As a result, the mode of operation was "find a working > > solution, document it in an RFC, and move to the next > > problem." > > > > Note that most TCP work was NOT done in IETF but was done in > > the End-to-End > > Task Force (which created this mailing list). > > > This is pretty interesting, but, I had better get back to work ;^) > BTW...Is this history recorded anywhere besides in your memories? Not that I'm aware of. On my (long) queue of things I'd like to do is write up a history of what I call the Internet's adolescence -- from about 1987 to 1997 -- which would cover the evolution of the IETF, etc. I do have many of the relevant emails still stashed in my folders and you can extract some of this from the early IETF minutes on ietf.org > > Always a killer problem -- indeed, within a few years of the > > IETF getting > > going, Steve Crocker (an IESG member) noted we were > > beginning to develop the > > processes that tend to stymie standards organizations such > > as the ability > > to appeal decisions and copious mechansisms to ensure > > fairness over > > effectiveness.  These, incidentally, were in response > > to the arrival of > > corporate representatives at IETF -- in the early years, > > folks showed up > > to solve problems and didn't worry if the solution was > > optimal vis-a-vis > > their corporate market strategy. > > > > Thanks! > > > > Craig > > > Hmmmm, so let me see if I understand what happened. The End-to-End Task Forc > e was created to speed up the process, then over time in response to the infl > ux of corporate interests developed methods that slow it back down? The IETF, not End-to-End TF. (End-to-End was created in 1983 to deal with transport protocol issues for the Internet -- in the mid-1990s this was made a mostly IETF Problem and the End-to-END TF was made the End-to-End Research Group). But the gist is right -- I'd restate slightly: The IETF was created to speed up the resolution of Internet operations and standards issues. Over time, the IETF found that its time to react was slowed by the need, often in response to people representing corporate interests, to create additional processes before a standard could be approved. > (Sorry for the oversimplification. I hate to gloss over decades of history i > n one or two sentences, but, I really do have to finish preparing homework fo > r my students) > > I think that the point is important too. The corporate interests are not goi > ng to go away and they are not going to suddenly become altruistic (except as > it agrees with the bottom line). They are doing what they are supposed to > do and that is that. > > This begs for a solution that is both fair enough to weigh the needs of all t > he different players, but, still fast enough to keep new minds from growing f > rustrated and deciding to do something else less political ;^) > > A KILLER problem indeed ;^) > > This is really interesting. How would I find out more about the process and > history? Do I just have to sit on this list and wait for the story to work i > t's way to light? You can sort of work it out by reading thousands of pages of IETF minutes and relevant RFCs. For instance, see how the IETF had to develop rules for incorporating intellectual property in IETF standards. Thanks! Craig From detlef.bosau at web.de Tue Feb 7 02:55:52 2012 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 07 Feb 2012 11:55:52 +0100 Subject: [e2e] Google seeks to tweak TCP In-Reply-To: References: <1328556581.26405.YahooMailClassic@web130103.mail.mud.yahoo.com> <4F303881.9080607@web.de> Message-ID: <4F310338.4000707@web.de> On 02/06/2012 10:47 PM, Saverio Mascolo wrote: > > > On Mon, Feb 6, 2012 at 9:30 PM, Detlef Bosau > wrote: > > > > > For streaming? By all means! For streaming, TCP is simply the > wrong protocol. > > > I would not say that since youtube is using TCP ;) > > saverio > And Youtube does streaming? ;-) -- ------------------------------------------------------------------ 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 dhavey at yahoo.com Tue Feb 7 03:16:52 2012 From: dhavey at yahoo.com (Daniel Havey) Date: Tue, 7 Feb 2012 03:16:52 -0800 (PST) Subject: [e2e] Google seeks to tweak TCP In-Reply-To: <4F310338.4000707@web.de> Message-ID: <1328613412.55949.YahooMailClassic@web130101.mail.mud.yahoo.com> ACK ;^) It is the wrong protocol, and we are using it. ...Daniel ? ???For streaming? By all means! > For streaming, TCP is simply the > >? ???wrong protocol. > > > > > > I would not say that since youtube is using TCP ;) > > > > saverio > > > > And Youtube does streaming? ;-) > > -- > ------------------------------------------------------------------ > 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 > ------------------------------------------------------------------ > > >