[Cerowrt-devel] RE : [Bloat] better business bufferbloat monitoring tools?
Bill I beleive you hit the limit of what you can do with AQM w/o FQ. something more can be achieved with paced sources as said in this thread. I do not see incentives for ABR folks to do true pacing however. doing partial pacing to fix the TSO/GSO problem is of course a must but won't solve the problem you mention. see you on monday at the conference. I 'm giving a talk right before you. Luca Message d'origine De : "Bill Ver Steeg (versteb)" Date :2015/05/14 00:54 (GMT+01:00) À : Dave Taht Cc : cerowrt-devel@lists.bufferbloat.net, bloat Objet : Re: [Bloat] better business bufferbloat monitoring tools? Dave That said - It has generally been my hope that most of the big movie streaming folk have moved to some form of pacing by now but have no data on it. (?) Bill VerSteeg replies - Based on my recent tests, the production ABR flows are still quite bursty. There has been some work done in this area, but I do not think bloat is top-of-mind for the ABR folks, and I do not think it has made it into production systems. Some of the work is in the area of pacing TCP's micro-bursts using sch_fq-like methods. Some has been in the area of application rate estimation. Some of the IW10 pacing stuff may also be useful. I am actually giving a talk on AQM to a small ABR video conference next week. The executive summary of my talk is "AQM makes bursty ABR flows less impactful to the network buffers (and thus cross traffic), but the bursts still cause problems. The problems are really bad on legacy buffer management algorithms. The new AQM algorithms take care of most of the issues, but bursts of data make the new algorithms work harder and do cause some second-order problems." The main problem that I have seen in my testing has been in the CoDel/PIE (as opposed to FQ_XXX) variants. When the bottleneck link drops packets as the elephant bursts, the mice flows suffer. Rather than completing in a handful of RTTs, it takes several times longer for the timeouts and rexmits to complete the transfer. When running FQ_Codel or FQ_PIE, the elephant flow only impacts itself, as the mice are on their own queues. There are also some corner cases when the offered load is extremely high, but these seem to be third order effects. I will let the list know what the current state of the art on pacing is after next week's conference, but I suspect that the ABR folks are still on a learning curve here. Bvs -Original Message- From: Dave Taht [mailto:dave.t...@gmail.com] Sent: Wednesday, May 13, 2015 9:37 AM To: Bill Ver Steeg (versteb) Cc: bloat; cerowrt-devel@lists.bufferbloat.net Subject: Re: [Bloat] better business bufferbloat monitoring tools? On Wed, May 13, 2015 at 6:20 AM, Bill Ver Steeg (versteb) wrote: > Time scales are important. Any time you use TCP to send a moderately large > file, you drive the link into congestion. Sometimes this is for a few > milliseconds per hour and sometimes this is for 10s of minutes per hour. > > For instance, watching a 3 Mbps video (Netflix/YouTube/whatever) on a 4 Mbps > link with no cross traffic can cause significant bloat, particularly on older > tail drop middleboxes. The host code does an HTTP get every N seconds, and > drives the link as hard as it can until it gets the video chunk. It waits a > second or two and then does it again. Rinse and Repeat. You end up with a > very characteristic delay plot. The bloat starts at 0, builds until the > middlebox provides congestion feedback, then sawtooths around at about the > buffer size. When the burst ends, the middlebox burns down its buffer and > bloat goes back to zero. Wait a second or two and do it again. The dslreports tests are opening 8 or more full rate streams at once. Not pretty results. Web browsers expend most of their flows entirely in slow start. Etc. I am very concerned with what 4k streaming looks like, and just got an amazon box to take a look at it. (but have not put out the cash for a suitable monitor) > You can't fix this by adding bandwidth to the link. The endpoint's TCP > sessions will simply ramp up to fill the link. You will shorten the > congested phase of the cycle, but TCP will ALWAYS FILL THE LINK (given > enough time to ramp up) It is important to keep stressing this point as the memes propagate outwards. > > The new AQM (and FQ_AQM) algorithms do a much better job of controlling the > oscillatory bloat, but you can still see ABR video patterns in the delay > figures. It has generally been my hope that most of the big movie streaming folk have moved to some form of pacing by now but have no data on it. (?) Certainly I'm happy with what I saw of quic and have hope that http/2 will cut the number of simultaneous flows in progress. But I return to my original point in that I would like to continue to find more ways to make the sub 5 minute behaviors visible and comprehensible to more people... > Bvs > > > -Original Message--
Re: [Cerowrt-devel] [Bloat] heisenbug: dslreports 16 flow test vs cablemodems
That would be OK for ledbat-like vs TCP Real time vs ledbat-like isn't that clear to me why real time should be protected. I'd say that Skype would suffer against any protocol probing for bandwidth. Original message From: "Eggert, Lars" Date:18/05/2015 1:49 PM (GMT+01:00) To: Simon Barber Cc: c...@lists.bufferbloat.net, dpr...@reed.com, "Klatsky, Carl" , cerowrt-devel@lists.bufferbloat.net, bloat Subject: Re: [Bloat] [Cerowrt-devel] heisenbug: dslreports 16 flow test vs cablemodems On 2015-5-18, at 07:06, Simon Barber mailto:si...@superduper.net>> wrote: Windows update will kill your Skype call. Really? AFAIK Windows Update has been using a LEDBAT-like scavenger-type congestion control algorithm for years now. Lars _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
[Cerowrt-devel] RE : [Bloat] Save WiFi from the FCC - DEADLINE is in 3 days *September* 8
is there any serious study that proves that LTE U is a threat? Message d'origine De : Dave Taht Date :2015/09/06 12:06 AM (GMT+01:00) À : Rich Brown Cc : make-wifi-f...@lists.bufferbloat.net, cerowrt-devel , bloat Objet : Re: [Bloat] Save WiFi from the FCC - DEADLINE is in 3 days *September* 8 while the current FCC course sucks, I personally have been unable to summon the moxy to fight anymore. Decided to migrate to the eu instead, only to find the same ruling going into play here. Is there no place left on the planet safe to innovate in? and: LTE-U is an even greater threat, and I'm low on ideas on how to counter it. http://www.wsj.com/articles/cell-carriers-battle-for-wi-fi-airwaves-1440543853 On Sat, Sep 5, 2015 at 7:12 AM, Rich Brown wrote: > Folks, > > Dave may have buried the lede in his previous note... The date for comments > to the FCC is not a month away, but only three days away - 8 Sep 2015. > > To see the talking points for preparing your comments, go to: > https://libreplanet.org/wiki/Save_WiFi > > To submit a comment, click the green "SUBMIT A FORMAL COMMENT" button on > https://www.federalregister.gov/articles/2015/08/06/2015-18402/equipment-authorization-and-electronic-labeling-for-wireless-devices > > Please post a link to your comments when you're done. > > Rich > > On Sep 5, 2015, at 6:42 AM, Dave Taht wrote: > > In other news: > > I am glad to see the more political save-the-wifi coming online rapidly: > > https://libreplanet.org/wiki/Save_WiFi > > I HAD NO IDEA that the follow-on rules for 2016 would basically ban > modifiable firmware entirely, nor that the DFS problem was due to only 41 > old radars that need to be replaced anyway. > > Comment deadline for the fcc is sept 8th, not oct 8, which means we should > strap ourselves into the writing console, like, today. > > -- Dave Täht endo is a terrible disease: http://www.gofundme.com/SummerVsEndo ___ Bloat mailing list bl...@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
