Is the cwnd also oscillating wildly or is it just an artefact of the visible
part of the queue only being a fraction of the real queue?
Are ACK packets being aggregated by wireless? That would be a good explanation
for large bursts that flood the buffer, if the rwnd opens a lot suddenly. This
w
My impression is that ECN ignorant flows do exist, because of stupid routers
rather than malice, and that Dave considers this a problem worth tackling in
codel.
However I would disagree that the problem needs tackling here, at least for
fq_codel which already segregates non-responsive flows fr
e single 10GE link to each
floor, rather than the fileserver's own NICs.
That's all theoretical, of course - I've never built a datacentre network so I
don't know how it's done in practice.
- Jonathan Morton
___
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
I think that in most cases, a long RTT flow and a short RTT flow on the same
interface means that the long RTT flow isn't bottlenecked here, and therefore
won't ever build up a significant queue - and that means you would want to
track over the shorter interval. Is that a reasonable assumption?
It may be worth noting that fq-codel is not stochastic in it's fairness
mechanism. SFQ suffers from the birthday effect because it hashes packets
into buffers, which is what makes it stochastic.
- Jonathan Morton
On Nov 28, 2012 6:02 PM, "Paul E. McKenney"
wrote:
> Dave ga
s not enough to run even a relatively
simple algorithm like codel.
Dedicated logic that *is* fast enough to run the algorithm on each packet
shouldn't be any bigger than such a CPU.
- Jonathan Morton
On Dec 20, 2012 10:17 AM, "Hal Murray" wrote:
>
> If I was going to do some
Is the bottleneck actually at your router, or (as is more usual) at the
modem?
- Jonathan Morton
On Dec 20, 2012 7:57 PM, "Alessandro Bolletta"
wrote:
> Hi everybody,
> Today i made some tests on my tplink home router powered by the lastest
> snapshot build of Openwrt.
>
On 1 May, 2013, at 11:26 pm, Simon Barber wrote:
> Interesting to note that sfq-codel's reaction to a non conforming flow is of
> course to start dropping more aggressively to make it conform, leading to the
> high loss rates for whatever is hashed together with a VoIP flow that does
> not red
tion, the necessary information should be available at that point. I am
reminded of the way Azureus adjusts global bandwidth limits - both incoming and
outgoing - to match reality, based on both periodic and continuous measurements.
- Jonathan Morton
___
eue containing the VoIP flow is the fullest queue, not the emptiest. That's
independent of the number of flow queues, including the infinite case. Think
about it carefully.
- Jonathan Morton
___
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
ey are to actually
turn it on.
- Jonathan Morton
___
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
dd dev $IFACE parent 1:1 handle 10: fq_codel
That works perfectly well if $RATE is less than line rate, even without BQL.
- Jonathan Morton
___
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
carries such
> big frames.
If it is really 1550 bytes, then that's barely bigger than a standard Ethernet
frame of 1500 bytes. No special adjustment could possibly be needed for that,
beyond standard debloating techniques.
- Jonathan Morton
___
retransmitted quickly.
That is the sort of behaviour you should test for when comparing fq_codel and
SFQ. A simple ping test under load is satisfied by both qdiscs.
- Jonathan Morton
___
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
appens?
- Jonathan Morton
___
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
easier to configure. This makes it much more deployable.
- Jonathan Morton
___
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
some boring papers like "RED in
a different light".
- Jonathan Morton
___
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
To answer that question, simply think about the lifetime of a packet in the
queue. It is enqueued, spends some time waiting there (very little if the
link isn't congested, potentially much more if it is), then is dequeued.
So the difference in time between enqueue and dequeue is...?
- Jon
el.
This relatively simple traffic situation demonstrates that marking on
dequeue rather than enqueue is twice as effective at managing queue length.
- Jonathan Morton
___
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
n the traffic you're testing.
In the forward data flow direction, expect most packets to be at the link
segment size limit, 1500 bytes for Ethernet.
But if you have heterogeneous or bidirectional traffic, this calculation
breaks down. This may simply be one limitation of ns2.
- Jonat
Elementary arithmetic, my dear.
Or, specifically for Codel (rather than drop tail), you could just make it
a big number like 1 to get it out of the way. Codel will generally get
control of the queue back long before that sort of limit is hit.
- Jonathan Morton
The delay to that individual packet's data may be increased, but the queue
length is reduced by triggering TCP's congestion control, reducing the
delay to other packets by (in aggregate) a much larger amount.
And with ECN marking, even the victim packet is not delayed extra.
- Jonat
those fundamental points will make it very difficult for you to
conduct any sort of coherent research into AQM.
- Jonathan Morton
___
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
e they tend not to be the ones using the bulk
of the bandwidth. Conversely, if a single UDP flow was responsible for the
congestion, it would let the other traffic bypass it. This is why fq_codel
is better than just plain codel, if you can get it.
- Jonathan Morton
I rather suspect that this question has already been answered. I recommend
paying special attention to posts on this list by Kathleen Nichols - she
wrote Codel in the first place.
- Jonathan Morton
___
Codel mailing list
Codel@lists.bufferbloat.net
into why such large windows seem desirable to those unaware of AQM,
and why they become mostly irrelevant when good AQM is introduced.
- Jonathan Morton
___
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
fered Ethernet device without BQL.
- Jonathan Morton
___
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
.
However, making progress in these two areas requires the people involved to
have understood the state of the art at a deep level before they can
usefully contribute. It also requires work with real traffic and
environments, or at least simulators considerably more advanced than ns2.
- Jonathan Morton
They mean the same thing, for most practical purposes. However, you could
(when writing your own papers) usefully define latency as the total RTT,
and delay as only the avoidable components of that. The speed of light,
etc, mean that some latency is unavoidable in any communication.
- Jonathan
enough degree, but
we really need something different for wifi - although several of cake’s
components and ideas could be used in such a qdisc.
Roll on cake3.
- Jonathan Morton
___
Codel mailing list
Codel@lists.bufferbloat.net
https
ally for best effort
> and background.
Let’s see how well it works this way. It should be fairly easy to adjust this
aspect of behaviour later on.
- Jonathan Morton
___
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
ink-speed information.
- Jonathan Morton
___
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
fects download as well
at a multiple of the upload effect bandwidth, even if download is not
shaped. The multiple depends on how the receiving host spaces acks.
- Jonathan Morton
___
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/lis
this outer
> limit appropriately, but I don't think mechanisms exist to do that.
It may be feasible to guess an initial value, and refine it based on the
observed throughput when the queue is busy.
- Jonathan Morton
___
Codel mailing list
Codel@l
cake) are a little cleverer than that, even when they hit the
hard limit. They still drop from the head, and they shoot the longest
flow-queue first.
- Jonathan Morton
___
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
r-queue limit is hit, then
by definition that’s the longest queue.)
I should probably re-read the code to be certain of that, though. I’m
currently eyeball-deep in running software updates on half a dozen very
obsolete machines, and cracking the cases on half a dozen routers to see what
em better? is there someone
> willing to work on it that someone could fund?
I might be able to justify rolling that into my tinkering with cake.
- Jonathan Morton
___
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
track sparse flows).
Still lots of little things to do…
- Jonathan Morton
___
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
dds (which an ARM in particular can do extremely
efficiently, but a MIPS isn’t hurt much either) rather than multiplies in the
fast path. There’s a stray multiply in the hash function which I still want to
excise.
It might also be possible, later on, to add a kernel config switch t
gt; udp flood; not that I think a router should work great during a flood/attack,
> but it certainly should not crash…
By the time I read this, I’d already implemented these. :-)
Now to update iproute2 - again - to deal with the new statistics outputs, and I
might be in
drive into saturation.
The kernel patch applies on top of the previous one, but the iproute2 patch
should apply to stock. Note that the current git version of iproute2 seems to
have a problem with displaying the stats from an ingress filter.
- Jonathan Morton
cake3-take7.patch.gz
Descripti
e are more than 8 distinct flows attempting to occupy
queues in the same set. In such a case, the search for an empty queue is
terminated and the packet is placed in the queue matching the plain hash.
NB: so far this code path is completely untested to my knowledge!
- Jonathan Morton
__
fairness and a priority boost to sparse
flows. Recent work has also found a way to significantly reduce the hash
collision problem without imposing much additional overhead, and this has
been incorporated into cake.
- Jonathan Morton
___
Codel mailing list
is why cake uses AQM, FQ *and* Diffserv, all at once.
The linked paper didn’t measure HLC against fq_codel, even though they mention
fq_codel. That’s a major shortcoming.
- Jonathan Morton
___
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
ce of equipment such as a router placed
between them, or the NICs of the two machines themselves.
- Jonathan Morton
___
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
ands every step of
the way; we have work to do.
To guide you in the right direction, let me mention that in RRUL, the heavy
traffic starts at the 5-second mark. Before that, there is only probe traffic.
Now, armed with that knowledge, look at the latency graph and tell u
> On 10 May, 2015, at 06:35, Dave Taht wrote:
>
> On Sat, May 9, 2015 at 12:02 PM, Jonathan Morton
> wrote:
>>> The "right" amount of buffering is *1* packet, all the time (the goal is
>>> nearly 0 latency with 100% utilization). We are quite
If e2e we know we are being FQ´d…
In general, E2E we don’t know what’s in the middle unless we receive notice
about it. Or unless we’re in a lab.
- Jonathan Morton
___
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
> On 11 May, 2015, at 14:34, Jonathan Morton wrote:
>
> I’m also now thinking about how to approximate fairness between ELR flows
> *without* flow isolation. Since ELR would aim to provide a continuous signal
> rather than a stochastic one, this is actually a harder problem th
An updated SSL certificate also seems like a really good idea.
- Jonathan Morton
___
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
sort of decay?
> I.e. a function of how long ago the drop state was exited?
Such things are theoretically possible, but require further thought to
determine how best to do them.
- Jonathan Morton
___
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
ing will not occur by at least 3x (and generally more). Since this
greatly reduces the risk of packet loss, it might actually reduce the average
time that the sender needs to maintain the connection’s buffers, despite the
deliberate 1-RTT delay introduced.
- Jon
about
adjusting that.
- Jonathan Morton
___
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
numbers to be more
confident about adjusting that.
>
>k. What bandwidth?
100/10 Mbit, no added latency, on a LAN.
I should also check what happens when I add a little latency to the mix.
- Jonathan Morton
___
Codel mailing list
Codel@lis
lternatively, codel_dequeue() can be re-structured as two routines…
Certainly a refactoring would be beneficial for readability. I haven’t got
around to doing it yet.
- Jonathan Morton
___
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
t would also be reasonable to scale the backoff with time,
rather than thresholding it.
- Jonathan Morton
___
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
with sojourn times above the limit). Practical qdisc implementations do
have such mechanisms.
Flow isolation helps in such circumstances, especially if the qdisc drops
from the longest queue on enqueue overflow.
- Jonathan Morton
___
Codel mailing list
y/000227.html
>
>
> My question is - are these changes valid for a standalone Codel or are they
> specifically made to optimize Cake's scheduler?
I believe they could be. The intent is to bias interval according to how
quickly the queue is growing, so as to react more agg
target sojourn time) at twice
the nominal interval. This also places the fastest possible trigger at about a
third of the nominal interval.
- Jonathan Morton
___
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
hin Cake, by turning off all of the other fancy features:
tc qdisc change dev eth0 handle 1: cake unlimited raw besteffort
flowblind
This leaves you with no flow-isolation, no Diffserv support, no shaping and no
overhead compensation - just Codel and GSO peeling.
nsive 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
___
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
t 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
___
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
sably 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
___
has an order-of-magnitude effect on the general flow collision rate
once you get into the tens of flows, for very little CPU cost.
- Jonathan Morton
___
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
I hadn’t appreciated, though, that the TXQ struct was station-specific. This
wasn’t obvious from the code fragments posted, so it looked like packets that
incurred hash collisions would be dumped into a single overflow queue.
- Jonathan Morton
___
Cod
e flow won’t care either way, but a responsive one will.
- Jonathan Morton
___
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
ol is increasingly used
in game updater-launchers, too.
- Jonathan Morton
___
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
sive, but on an
order-magnitude longer timescale than may have been configured as optimum.
The real problem is that fq_codel_drop() performs the same (excessive) amount
of work to cope with a single unresponsive flow as it would for a true DDoS.
Optimising the search function is sufficient.
p. That’s a straightforward optimisation which
covers the case in question here, and has no effect on the fast path.
- Jonathan Morton
___
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
is almost the same than having no queue at all)
This, while theoretically important in extreme cases with very large numbers of
flows, is not relevant to the specific test in question.
- Jonathan Morton
___
Codel mailing list
Codel@list
” protocol number. This
has the distinct advantages of keeping related fragments together, and ensuring
they can’t take up a disproportionate share of bandwidth in competition with
normal traffic.
- Jonathan Morton
___
Codel mailing list
Codel
Normal traffic does not include large numbers of fragmented packets (I would
expect a mere handful from certain one-shot request-response protocols which
can produce large responses), so it is better to shunt them to a single queue
per host-pair.
- Jonathan Morton
___
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
> On 20 May, 2016, at 16:41, David Lang wrote:
>
> On Fri, 20 May 2016, Jonathan Morton wrote:
>
>> Normal traffic does not include large numbers of fragmented packets (I would
>> expect a mere handful from certain one-shot request-response protocols which
>> ca
ough for Codel to deal with.
Hence BLUE will hand control back to Codel only when it is sure its extra
effort is not required.
- Jonathan Morton
___
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
required for reassembly. Presently those costs are borne
by the receiving host, which is in a better position to do so.
- Jonathan Morton
___
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
> On 20 May, 2016, at 17:04, David Lang wrote:
>
> Is it possible to get speed testing software to detect that it's receiving
> fragments and warn about that?
Do iperf3’s maintainers accept patches?
- Jonathan Morton
___
Codel m
> On 20 May, 2016, at 19:20, Rick Jones wrote:
>
> On 05/20/2016 08:12 AM, Jonathan Morton wrote:
>>
>>> On 20 May, 2016, at 17:04, David Lang wrote:
>>>
>>> Is it possible to get speed testing software to detect that it's receiving
>&g
already in Linux, if you want to
see how it behaves independently). It’s merely a case of modifying a fork of
sch_codel and/or sch_fq_codel and/or sch_cake to run it in parallel with the
Codel algorithm.
I’ll probably get around to it once I’ve got some current Cake changes out of
the way.
to examine packet
traces associated with each test.
- Jonathan Morton
___
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
P_MTU_DISCOVERY socket option mentioned.
- Jonathan Morton
___
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
> On 20 May, 2016, at 19:03, David Lang wrote:
>
> On Fri, 20 May 2016, Jonathan Morton wrote:
>
>>>> If the relative load from the flow decreases, BLUE’s action will begin to
>>>> leave the subqueue empty when serviced, causing BLUE’s drop probability to
ng end of the stick.
- Jonathan Morton
___
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
> On 20 May, 2016, at 19:43, Jonathan Morton wrote:
>
>> On 20 May, 2016, at 19:37, Luis E. Garcia wrote:
>>
>> I think this would be a great idea to implement and test.
>> Can COBALT's behavior be easily implemented to test it using the OpenWRT or
&g
y
packet below the target sojourn time clears the “dropping” flag, which prevents
marking or dropping from occurring - which is why the explicit “primed” state
is eliminated.
Since the timestamp is set in this way whenever the “dropping” flag transitions
from cleared to set, there ar
e invsqrt cache bug yesterday?
- Jonathan Morton
___
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
a lot easier to integrate into a complex qdisc than Codel’s.
- Jonathan Morton
___
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
may be to enquire as to whether DCTCP is in fact in
use. If so, the TCP Prague people should be brought into the loop, as this
would constitute evidence that Codel can’t control DCTCP via ECN under
practical Internet conditions.
- Jonathan Morton
chanism,
though a much blunter one; it is significantly superior to tail-drop for two
major reasons, but can easily result in burst loss.
It is also this overflow which acts as the up-trigger for BLUE; the longest
queue not only gets the instant head-drop but a notification to its CO
ally work.
As for who these servers are: Valve Software’s Steam platform. I did say they
were large and popular.
- Jonathan Morton
___
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
> On 4 Jun, 2016, at 17:01, moeller0 wrote:
>
> Maybe cake should allow to switch from the default mark by ECN policy to mark
> by drop per command line argument? At least that would allow much easier in
> the field testing… As is there is only the option of disabling ECN at the
> endpoint(s)
ormance against the faulty traffic.
- Jonathan Morton
___
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
down please”) are ultimately unhelpful. But at least they
are still ack-clocked.
- Jonathan Morton
___
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
ion for me to build into my next overhead
model update.
- Jonathan Morton
___
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
> On 4 Jun, 2016, at 22:55, Jonathan Morton wrote:
>
> COBALT should turn out to be a reasonable antidote to sender-side cheating,
> due to the way BLUE works; the drop probability remains steady until the
> queue has completely emptied, and then decays slowly. Assuming th
ou don’t
plan to actually *use* 40Mbps full-time, but that your AQM solution depends on
knowing how much bandwidth is available for when *your* customers randomly
demand it.
- Jonathan Morton
___
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
FQ keeps them from impacting other
flows, and BLUE starts dropping if their window growth is unbounded.
- Jonathan Morton
___
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
n. That sounds like what you’re
trying to experiment with.
- Jonathan Morton
___
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
bottleneck, nobody
else on the same path is, and therefore their drop probabilities are all zero.
This assumes only that you're dealing with traffic that's responsive to
congestion signals, as TCP is. Transient conditions may exist where the
assumption isn't entirely
queue with linear search (in
software) or constant-time CAM search (in hardware).
- Jonathan Morton
___
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
1:1
Yes, this is an extensively tested configuration. Have you tried it?
You could also just use Cake, which does all the above, better, with only one
tc invocation:
tc qdisc replace dev r1-eth0 root handle 1: cake bandwidth 10000kbit
besteffort flows
- Jonathan Morton
__
1 - 100 of 115 matches
Mail list logo
