[Ecn-sane] net-next dctcp mod question

Dave Taht dave.taht at gmail.com
Mon Aug 5 16:00:34 EDT 2019


On Mon, Aug 5, 2019 at 12:53 PM Dave Taht <dave.taht at gmail.com> wrote:
>
> On Mon, Aug 5, 2019 at 12:10 PM Jonathan Morton <chromatix99 at gmail.com> wrote:
> >
> > > On 5 Aug, 2019, at 9:21 pm, Dave Taht <dave.taht at 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.
>

oops, meant to point to this:

https://github.com/chromi/sce/blob/sce/net/ipv4/tcp_dctcp_sce.c

I'm still not convinced either is "correct" but that's why I compile things.

> (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



-- 

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


More information about the Ecn-sane mailing list