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

[Luca Muscariello <luca.muscariello@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 6419 bytes --]

I suggest re-reading this

https://queue.acm.org/detail.cfm?id=3022184


On Tue 27 Nov 2018 at 21:58, Dave Taht <dave.taht@gmail.com> 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 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 conversational flows.
> :)
>
> On Tue, Nov 27, 2018 at 1:24 AM Luca Muscariello
> <luca.muscariello@gmail.com> wrote:
> >
> > 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 link
> efficiency, i.e. the queue never empties out.
>
> no, I think it needs a BDP in flight.
>
> I think some of the confusion here is that your TCP stack needs to
> keep around a BDP in order to deal with
> retransmits, but that lives in another set of buffers entirely.
>
> > This gives rule of thumbs to size buffers which is also very practical
> and thanks to flow isolation becomes very accurate.
> >
> > Which is:
> >
> > 1) find a way to keep the number of backlogged flows at a reasonable
> value.
> > This largely depends on the minimum fair rate an application may need in
> the long term.
> > We discussed a little bit of available mechanisms to achieve that in the
> literature.
> >
> > 2) fix the largest RTT you want to serve at full utilization and size
> the buffer using BDP * N_backlogged.
> > Or the other way round: check how much memory you can use
> > in the router/line card/device and for a fixed N, compute the largest
> RTT you can serve at full utilization.
>
> My own take on the whole BDP argument is that *so long as the flows in
> that BDP are thoroughly mixed* you win.
>
> >
> > 3) there is still some memory to dimension for sparse flows in addition
> to that, but this is not based on BDP.
> > It is just enough to compute the total utilization of sparse flows and
> use the same simple model Toke has used
> > to compute the (de)prioritization probability.
> >
> > 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 queue. Which is, BTW, already available in
> Cisco nexus switches for data centres.
> >
> > I think that the the codel part would still provide the ECN feature,
> that all the others cannot have.
> > However the others, the last one especially can be implemented in
> silicon with reasonable cost.
> >
> >
> >
> >
> >
> > On Mon 26 Nov 2018 at 22:30, Jonathan Morton <chromatix99@gmail.com>
> wrote:
> >>
> >> > On 26 Nov, 2018, at 9:08 pm, Pete Heist <pete@heistp.net> 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 or calculated rwnd and
> cwnd limits (the rwnd is visible on the wire and usually chosen to be large
> enough to be a non-factor), or when the queue overflows.  Large windows
> require buffer memory in both sender and receiver, increasing costs on the
> sender in particular (who typically has many flows to manage per machine).
> >>
> >> Queue overflow tends to result in burst loss and head-of-line blocking
> in the receiver, which is visible to the user as a pause and subsequent
> jump in the progress of their download, accompanied by a major fluctuation
> in the estimated time to completion.  The lost packets also consume
> capacity upstream of the bottleneck which does not contribute to
> application throughput.  These effects are independent of whether overflow
> dropping occurs at the head or tail of the bottleneck queue, though
> recovery occurs more quickly (and fewer packets might be lost) if dropping
> occurs from the head of the queue.
> >>
> >> From a pure throughput-efficiency standpoint, Codel allows using ECN
> for congestion signalling instead of packet loss, potentially eliminating
> packet loss and associated lead-of-line blocking entirely.  Even without
> ECN, the actual cwnd is kept near the minimum necessary to satisfy the BDP
> of the path, reducing memory requirements and significantly shortening the
> recovery time of each loss cycle, to the point where the end-user may not
> notice that delivery is not perfectly smooth, and implementing accurate
> completion time estimators is considerably simplified.
> >>
> >> An important use-case is where two sequential bottlenecks exist on the
> path, the upstream one being only slightly higher capacity but lacking any
> queue management at all.  This is presently common in cases where home CPE
> implements inbound shaping on a generic ISP last-mile link.  In that case,
> without Codel running on the second bottleneck, traffic would collect in
> the first bottleneck's queue as well, greatly reducing the beneficial
> effects of FQ implemented on the second bottleneck.  In this topology, the
> overall effect is inter-flow as well as intra-flow.
> >>
> >> The combination of Codel with FQ is done in such a way that a separate
> instance of Codel is implemented for each flow.  This means that congestion
> signals are only sent to flows that require them, and non-saturating flows
> are unmolested.  This makes the combination synergistic, where each
> component offers an improvement to the behaviour of the other.
> >>
> >>  - Jonathan Morton
> >>
> >> _______________________________________________
> >> Bloat mailing list
> >> Bloat@lists.bufferbloat.net
> >> https://lists.bufferbloat.net/listinfo/bloat
> >
> > _______________________________________________
> > Bloat mailing list
> > Bloat@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/bloat
>
>
>
> --
>
> Dave Täht
> CTO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-831-205-9740
>

[-- Attachment #2: Type: text/html, Size: 7704 bytes --]