Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

Hi, A few answers below: > On Nov 27, 2018, at 9:10 PM, Dave Taht wrote: > > On Mon, Nov 26, 2018 at 1:56 PM Michael Welzl > wrote: >> >> Hi folks, >> >> That “Michael” dude was me :) >> >> About the stuff below, a few comments. First, an impressive effort to

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

On Fri, 30 Nov 2018 06:51:34 +0100 (CET) Mikael Abrahamsson wrote: > On Thu, 29 Nov 2018, Stephen Hemminger wrote: > > > The problem is that any protocol is mostly blind to the underlying > > network (and that can change). To use dave's analogy it is like being > > put in the driver seat of

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

On Thu, Nov 29, 2018 at 9:51 PM Mikael Abrahamsson wrote: > > On Thu, 29 Nov 2018, Stephen Hemminger wrote: > > > The problem is that any protocol is mostly blind to the underlying > > network (and that can change). To use dave's analogy it is like being > > put in the driver seat of a vehicle

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

>>If I can restate that in a more concrete way: the queue may not drain at a >>smooth, constant rate. There are several real-world link technologies which >>exhibit this behaviour - wifi and DOCSIS come to mind, not to mention 3G/4G >>with variable signal strength. This! Also, bottlenecks

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

> On 30 Nov, 2018, at 12:32 pm, Luca Muscariello > wrote: > > Two last comments: one should always used fluid approximation with care, > because they are approximations, > the real model is more complex. Nobody considers that the RTT varies during > the connection lifetime and that ACK can

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

Mario, agreed. Two last comments: one should always used fluid approximation with care, because they are approximations, the real model is more complex. Nobody considers that the RTT varies during the connection lifetime and that ACK can be delayed. So CWD increases in a non simple way. This is

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

Luca, I'm not that happy with the theorem either, since it stresses a limitation that can actually be overcome. However, I quoted it to demonstrate there is a challenge involved. In my point of view there is actually a subtle thing that's often lost when modeling the queue based on input

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

On Thu, 29 Nov 2018, Stephen Hemminger wrote: The problem is that any protocol is mostly blind to the underlying network (and that can change). To use dave's analogy it is like being put in the driver seat of a vehicle blind folded. When you step on the gas you don't know if it is a

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

Mario, putting aside LoLa for a second, I'm not quite sure that the theorem you cite is valid. According to the model R_i is the sending rate. The sum across all flows bottlenecked at the link does not need to be equal to the link capacity. The input rate can be instantaneously below or above

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

On Thu, Nov 29, 2018 at 10:43 AM Stephen Hemminger wrote: > > On Wed, 28 Nov 2018 23:35:53 -0800 > Dave Taht wrote: > > > > As someone who works with moving packets, it's perplexing to me to > > > interact with transport peeps who seem enormously focused on > > > "goodput". My personal opinion

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

On Wed, 28 Nov 2018 23:35:53 -0800 Dave Taht wrote: > > As someone who works with moving packets, it's perplexing to me to > > interact with transport peeps who seem enormously focused on > > "goodput". My personal opinion is that most people would be better off > > with 80% of their available

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

Hi Luca, I'm answering on behalf of Roland, since I am a co-author of the paper. This is an excellent question, since it goes right at the heart of how LoLa works. Indeed, the paper is a first of a series. A second one, looking deeper into the fair flow balancing mechanism, is currently

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

Hi Roland, It took me quite a lot of time to find this message in the thread... I read the paper you sent and I guess this is the first of a series as many things stay uncovered. Just a quick question: why is X(t) always increasing with t? On Tue, Nov 27, 2018 at 11:26 AM Bless, Roland (TM)

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

Hi Jonathan, Am 29.11.18 um 08:45 schrieb Jonathan Morton: >> On 29 Nov, 2018, at 9:39 am, Dave Taht wrote: >> >> …when it is nearly certain that more than one flow exists, means aiming >> for the BDP in a single flow is generally foolish. > > It might be more accurate to say that the BDP of

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

> On Nov 29, 2018, at 8:33 AM, Dave Taht wrote: > > This whole thread, although diversive... well, I'd really like everybody > to get together and try to write a joint paper on the best stuff to do, > worldwide, to make bufferbloat go away. +1 I don’t think it’s an accident that a discussion

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

Hi Dave, Am 29.11.18 um 08:39 schrieb Dave Taht: > "Bless, Roland (TM)" writes: > >> Hi Luca, >> >> Am 27.11.18 um 11:40 schrieb Luca Muscariello: >>> OK. We agree. >>> That's correct, you need *at least* the BDP in flight so that the >>> bottleneck queue never empties out. >> >> No, that's not

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

Hi Dave, Am 29.11.18 um 08:33 schrieb Dave Taht: > "Bless, Roland (TM)" writes: > >> Hi Luca, >> >> Am 27.11.18 um 10:24 schrieb Luca Muscariello: >>> A congestion controlled protocol such as TCP or others, including QUIC, >>> LEDBAT and so on >>> need at least the BDP in the transmission queue

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

On Wed, Nov 28, 2018 at 11:45 PM Jonathan Morton wrote: > > > On 29 Nov, 2018, at 9:39 am, Dave Taht wrote: > > > > …when it is nearly certain that more than one flow exists, means aiming > > for the BDP in a single flow is generally foolish. > > It might be more accurate to say that the BDP of

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

> On 29 Nov, 2018, at 9:39 am, Dave Taht wrote: > > …when it is nearly certain that more than one flow exists, means aiming > for the BDP in a single flow is generally foolish. It might be more accurate to say that the BDP of the fair-share of the path is the cwnd to aim for. Plus epsilon for

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

Mikael Abrahamsson writes: > On Tue, 27 Nov 2018, Luca Muscariello wrote: > >> link fully utilized is defined as Q>0 unless you don't include the >> packet currently being transmitted. I do, so the TXtteer is never >> idle. But that's a detail. > > As someone who works with moving packets, it's

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

"Bless, Roland (TM)" writes: > Hi Luca, > > Am 27.11.18 um 10:24 schrieb Luca Muscariello: >> A congestion controlled protocol such as TCP or others, including QUIC, >> LEDBAT and so on >> need at least the BDP in the transmission queue to get full link >> efficiency, i.e. the queue never

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

"Bless, Roland (TM)" writes: > Hi Luca, > > Am 28.11.18 um 11:48 schrieb Luca Muscariello: > >> And for BBR, I would say that one thing is the design principles another >> is the implementations >> and we better distinguish between them. The key design principles are >> all valid. > > While the

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

Luca Muscariello writes: > On Wed, Nov 28, 2018 at 11:40 AM Dave Taht > wrote: > > On Wed, Nov 28, 2018 at 1:56 AM Luca Muscariello > wrote: > > > > Dave, > > > > The single BDP inflight is a rule of thumb that does not account > for fluctuations of the RTT. > >

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

Michael Welzl writes: > Just a small clarification: > > > > > To me the switch to head dropping essentially killed the tail > loss RTO > problem, eliminated most of the need for ecn. > > > > I doubt that: TCP will need to retransmit that

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

Hi Luca, Am 28.11.18 um 11:48 schrieb Luca Muscariello: > And for BBR, I would say that one thing is the design principles another > is the implementations > and we better distinguish between them. The key design principles are > all valid. While the goal is certainly right to operate around

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

On Wed, Nov 28, 2018 at 11:40 AM Dave Taht wrote: > On Wed, Nov 28, 2018 at 1:56 AM Luca Muscariello > wrote: > > > > Dave, > > > > The single BDP inflight is a rule of thumb that does not account for > fluctuations of the RTT. > > And I am not talking about random fluctuations and noise. I am

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

On Wed, Nov 28, 2018 at 1:56 AM Luca Muscariello wrote: > > Dave, > > The single BDP inflight is a rule of thumb that does not account for > fluctuations of the RTT. > And I am not talking about random fluctuations and noise. I am talking about > fluctuations > from a control theoretic point of

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

Dave, The single BDP inflight is a rule of thumb that does not account for fluctuations of the RTT. And I am not talking about random fluctuations and noise. I am talking about fluctuations from a control theoretic point of view to stabilise the system, e.g. the trajectory of the system variable

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

Pete Heist writes: > On Nov 27, 2018, at 9:10 PM, Dave Taht > wrote: > > EVEN with http 2.0/ I would be extremely surprised to learn that > many > websites fit it all into one tcp transaction. > > There are very few other examples of TCP traffic requiring a low

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

