Re: [aqm] RFC 8290 on The Flow Queue CoDel Packet Scheduler and Active Queue Management Algorithm

[Toke Høiland-Jørgensen]

rfc-edi...@rfc-editor.org writes:

> A new Request for Comments is now available in online RFC libraries.
>
> 
> RFC 8290
>
> Title:  The Flow Queue CoDel Packet 
> Scheduler and Active Queue Management Algorithm

Yay! Happy new year to all! :D

-Toke

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] CoDel: After much ado ...

[Toke Høiland-Jørgensen]

"Mirja Kuehlewind (IETF)"  writes:

> Thanks! Will approve now! Finally! Yeah!

And there was much rejoicing! Wooh! :)

-Toke

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] Warren Kumari's Yes on draft-ietf-aqm-codel-07: (with COMMENT)

[Toke Høiland-Jørgensen]

Toke Høiland-Jørgensen <t...@toke.dk> writes:

> Jana Iyengar <j...@google.com> writes:
>
>> Yup, coming up next week.
>
> Or maybe this week? ;)

So, any chance of getting this submitted before the cutoff date on Monday?

-Toke

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] Warren Kumari's Yes on draft-ietf-aqm-codel-07: (with COMMENT)

[Toke Høiland-Jørgensen]

Jana Iyengar  writes:

> Yup, coming up next week.

Or maybe this week? ;)

-Toke

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] Warren Kumari's Yes on draft-ietf-aqm-codel-07: (with COMMENT)

[Toke Høiland-Jørgensen]

Jana Iyengar  writes:

> +1 to Mirja's response. I'll do some restructuring. Thanks for your
> comments!

Any progress on said restructuring? :)

-Toke

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] status of codel WGLC

[Toke Høiland-Jørgensen]

Jana Iyengar  writes:

> We'll send out a revised draft early next week.

Soo... Ping?

-Toke

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] status of codel WGLC

[Toke Høiland-Jørgensen]

Dave Täht  writes:

> On 9/14/16 6:26 AM, Wesley Eddy wrote:
>> Hi, for awhile, the CoDel draft was in working group last call. Some
>> comments were received, and the authors made an update some time ago. 
>> There hasn't been much follow-up discussion.  I assume this means the
>> current draft meets people's expectations?  If not, now is a good time
>> to shout, because I'm working on the shepherd write-up so that it can be
>> submitted to the IESG soon.
>> 
>> https://datatracker.ietf.org/doc/draft-ietf-aqm-codel/
>> 
>> There are a few small things I noticed while doing the shepherd write-up:
>> 
>> 1) I thought the ADs and WG were happy to go Experimental rather than
>> Informational
>> (https://www.ietf.org/mail-archive/web/aqm/current/msg01727.html ) ...
>> was there a reason from the authors that it didn't change?
>
> Sigh. I've really lost track. This was discussed again on the friday
> meeting at the last ietf... and I don't remember what was decided!
>
> My overall suggestion was merely that pie,codel, and fq_codel have the
> same status and I don't care which one it is.

+1

PIE and FQ-CoDel are marked as experimental, and PIE is already through
the process; so changing the CoDel draft would be the pragmatic thing to
do...

-Toke

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

[aqm] Applying AQM to the WiFi MAC layer

[Toke Høiland-Jørgensen]

Since Andrew McGregor mentioned this at the mic during the tsvwg/aqm
session in Berlin, I thought I'd post some references to the work on
fixing queueing behaviour on WiFi (by incorporating principles from
FQ-CoDel in the Linux WiFi stack at the MAC layer).

There are still some bugs to work out, but these two blog entries
provide some details on the progress so far:

https://blog.tohojo.dk/2016/06/fixing-the-wifi-performance-anomaly-on-ath9k.html

http://blog.cerowrt.org/post/fq_codel_on_ath10k/

Cheers,

-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:

> 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

[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

Re: [aqm] Alia Atlas' No Objection on draft-ietf-aqm-fq-codel-05: (with COMMENT)

[Toke Høiland-Jørgensen]

Dave Taht  writes:

>> I've added a reference pointing to the fq_codel code in Linux git tree
>> to the latest updated version, available here:
>> https://kau.toke.dk/ietf/draft-ietf-aqm-fq-codel-06.html (or .txt).
>
> I'm not huge on calling this reference [LINUX]. [LINUXSRC]? [SRC]?

Figured the RFC editor was going to fix that.

> I also felt compelled, after this round of cite-adding, to add a few
> more cites, (what will be) rfc7806, BQL, HTB, and HFSC, with a brief
> section explaining why they are needed also. BQL was the under
> appreciated breakthrough that made scaling past a gbit possible, and
> would (if implemented) make dsl and cable modems a lot better,
> at their (much slower) speeds.
>
> https://github.com/dtaht/bufferbloat-rfcs/commit/7d500133008857b7b78000abac9d592e66477ffb
>
> adding:
>
> ## Device queues must also be well controlled
>
> It is best that these AQM and FQ algorithms run as close to the hardware
> as possible. Scheduling such complexity at interrupt time is difficult, so
> a small standing queue between the algorithm and the wire is often needed
> at higher transmit rates.
>
> In Linux, this is accomplished via "Byte Queue Limits" {{BQL}} in the
> device driver ring buffer (for physical line rates), and via a software
> rate limiter such as {HTB}}, {{HFSC}}, or {{CAKE}} otherwise.
>
> Other issues with concatenated queues are described in {{CODEL}}.

Will fix up your additions before submitting the updated draft tomorrow
(from eyeballing, I'm pretty sure it doesn't currently compile).

> There has been such an accumulation of small changes in response to
> this wonderful review process that I fear that going through another
> "last, last" call will be needed.

Well, while there has been a bunch, they're all clarifications and minor
changes; the substance is not changed from the version that went to last
call.

-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]

