From: Dave Taht <dave.taht@gmail.com>
To: Jonathan Morton <chromatix99@gmail.com>
Cc: ECN-Sane <ecn-sane@lists.bufferbloat.net>
Subject: Re: [Ecn-sane] net-next dctcp mod question
Date: Mon, 5 Aug 2019 12:53:57 -0700 [thread overview]
Message-ID: <CAA93jw4dCWMGkFnjLCdLFe4+SvvUtM7UdEwod5H27=s2QTFf8Q@mail.gmail.com> (raw)
In-Reply-To: <F246CC91-1B18-4192-A9B3-EAA708A6596A@gmail.com>
On Mon, Aug 5, 2019 at 12:10 PM Jonathan Morton <chromatix99@gmail.com> wrote:
>
> > On 5 Aug, 2019, at 9:21 pm, Dave Taht <dave.taht@gmail.com> wrote:
> >
> > The SCE tree had two key looking modifications to it that seem to have
> > been superceded by net-next.
> >
> > My reading of the remaining differences seem to be resolved in the
> > state machine where setting the last portion
> > of the SCE patch appears to do a decrease on multiple losses. ? Can I
> > not forward port these?
>
> I basically gave up on the original DCTCP code, and re-implemented it nearly from scratch for DCTCP-SCE. In the process I deleted a lot of unnecessary complications which actually slowed the response by about 1 RTT, and fixed the various bugs which stopped it from responding correctly to loss and RFC-3168 CE marks (though the latter was by design in the original).
Yes, your dctcp_sce.c (
https://github.com/chromi/sce/blob/sce/net/ipv4/tcp_dctcp.c ) is a ton
easier to read than
the mainline one.
(and compared to, like bbrv2, a marvel in simplicity)
>
> I noticed that work had been done on the original when I tried to apply the SCE changes as a patch over the Raspberry Pi tree. Everything applied cleanly besides that. I just deleted that part of the patch and moved on without investigating more deeply.
OK. Hopefully someone more familiar with the logic will show up.
>
> Usefully, you can simulate how DCTCP is supposed to work by mangling CE marks into SCE ones at the receiver (SCE enabled), running DCTCP-SCE at the sender, and inserting your choice of CE marking scheme in the middle. We did that in Montreal to substantiate our calculation of how TCP Prague would react to Codel if it worked as designed.
Yep. I was/am mostly concerned that linux net-next tcp_dctcp.c is
still not reacting properly to loss.
> - Jonathan Morton
>
--
Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740
next prev parent reply other threads:[~2019-08-05 19:54 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-05 18:21 Dave Taht
2019-08-05 19:10 ` Jonathan Morton
2019-08-05 19:53 ` Dave Taht [this message]
2019-08-05 20:00 ` Dave Taht
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='CAA93jw4dCWMGkFnjLCdLFe4+SvvUtM7UdEwod5H27=s2QTFf8Q@mail.gmail.com' \
--to=dave.taht@gmail.com \
--cc=chromatix99@gmail.com \
--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