From: Dave Taht <dave.taht@gmail.com>
To: ECN-Sane <ecn-sane@lists.bufferbloat.net>,
Cake List <cake@lists.bufferbloat.net>
Subject: [Ecn-sane] ECN is off on retransmit by default, upstreaming a bug fix, and some patch cleanup
Date: Mon, 5 Aug 2019 09:00:11 -0700 [thread overview]
Message-ID: <CAA93jw48Jv9GXTaSAgREUOeQq5qYxRyjZEjuNGUE1naanygJfQ@mail.gmail.com> (raw)
I burned yesterday attempting to forward port chromi's SCE branch to
be part of net-next + bbrv2, and I'm mostly there.
(I have a few other non-related kernel things I'm doing)
Three notes thus far:
A) This looks to me to be a generic bug to a nonce OR SCE OR L4S
deployment and should go upstream
static inline int INET_ECN_is_capable(__u8 dsfield)
{
- return dsfield & INET_ECN_ECT_0;
+ return dsfield & INET_ECN_MASK;
}
B)
In terms of upstreaming other stuff, sch_cake should stop filtering
out the nonce in the ack filter (?), and I'd like to add support for
the
new LE codepoint to cake and the sqm-scripts this round. The rfc
depreciates CS1 however, and I don't think that's a good idea.
Cleaning up the former patch a little bit....
#define CAKE_ACK_IGNORE (TCP_FLAG_ECE | TCP_FLAG_CWR | TCP_FLAG_ESCE)
(but it was ironic there wasn't even a define for the NS in the first
place, though)
C) I'd essentially forgotten than on a retransmit, the existing RFCs
turn off ECN capability entirely (falling back to lossy
retransmits in an ancient attempt to keep the impact of ecn lower) -
which bodes ill for the conflicts between L4S and SCE,
and not shown in various prior dctcp benchmarks that previously had no
reaction to loss at all and presumably no or few circumstances
where a loss and retransmit were triggered. (another win for not using
ect1 as an identifier, in that in SCE we don't HAVE to change
this fallback)
I had suggested in a prior mail that when cwnd falls below 2 that ECN
be disabled also in a prior email. Don't know if that's ever been
suggested anywhere.
In some experimental RFC or another setting ECN even on retransmits is
suggested, which I think was a L4S requirement?
case INET_ECN_NOT_ECT:
/* Funny extension: if ECT is not set on a segment,
* and we already seen ECT on a previous segment,
* it is probably a retransmit.
*/
if (tp->ecn_flags & TCP_ECN_SEEN)
tcp_enter_quickack_mode(sk, 2);
break;
--
Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740
reply other threads:[~2019-08-05 16:00 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/ecn-sane.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAA93jw48Jv9GXTaSAgREUOeQq5qYxRyjZEjuNGUE1naanygJfQ@mail.gmail.com \
--to=dave.taht@gmail.com \
--cc=cake@lists.bufferbloat.net \
--cc=ecn-sane@lists.bufferbloat.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox