From dhavey at yahoo.com Sun Dec 4 13:22:19 2011 From: dhavey at yahoo.com (Daniel Havey) Date: Sun, 4 Dec 2011 13:22:19 -0800 (PST) Subject: [e2e] TCP Cubic Message-ID: <1323033739.52288.YahooMailClassic@web130115.mail.mud.yahoo.com> This is interesting.? Could you please elaborate on why you think your experiments show these results? 1. a larger RTT? Why?? Because of queuing?? It doesn't seem like queuing delay would add very much to the RTT.? A full 1000 segment queue will be drained by a 1 Gbps router in (1500 bytes * 8 bits)?1 Gbps * 1000 packets =? 0.012 seconds. What kind of RTTs are we talking about here?? If the average RTT is 200ms then 12ms is not a big deal.? It the average RTT is 10ms then it is a big deal. I think this result may be caused by something other than queuing delay. 2. A larger number of retransmissions? Why did this happen?? How many more retransmissions?? A lot more?? Like an order of magnitude or just a little?? I think I have a theory as to how this could happen. All TCPs act in the same general manner.? Bring the bottleneck queue to 100% utilization, lose a few packets, backoff.? Repeat ad infinitum. TCP Cubic in particular differs from NewReno because it has an exponential increase until the previous CWND, then a linear (TCP friendly) phase, and finally a second exponential phase.? I think you called it "probing".? Good term ;^) So the only possible source of additional retransmissions is after we have reached 100% queue utilization and we are losing a "few" packets before the congestion event causes the sender to backoff the CWND. It seems unlikely that this would occur during the first exponential phase of the Cubic algorithm because a congestion event just occurred and the queue at the bottleneck router has just been drained.? If it occurs during the linear increase phase then this is the same as NewReno.? If it occurs during the last exponential phase of the algorithm then your Cubic TCP may be out of tune. The congestion event is supposed to occur within the linear phase of the Cubic algorithm.? If the congestion event occurs during the probing phase of Cubic this indicates the CWND was a much lower value than the available space in the bottleneck router queue. This is very scenario dependent.? I have a graph of the queuing behavior of a Cubic TCP operating over a 10 Mbps link with an RTT of ~200 ms. In my experiments the Cubic TCP does congest the queue during the probing phase, however, I still get plenty of goodput (~8-10 Mbps). This is because I have a large RTT (TCP Cubic is probably not tuned for 200 ms).? The high goodput is probably because I have a low speed link (10 Mbps). ...Daniel Dear all, > > we know that TCP BIC/Cubic is default in Linux and as a consequence > 50% of servers employs TCP BIC/Cubic. > > Our measurements say that there could be reasons not to deploy TCP > BIC/Cubic. These reasons? are in our opinion rooted in its more > aggressive probing phase. In particular, in common network conditions, > TCP BIC/CUBIC exhibits: 1. a larger RTT average wrt to TCP NewReno or > TCP Westwood+; 2. a larger number of retransmission wrt to TCP NewReno > or TCP Westwood+; 3 larger throughput but same goodput wrt to TCP > NewReno or Westwood+. From ycai at ecs.umass.edu Sat Dec 10 23:22:31 2011 From: ycai at ecs.umass.edu (Yan Cai) Date: Sat, 10 Dec 2011 23:22:31 -0800 Subject: [e2e] TCP Cubic In-Reply-To: <1323033739.52288.YahooMailClassic@web130115.mail.mud.yahoo.com> References: <1323033739.52288.YahooMailClassic@web130115.mail.mud.yahoo.com> Message-ID: <4EE45A37.5020409@ecs.umass.edu> A few thoughts on comparison between TCP Cubic and Newreno. 1. Newreno like TCP is additive increase and multiplicative decrease (AIMD) while Cubic is one of MIMD TCP's. 2. To me, the most significant reason for adopting an MIMD TCP is due to the incapability of AIMD TCP's grabbing bandwidth in a large bandwidth-delay link: AIMD TCP takes very long time to make the pipe "congested." 3. Goodput/throughput vs link utilization. Goodput/throughput can be used to characterize both a TCP session and a bottleneck link while link utilization is mainly for the bottleneck link. However, both of them are heavily impacted by the buffer size at the bottleneck link. In the case of TCP newreno, the rule of thumb, that is, buffer size = RTT * bandwidth, has been proven to provide a 100% link utilization for the bottleneck link while achieving the smallest average RTT for the TCP session. A bigger buffer leads to larger RTTs (overbuffer) while a smaller one makes the link utilization lower than 100% (underbuffer). It seems that the (MIMD) TCP performance is not only determined by the congestion avoidance algorithm, but also affected by the network topology and parameters. A detailed description on the experiment setup will help understand the experimental results better. Many thanks, Yan On 12/4/2011 1:22 PM, Daniel Havey wrote: > This is interesting. Could you please elaborate on why you think your experiments show these results? > > 1. a larger RTT? > Why? Because of queuing? It doesn't seem like queuing delay would add very much to the RTT. A full 1000 segment queue will be drained by a 1 Gbps router in (1500 bytes * 8 bits)?1 Gbps * 1000 packets = 0.012 seconds. > > What kind of RTTs are we talking about here? If the average RTT is 200ms then 12ms is not a big deal. It the average RTT is 10ms then it is a big deal. > > I think this result may be caused by something other than queuing delay. > > > 2. A larger number of retransmissions? > Why did this happen? How many more retransmissions? A lot more? Like an order of magnitude or just a little? I think I have a theory as to how this could happen. > > All TCPs act in the same general manner. Bring the bottleneck queue to 100% utilization, lose a few packets, backoff. Repeat ad infinitum. > > TCP Cubic in particular differs from NewReno because it has an exponential increase until the previous CWND, then a linear (TCP friendly) phase, and finally a second exponential phase. I think you called it "probing". Good term ;^) > > So the only possible source of additional retransmissions is after we have reached 100% queue utilization and we are losing a "few" packets before the congestion event causes the sender to backoff the CWND. > > It seems unlikely that this would occur during the first exponential phase of the Cubic algorithm because a congestion event just occurred and the queue at the bottleneck router has just been drained. If it occurs during the linear increase phase then this is the same as NewReno. If it occurs during the last exponential phase of the algorithm then your Cubic TCP may be out of tune. > > The congestion event is supposed to occur within the linear phase of the Cubic algorithm. If the congestion event occurs during the probing phase of Cubic this indicates the CWND was a much lower value than the available space in the bottleneck router queue. > > This is very scenario dependent. I have a graph of the queuing behavior of a Cubic TCP operating over a 10 Mbps link with an RTT of ~200 ms. > > In my experiments the Cubic TCP does congest the queue during the probing phase, however, I still get plenty of goodput (~8-10 Mbps). > > This is because I have a large RTT (TCP Cubic is probably not tuned for 200 ms). The high goodput is probably because I have a low speed link (10 Mbps). > > ...Daniel > > > > Dear all, >> we know that TCP BIC/Cubic is default in Linux and as a consequence >> 50% of servers employs TCP BIC/Cubic. >> >> Our measurements say that there could be reasons not to deploy TCP >> BIC/Cubic. These reasons are in our opinion rooted in its more >> aggressive probing phase. In particular, in common network conditions, >> TCP BIC/CUBIC exhibits: 1. a larger RTT average wrt to TCP NewReno or >> TCP Westwood+; 2. a larger number of retransmission wrt to TCP NewReno >> or TCP Westwood+; 3 larger throughput but same goodput wrt to TCP >> NewReno or Westwood+. > > > > From lachlan.andrew at gmail.com Sun Dec 11 15:05:00 2011 From: lachlan.andrew at gmail.com (Lachlan Andrew) Date: Mon, 12 Dec 2011 10:05:00 +1100 Subject: [e2e] TCP Cubic In-Reply-To: <4EE45A37.5020409@ecs.umass.edu> References: <1323033739.52288.YahooMailClassic@web130115.mail.mud.yahoo.com> <4EE45A37.5020409@ecs.umass.edu> Message-ID: Greetings, On 11 December 2011 18:22, Yan Cai wrote: > A few thoughts on comparison between TCP Cubic and Newreno. > > 1. Newreno like TCP is additive increase and multiplicative decrease (AIMD) > while Cubic is one of MIMD TCP's. No, Cubic is not MIMD. (STCP was the only well-known MIMD proposal, to my knowledge.) > > 2. To me, the most significant reason for adopting an MIMD TCP is due to the > incapability of AIMD TCP's grabbing bandwidth in a large bandwidth-delay > link: AIMD TCP takes very long time to make the pipe "congested." That depends on what is added. It is easy to use AIMD and add an amount per RTT that is proportional to the RTT. (That is still AI because it is independent of the current window.) Using bandwidth estimation techniques, it is also possible to use AI that adds an amount roughly proportional to the capacity of the lowest-capacity link on the path. On a high-BDP path, this typically gives convergence time roughly independent of the BDP. Of course, adding large amounts per RTT causes other big problems; my point is just that "AIMD" is much more flexible than "Reno", and needn't suffer Reno's limitations. > 3. Goodput/throughput vs link utilization. > Goodput/throughput can be used to characterize both a TCP session and a > bottleneck link while link utilization is mainly for the bottleneck link. > However, both of them are heavily impacted by the buffer size at the > bottleneck link. In the case of TCP newreno, the rule of thumb, that is, > buffer size = RTT * bandwidth, has been proven to provide a 100% link > utilization for the bottleneck link while achieving the smallest average RTT > for the TCP session. A bigger buffer leads to larger RTTs (overbuffer) while > a smaller one makes the link utilization lower than 100% (underbuffer). Yes, Daniel's comment that buffering isn't a big contributor to the increase in delay ignores this rule of thumb. It is well known that CTCP causes high delay compared to Reno, because it keeps the buffers almost full. This is devastating on typical DSL links which are massively over-buffered. Note that the ubiquitous "buffer=BDP" rule of thumb has been widely challenged. Look for Nick McKeown's and Damon Wischik's contributions. Srikant also had a good Infocom paper studying the variation with buffer size of the transmission completion time (a much more useful measure than link utilization). > It seems that the (MIMD) TCP performance is not only determined by the > congestion avoidance algorithm, but also affected by the network topology > and parameters. A detailed description on the experiment setup will help > understand the experimental results better. Not really. The results are pretty standard. The main driver for "high speed" TCP variants was to provide higher throughput in the presence of occasional packet loss, and so it is natural that they almost all have higher self-induced loss than Reno does. (That applies to HS-TCP and H-TCP as well. It doesn't apply to delay-based algorithms such as FAST which have no intrinsic self-induced loss, but have their own set of problems.) In essence, each loss-based TCP induces a fixed amount of loss for a given transmission rate. In the absence of external loss (such as caused by bursts of cross traffic), all will fill a pipe (explaining Saverio's observation 3), and so those designed to be more resilient to external loss will have to induce a higher level of loss to keep themselves down to this rate (observation 2). Cubic responds to loss by reducing the window but racing back as quickly as possible to the window size that caused the loss, and so it keeps windows perpetually almost full (observation 1). This design decision was the cause of much heated debate about Cubic vs HTCP (which responds to loss with a much slower initial window growth, and hence actually has a smaller mean delay than Reno). There was a paper on this recently in LCN by Lawrence Stewart and others. For anyone who is interested, this may be better discussed on the ICCRG mailing list. Cheers, Lachlan -- Lachlan Andrew? Centre for Advanced Internet Architectures (CAIA) Swinburne University of Technology, Melbourne, Australia Ph +61 3 9214 4837 From alexsm at gmail.com Mon Dec 12 05:29:35 2011 From: alexsm at gmail.com (Alex Moura) Date: Mon, 12 Dec 2011 11:29:35 -0200 Subject: [e2e] BufferBloat: What's Wrong with the Internet? References: <20111212081120.B1B8812036A@pegasus.na-df.rnp.br> Message-ID: BufferBloat: What's Wrong with the Internet? http://queue.acm.org/detail.cfm?id=2076798 From lachlan.andrew at gmail.com Mon Dec 12 16:44:51 2011 From: lachlan.andrew at gmail.com (Lachlan Andrew) Date: Tue, 13 Dec 2011 11:44:51 +1100 Subject: [e2e] TCP Cubic In-Reply-To: References: <1323033739.52288.YahooMailClassic@web130115.mail.mud.yahoo.com> <4EE45A37.5020409@ecs.umass.edu> Message-ID: On 12 December 2011 10:05, Lachlan Andrew wrote: > It is well known that > CTCP causes high delay compared to Reno, because it keeps the buffers > almost full. Oops. I should have said "Cubic TCP" -- not to be confused with Microsoft's "Compound TCP", which is much better behaved. 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 Tue Dec 13 05:49:08 2011 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 13 Dec 2011 14:49:08 +0100 Subject: [e2e] calculated SNR traces? Message-ID: <4EE757D4.1090200@web.de> Although this is a bit off topic here: Is there anybody around who can help me with generated SNR traces for Rayleigh channels? I would particularly appreciate getting in touch with an EE or CE guy, because this is not mainly a CS topic. Thanks 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 lachlan.andrew at gmail.com Tue Dec 13 21:08:58 2011 From: lachlan.andrew at gmail.com (Lachlan Andrew) Date: Wed, 14 Dec 2011 16:08:58 +1100 Subject: [e2e] calculated SNR traces? In-Reply-To: <4EE757D4.1090200@web.de> References: <4EE757D4.1090200@web.de> Message-ID: Greetings Detlef, What sort of help would you like? There is a Matlab/octave script to generate Rayleigh fading at: Is that what you're after? Cheers, Lachlan On 14 December 2011 00:49, Detlef Bosau wrote: > Although this is a bit off topic here: Is there anybody around who can help > me with generated SNR traces for Rayleigh channels? > > I would particularly appreciate getting in touch with an EE or CE guy, > because this is not mainly a CS topic. > > Thanks > > 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 > ------------------------------------------------------------------ > > -- 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 Wed Dec 14 02:00:52 2011 From: detlef.bosau at web.de (Detlef Bosau) Date: Wed, 14 Dec 2011 11:00:52 +0100 Subject: [e2e] calculated SNR traces? In-Reply-To: References: <4EE757D4.1090200@web.de> Message-ID: <4EE873D4.3080708@web.de> On 12/14/2011 06:08 AM, Lachlan Andrew wrote: > Greetings Detlef, > > What sort of help would you like? > > There is a Matlab/octave script to generate Rayleigh fading at: > > > Is that what you're after? Basically yes. Because I don't have a Matlab-license, it is nessecary for the script to run in octave. (Although it is often no big deal to adapt the script, I don't want to do this myself, because I cannot check the plausibility of the results. I would be more comfortable to do this in cooperation with some EE or CE guy.) -- ------------------------------------------------------------------ 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 Tue Dec 20 09:58:51 2011 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 20 Dec 2011 18:58:51 +0100 Subject: [e2e] calculated SNR traces? In-Reply-To: <4EE873D4.3080708@web.de> References: <4EE757D4.1090200@web.de> <4EE873D4.3080708@web.de> Message-ID: <4EF0CCDB.4050803@web.de> Is there no one to get in touch with? I'm not quite sure, how anyone can deal with TCP/IP in wireless networks, when there is no one to know anything reliable about wireless channels. Perhaps, one could give me a hint, where I could find people to talk to about these things? Thanks. 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 hagen at jauu.net Tue Dec 20 11:59:08 2011 From: hagen at jauu.net (Hagen Paul Pfeifer) Date: Tue, 20 Dec 2011 20:59:08 +0100 Subject: [e2e] calculated SNR traces? In-Reply-To: <4EF0CCDB.4050803@web.de> References: <4EE757D4.1090200@web.de> <4EE873D4.3080708@web.de> <4EF0CCDB.4050803@web.de> Message-ID: <20111220195907.GB6220@hell> * Detlef Bosau | 2011-12-20 18:58:51 [+0100]: >Is there no one to get in touch with? > >I'm not quite sure, how anyone can deal with TCP/IP in wireless >networks, when there is no one to know anything reliable about >wireless channels. > >Perhaps, one could give me a hint, where I could find people to talk >to about these things? Some time ago I validated radio propagation models in ns3. Under http://jauu.net/data/pdf/propagation-models.pdf you will find a presentation. With all the math: wave length, system loss, antenna gain, bolzmann constant, receiver noise, Nakagami model including information how to interpret the results (e.g from SNR to Symbol Error Rate (for QPSK, QAM, ...) The presentation is completely generated: including source code for Nakagami and so on. All you need is a C compiler and the GNU scientific library. git clone http://git.jauu.net/wireless-propagation.git If you understand the source - all your questions are answered. ;-) Hagen PS: please don't get in touch with me. Try to understand the code, if you have troubles please consider to buy a books?! ;-) From detlef.bosau at web.de Thu Dec 22 09:33:04 2011 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 22 Dec 2011 18:33:04 +0100 Subject: [e2e] calculated SNR traces? In-Reply-To: <20111220195907.GB6220@hell> References: <4EE757D4.1090200@web.de> <4EE873D4.3080708@web.de> <4EF0CCDB.4050803@web.de> <20111220195907.GB6220@hell> Message-ID: <4EF369D0.4050804@web.de> On 12/20/2011 08:59 PM, Hagen Paul Pfeifer wrote: > > The presentation is completely generated: including source code for Nakagami > and so on. All you need is a C compiler and the GNU scientific library. > > git clone http://git.jauu.net/wireless-propagation.git > > If you understand the source - all your questions are answered. ;-) > > Hagen > > PS: please don't get in touch with me. Try to understand the code, if you have > troubles please consider to buy a books?! ;-) I explicitly asked to get in touch with someone. I case someone is explicitly not willing to do so, I don't see a value in his contribution to this thread. This is a scientific discussion group. When people reject the scientific discussion, I raise the question whether this group is an appropriate venue for these people. 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 ------------------------------------------------------------------