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 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.
*/
....
Re: 5.0: will look over that code
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;
re: 5.2: strongly agree that the lookup table doesn't scale properly.
The linux code appears to differ from the draft also, here, with a
smaller lookup table, and some other smoothing functions. I am going
to stop pasting now and just point at:
https://github.com/torvalds/linux/blob/master/net/sched/sch_pie.c#L334
Will await more feedback from y'all on that.
Codel also has a similar undershoot problem for which I proposed we
try a fixed point fractional count variable in a recent post to the
cake mailing list.
re: 5.3.1: In the environments i work in it is extremely hard to get
timers to reliably fire in under 2ms intervals, particularly on vm'd
systems. Also as you fire the timer more rapidly the current
calculations in pie now done out of band of the packet processing have
a couple divides in them which tend to be processor intensive... both
things said, i figure this and other implementations could fire faster
than the default 16ms...
re: 5.3.2: I like what you are saying but I gotta go work it out for
myself. which will take a while. patches wanted.
re: 5.4: linux and all my tests have always been against:
/* default of 100 ms in pschedtime */
vars->burst_time = PSCHED_NS2TICKS(100 * NSEC_PER_MSEC);
5.5: explains a lot. Probably. Will think on it.
5.6: :chortle: heats_this_room() indeed! Derandomization always looked
to me like an overly complex solution to a non-problem.
5.7: don't think this problem exists in the linux code but will step through.
But: in one of my recent (450 rrul_50_up tcp flows) tests neither
codel or pie got to a sane drop rate in under 60 seconds, and pie
stayed stuck at 10000 packets outstanding, i did not try more - on
gigE local links. I think a lot of pie tests were run by others with a
very low outside packet limit (200 packets) and thus the tail drop
kicked in before pie itself could react.
5.8: I think this is a quibblish change not relevant for any
reasonable length of queue measured in packets.
but I do note that we switched from packet limits to byte limits in
cake but that was for other reasons - primarily due to the extreme
(1000x1) dynamic range of a modern "packet".
6: I do wish the draft and the code I have still lined up, and the
constants clearly defined.
7: exp(p) is not cheap, and there aint no floating point in the kernel either.
8. Haven't read the draft, can't comment on the nits.
One quick note on:
"4.1 Random Dropping s/Like any state-of-the-art AQM scheme, PIE would
drop packets randomly/ /PIE drops packets randomly/ Rationale: The
other scheme with a claim to be state-of-the-art doesn’t (CoDel). I
would agree if the draft had said “A state of the art scheme should
introduce randomness into packet dropping in order to desynchronize
flows,” but maybe it was decided not to introduce such underhand
criticism of CoDel. Whatever, the draft needs to be careful about
evangelising random drop, given it attempts to derandomize later."
I don't buy the gospel that randomness is needed to avoid tcp global
synchronization. I would prefer that whatever evangelicalization of
randomness exists in any draft here or elsewhere be dropped in favor
always of discussing the real problem of tcp global sync instead...
... which as near as I can tell both codel and fq_codel avoid just
fine without inducing a random number generator. I welcome evidence to
the contrary.
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