Hi Bob

Thank you for your timely and constructive comments. Please see the
inline responses below.

> 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."
>
> Can one of the authors explain why a solution with the limitations in
> section 6 can still be described as "safe"?

"We believe it to be a safe default" means that we have not seen any of
the theoretical limitations we have documented in section 6 be a concern
*in practice* in any of the extensive number of deployments FQ-CoDel has
seen already. And that the benefits of turning on FQ-CoDel are
sufficient that nudging people in that direction is a good idea.

> Indeed, these sentences seem rather Orwellian.

I can assure you that we are not attempting to exert "draconian control
by propaganda, surveillance, misinformation, denial of truth, and
manipulation of the past" (quoting
https://en.wikipedia.org/wiki/Orwellian here). But thank you for
implying it :)

> Would it not be correct instead to say that FQ_CoDel has been made the
> default in a number of Linux distributions despite not being safe in
> some circumstances?

At the time it was made the default in OpenWrt (several years ago now,
if memory serves me right), there was not a whole lot of real-world
deployment experience, due to the chicken-and-egg problem of not wanting
to change the default before we have gathered more experience. However,
today the situation is quite different, thanks in part to the boldness
of the OpenWrt devs. So no, I do not believe that to be the case any
longer.

> 2. Default?
>
> If a draft saying "We believe it to be a safe default..." is published as an
> RFC, it means "The IETF/IESG/etc believes..."
> Only one solution can be default, so if the IETF says that FQ_CoDel is a safe
> default, and no other AQM RFC makes any claim to being a safe default (which
> they do not at the moment), it could be read as the IETF recommending FQ_CoDel
> for default status and, by implication, other AQMs (like PIE, say) are not
> recommended for default status.

This is certainly not my reading. This is an experimental RFC saying "we
believe it to be safe as a default" not a standards track RFC saying
"this should be the default". This is an important difference; we are
not mandating anything, but rather expressing our honest opinion on
the applicability of FQ-CoDel as a default, should anyone wish to make
it one in their domain.

> As far as I know, unlike the listed FQ_CoDel limitations, no
> limitations of PIE have been identified. I don't think anyone is
> claiming that the performance of FQ_CoDel is awesomely better than
> PIE. May be a bit better, may be a bit worse, depending on
> circumstances, and depending on which you value most out of low
> queuing delay, high utilization, or low loss.

Well, for CoDel and PIE that is certainly true. But FQ-CoDel in many
cases reduces latency under load by an order of magnitude compared to
both of them, while improving throughput.

> So, if the authors want the IETF to recommend a default AQM on the
> basis of safety (and I agree safety is the most important factor when
> choosing a default), the most likely candidate would be PIE, wouldn't
> it? FQ_CoDel has unintended side-effects, which implies it is not a
> good candidate for default; it should only be configured deliberately
> by those who can live with the side-effects.

