[Cake] Advantages to tightly tuning latency

[Dave Taht]

On Tue, Apr 21, 2020 at 4:07 PM Jonathan Morton <chromatix99 at gmail.com> wrote:
>
> > On 22 Apr, 2020, at 1:50 am, Dave Taht <dave.taht at gmail.com> wrote:
> >
> > Jon, how's SCE looking? ready for a backport yet?
>
> We can't do any sort of wide deployment of SCE until it's been approved as an Internet experiment by the IETF.

If the present algorithm on the qdisc is stable, I'd like to try it on wifi.

> Interested individuals can already compile the SCE-enabled kernel and jump through the hoops to try things out - carefully.  There's a bit of infrastructure code to go with the new TCP algorithms and qdiscs, so I'm not certain how easy a backport would be; better to just build the (relatively) current code for now.

Not on openwrt. It seemed easy to backport just cake there, and the
rest of the code on dedicated servers and clients. Similarly I'd try
for the wifi attempt also.

I care about the cpu impact a lot. Also a recent string of postings on
netdev that I have had too much PTSD to reply to seem to indicate that
accecn *requires* that the tcp offload engine be disabled, which is
difficult to swallow. Can SCE work with tcp offloads enabled (on the
server, client and qdisc?)?

The same post claimed that apple proved we could "just turn ecn on",
and to explore that claim I updated my osx to the latest only to
immediate find apple's heuristics *disabled* attempts at ecn
negotiation on the second of two rrul tests, and I'd also poked into a
worldwide dataset that showed WAY less ecn attempts making it from
apple gear to the test server.

Another post (which I have not responded to either) pointed to an
improvement in the 3WHS that may or may not be genuinely useful, but
at that point, I went back to fixing wifi with what I knew worked.

The code itself, was not bad. Perhaps some review of that set of
patches and thread is needed by some others with stronger stomachs.

https://www.spinics.net/lists/netdev/msg638882.html


>
> IETF TSVWG interim meeting next week (the second of two replacing planned in-person sessions at Vancouver) will discuss the big ECT(1) issue, which is hotly disputed between SCE and L4S.  The key question is whether ECT(1) should become a classifier input to the network (orthogonal to Diffserv but with some of the same basic problems), or an additional congestion signal output from the network (indicating a lesser degree of congestion, to which a smaller and more nuanced response is desired).  It's anyone's guess how that will turn out, but the technical merit is on our side and that really should count for something.
>
> If you're keeping an eye on the TSVWG list, expect a major bombshell to drop there in the next few days.

I do. I wish more did. Beverage in hand. :)

>  - Jonathan Morton
>


-- 
Make Music, Not War

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-435-0729