great, but not widely supported in
> current hw.
Yes, and that's a policy I can support (as far as it goes). I'd much rather
have, say, 100ms of bloat than 45000ms (which I've previously encountered).
- Jonathan Morton
___
aqm mailing
, and is typically implemented
anyway as part of per-subscriber provisioning.
If tests are carried out, that might be the best scenario to start with.
- Jonathan Morton
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
ounds like the fairly coarsely discrete time intervals in PIE are the main
justification for this particular heuristic, so it might be sufficient to
document that WRT PIE itself. Using finer time intervals is clearly a better
choice for the future.
- Jonathan Morton
_
an interface transmitting as long as there is data in the queue, while
> a non-work-conserving algorithm reduces the effective rate of the interface
> by spacing packets out.
In which case the explanation makes even less sense, as PIE doesn’t include a
shaper.
- Jonathan Morton
___
case, there
is no congestion to signal for. But there really is no need to have any
complex state-switching logic for that. If your underlying algorithm is sound,
it will naturally decay to zero packet drops if the empty-queue condition
persists.
- Jonathan Morton
_
ed in rapid succession.
It could be that the receiver has poor receive-interrupt latency, or that it is
aggregating the reverse send path too heavily. The variable spacing within the
ack burst (in particular, in both examples the gap between first and second is
larger than the rest) favours the former
ackets received. Nothing particularly weird or unusual appears to be
happening in the network.
- Jonathan Morton
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
g them in child qdiscs) when the bucket is empty,
not simply dropping them.
The interaction with AQM-related marking and dropping will be interesting to
read, though. It’s not a-priori obvious how much a shaper-AQM combination
looks like a policer.
-
he “sparse = latency sensitive” heuristic to be a good one in practice,
both in Cake and in fq_codel.
- Jonathan Morton
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
pointless because they don't work at some level (often layer 8 or 9).
Indeed. I’m not aware of any “complete” systems in category 2 - and I don’t
count “data caps” among them, unpopular though they are.
- Jonathan Morton
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
with drop
probabilities for that), but it *does* work acceptably well with multiple flows
sharing a queue, due to this operating-point search.
- Jonathan Morton
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
t_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:
he action
of WFQ to equalise capacity per flow, and the off-peak scenario where each flow
is bottlenecked at the CVLANs? I don’t see it.
- Jonathan Morton
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
se) flow-dissection
mechanism which accounts for these factors and yields a straightforward hash
value. Perhaps a document dedicated to discussing this problem would be
valuable, if it doesn’t already exist (and if it does, it should be referenced).
- Jonathan Morton
___
th that self-tuning, Cake works usably well down to 64Kbps. At that level,
typical modern TCPs (especially CUBIC) saturate the link continuously from the
outset, so Codel ends up constantly signalling them to slow down. With ECN on,
this is harmless.
- Jonathan Morton
_codel. I’ve just finished adding “triple
isolation” to it, and I plan to make it the default in the near future, unless
someone turns up a major problem.
- Jonathan Morton
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
d unresponsive flows do not share the same buffer. When the
buffer limit is reached, only the longest queue is culled, and this will be the
unresponsive flow.
- Jonathan Morton
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
ng the feasibility of adding ECN to uTP (ie. BitTorrent). The code
looks horrid, but what raw sockets code doesn’t?
- Jonathan Morton
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
a heuristic) latency-sensitive packets do tend to be small. That’s what I was
pointing out.
- Jonathan Morton
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
his
required special handling - it just falls out of a well-engineered,
protocol-agnostic AQM scheme.
The important point, however, is that Cake *only* performs ack thinning when
the link is congested. If there’s sufficient bandwidth to send all the acks,
it sends them all.
- Jonathan Morton
.
- Jonathan Morton
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
nd-user, until the lost packet is
retransmitted and actually arrives. Hence the addition of two MAC grant delays
(60ms?) may make the difference between an imperceptible problem and a
noticeable one.
- Jonathan Morton
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
is to bias interval according to how
quickly the queue is growing, so as to react more aggressively to slow-start’s
rapid growth than to congestion-avoidance slow growth. It might be worth
testing in a standalone context.
- Jonathan Morton
___
aqm
interval. This also places the fastest possible trigger at about a
third of the nominal interval.
- Jonathan Morton
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
; with a properly functioning AQM,
the effects of an oversized raw queue are nil.
- Jonathan Morton
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
The version of codel that cake uses does indeed use such a lookup table for
1..15. This was for accuracy rather than performance reasons.
- Jonathan Morton
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
is not
fatal. This, I think, is a natural use of the remaining codepoint.
At some point, I’ll get around to writing it up more formally.
- Jonathan Morton
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
I don't know what a surprisingly high number of collisions is...
Surprising to people unfamiliar with the birthday paradox, perhaps. The set
associative hash produces results that are much more intuitively reasonable.
- Jonathan Morton
___
aqm mailing
be beneficial for readability. I haven’t got
around to doing it yet.
- Jonathan Morton
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
for each flow, and unresponsive flows are
isolated.
- Jonathan Morton
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
be interval=1ms and target=50us. If you re-run your analysis
using those parameters, do you get more reasonable behaviour? Intuitively, I
think you should get similar per-packet behaviour at 100G using those
parameters, as at 1G using the defaults.
- Jonathan Morton
My favourite part of that is disabling TSO leads to a doubling in
throughput. In precisely the sort of situation that TSO was intended to
help throughput.
- Jonathan Morton
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
traffic classes.
*/
It’s a mess, isn’t it?
- Jonathan Morton
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
is resolved
satisfactorily.
- Jonathan Morton
___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
and voice classes applies only up to given shares of the
overall bandwidth. If traffic in those classes exceeds that allocated share,
deprioritisation occurs. This ensures that improperly marked traffic cannot
starve the link, and attempts to incentivise correct marking.
- Jonathan Morton
35 matches
Mail list logo