I'm not sure it would be possible for the AQM group to agree on a
recommendation for a default. But I suppose it might be a good
bikeshedding exercise. And as noted above, this is not what we intend to
do in this case.

> 3. A Detail
>
> I also have a concern about the way the limitations are written
> (typically, each limitation is stated, followed by a arm-waving
> qualification attempting to create an impression that there is not
> really a limitation). To keep the thread clean, I'll send that in a
> follow-up email.

It is certainly not our intention to "create an impression that there is
not really a limitation". Rather, we are trying to suggest ways in which
each limitation can be mitigated by people who are concerned about it,
but still want to realise the benefits of deploying FQ-CoDel. Sure, some
of those proposals are not exactly at the "running code" stage, but
dismissing them as arm-waving is hardly fair.

I'll add, as I noted initially, that many of the limitations we have
noted are of a theoretical nature (in the sense that we are not aware of
any deployments where they have caused issue in practice). This does not
make it any less important to document them, of course, and we have been
grateful for the feedback from the working group that the section grew
out of (you yourself were 

Re: [aqm] Spencer Dawkins' Yes on draft-ietf-aqm-fq-codel-05: (with COMMENT)

[Toke Høiland-Jørgensen]

"Spencer Dawkins"  writes:

> --
> COMMENT:
> --
>
> Very nice work. I have some nit-ish questions I hope you'll consider,
> but nothing blocking.

Hi Spencer

Thank you, and thank you for your comments. I've updated the text to
account for them; the updated version is currently available here:
https://kau.toke.dk/ietf/draft-ietf-aqm-fq-codel-06.html (or .txt), and
I'll post it to the IETF tracker once I'm sure I have covered all the
review comments.


> This text in the Introduction,
>
>The FQ-CoDel algorithm is a combined packet scheduler and AQM
>developed as part of the bufferbloat-fighting community effort.  It
>is based on a modified Deficit Round Robin (DRR) queue scheduler,
>with the CoDel AQM algorithm operating on each queue.
>
> introduces both CoDel and DDR, but they don't have references until
> Section 1.3. Maybe move that forward in the doc?

This has been fixed.

> Perhaps this text:
>
>FQ-CoDel stochastically classifies incoming packets into different
>queues by hashing the 5-tuple of IP protocol number and source and
>destination IP and port numbers, perturbed with a random number
>selected at initiation time (although other flow classification
>schemes can optionally be configured instead). 
>
> would benefit from a forward reference to Section 4.1.1?

You're right; added the forward reference.

> Just as a nit, you have an "is is" in Section 3.

Yup, you're not the first one to notice; fixed :)

> In this text:
>
>After having selected a queue from which to dequeue a packet, the
>CoDel algorithm is invoked on that queue.  This applies the CoDel
>control law, 
>
> "CoDel control law" hasn't been introduced, and isn't included in Section
> 1.2. Could you provide a reference or pointer?

I've updated the text to explain what the control law does, and point to
the CoDel draft. The full paragraph now reads:

After having selected a queue from which to dequeue a packet, the
CoDel algorithm is invoked on that queue. This applies the CoDel
control law, which is the mechanism CoDel uses to determine when to
drop packets (see [I-D.ietf-aqm-codel]). As a result of this, one
or more packets may be discarded from the head of the selected
queue, before the packet that should be dequeued is returned (or
nothing is returned if the queue is or becomes empty while being
handled by the CoDel algorithm).

> In this text:
>
>This parameter can be set only at load time since memory has to be
>allocated for the hash table in the current implementation.
>
> if "in the current implementation" refers to "can be set only at load
> time", 
>
>This parameter can be set only at load time in the current
> implementation,
>since memory has to be allocated for the hash table.
>
> might be clearer.

I agree. Fixed.

> I wonder if 
>
>while CoDel itself can take a while
>to respond, fq_codel doesn't miss a beat.
>
> is clear to non-native English language readers?

That was already changed to read "while CoDel itself can take a while to
respond, FQ-CoDel reacts almost immediately".

> In this text:
>
>In the presence of queue management schemes that contain latency
>under load, 
>
> "contain" means something like "limit" right? That wasn't what I
> understood in my first parsing attempt.

I see what you mean. Changed 'contain' to 'limit'.

> I'm confused by this text:
>
>o  Packet fragments without a layer 4 header can be hashed into
>   different bins than the first fragment with the header intact.
>   This can cause reordering and/or adversely affect the performance
>   of the flow.  Keeping state to match the fragments to the
>   beginning of the packet, or simply putting all fragmented packets
>   into the same queue, are two ways to alleviate this.
>
> Is this "all fragmented packets", or "all packet fragments"?
>
> If it's "all fragmented packets", don't you have to reassemble the
> fragments? 
>
> If it's "all packet fragments", the packet fragments would all be
> transmitted in order, but could the fragments with headers and without
> headers of a single packet be reordered?

It's the latter. Updated the text to read "Keeping state to match the
fragments to the beginning of the packet, or simply putting all packet
fragments (including the first fragment of each fragmented packet) into
the same queue, are two ways to alleviate this."

> Do we say things like 
>
>In this document we have documented the Linux
>implementation in sufficient detail for an independent
>implementation, and we encourage such implementations be widely
>deployed.
>
> in Experimental RFCs?

Apparently not, as others have pointed out. Fixed :)

-Toke

___
aqm mailing list
aqm@ietf.org

Re: [aqm] Experimental vs informational vs standards track

[Toke Høiland-Jørgensen]

Wesley Eddy  writes:

> IMHO, Standards Track carries more weight to say that there are no
> sharp corners, and the IETF is pretty sure this works well.
> Experimental is more cautious saying this looks pretty useful, and you
> should consider trying it out, but it might have some rough edges
> (e.g. like open research questions, identified in several of the AQM
> drafts).

Well, for the FQ-CoDel algorithm the caveats are more of the form
"fairness queueing in some cases have limitations", not "this particular
algorithm has limitations". So if we assume that people know what a
fairness queueing algorithm is, I think that FQ-CoDel can most certainly
be considered to "work well". I think the fact that it is now on *by
default* in a whole range of Linux distributions should attest to that.

-Toke

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] A question regarding the latest FQ-CoDel Internet-Draft

[Toke Høiland-Jørgensen]

"Agarwal, Anil"  writes:

> Might be beneficial to fix the following line in section 5.4 -
>
>int   deficit; /* this is the queue credit */

Yeah, I'm aware of that. Couldn't decide what to do about the fact that
the Linux code calls it 'deficit' instead of 'credit', so just punted on
it and added that comment. Guess it's less confusing to just call the
variable 'credit'. Thanks for confirming that it was definitely
confusing ;)

Fixed in the -04.

-Toke

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] I-D Action: draft-ietf-aqm-fq-codel-02.txt

[Toke Høiland-Jørgensen]

internet-dra...@ietf.org writes:

> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
>  This draft is a work item of the Active Queue Management and Packet 
> Scheduling Working Group of the IETF.
>
> Title   : FlowQueue-Codel
>     Authors     : Toke Høiland-Jørgensen
>   Paul McKenney
>   Dave Taht
>   Jim Gettys
>   Eric Dumazet
>   Filename: draft-ietf-aqm-fq-codel-02.txt
>   Pages   : 19
>   Date: 2015-10-19

This is a minor update of the FQ-CoDel draft. It adds text to the
"Security considerations" section about the implementation details
necessary to pay attention to in order to avoid security issues. In
addition, it contains updated calculations for hash collision
probabilities, which we are very thankful to Anil Agarwal for providing.

As of this writing, we believe the only outstanding issue on this draft
(apart from the dependency on the CoDel draft) is Bob's promised review
comments. He has promised those should be forthcoming soon, but we
decided to submit this version now anyway: no reason to waste a nice
deadline :)

Please do not hesitate to point out any other comments you may have on
the current version of the draft.

-Toke

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] ECT(1)

[Toke Høiland-Jørgensen]

Bob Briscoe  writes:

> Yes, and because flow-queuing overrides the packet rate choices of
> applications (breaking the end-to-end principle). In testing, fq
> completely rips apart CBR and variable rate video when running
> alongside long-running TCP flows, when they would otherwise work just
> fine in a FIFO.

Are these tests available somewhere? Don't think I've actually seen a
well-specified test scenario that demonstrates this, and would love to
poke into it some more...

-Toke

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] CoDel's control law that determines drop frequency

[Toke Høiland-Jørgensen]

Polina Goltsman  writes:

>> Early on, Rong Pan showed that it takes CoDel ages to bring high load under
>> control. I think this linear increase is the reason.
>
> Is there a link to this ?

I have an analysis of transient behaviour in my recent paper (section 6.2):
http://www.sciencedirect.com/science/article/pii/S1389128615002479

PIE struggles with this too, BTW...

-Toke

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] FQ-PIE kernel module implementation

[Toke Høiland-Jørgensen]

Fred Baker (fred) f...@cisco.com writes:

 I'm not sure it makes sense to discuss fq_codel having a separate
 instance for each queue.

Why not? It does. Completely separate state variables and everything...

 It could, I suppose (by having a separate target delay value for each
 queue), but... the codel algorithm timestamps packets on enqueue and
 compares the difference between that timestamp and the current time
 against a common target delay value on dequeue.

That much is true: all the queues *start out* the same. Doesn't mean
they're not separate...

 If that comparison shows that the induced latency is greater than some
 value, the packet is discarded with some probability.

The state variables (drop count) governing when packets are dropped *are*
separate for each queue, so you can have completely different drop rates
for different queues if they build queues at different rates.

 In the linux fq algorithm, or its counterpart in fq_codel, there is
 one queue for mice and zero or more separate queues for elephant
 flows.

Not so. There can be several 'mice' queues. In fact, each and every
queue starts out its life as a 'mice' queue (getting prioritised) before
being demoted to the second tier ('elephant' queues) after having
dequeued its first quantum (by default an MTU's worth of bytes).

 It is technically possible for a packet to be delayed inordinately
 long in the mice queue, if the interface is undergoing a long term
 overload, but that would be pretty unusual (can you say DDOS?). More
 probably, discards happen to the elephant data flows and their
 corresponding queues, as they are more likely to build a backlog.

The way fq_codel is implemented pretty much guarantees that packets are
not dropped from the mice flows: By definition, they are only mice flows
when dequeueing their first quantum of bytes, at which point the CoDel
state vars are zeroed. Which means that even if the first packet is
queued for longer than the target (which can easily happen at low
bandwidths), this will trigger the wait time for an interval before an
actual drop happens. So unless the mice flow has two consecutive
packets, totalling less than a quantum (MTU) bytes, of which the first
takes more than an interval to put on the wire, the mice flow is not
going to see a drop.

This is, as far as I can tell from your explanation, different than what
fq_pie does.

-Toke

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] References on AQM test results and fq_nocodel

[Toke Høiland-Jørgensen]

David Lang da...@lang.hm writes:

 if the fq portion is being gamed, how severe can the imbalance be? Is
 it a matter that if there are N flows without gaming the system, and
 each is getting 1/N bandwith, then if a cheater uses M flows the
 cheater gets M/(N+M) of the bandwidth?

Yes, not counting hash collisions, that would be the case.

 more importantly, is there any way short of a massive number of flows
 (essentially a DDOS), that this gaming of the system can hurt the
 latency of the other flows? or is it just the relative bandwidth of
 the different apps that suffers, and if an app is low bandwidth, but
 latency sensitive (i.e. VoIP), it won't be affected until it's share
 of bandwidth drops below the minimum it needs?

Well, since fq_codel is hash based, if you manage to hit the same bucket
as the VoIP flow, that VoIP flow is not going to get the nice implicit
priority it would otherwise from the flow queueing. So yeah, if you,
say, send out 1000 packets at once on different UDP ports, then the VoIP
flow is going to notice. But in this case you're basically DOS'ing the
router; and FIFO queueing and pure AQMs fare pretty badly as well...

 Looping back to the start of the topic, the slides apparently are
 being read that fq without codel is just as good, or better than
 fq_codel, so codel can be dropped, and only fq is needed.

 Is this what you are concluding from this? Or is that a misreading of
 something (the data, your work, or me misreading this thread)?

Well, *for the tested scenarios and metrics* that is true. However,
there can be other scenarios where you will benefit from having AQM on
each of the queues. Several such hypothetical scenarios have been
mentioned in this thread. The open question, as far as I'm concerned, is
*how much* a difference it makes. I.e. exactly how much the performance
degrades if it is absent, and in which scenarios. As I said before, I
don't think anyone has ever actually tried it and produced data...

-Toke

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] adoption call: algorithm drafts

[Toke Høiland-Jørgensen]

