Re: [aqm] Last Call: (FlowQueue-Codel) to Experimental RFC
> On 21 Mar, 2016, at 20:04, Bob Briscoe wrote: > > The experience that led me to understand this problem was when a bunch of > colleagues tried to set up a start-up (a few years ago now) to sell a range > of "equitable quality" video codecs (ie constant quality variable bit-rate > instead of constant bit-rate variable quality). Then, the first ISP they > tried to sell to had WFQ in its Broadband remote access servers. Even tho > this was between users, not flows, when video was the dominant traffic, this > overrode the benefits of their cool codecs (which would have delivered twice > as many videos with the same quality over the same capacity. This result makes no sense. You state that the new codecs “would have delivered twice as many videos with the same quality over the same capacity”, and video “was the dominant traffic”, *and* the network was the bottleneck while running the new codecs. The logical conclusion must be either that the network was severely under-capacity and was *also* the bottleneck, only twice as hard, under the old codecs; or that there was insufficient buffering at the video clients to cope with temporary shortfalls in link bandwidth; or that demand for videos doubled due to the new codecs providing a step-change in the user experience (which feeds back into the network capacity conclusion). In short, it was not WFQ that caused the problem. - Jonathan Morton ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
Re: [aqm] Last Call: (FlowQueue-Codel) to Experimental RFC
Dave Cridland writes: > If this isn't standards track because there's no WG consensus for a single > algorithm (and we'll argue over whether a queueing algorithm is a protocol or > not some other time), then I think this WG document should reflect that > consensus and hold back on the recommendations, then, unless you really have > WG > consensus for that position. > > If this were an individual submission, it'd be different, but a WG document > must > reflect the Working Group as a whole and not just the authors. Yes, well, ensuring that it does is what the WG last call and review process is for, isn't it? Which the draft has been through without anyone taking issue with it. Not even sure what (if any) the proper process for handling this is at this time (the tracker lists the status as "Submitted to IESG for Publication")...? I explained the reasoning behind the current language in a previous email. The only proposal for alternative language has been from Grenville, and as I said I can live with that. However, I'm not terribly inclined to spend more time editing this until I'm sure that it will actually put the issue to rest. -Toke ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
Re: [aqm] Last Call: (FlowQueue-Codel) to Experimental RFC
On 3/24/2016 9:01 AM, Toke Høiland-Jørgensen wrote: Dave Cridland writes: Well, I have to ask why, in this case, it's Experimental and not Standards-Track? Heh. Well, I guess the short answer is "because there wasn't WG consensus to do that". Basically, the working group decided that all the algorithms we are describing will be experimental rather than standards track, at least for now. Because they are queueing algorithms and not protocols (and so do not have the same interoperability requirements), this was deemed an acceptable way forward, and a way to get it "out there" without having to have to agree to push for The One True AQM(tm). (This is my understanding; I'm sure someone will chime in and correct me if I'm wrong). Personally, I would have no problem with this being standards track :) I am one of the WG chairs and document shepherd. The AQM charter does allow for publication on the Standards Track, but at this point in time there did not seem to be a consensus that this was necessary, plus given some of the open research questions, it seemed like a prudent choice. We can always go stronger and make a standard later on. I think Bob's concerns here, and the disagreement about what happens in reality, make it very obvious that Experimental is the right choice! The indications so far are that this has a lot of promise to help, but there are questions, and it could benefit from even more experience deploying in the wild, and watching what happens. ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
Re: [aqm] Last Call: (FlowQueue-Codel) to Experimental RFC
On 24 March 2016 at 13:01, Toke Høiland-Jørgensen wrote: > Dave Cridland writes: > > > What we meant to say was something along the lines of "You want to > turn > > this on; it'll do you good, so get on with it! You won't regret it! > Now > > go fix the next 100 million devices!". The current formulation in the > > draft is an attempt to be slightly less colloquial about it... ;) > > > > Well, I have to ask why, in this case, it's Experimental and not > > Standards-Track? > > Heh. Well, I guess the short answer is "because there wasn't WG > consensus to do that". Basically, the working group decided that all the > algorithms we are describing will be experimental rather than standards > track, at least for now. Because they are queueing algorithms and not > protocols (and so do not have the same interoperability requirements), > this was deemed an acceptable way forward, and a way to get it "out > there" without having to have to agree to push for The One True AQM(tm). > > If this isn't standards track because there's no WG consensus for a single algorithm (and we'll argue over whether a queueing algorithm is a protocol or not some other time), then I think this WG document should reflect that consensus and hold back on the recommendations, then, unless you really have WG consensus for that position. If this were an individual submission, it'd be different, but a WG document must reflect the Working Group as a whole and not just the authors. Of course, this isn't even my biscuit to dunk, let alone my hill to die on. > (This is my understanding; I'm sure someone will chime in and correct me > if I'm wrong). > > > Personally, I would have no problem with this being standards track :) > > -Toke > ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
Re: [aqm] Last Call: (FlowQueue-Codel) to Experimental RFC
On 24 March 2016 at 10:32, Toke Høiland-Jørgensen wrote: > Dave Cridland writes: > > > Actually I'd read that as more of a recommendation than merely safe. I > > think by safe, the authors mean that no significant harm has been > > found to occur. > > What we meant to say was something along the lines of "You want to turn > this on; it'll do you good, so get on with it! You won't regret it! Now > go fix the next 100 million devices!". The current formulation in the > draft is an attempt to be slightly less colloquial about it... ;) > Well, I have to ask why, in this case, it's Experimental and not Standards-Track? Please try to explain as if I haven't read your draft and wouldn't understand it if I did, but you seem to be saying this is an applicability statement indicating you want wide deployment, but, from RFC 2026: (d) Limited Use: The TS is considered to be appropriate for use only in limited or unique circumstances. For example, the usage of a protocol with the "Experimental" designation should generally be limited to those actively involved with the experiment. If what you're saying is that you do believe this is "ready" for wide deployment, you should be publishing on the Standards Track, surely? Dave. ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
Re: [aqm] Last Call: (FlowQueue-Codel) to Experimental RFC
On 24 Mar 2016 3:02 am, "grenville armitage" wrote: > > > > On 03/18/2016 21:35, Bob Briscoe wrote: >> >> IESG, authors, >> >> 1. Safe? >> >> My main concern is with applicability. In particular, the sentence in section 7 on Deployment Status: "We believe it to be a safe default and encourage people running Linux to turn it on: ...". and a similar sentiment repeated in the conclusions. "and we believe it to be safe to turn on by default, as has already happened in a number of Linux distributions." > > > At the risk of incurring further wrath, and noting that the IESG did request "final comments on this action" (hence all the CCs), I think there's something to Bob's observation about the word "safe". > > What about: > > Section 1: "...and we believe it to be safe to turn on by default, ..." -> "...and we believe it to be significantly beneficial to turn on by default, ..." > Section 7: "We believe it to be a safe default and ..." -> "We believe it to be a significantly beneficial default and ..." > Actually I'd read that as more of a recommendation than merely safe. I think by safe, the authors mean that no significant harm has been found to occur. Simply restating that the protocol is experimental should be enough, I'd have thought, though if you really want: Although Experimental, this is believed to do no harm as a default in practise, and ... > (Yes, this is going to be an Experimental RFC. And yes, turning on FQ_CoDel generally results in awesome improvements wrt pfifo. But the two instances of "safe" in draft-ietf-aqm-fq-codel-05.txt do imply to me a wider degree of applicability than is probably warranted at this juncture. I just hadn't noticed until Bob mentioned it.) > > cheers, > gja > > > > > > > ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
Re: [aqm] Last Call: (FlowQueue-Codel) to Experimental RFC
Dave Cridland writes: > What we meant to say was something along the lines of "You want to turn > this on; it'll do you good, so get on with it! You won't regret it! Now > go fix the next 100 million devices!". The current formulation in the > draft is an attempt to be slightly less colloquial about it... ;) > > Well, I have to ask why, in this case, it's Experimental and not > Standards-Track? Heh. Well, I guess the short answer is "because there wasn't WG consensus to do that". Basically, the working group decided that all the algorithms we are describing will be experimental rather than standards track, at least for now. Because they are queueing algorithms and not protocols (and so do not have the same interoperability requirements), this was deemed an acceptable way forward, and a way to get it "out there" without having to have to agree to push for The One True AQM(tm). (This is my understanding; I'm sure someone will chime in and correct me if I'm wrong). Personally, I would have no problem with this being standards track :) -Toke ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
Re: [aqm] Last Call: (FlowQueue-Codel) to Experimental RFC
Dave Cridland writes: > Actually I'd read that as more of a recommendation than merely safe. I > think by safe, the authors mean that no significant harm has been > found to occur. What we meant to say was something along the lines of "You want to turn this on; it'll do you good, so get on with it! You won't regret it! Now go fix the next 100 million devices!". The current formulation in the draft is an attempt to be slightly less colloquial about it... ;) -Toke ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
Re: [aqm] Last Call: (FlowQueue-Codel) to Experimental RFC
grenville armitage writes: > What about: > > Section 1: "...and we believe it to be safe to turn on by default, ..." -> > "...and we believe it to be significantly beneficial to turn on by default, > ..." > Section 7: "We believe it to be a safe default and ..." -> "We believe it to > be > a significantly beneficial default and ..." Aha! Finally someone is being constructive! Thank you! > (Yes, this is going to be an Experimental RFC. And yes, turning on FQ_CoDel > generally results in awesome improvements wrt pfifo. But the two instances of > "safe" in draft-ietf-aqm-fq-codel-05.txt do imply to me a wider degree of > applicability than is probably warranted at this juncture. I just hadn't > noticed > until Bob mentioned it.) Still not sure I agree that having the word 'safe' in there is such a big deal, but, well, if multiple people think it's an issue that in itself might be reason enough to change it. And I can live with your alternative formulation. :) -Toke ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm