Re: [aqm] I-D Action: draft-ietf-aqm-recommendation-04.txt
On 5/8/2015 11:42 PM, Simon Barber wrote: I have a couple of concerns with the recommendations of this document as they stand. Firstly - implementing AQM widely will reduce or even possibly completely remove the ability to use delay based congestion control in order to provide a low priority or background service. I think there should be a recommendation that if you are implementing AQM then you should also implement a low priority service using DSCP, e.g. CS1. This will enable these low priority applications to continue to work in an environment where AQM is increasingly deployed. Unlike DSCPs that give higher priority access to the network, a background or low priority DSCP is not going to be gamed to get better service! Secondly, there is a recommendation that AQM be implemented both within classes of service, and across all classes of service. This does not make sense. If you are implementing AQM across multiple classes of service, then you are making marks or drops while ignoring what class the data belongs to. This destroys the very unfairness that you wanted to achieve by implementing the classes in the first place. Hi Simon, thanks for your comments. These comments appear to be in response to version -04 of the document, from around 1 year ago. The document is currently on version -11, has past working group last call and IESG evaluation, and is in the RFC Editor's queue. I mention this, because it isn't clear to me how applicable your comments are with regard to the current copy. The current copy can be found at: https://datatracker.ietf.org/doc/draft-ietf-aqm-recommendation/ The current revision does mention the impact to delay-based end-host algorithms as an area for future research. While I agree that in a lot of cases it seems like logically a good idea to have a DiffServ configuration like you mention, I don't think we have seen data on this yet in the working group. Looking into this could be part of that mentioned future work, though not something I'd want to see hacked into this document today, so late in its publication process. -- Wes Eddy MTI Systems ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
Re: [aqm] draft-ietf-aqm-pie-01: review
Greg, At 23:44 12/05/2015, Greg White wrote: Bob, I haven't had a chance to fully read your review (though what I've read looks to be insightful), but there was one comment in the email thread that compelled me to respond. You wrote: There really is no point in employing control theory experts to work out the stability limits for how fast a control algorithm can respond, if implementers then add in extra arbitrary limits on the responsiveness like this. I would personally truncate/modify that statement to something more like: There really is no point in employing control theory experts to work out the stability limits for how fast an AQM control algorithm can respond. :) I disagree in this respect: the control theory analysis gave the designer of the algorithm (Rong) a feel for what autotuning would be needed, to keep it far enough away from instability (given the idealised assumptions, i.e. only TCP Reno etc.) That's the whole point of a gain and phase /margin/. Not gospel, but a better insight into how much 'margin of error' there is under idealised conditions that are something close to those expected to be common. My comment was in response to discovering an arbitrary limit had been added to the Linux implementation: Limit the change in p per T_UPDATE to 2%. The whole point of the rest of the PIE algorithm is to automatically limit how rapidly p changes, by steering a mid-course far enough away from two cliffs known to be out there somewhere (probably not where the theory says they are, but at least it gives a feel). So to write in a hard-coded limit that completely overrides all the autotuning is IMO just plain ignorant (I'll eat my words if someone like Rong wrote that code!). It will make PIE unnecessarily sluggish when conditions are changing fast and the rest of the code has judged that it will be quite safe to react fast. And, I should add here that 'safe' only means 'unlikely to harm utilisation'. Even if PIE becomes unstable, the oscillations only hurt utilisation. It's not like we're dealing with nitroglycerin or something. No. Actually, I will push back harder. This community needs skilled mathmaticians, skilled designers, skilled evangelists and skilled implementers. And we all need humility, to listen carefully to the others. And yes, agreed, we also need to be wary that someone who sounds like an expert could be pushing inapplicable theory. Real networks aren't LTI systems, and I actually think it is disingenuous to present classical control theoretical analyses of AQMs that are intended to be deployed in real networks. PIE borrows from classical control theory, and that is fine, but I think that is about as far as one should take it. I'm not sure what you're saying. How can it be fine, but not be taken? I found reading the stability analysis in the HPSR paper on PIE useful for understanding how to improve PIE autotuning over a wide range. I think you're criticism assumes the analysis is trying to claim something about the solution. Whereas I saw it as providing insight for those who designed it, and for those wanting to understand (and improve) the design. As long as you know how much weight to give such analysis and what it's limits are, it is much much better than the Dilbert rule of thumb: 87% of made up numbers are better than those derived from analysis. I assume whoever wrote that 2% limit in the Linux code must live by Dilbertisms like this. To me PIE has always seemed like a steampunk AQM in that there are a lot of knobs, gears and wires that make it look arcane. All of those knobs/gears/wires were added for a reason, and they do make for a system that works well* in comparative testing. But, is all of the algorithmic complexity needed? Maybe not. And when you read my review (pls do) you will get a feel for my assessment of PIE: it looks to me like the implementation (by which I mean the pseudocode on which other implementations are based) has failed to realise the intent of the design. In places this is because there are still holes in the design, and the implementation has made a mess of filling them. But it's often because the implementation has introduced a lot of bad practices (e.g. abitrary constants). Most importantly, too little deep thought and care has gone into the pseudocode. Is there a more streamlined version that would work equally well (or better)? Probably. We are nearly finished testing a very simple AQM that doesn't use any of theose steampunk PI controls. But only having understood the control stuff could we build up the confidence and intuition to understand where it's probably not necessary. It's aimed at cost-reduction more than perfection for very large numbers of low stat-mux queues within a larger scheduling hierarchy. Not really your scenario (cable modems), but it's possible it could be retargeted at residential gateways and be as good as PIE, or
Re: [aqm] draft-ietf-aqm-pie-01: review
Bob,
I haven't had a chance to fully read your review (though what I've read
looks to be insightful), but there was one comment in the email thread
that compelled me to respond.
You wrote: There really is no point in employing control
theory experts to work out the stability limits
for how fast a control algorithm can respond, if
implementers then add in extra arbitrary limits
on the responsiveness like this.
I would personally truncate/modify that statement to something more like:
There really is no point in employing control theory experts to work out
the stability limits for how fast an AQM control algorithm can respond. :)
Real networks aren't LTI systems, and I actually think it is disingenuous
to present classical control theoretical analyses of AQMs that are
intended to be deployed in real networks. PIE borrows from classical
control theory, and that is fine, but I think that is about as far as one
should take it.
To me PIE has always seemed like a steampunk AQM in that there are a lot
of knobs, gears and wires that make it look arcane. All of those
knobs/gears/wires were added for a reason, and they do make for a system
that works well* in comparative testing. But, is all of the algorithmic
complexity needed? Maybe not. Is there a more streamlined version that
would work equally well (or better)? Probably. One of the most
compelling arguments in favor of PIE for the cable industry was that
nearly all of the control-law functions could be done in CPU as opposed to
being burned into gates (in a cost-constained high-performance mass-market
chip). So, it is relatively easy to make changes if further studies point
out improvements that can be made. I'm happy that it is getting another
set of smart eyes looking at it and suggesting improvements. I would be
especially pleased if we could show equivalent or better performance
across a broader range of scenarios with a simplified algorithm.
*works well when integrated with the DOCSIS MAC layer, in simulation.
We'll have real equipment at some point to do validation testing with.
Note, some of the comments in your review are arising from a few
errors/omissions in the pseudocode that were pointed out by others and
that Rong will have fixed in the next draft (e.g. status_update() runs
every 16ms regardless of packet arrivals, the T_UPDATE check was probably
not the best way to explain this. In DOCSIS the updates are suppressed
when in sleep mode, and resume with initialized state upon exit from
sleep). But in my view many of the others look like good suggestions that
would warrant further study.
Your comment on queue sampling comes close to one of my lingering mental
issues with PIE. CoDel's insight was that it isn't the current queue
latency (or moving average queue latency) that matters as much as the
minimum queue latency over a recent window. PIE doesn't take advantage of
this insight. (CoDel, however, misses that it probably does matter how
big that minimum queue latency is and how fast it is growing/shrinking).
-Greg
On 5/9/15, 11:13 AM, Bob Briscoe bob.bris...@bt.com wrote:
Dave,
At 00:51 09/05/2015, Dave Taht wrote:
Dear Bob:
I now understand the linux codebase for pie a lot better, as well as
some of the experimental data I have. It looks like I could make
several of the changes you describe and put them in my next series of
tests, and based on your parameters I should be able to exercise some
edge cases across those changes. Wow, thx!
I'd like to allow the authors a chance to think
and respond before anyone does any changes to
implementations - they may have their reasons that I didn't understand.
I have not actually read the latest pie draft, but would like to make
a few comments on your comments quickly:
re: 3.1: in linux, params-ecn is presently a boolean, and could
easily be modified to mean anything and compare anything you want.
What would be a good default?
The ECN support in the linux code on enqueue looks like:
if (!drop_early(sch, skb-len)) {
enqueue = true;
} else if (q-params.ecn (q-vars.prob = MAX_PROB / 10)
INET_ECN_set_ce(skb)) {
/* If packet is ecn capable, mark it if drop probability
* is lower than 10%, else drop it.
*/
Next mail I'll send an email I sent to Fred offlist on this subject.
Re: 5.0: will look over that code
My review didn't have a section 5.0
:?
re: 5.1, linux code:
/* Non-linear drop in probability: Reduce drop probability
quickly if
* delay is 0 for 2 consecutive Tupdate periods.
*/
if ((qdelay == 0) (qdelay_old == 0) update_prob)
q-vars.prob = (q-vars.prob * 98) / 100;
Ooh joy. The great thing about open source is
that it allows everyone to assert their human
right to add their own made-up numbers.
http://dilbert.com/strip/2008-05-08
Looking at the Linux code, I just found
Re: [aqm] I-D Action: draft-ietf-aqm-recommendation-04.txt
Hi Wesley, Thanks for considering my comments, and apologies for being so late in the process - I've only recently been able to put time into this area, and I understand it may be too late in the process to hack things in. I replied to John with where I'm concerned with the current -11 text. Re: background / low priority streams. There are other ways to achieve a 'lower priority', such as changing the AIMD parameters. Does not help if FQ is involved though. My concern is that implementing AQM removes a capability from the network, so doing so without providing a mechanism to support low priority is a negative for certain applications (backups, updates - and the impact these have on other applications). Would be good for this to be at least common knowledge. Is there any other document this could go in? Simon On 5/12/2015 5:11 PM, Wesley Eddy wrote: On 5/8/2015 11:42 PM, Simon Barber wrote: I have a couple of concerns with the recommendations of this document as they stand. Firstly - implementing AQM widely will reduce or even possibly completely remove the ability to use delay based congestion control in order to provide a low priority or background service. I think there should be a recommendation that if you are implementing AQM then you should also implement a low priority service using DSCP, e.g. CS1. This will enable these low priority applications to continue to work in an environment where AQM is increasingly deployed. Unlike DSCPs that give higher priority access to the network, a background or low priority DSCP is not going to be gamed to get better service! Secondly, there is a recommendation that AQM be implemented both within classes of service, and across all classes of service. This does not make sense. If you are implementing AQM across multiple classes of service, then you are making marks or drops while ignoring what class the data belongs to. This destroys the very unfairness that you wanted to achieve by implementing the classes in the first place. Hi Simon, thanks for your comments. These comments appear to be in response to version -04 of the document, from around 1 year ago. The document is currently on version -11, has past working group last call and IESG evaluation, and is in the RFC Editor's queue. I mention this, because it isn't clear to me how applicable your comments are with regard to the current copy. The current copy can be found at: https://datatracker.ietf.org/doc/draft-ietf-aqm-recommendation/ The current revision does mention the impact to delay-based end-host algorithms as an area for future research. While I agree that in a lot of cases it seems like logically a good idea to have a DiffServ configuration like you mention, I don't think we have seen data on this yet in the working group. Looking into this could be part of that mentioned future work, though not something I'd want to see hacked into this document today, so late in its publication process. ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
Re: [aqm] I-D Action: draft-ietf-aqm-recommendation-04.txt
Hi John, Where would be the best place to see if it would be possible to get agreement on a global low priority DSCP? In the latest draft: https://tools.ietf.org/html/draft-ietf-aqm-recommendation-11 Top of page 16, line 3 it says AQM should be applied across the classes or flows as well as within each class or flow It does also say AQM mechanisms need to allow combination with other mechanisms, such as scheduling, to allow implementation of policies for providing fairness between different flows. But I'm still not happy with the statement that AQM should be applied 'across the classes'. Simon On 5/9/2015 6:58 PM, John Leslie wrote: Simon Barber si...@superduper.net wrote: I have a couple of concerns with the recommendations of this document as they stand. Firstly - implementing AQM widely will reduce or even possibly completely remove the ability to use delay based congestion control in order to provide a low priority or background service. I agree that if AQM succeeds in reducing delay, that will reduce the delay variation that low priority services depend upon. However, that strikes me a a problem that delay-based congestion- control services will have to deal with regardless of AQM. Wouldn't we be better off to figure out how AQMs could signal what these delay-based services actually care about? I think there should be a recommendation that if you are implementing AQM then you should also implement a low priority service using DSCP, e.g. CS1. I don't follow how that could help in practice, except for the case where the AQM is implemented _very_ near the sender. (DSCP gets lost pretty quickly at Autonomous System boundaries.) This will enable these low priority applications to continue to work in an environment where AQM is increasingly deployed. Unlike DSCPs that give higher priority access to the network, a background or low priority DSCP is not going to be gamed to get better service! (I wish I believed we could get agreement to do this!) Secondly, there is a recommendation that AQM be implemented both within classes of service, and across all classes of service. I'm not finding this in the document: Quality of Service is found in Section 2.1; but that's not class of service. Traffic class is found in Sections 2.1 and 4.4, neither of which mentions across all classes. ??? This does not make sense. Agreed. If you are implementing AQM across multiple classes of service, then you are making marks or drops while ignoring what class the data belongs to. Alas, that doesn't make sense either. :^( This destroys the very unfairness that you wanted to achieve by implementing the classes in the first place. That's a funny way to phrase it... -- John Leslie j...@jlc.net ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
Re: [aqm] I-D Action: draft-ietf-aqm-recommendation-04.txt
On May 12, 2015, at 9:06 PM, Simon Barber si...@superduper.net wrote: Where would be the best place to see if it would be possible to get agreement on a global low priority DSCP? I’d suggest https://tools.ietf.org/html/rfc4594 4594 Configuration Guidelines for DiffServ Service Classes. J. Babiarz, K. Chan, F. Baker. August 2006. (Format: TXT=144044 bytes) (Updated by RFC5865) (Status: INFORMATIONAL) It refers to [QBSS] QBone Scavenger Service (QBSS) Definition, Internet2 Technical Report Proposed Service Definition, March 2001. (http://mgoutell.free.fr/gridftp/QBSS/qbss-definition.txt) and states that Within QBone, traffic marked with DSCP 001000 (binary) shall be considered in the QBSS class and should be given the service described in this document. Notice that while DSCP values generally have only local significance we are assigning global significance to this particular codepoint within QBone. We refer to packets marked with DSCP 001000 as being marked with the QBSS code point”. That’s where we came up with recommending CS1 (001000) for the traffic class. I’m pretty sure the latter ultimately resulted in an RFC, but for some reason I’m not finding it. The closest thing I see is https://tools.ietf.org/html/rfc6297 6297 A Survey of Lower-than-Best-Effort Transport Protocols. M. Welzl, D. Ros. June 2011. (Format: TXT=46532 bytes) (Status: INFORMATIONAL) signature.asc Description: Message signed with OpenPGP using GPGMail ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