Dave Taht dave.t...@gmail.com writes:

 I agree it relies heavily on the codel draft to keep the distinction
 between flow queuing and aqm distinct. If it were to include codel (or
 vice versa), the draft would get rather long.

IMO it would be quite possible to make the description AQM-agnostic; and
I do believe the scheduling mechanism has value in itself. I'll be happy
to present some data on this at the Honolulu meeting if there's interest
in it.

Perhaps a way forward would be to make the main description of the
scheduling mechanism AQM-agnostic, and then have a section describing
interactions with specific AQMs. This would just include CoDel right
now, of course, but would make it possible to, for instance, add in an
fq_pie at a later date...

 We would like feedback right now on adopting:
 1 - http://tools.ietf.org/html/draft-pan-aqm-pie-01 and
 2 - http://tools.ietf.org/html/draft-nichols-tsvwg-codel-02
 towards the charter milestone for submitting algorithm
 specifications to the IESG.  Whether they are Proposed Standard
 or Experimental can be debated now or later, but we want to
 probe if there's critical mass to adopt them first.

 +1 on both.

+1.

-Toke


signature.asc
Description: PGP signature
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] [Bloat] the side effects of 330ms lag in the real world

[Toke Høiland-Jørgensen]

Jim Gettys j...@freedesktop.org writes:

 Now, if someone gives me real fiber to the home, with a real switch fabric
 upstream, rather than gpon life might be somewhat better (if the switches 
 aren't
 themselves overbuffered But so far, it isn't.

As a data point for this, I have fibre to my apartment building and
ethernet into the apartment. I get .5 ms to my upstream gateway and
about 6 ms to Google. Still measured up to ~20 ms of bufferbloat while
running at 100 Mbps...

http://files.toke.dk/bufferbloat/data/karlstad/cdf_comparison.png

However, as that graph shows, it is quite possible to completely avoid
bufferbloat by deploying the right shaping. And in that case fibre
*does* have a significant latency advantage. The best latency I've seen
to the upstream gateway on DSL has been ~12 ms.

-Toke


signature.asc
Description: PGP signature
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] [AQM Evaluation Guidelines]

[Toke Høiland-Jørgensen]

Nicolas KUHN nicolas.k...@telecom-bretagne.eu writes:

 and realistic HTTP web traffic (repeated download of 700kB). As a reminder,
 please find here the comments of Shahid Akhtar regarding these values:

The Cablelabs work doesn't specify web traffic as simply repeated
downloads of 700KB, though. Quoting from [0], the actual wording is:

 Webs indicates the number of simultaneous web users (repeated
 downloads of a 700 kB page as described in Appendix A of [White]),

Where [White] refers to [1] which states (in the Appendix):

 The file sizes are generated via a log-normal distribution, such that
 the log10 of file size is drawn from a normal distribution with mean =
 3.34 and standard deviation = 0.84. The file sizes (yi) are calculated
 from the resulting 100 draws (xi ) using the following formula, in
 order to produce a set of 100 files whose total size =~ 600 kB (614400
 B):

And in the main text it specifies (in section 3.2.3) the actual model
for the web traffic used:

 Model single user web page download as follows:

 - Web page modeled as single HTML page + 100 objects spread evenly
 across 4 servers. Web object sizes are currently fixed at 25 kB each,
 whereas the initial HTML page is 100 kB. Appendix A provides an
 alternative page model that may be explored in future work.
 
 - Server RTTs set as follows (20 ms, 30 ms, 50 ms, 100 ms).
 
 - Initial HTTP GET to retrieve a moderately sized object (100 kB HTML
 page) from server 1.
 
 - Once initial HTTP GET completes, initiate 24 simultaneous HTTP GETs
 (via separate TCP connections), 6 connections each to 4 different
 server nodes
 
 - Once each individual HTTP GET completes, initiate a subsequent GET
 to the same server, until 25 objects have been retrieved from each
 server.


Which is a pretty far cry from just saying repeated downloads of 700
KB and, while still somewhat bigger, matches the numbers from Google
better in terms of distribution between page sizes and other objects.
And, more importantly, it features the kind of parallelism and
interactions that a real web browser does; which, as Shahid mentioned is
(can be) quite important for the treatment it receives by an AQM.

As such I would be strongly in favour of changing the draft to actually
describe realistic web client behaviour, rather than just summarising it
as repeated downloads of 700KB.


-Toke


[0] 
http://www.cablelabs.com/wp-content/uploads/2013/11/Active_Queue_Management_Algorithms_DOCSIS_3_0.pdf

[1] 
http://www.cablelabs.com/downloads/pubs/PreliminaryStudyOfCoDelAQM_DOCSISNetwork.pdf

[2] https://developers.google.com/speed/articles/web-metrics


signature.asc
Description: PGP signature
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

[aqm] Draft on fq_codel submitted

[Toke Høiland-Jørgensen]

Hi everyone

This is to notify you of the availability of a draft explaining the
fq_codel algorithm. It is available from here:
http://datatracker.ietf.org/doc/draft-hoeiland-joergensen-aqm-fq-codel/

Thanks,
-Toke

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

Re: [aqm] [AQM Evaluation Guidelines]

[Toke Høiland-Jørgensen]

Nicolas KUHN nicolas.k...@telecom-bretagne.eu writes:

 I believe the draft must be the most generic the possible. These
 guidelines provide the tools and aspects that must be looked at,
 however the AQM is tested. Even-driven simulations (such as in
 NS-2,OMNET) enable to achieve an economical and fast protocol
 experimentation [http://arxiv.org/pdf/1002.2827.pdf]. These guidelines
 cannot reject a proposal because it has not been tested in the 'real'
 world.

Sure, I'm not saying simulation is not useful. I'm just saying it should
not be the only evaluation of an algorithm.

 I will add in the methodology section something about that issue,
 saying that proposals SHOULD be evaluated in testbeds, and MAY be
 evaluated with event-driven simulations to better understand their
 internal behaviour.

Great. Would add reference implementation available to that. :)

 This is the kind of discussion that should be avoided in the draft.
 Indeed, I am afraid we may open a pandora's box as we do not want to
 list all the issues encountered by any evaluation tool set.

Not all of them perhaps, but the most common, and those that apply
generally across tool sets.

 We may end discussing why choosing emulation, vs simulation, vs
 mathematical model, vs real-workd experiment.

A discussion that is sorely lacking, IMO :)

 ...case where latency is measured by a separate flow (such as a straight
 'ping' alongside the test) vs directly measuring the queueing delay
 of the packets making up the traffic scenario;

 I think that this is more a metric linked to the evaluation tool set.
 If we want the guidelines to be generic and evaluation tool set
 free, this should not be discussed.

My interest here was more to avoid comparing apples to oranges: the two
different kinds of measurements can give widely varying results. As an
example, a strict priority queue would give very good latency for flows
alongside the main elephant, but could completely starve the elephant
itself. Which may be desirable in some cases: but distinguishing between
different types of behaviour is important if we want to compare
different algorithms fairly. And I think it is worth specifying that in
the draft somewhere.

 I am not sure that it makes sense here, that would be another
 pandora's box: the guidelines should not consider every possible TCP
 improvements. Otherwise, others would say do you consider RENO?
 CUBIC? Delay based CC? or what about MultiPath?. We must generic
 and speak generally about TCP and UDP - without much more details.

Well, the draft does mention CUBIC under aggressive senders. But if
you don't want to enumerate all the permutations, some generic language
(along the lines of SHOULD be evaluated against the most commonly seen
TCP variants deployed on the internet (for example, CUBIC, IW4, IW10,
etc).

 Yes I updated the Section Medium bandwidth, medium delay: Wi-Fi so
 that the tester may include small time scales varying bandwidth

Right, better. Still not entirely sure that it is a good representation
of wifi, but I'm not going to argue the point vehemently... :)

 I agree as well - the draft would then need some rewording

 I will add an entry in the glossary explaining that by AQM, the draft
 consider hybrid AQM+scheduling

 I will update the Section (4.4) considering that scheduling is a
 feature of an AQM, and is not introduced on top of it.

Great!

 seems a bit speculative to me. Has the fact that the algorithms'
 activation time is a predictor of adverse side effects actually been
 demonstrated?

 The guidelines just mention that this MAY be destructive and this
 issue should be carefully discussed.

Yeah, I was just puzzled by why specifically one configuration of
activation time interaction is mentioned as potentially problematic,
instead of just saying potentially destructive interactions between AQM
and scheduling should be accounted for or somesuch.

-Toke


signature.asc
Description: PGP signature
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm