Re: [aqm] Sane analysis of typical traffic
Dave, Web traffic was part of the study - you should be able to see page load times on slide 12 Lower levels of traffic were also tested (slides 11,12), however the highest impact of AQM was observed at high traffic levels We included the largest components of Internet traffic (HAS, Web Traffic, Video Progressive download) which constitute over 75% of all traffic (https://www.sandvine.com/downloads/general/global-internet-phenomena/2014/1h-2014-global-internet-phenomena-report.pdf) at peak hour The study presented in Nov was our initial work and is not the only component in development of any configuration guidelines -Shahid. -Original Message- From: Dave Taht [mailto:dave.t...@gmail.com] Sent: Tuesday, July 15, 2014 4:00 PM To: Akhtar, Shahid (Shahid) Cc: Fred Baker (fred); John Leslie; aqm@ietf.org Subject: Sane analysis of typical traffic changing the title as this is not relevant to the aqm document... ... but to an attitude that is driving me absolutely crazy. On Tue, Jul 15, 2014 at 10:46 AM, Akhtar, Shahid (Shahid) shahid.akh...@alcatel-lucent.com wrote: Dave, The message of the results that we presented in November is that it is possible, with currently deployed access hardware, to configure RED so that it consistently improves the end user experience of common network services over Tail-Drop (which is most often configured), and that this improvement can be achieved with a fixed set of RED configuration guidelines. We did not run experiments with sfq_codel because it is not deployed in access networks today. We ran experiments with plain CoDel to understand the difference between a well-configured RED and a more recent single-bucket AQM in our target scenarios, and as reported, didn't observe significant differences in application QoE. Your application was a bunch of video streams. Not web traffic, not voip, not, gaming, not bittorrent, not a family of four doing a combination of these things, nor a small business that isn't going to use HAS at all. Please don't over generalize your results. RED proven suitable for family of couch potatoes surfing the internet and watching 4 movies at once over the internet but not 5, at 8mbit/sec might have been a better title for this paper. In this fictional family, just one kid under the stair, trying to do something useful, interactive and/or fun, can both wreck the couch potatoes' internet experience, and have his own, wrecked also. Additional inline clarifications below. -Shahid. -Original Message- From: Dave Taht [mailto:dave.t...@gmail.com] Sent: Monday, July 14, 2014 2:00 PM To: Akhtar, Shahid (Shahid) Cc: Fred Baker (fred); John Leslie; aqm@ietf.org Subject: Re: [aqm] Obsoleting RFC 2309 On Mon, Jul 14, 2014 at 11:08 AM, Akhtar, Shahid (Shahid) shahid.akh...@alcatel-lucent.com wrote: Hi Fred, All, Let me an additional thought to this issue. Given that (W)RED has been deployed extensively in operators' networks, and most vendors are still shipping equipment with (W)RED, concern is that obsoleting 2309 would discourage research on trying to find good configurations to make (W)RED work. We had previously given a presentation at the ICCRG on why RED can still provide value to operators (http://www.ietf.org/proceedings/88/slides/slides-88-iccrg-0.pdf). We have a paper at Globecom 2014 that explains this study much better, but I cannot share a link to it until the proceedings are available. My problem with the above preso and no doubt the resulting study is that it doesn't appear cover the classic, most basic, bufferbloat scenario, which is 1 stream up, 1 stream down, one ping (or some form of voip-like traffic) and usually on an edge network with asymmetric bandwidth. Two additional analyses of use from the download perspective might be Arris's analysis of the benefits of red and fq over cable head ends: http://snapon.lab.bufferbloat.net/~d/trimfat/Cloonan_Paper.pdf and the cable labs work which focused more on the effects of traffic going upstream which has been discussed fairly extensively here. SA: We tried to cover the typical expected traffic over the Internet. I don't know where you get your data, but my measured edge traffic looks nothing like yours. Sure bandwidth wise, theres the netflix spike 3 hours out of the day but the rest sure isn't HAS. Most of the traffic is now HAS traffic (as per the sandvine report), so if only a single stream is present, it is likely to be HAS. The closest approximation of a continuous TCP stream, as you mention, would be a progressive download which can last long enough to look continuous. These were modeled together with other types of traffic. You keep saying, download, download, download. I am saying merely please ALWAYS try an upload at the same time you are testing downloads - be it videoconferencing (which can easily use up that 1.6mbit link), a youtube upload, a rsync backup, a scp,
[aqm] Sane analysis of typical traffic
changing the title as this is not relevant to the aqm document... ... but to an attitude that is driving me absolutely crazy. On Tue, Jul 15, 2014 at 10:46 AM, Akhtar, Shahid (Shahid) shahid.akh...@alcatel-lucent.com wrote: Dave, The message of the results that we presented in November is that it is possible, with currently deployed access hardware, to configure RED so that it consistently improves the end user experience of common network services over Tail-Drop (which is most often configured), and that this improvement can be achieved with a fixed set of RED configuration guidelines. We did not run experiments with sfq_codel because it is not deployed in access networks today. We ran experiments with plain CoDel to understand the difference between a well-configured RED and a more recent single-bucket AQM in our target scenarios, and as reported, didn't observe significant differences in application QoE. Your application was a bunch of video streams. Not web traffic, not voip, not, gaming, not bittorrent, not a family of four doing a combination of these things, nor a small business that isn't going to use HAS at all. Please don't over generalize your results. RED proven suitable for family of couch potatoes surfing the internet and watching 4 movies at once over the internet but not 5, at 8mbit/sec might have been a better title for this paper. In this fictional family, just one kid under the stair, trying to do something useful, interactive and/or fun, can both wreck the couch potatoes' internet experience, and have his own, wrecked also. Additional inline clarifications below. -Shahid. -Original Message- From: Dave Taht [mailto:dave.t...@gmail.com] Sent: Monday, July 14, 2014 2:00 PM To: Akhtar, Shahid (Shahid) Cc: Fred Baker (fred); John Leslie; aqm@ietf.org Subject: Re: [aqm] Obsoleting RFC 2309 On Mon, Jul 14, 2014 at 11:08 AM, Akhtar, Shahid (Shahid) shahid.akh...@alcatel-lucent.com wrote: Hi Fred, All, Let me an additional thought to this issue. Given that (W)RED has been deployed extensively in operators' networks, and most vendors are still shipping equipment with (W)RED, concern is that obsoleting 2309 would discourage research on trying to find good configurations to make (W)RED work. We had previously given a presentation at the ICCRG on why RED can still provide value to operators (http://www.ietf.org/proceedings/88/slides/slides-88-iccrg-0.pdf). We have a paper at Globecom 2014 that explains this study much better, but I cannot share a link to it until the proceedings are available. My problem with the above preso and no doubt the resulting study is that it doesn't appear cover the classic, most basic, bufferbloat scenario, which is 1 stream up, 1 stream down, one ping (or some form of voip-like traffic) and usually on an edge network with asymmetric bandwidth. Two additional analyses of use from the download perspective might be Arris's analysis of the benefits of red and fq over cable head ends: http://snapon.lab.bufferbloat.net/~d/trimfat/Cloonan_Paper.pdf and the cable labs work which focused more on the effects of traffic going upstream which has been discussed fairly extensively here. SA: We tried to cover the typical expected traffic over the Internet. I don't know where you get your data, but my measured edge traffic looks nothing like yours. Sure bandwidth wise, theres the netflix spike 3 hours out of the day but the rest sure isn't HAS. Most of the traffic is now HAS traffic (as per the sandvine report), so if only a single stream is present, it is likely to be HAS. The closest approximation of a continuous TCP stream, as you mention, would be a progressive download which can last long enough to look continuous. These were modeled together with other types of traffic. You keep saying, download, download, download. I am saying merely please ALWAYS try an upload at the same time you are testing downloads - be it videoconferencing (which can easily use up that 1.6mbit link), a youtube upload, a rsync backup, a scp, anything... It needent be the crux of your paper! But adding several tests of that sort does need to inform your total modeling experience. If you do that much, you we get a feel for how present day systems interact with things like ack clocking which will do very interesting things to your downstream to the couch potato performance metrics. It's not clear from the study that this is a 8mbit down 1mbit up DSL network (?), SA: In the study presented, It was 8M down and 1.6M up - slide 9 Thx. nor is it clear if RED is being applied in both directions or only one direction onl? SA: AQMs (including RED) were only applied in downstream direction - slide 9 Are you going to follow up with stuff that looks at the upstream direction? (and the results you get from an asymmetric network are quite interesting, particularly in the face of any cross traffic at all) SA:
