netdev - Re: [PATCH net-next 2/2] fq_codel: implement L4S style ce_threshold

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CADVnQyn5qjonOejvmsQh+KJ04NV0f+NoGWXB-AQBPXLUkqPU6w@mail.gmail.com>
Date:   Fri, 15 Oct 2021 11:49:32 -0400
From:   Neal Cardwell <ncardwell@...gle.com>
To:     Eric Dumazet <edumazet@...gle.com>
Cc:     Bob Briscoe <ietf@...briscoe.net>,
        Eric Dumazet <eric.dumazet@...il.com>,
        netdev <netdev@...r.kernel.org>,
        Ingemar Johansson S <ingemar.s.johansson@...csson.com>,
        Tom Henderson <tomh@...h.org>,
        "David S . Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>
Subject: Re: [PATCH net-next 2/2] fq_codel: implement L4S style
 ce_threshold_ect1 marking

On Fri, Oct 15, 2021 at 10:08 AM Eric Dumazet <edumazet@...gle.com> wrote:
>
> On Fri, Oct 15, 2021 at 5:59 AM Bob Briscoe <ietf@...briscoe.net> wrote:
> >
> > Eric,
> >
> > Because the threshold is in time units, I suggest the condition for
> > exceeding it needs to be AND'd with (*backlog > mtu), otherwise you can
> > get 100% solid marking at low link rates.
> >
> > When ce_threshold is for DCs, low link rates are unlikely.
> > However, given ce_threshold_ect1 is mainly for the Internet, during
> > testing with 1ms threshold we encountered solid marking at low link
> > rates, so we had to add a 1 packet floor:
> > https://bobbriscoe.net/projects/latency/dctth_journal_draft20190726.pdf
> >
> > Sorry to chime in after your patch went to net-next.
> >
>
> What you describe about a minimal backlog was already there with
> ce_threshold handling ?

For my education, do you have a pointer to where the ce_threshold
marking logic has a minimum backlog size requirement in packets or
bytes? AFAICT the ce_threshold marking in include/net/codel_impl.h
happens regardless of the current size of the backlog.

> Or is it something exclusive to L4S ?

I don't think it's exclusive to L4S. I think Bob is raising a general
issue about improving ECN marking based on ce_threshold. My
interpretation of Bob's point is that there is sort of a quantization
issue at very low link speeds, where the serialization delay for a
packet is at or above the ce_threshold delay. In such cases it seems
there can be behavior where the bottleneck marks every packet CE all
the time, causing any ECN-based algorithm (even DCTCP) to suffer poor
utilization.

I suppose with a fixed-speed link the operator could adjust the
ce_threshold based on the serialization delays implied by the link
speed, but perhaps in general this is infeasible due to variable-speed
(e.g., radio) links.

I guess perhaps this could be reproduced/tested with DCTCP (using
ECT(0)), a ce_threshold of 1ms (for ECT(0)), and an emulated
bottleneck link speed with a serialization delay well above 1ms (so a
link speed well below 12Mbps).

> This deserves a separate patch, if anything :)

Agreed, in the Linux development model this would make sense as a
separate patch, since it is conceptually separate and there do not
need to be any dependencies between the two changes. :-)

neal