[Ecn-sane] a data point on syn and dscp

[Ecn-sane] a data point on syn and dscp

[Dave Taht]

I have been noticing some syn packets get marked AF21 in transit. I
haven't looked into it hard as yet,
but it might be a useful statistic to be collecting from various vantage points.

secondly, I am under the impression that linux now paces even the
initial iw based on the syn/ack pairb,
but haven't tracked it very much. Is this true? I haven't built a
kernel in ages, nor reviewed git logs. Trying to get on it now.

Now, I don't mind if the syn or syn/ack are getting prioritized very
much - delay in one direction
does not equal the delay in the other, but it does lead to a slight
mis-estimate as to how to fill the pipe
with that initial burst being prioritized outside the main fifo.
(fq_codel of course, essentially offers
zero delay and a correct estimate of the length of the pipe for both
kinds of packet)

this leads to my final question in that early sce and l4s experiments
did have a lot of trouble with having to pace the initial burst, and I
don't know what is actually done there, now, in current oses.

-- 
"For a successful technology, reality must take precedence over public
relations, for Mother Nature cannot be fooled" - Richard Feynman

dave@taht.net <Dave Täht> CTO, TekLibre, LLC Tel: 1-831-435-0729

Re: [Ecn-sane] SCE pacing (was: a data point on syn and dscp)

[Pete Heist]

Not sure if this covers it, but there was a brief time before we had
enabled pacing programmatically in our TCP CCAs. There's a sysctl with
default:

net.ipv4.tcp_sce_pacing = 1

and in each CCA:

if (sock_net(sk)->ipv4.sysctl_tcp_sce_pacing)
    cmpxchg(&sk->sk_pacing_status, SK_PACING_NONE, SK_PACING_NEEDED);

This should enable the internal pacing mechanism in the kernel, which
is different from the one used by the fq qdisc, iirc.

On Tue, 2021-03-09 at 10:58 -0800, Dave Taht wrote:
> 
> this leads to my final question in that early sce and l4s experiments
> did have a lot of trouble with having to pace the initial burst, and I
> don't know what is actually done there, now, in current oses.
>