Re: [aqm] Last Call: (FlowQueue-Codel) to Experimental RFC

[Toke Høiland-Jørgensen]

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

[Wesley Eddy]

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

[Dave Cridland]

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

[Dave Cridland]

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

[Toke Høiland-Jørgensen]

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

[Toke Høiland-Jørgensen]

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

[Toke Høiland-Jørgensen]

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