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

[Klatsky, Carl]

> On 7 Jul, 2016, at 15:34, Michael Menth  wrote:
> 
>> Based on our evaluations, with pure CoDel (without FQ-CoDel), 
>> "reentering" is actually a common case. I think Dave and Toke should 
>> have more experimental results to answer this question. (I included 
>> Dave in CC)
> 
> We also studied this issue about one or two years ago. The algorithm 
> controlling the reentering of the dropping mode may have a significant 
> impact on control variables, drop rates, drop pattern depending on the 
> traffic. It can also impact utilization. Most interesting is probably 
> Fig. 6 on page 7 in 
> https://atlas.informatik.uni-tuebingen.de/~menth/papers/Menth16e.pdf

That’s a very interesting paper for Codel enthusiasts.  IMHO, Codel-ACT 
performs much better on the important metrics than plain Codel, especially when 
faced with multiplexed flows.

[CK] I am familiar with CoDel and FQ-CoDel, but what is CoDel-ACT?

I had also noticed the potential for Codel’s count to increase unboundedly 
while working on Cake; in fact when implemented as a 16-bit counter, it would 
wrap around on certain workloads, causing apparently chaotic behaviour.  I 
therefore modified the variant of Codel that Cake used to *halve* the count on 
re-entry, a much more aggressive reduction than Codel-ACT uses, as well as 
using a saturating increment to prevent wraparound.  However, I kept the basic 
behaviour of waiting a full interval before re-entry.

More recently, I have changed Cake over to use COBALT, which is a combination 
of Codel and BLUE; Codel is intended to handle responsive flows which behave in 
a TCP-like manner, and BLUE to take over if the flow proves to be unresponsive 
(by running into the queue length limit).

COBALT uses a re-implemented version of Codel with a much simplified main loop. 
 It also has a novel re-entry behaviour: the count is reduced while the queue 
length is below target by running the algorithm in reverse, without marking or 
dropping.  This means that very short non-dropping periods result in a slight 
reduction in count, and longer periods result in a larger reduction; the 
reduction also occurs faster when count is high.

With your paper in mind, I may also change it to use the shorter re-entry delay 
of Codel-ACT, as you explain very clearly how it may be beneficial, and this 
shows in the graphs as a lower peak delay and a reduction in loss 
synchronisation between flows.  I also think it will allow Codel to adapt more 
cleanly to RTTs significantly shorter than it is configured for - this is 
important where the defaults are set for internet-scale traffic, and people 
unthinkingly rely on those defaults in a LAN environment.

Here is the relevant part of COBALT’s Codel implementation, showing the 
re-entry count reduction strategy:

if(next_due && vars->dropping) {
/* Use ECN mark if possible, otherwise drop */
drop = !(vars->ecn_marked = INET_ECN_set_ce(skb));

vars->count++;
if(!vars->count)
vars->count--;
cobalt_invsqrt(vars);
vars->drop_next = cobalt_control_law(vars->drop_next, p->interval, 
vars->rec_inv_sqrt); } else {
while(next_due) {
vars->count--;
cobalt_invsqrt(vars);
vars->drop_next = cobalt_control_law(vars->drop_next, 
p->interval, vars->rec_inv_sqrt);
schedule = now - vars->drop_next;
next_due = vars->count && schedule >= 0;
}
}

The full code can be found here:
https://github.com/dtaht/sch_cake/blob/master/cobalt.c

 - Jonathan Morton

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

Re: [aqm] status of PIE drafts WGLC

[Klatsky, Carl]

Wes,

If the 'algorithm' drafts (CoDel, FQ-CoDel, and PIE) are targeted as 
Experimental, does that mean at some time later their status moves onto either 
PS (if real-world testing & use pans out) or Informational (if no activity 
further proves it out but the authors want to keep the info out there for the 
community)?  If so, how does that occur of the WG closes down?

Regards,

Carl Klatsky
Comcast
215-286-8256


-Original Message-
From: aqm [mailto:aqm-boun...@ietf.org] On Behalf Of Wesley Eddy
Sent: Wednesday, February 10, 2016 2:27 PM
To: aqm@ietf.org
Subject: Re: [aqm] status of PIE drafts WGLC

