Message-ID: <CAA93jw6aky0KOW3cxoJMP8vVChD_CUejOWTVcQj5o=u_UH0qoA@mail.gmail.com>
Date:   Tue, 29 Jun 2021 08:26:54 -0700
From:   Dave Taht <dave.taht@...il.com>
To:     Niclas Hedam <nhed@....dk>
Cc:     Toke Høiland-Jørgensen <toke@...hat.com>,
        "stephen@...workplumber.org" <stephen@...workplumber.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH v2] net: sched: Add support for packet bursting.

Thx for bringing me in. I don't really have an opinion as to the value
of this patchset, but I do have an opinion on the slot functionality.

The slot functionality was my first attempt at properly emulating wifi
behaviors in netem, and although it does capture how aggregation
behaves in 802.11n, which was VERY important - it falls down miserably
on later standards and on more than one station being present due to
the half duplex nature of wifi, and the ingress and egress queues
being tightly coupled.

Used extremely carefully (along with the packet trace models also now
in netem), you *can* get closer to an emulation of how one or two wifi
stations actually behave in normal and tightly coupled systems with
tcp-friendly protocols, but I often wish I'd *never* released the code
as any result you get from it for tcp behaviors over denser wifi
networks is extremely misleading. (although, still better than
anything else out there in terms of emulating aggregation properly!).

Us not having been (since) able to gain access to low level firmwares
for wifi 6 (though the openwifi project is promising), has made it
really difficult to actually implement the real fixes for wifi (and
starlink) that we have as an outgrowth of the make-wifi-fast project.
In particular, merely getting a "txop is nearly done" interrupt would
make a huge difference if only we could find a chipset to leverage.

We are still forced to construct a two txop standing queue which can
really hurt wifi
performance on every chipset we have tried to improve. Dang it.

To quote from the codel paper:

"The standing queue, resulting from a mismatch between the window and
pipe size, is the essence of bufferbloat. It creates large delays but
no improvement in throughput. It is not a phenomenon treated by
queuing or traffic theory, which, unfortunately, results in it being
almost universally misclassified as congestion (a completely different
and much rarer pathology). These theories usually assume Poisson
arrival processes, which are, by definition, uncorrelated. The
arrivals of a closed-loop, reliable transport process such as TCP are
completely correlated, resulting in an arrival and departure rate
equality that theorists have dismissed as unnatural and wildly
improbable. Since normal cures for congestion such as usage limits or
usage-based billing have no effect on bufferbloat but annoy customers
and discourage network use, addressing the real problem would be
prudent."  - https://queue.acm.org/detail.cfm?id=2209336







On Mon, Jun 28, 2021 at 6:24 AM Niclas Hedam <nhed@....dk> wrote:
>
> Thanks for the valuable thoughts, Toke.
>
> The patch started with me being tasked to try and mitigate timing attacks caused by network latencies.
> I scouted over the current network stack and didn't find anything that fully matched my use-case.
> While I now understand that you can actually leverage the slots functionality for this, I would still opt for a new interface and implementation.
>
> I have not done any CPU benchmarks on the slots system, so I'm not approaching this from the practical performance side per se.
> Instead, I argue for seperation with reference to the Seperation of Concern design principle. The slots functionality is not built/designed to cater security guarantees, and my patch is not built to cater duty cycles, etc.
> If we opt to merge these two functionalities or discard mine, we have to implement some guarantee that the slots functionality won't become significantly slower or complex, which in my opinion is less maintainable than two similar systems. Also, this patch is very limited in lines of code, so maintaining it is pretty trivial.
>
> I do agree, however, that we should define what would happen if you enable both systems at the same time.
>
> @Dave: Any thoughts on this?
>
> > On 28 Jun 2021, at 14:21, Toke Høiland-Jørgensen <toke@...hat.com> wrote:
> >
> > Niclas Hedam <nhed@....dk> writes:
> >
> >>>> From 71843907bdb9cdc4e24358f0c16a8778f2762dc7 Mon Sep 17 00:00:00 2001
> >>>> From: Niclas Hedam <nhed@....dk>
> >>>> Date: Fri, 25 Jun 2021 13:37:18 +0200
> >>>> Subject: [PATCH] net: sched: Add support for packet bursting.
> >>>
> >>> Something went wrong with the formatting here.
> >>
> >> I'll resubmit with fixed formatting. My bad.
> >>
> >>>>
> >>>> This commit implements packet bursting in the NetEm scheduler.
> >>>> This allows system administrators to hold back outgoing
> >>>> packets and release them at a multiple of a time quantum.
> >>>> This feature can be used to prevent timing attacks caused
> >>>> by network latency.
> >>>
> >>> How is this bursting feature different from the existing slot-based
> >>> mechanism?
> >>
> >> It is similar, but the reason for separating it is the audience that they are catering.
> >> The slots seems to be focused on networking constraints and duty cycles.
> >> My contribution and mechanism is mitigating timing attacks. The
> >> complexity of slots are mostly unwanted in this context as we want as
> >> few CPU cycles as possible.
> >
> > (Adding Dave who wrote the slots code)
> >
> > But you're still duplicating functionality, then? This has a cost in
> > terms of maintainability and interactions (what happens if someone turns
> > on both slots and bursting, for instance)?
> >
> > If the concern is CPU cost (got benchmarks to back that up?), why not
> > improve the existing mechanism so it can be used for your use case as
> > well?
> >
> > -Toke
>


--
Latest Podcast:
https://www.linkedin.com/feed/update/urn:li:activity:6791014284936785920/

Dave Täht CTO, TekLibre, LLC

Powered by blists - more mailing lists