From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id E0C3C3CB35 for ; Tue, 29 Jun 2021 12:42:22 -0400 (EDT) Received: by mail-il1-x12e.google.com with SMTP id h3so21445916ilc.9 for ; Tue, 29 Jun 2021 09:42:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=Q+QuP6xDjyAH2l08JQDGODpKrnjshqywTuVnXVwd2Rc=; b=p/RW6nGkCCyE9ttxDp/sR/N53bTvO5tM4C9h4f+RO1DVBjyDxeKHW905eL+5ksLza2 V0Lhe1qKp6eUJaTo33/+EyIOKxefV9Qf2jSogDUmRf4ojvM0waRUwWBT8grugX1Go3X8 G8tOObFSB1fIps1Bwgfq77guLFQj6EPNqZOmBo6zzC8vTEasD8VdUmZ5ZMLT6zD/5LG2 DtiL6N34GOiCsMwipT/sr5oLIF5YUTc+SsobazmOmN7bjy3mhehBZZY4o6BR1QqRl2z/ TAnC6yfUVgtG9GlqZg6abSZO+8gmkkyiCaTNuMzNq3phEYhUZ6QPHktLVqNwiaTK/4jz 3R+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=Q+QuP6xDjyAH2l08JQDGODpKrnjshqywTuVnXVwd2Rc=; b=nfUdPKU2ige0a4AW6apL5m7sr8WkGJ7730utPsFhOGiyBb/OcdDDIo0dzzM+1IwTGR 2XvTaEDdtE1wqk8h7Nvn4cOmybSazlldJTHpO5YzZYoXw5SHbupDKc/Amdi2XgBzhXZD flhYtNKjNTL8jOO7nVVpUVkaI4njmzO9o2HaQeb2/jM9ZqT8x/k7qlLq4R05lTkz2y+q Y7YvAk8x2u1M7UHVzyvQTXxD5zxwPMvdw9oBZn8iKJLxfmz1Q0Kadf0hBZQwjbgBEXgj 39CKXytd+dJJLYM4i3mWA9c5P0gYmj2hCfNH7kKYVmGMfCLMw0ZtqpEbqTfcwnWYIV6q bxdA== X-Gm-Message-State: AOAM533sg8a9V2uuEu3oGBolk1omtWJ9V4Q8G8HT1+1bXomp8acemo1e Q94uvEvj7yQAojHIDVsmKXEci+CcRcI2aFgd7HC2bmY2 X-Google-Smtp-Source: ABdhPJy8YkqegkJsXVTudTfISMNP0s37Yp19S7xy/rHEQV/gfjw+KK1CvHQxLsFyUGqfyhNfV8F+urpwwCVCHF4UBgs= X-Received: by 2002:a92:190f:: with SMTP id 15mr21522300ilz.45.1624984941943; Tue, 29 Jun 2021 09:42:21 -0700 (PDT) MIME-Version: 1.0 References: <532A8EEC-59FD-42F2-8568-4C649677B4B0@itu.dk> <877diekybt.fsf@toke.dk> <87wnqeji2n.fsf@toke.dk> In-Reply-To: From: Dave Taht Date: Tue, 29 Jun 2021 09:42:10 -0700 Message-ID: To: Make-Wifi-fast Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: [Make-wifi-fast] Fwd: [PATCH v2] net: sched: Add support for packet bursting. X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2021 16:42:23 -0000 I really wish we had a better wifi emulation. more below ---------- Forwarded message --------- From: Dave Taht Date: Tue, Jun 29, 2021 at 8:26 AM Subject: Re: [PATCH v2] net: sched: Add support for packet bursting. To: Niclas Hedam Cc: Toke H=C3=B8iland-J=C3=B8rgensen , stephen@networkplumber.org , netdev@vger.kernel.org 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=3D2209336 On Mon, Jun 28, 2021 at 6:24 AM Niclas Hedam 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 fu= lly matched my use-case. > While I now understand that you can actually leverage the slots functiona= lity 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 approa= ching this from the practical performance side per se. > Instead, I argue for seperation with reference to the Seperation of Conce= rn 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 signific= antly 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 main= taining it is pretty trivial. > > I do agree, however, that we should define what would happen if you enabl= e both systems at the same time. > > @Dave: Any thoughts on this? > > > On 28 Jun 2021, at 14:21, Toke H=C3=B8iland-J=C3=B8rgensen wrote: > > > > Niclas Hedam writes: > > > >>>> From 71843907bdb9cdc4e24358f0c16a8778f2762dc7 Mon Sep 17 00:00:00 20= 01 > >>>> From: Niclas Hedam > >>>> 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 t= hey are catering. > >> The slots seems to be focused on networking constraints and duty cycle= s. > >> 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 turn= s > > 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=C3=A4ht CTO, TekLibre, LLC --=20 Latest Podcast: https://www.linkedin.com/feed/update/urn:li:activity:6791014284936785920/ Dave T=C3=A4ht CTO, TekLibre, LLC