On 11/27/18 3:17 PM, Dave Taht wrote: ... > > but now that we all have bedtime reading, I'm going to go back to > hacking on libcuckoo. :) > > Geez, louise. As if everyone doesn't have enough to do! I apologize. I did not mean for anyone to completely read the links I sent, just look at the

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

> On Nov 27, 2018, at 9:10 PM, Dave Taht wrote: > > EVEN with http 2.0/ I would be extremely surprised to learn that many > websites fit it all into one tcp transaction. > > There are very few other examples of TCP traffic requiring a low > latency response. This is the crux of what I was

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

On Tue, Nov 27, 2018 at 2:30 PM Roland Bless wrote: > > Hi, > > On 27.11.18 at 23:19 Luca Muscariello wrote: > > I suggest re-reading this > > > > https://queue.acm.org/detail.cfm?id=3022184 > Probably not without this afterwards: > https://ieeexplore.ieee.org/document/8117540 > > (especially

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

Hi, On 27.11.18 at 23:19 Luca Muscariello wrote: > I suggest re-reading this  > > https://queue.acm.org/detail.cfm?id=3022184 Probably not without this afterwards: https://ieeexplore.ieee.org/document/8117540 (especially sections II and III). Regards, Roland

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

I suggest re-reading this https://queue.acm.org/detail.cfm?id=3022184 On Tue 27 Nov 2018 at 21:58, Dave Taht wrote: > OK, wow, this conversation got long. and I'm still 20 messages behind. > > Two points, and I'm going to go back to work, and maybe I'll try to > summarize a table > of the

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

Hi Kathie, [long time, no see :-)] I'm well aware of the CoDel paper and it really does a nice job of explaining the good queue and bad queue properties. What we found is that loss-based TCP CCs systematically build standing queues. Their positive function is to keep up the link utilization,

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

Just a small clarification: >> To me the switch to head dropping essentially killed the tail loss RTO >> problem, eliminated most of the need for ecn. > > I doubt that: TCP will need to retransmit that packet at the head, and that > takes an RTT - all the packets after it will need to wait in

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

Dave Taht writes: > On Tue, Nov 27, 2018 at 12:54 PM Toke Høiland-Jørgensen wrote: >> >> Dave Taht writes: >> >> > I've done things like measure induced latency on wireguard streams of >> > late and codel keeps it sane. still, wireguard internally is optimized >> > for single flow "dragster"

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

On Tue, Nov 27, 2018 at 12:54 PM Toke Høiland-Jørgensen wrote: > > Dave Taht writes: > > > I've done things like measure induced latency on wireguard streams of > > late and codel keeps it sane. still, wireguard internally is optimized > > for single flow "dragster" performance, and I'd like it

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

OK, wow, this conversation got long. and I'm still 20 messages behind. Two points, and I'm going to go back to work, and maybe I'll try to summarize a table of the competing viewpoints, as there's far more than BDP of discussion here, and what we need is sqrt(bdp) to deal with all the different

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

Dave Taht writes: > I've done things like measure induced latency on wireguard streams of > late and codel keeps it sane. still, wireguard internally is optimized > for single flow "dragster" performance, and I'd like it to gain the > same fq_codel optimization that did such nice things for

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

On Mon, Nov 26, 2018 at 1:30 PM Jonathan Morton wrote: > > > On 26 Nov, 2018, at 9:08 pm, Pete Heist wrote: > > > > So I just thought to continue the discussion- when does the CoDel part of > > fq_codel actually help in the real world? > > Fundamentally, without Codel the only limits on the

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

On Mon, Nov 26, 2018 at 11:28 AM Neal Cardwell wrote: > > I believe Dave Taht has pointed out, essentially, that the "codel" part of > fq_codel can be useful in cases where the definition of "flow" is not visible > to fq_codel, so that "fq" part is inactive. For example, if there is VPN >

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

On Mon, Nov 26, 2018 at 1:56 PM Michael Welzl wrote: > > Hi folks, > > That “Michael” dude was me :) > > About the stuff below, a few comments. First, an impressive effort to dig all > of this up - I also thought that this was an interesting conversation to have! > > However, I would like to

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

On Tue, Nov 27, 2018 at 10:44 AM Kathleen Nichols wrote: > > > I have been kind of blown away by this discussion. Jim Gettys kind of > kicked off the current wave of dealing with full queues, dubbing it > "bufferbloat". He wanted to write up how it happened so that people > could start on a

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

> On 27 Nov, 2018, at 3:19 pm, Michael Richardson wrote: > > If the drops are due to noise, then I don't think it will help. > The congestion signals should already getting made. If they are drops due to noise, then they are not congestion signals at all, as they occur independently of whether

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

I have been kind of blown away by this discussion. Jim Gettys kind of kicked off the current wave of dealing with full queues, dubbing it "bufferbloat". He wanted to write up how it happened so that people could start on a solution and I was enlisted to get an article written. We tried to draw on

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

On Tue, 27 Nov 2018, Luca Muscariello wrote: This is a whole different discussion but if you want to have a per-user context at the BNG level + TM + FQ I'm not sure that kind of beast will ever exist. Unless you have a very small user fan-out the hardware clocks could loop over several

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

On Tue, Nov 27, 2018 at 2:49 PM Mikael Abrahamsson wrote: > On Tue, 27 Nov 2018, Luca Muscariello wrote: > > > If you, Mikael don't want more than 10ms buffer, how do you achieve that? > > class class-default >random-detect 10 ms 2000 ms > > That's the only thing available to me on the

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

On Tue, 27 Nov 2018, Luca Muscariello wrote: If you, Mikael don't want more than 10ms buffer, how do you achieve that? class class-default random-detect 10 ms 2000 ms That's the only thing available to me on the platforms I have. If you would like this improved, please reach out to the

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

Another bit to this. A router queue is supposed to serve packets no matter what is running at the controlled end-point, BBR, Cubic or else. So, delay-based congestion controller still get hurt in today Internet unless they can get their portion of buffer at the line card. FQ creates incentives for

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

Pete Heist wrote: > I was asked a related question by my local WISP, who wanted to know if > there would be any reason that fq_codel or Cake would be an improvement > over sfq specifically for some "noisy links” (loose translation from > Czech) in a backhaul that have some loss

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

Hi Michael, Am 27.11.18 um 12:04 schrieb Michael Welzl: > I'm lost in this conversation: I thought it started with a statement saying > that the queue length must be at least a BDP such that full utilization is > attained because the queue never drains. I think it helps to distinguish between

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

Hi, Am 27.11.18 um 12:58 schrieb Luca Muscariello: > A buffer in a router is sized once. RTT varies. > So BDP varies. That’s as simple as that. > So you just cannot be always at optimum because you don’t know what RTT > you have at any time. The endpoints can measure the RTT. Yes, it's probably

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

> On 27 Nov, 2018, at 1:21 pm, Mikael Abrahamsson wrote: > > It's complicated. I've had people throw in my face that I need 2xBDP in > buffer size to smoothe things out. Personally I don't want more than 10ms > buffer (max), and I don't see why I should need more than that even if > transfers

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

A buffer in a router is sized once. RTT varies. So BDP varies. That’s as simple as that. So you just cannot be always at optimum because you don’t know what RTT you have at any time. Lola si not solving that. No protocol could BTW. BTW I don’t see any formal proof about queue occupancy in the

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

Hi Luca, Am 27.11.18 um 12:01 schrieb Luca Muscariello: > A BDP is not a large buffer. I'm not unveiling a secret. That depends on speed and RTT (note that typically there are several flows with different RTTs sharing the same buffer). The essential point is not how much buffer capacity is

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

Luca Muscariello writes: > This procedure would allow to size FQ_codel but also SFQ. > It would be interesting to compare the two under this buffer sizing. > It would also be interesting to compare another mechanism that we have > mentioned during the defense > which is AFD + a sparse flow

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

Hi, Am 27.11.18 um 12:40 schrieb Bless, Roland (TM): > Hi Luca, > > Am 27.11.18 um 11:40 schrieb Luca Muscariello: >> OK. We agree. >> That's correct, you need *at least* the BDP in flight so that the >> bottleneck queue never empties out. > > No, that's not what I meant, but it's quite simple.

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

Hi Luca, Am 27.11.18 um 11:40 schrieb Luca Muscariello: > OK. We agree. > That's correct, you need *at least* the BDP in flight so that the > bottleneck queue never empties out. No, that's not what I meant, but it's quite simple. You need: data min_inflight=2 * RTTmin * bottleneck_rate to filly

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

On Tue, 27 Nov 2018, Luca Muscariello wrote: A BDP is not a large buffer. I'm not unveiling a secret. It's complicated. I've had people throw in my face that I need 2xBDP in buffer size to smoothe things out. Personally I don't want more than 10ms buffer (max), and I don't see why I should

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

Well, I'm concerned about the delay experienced by people when they surf the web... flow completion time, which relates not only to the delay of packets as they are sent from A to B, but also the utilization. Cheers, Michael > On 27 Nov 2018, at 11:50, Mikael Abrahamsson wrote: > > On Tue,

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

> On 27 Nov, 2018, at 12:50 pm, Mikael Abrahamsson wrote: > > Could someone perhaps comment on the thinking in the transport protocol > design "crowd" when it comes to this? BBR purports to aim for the optimum of maximum throughput at minimum latency; there is a sharp knee in the

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

A BDP is not a large buffer. I'm not unveiling a secret. And it is just a rule of thumb to have an idea at which working point the protocol is working. In practice the protocol is usually working below or above that value. This is where AQM and ECN help also. So most of the time the protocol is

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

On Tue, 27 Nov 2018, Luca Muscariello wrote: link fully utilized is defined as Q>0 unless you don't include the packet currently being transmitted. I do, so the TXtteer is never idle. But that's a detail. As someone who works with moving packets, it's perplexing to me to interact with

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

OK. We agree. That's correct, you need *at least* the BDP in flight so that the bottleneck queue never empties out. This can be easily proven using fluid models for any congestion controlled source no matter if it is loss-based, delay-based, rate-based, formula-based etc. A highly paced source

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

Hi, Am 27.11.18 um 11:29 schrieb Luca Muscariello: > I have never said that you need to fill the buffer to the max size to > get full capacity, which is an absurdity. Yes, it's absurd, but that's what today's loss-based CC algorithms do. > I said you need at least the BDP so that the queue

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

I have never said that you need to fill the buffer to the max size to get full capacity, which is an absurdity. I said you need at least the BDP so that the queue never empties out. The link is fully utilized IFF the queue is never emptied. On Tue 27 Nov 2018 at 11:26, Bless, Roland (TM)

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

Hi Luca, Am 27.11.18 um 10:24 schrieb Luca Muscariello: > A congestion controlled protocol such as TCP or others, including QUIC, > LEDBAT and so on > need at least the BDP in the transmission queue to get full link > efficiency, i.e. the queue never empties out. This is not true. There are

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

> On 27 Nov, 2018, at 10:54 am, Pete Heist wrote: > > …any reason that fq_codel or Cake would be an improvement over sfq > specifically for some "noisy links” (loose translation from Czech) in a > backhaul that have some loss but also experience saturation. If the random loss is low enough

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

I think that this is a very good comment to the discussion at the defense about the comparison between SFQ with longest queue drop and FQ_Codel. A congestion controlled protocol such as TCP or others, including QUIC, LEDBAT and so on need at least the BDP in the transmission queue to get full

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

Thank you all for the responses! I was asked a related question by my local WISP, who wanted to know if there would be any reason that fq_codel or Cake would be an improvement over sfq specifically for some "noisy links” (loose translation from Czech) in a backhaul that have some loss but also

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

Michael Welzl writes: > However, I would like to point out that thesis defense conversations > are meant to be provocative, by design - when I said that CoDel > doesn’t usually help and long queues would be the right thing for all > applications, I certainly didn’t REALLY REALLY mean that. Just

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

Hi folks, That “Michael” dude was me :) About the stuff below, a few comments. First, an impressive effort to dig all of this up - I also thought that this was an interesting conversation to have! However, I would like to point out that thesis defense conversations are meant to be

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

> On 26 Nov, 2018, at 9:08 pm, Pete Heist wrote: > > So I just thought to continue the discussion- when does the CoDel part of > fq_codel actually help in the real world? Fundamentally, without Codel the only limits on the congestion window would be when the sender or receiver hit configured

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

I believe Dave Taht has pointed out, essentially, that the "codel" part of fq_codel can be useful in cases where the definition of "flow" is not visible to fq_codel, so that "fq" part is inactive. For example, if there is VPN traffic, where the individual flows are not separable by fq_codel, then