On 1/22/2016 10:01 AM, Wesley Eddy wrote:
> Hello; the working group last call on the PIE drafts generated some 
> emails, but I don't think I've seen any response from the editors.
> Specifically, there were a couple of emails with algorithm description 
> questoins and technical comments from Rasool Al-Saadi and Ilpo 
> Jarvinen, both with specific points that should be addressed.
>
> For the most part, as I understand the comments, these are things that 
> can be relatively simply fixed up or the intent clarified, and not 
> catastrophic issues that would prevent the PIE docs from being 
> publishable.  Please correct me if I misunderstand though.
>
> If the editors can respond and work up a revision that addresses the 
> comments to the satisfaction of Rasool and Ilpo, I'd like to keep the 
> PIE documents moving forward.
>


To be clear also, I think at this stage, the feedback received from the working 
group isn't supporting Proposed Standard, and that the next 
update should be targeted "Experimental".   I can mark it that way in 
the datatracker, but can't edit the document header myself, and these need to 
be consistent before going to the IESG.

I've heard a couple other people seem to agree with going Experimental for the 
CoDel, FQ-CoDel, and PIE drafts and getting all three into the RFC Editor's 
hands sooner rather than later. (DOCSIS-PIE will be
Informational.)  I've not yet heard folks saying that they really need a PS now 
and that PIE should be a PS now.

Definitely shout and correct me here if I'm wrong here, but I think this is the 
fastest path forward.




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

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

Re: [aqm] I-D Action: draft-ietf-aqm-eval-guidelines-09.txt

[Klatsky, Carl]

Wes and all,

My comment is in regard to Polina's comment "The WG currently has two AQMs 
(dropping/marking policy) in last call. Did someone evaluate these AQMs 
according to the specified guidelines?".  As I read over 
draft-ietf-aqm-eval-guidelines, I did not think the objective of this memo was 
to arrive at consensus to select one specific AQM.  I thought the objective was 
to publish guidelines for implementers & service providers on how they can 
select an AQM that is best for their environment.  And further that both AQMs 
in last call would complete the process as valid AQMs for implementers & 
service providers as available to use in their environment, with the guidelines 
helping them to decide which is best for them.  Some may chose PIE, some may 
chose FQ_CODEL.  And possibly other future AQMs would go through the IETF 
process for publication, and that would be an additional option for 
implementers & service providers to evaluate according to the guidelines as 
best for their environment.

Is my understand of draft-ietf-aqm-eval-guidelines correct?

Regards,

Carl Klatsky
Comcast

From: aqm [mailto:aqm-boun...@ietf.org] On Behalf Of Wesley Eddy
Sent: Friday, January 22, 2016 9:51 AM
To: aqm@ietf.org; Polina Goltsman
Subject: Re: [aqm] I-D Action: draft-ietf-aqm-eval-guidelines-09.txt

On 12/7/2015 7:32 AM, Polina Goltsman wrote:


In the abstract, the document says that it describes characterization 
guidelines for an AQM proposal, to decide whether it should be adopted by the 
AQM WG. The WG currently has two AQMs (dropping/marking policy) in last call. 
Did someone evaluate these AQMs according to the specified guidelines?


In my opinion, for "standardization" it would be good to have crisp guidelines. 
 For simply publishing RFCs that are experimental (not standardized), it is 
much less important.




Moreover, it seems to me that the WG is about to conclude. What exactly is the 
purpose of standardizing this document then ?


It's definitely true that the activity level has been low, and so we're trying 
to wrap up the outstanding work items before it flattens completely.  This 
document is not proposed for standards track, only "Informational".  The 
current goal as I see it (with co-chair hat on) is to see if we have rough 
consensus that this is a useful contribution to the community going forward, 
and that any small issues can be addressed.

As I understood your review (please correct if I'm wrong), a main issue you see 
is that there isn't specific guidance about numeric values or ranges to use in 
evaluations?  Nicolas explained why this might be a bit difficult to do in 
general (and specific values published in 2016 may be moot by 2018), so as I 
understand, one of the limitations of this document is that it is only going to 
be able to provide general descriptive guidance in terms of what kinds of tests 
to run, and what types of things to look for, but not prescriptive values and 
conditions to be met.  Do you think that's okay, even though it's probably less 
directly useful than if there were specific values?

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