[Ecn-sane] net-next dctcp mod question

[Ecn-sane] net-next dctcp mod question

[Dave Taht]

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?

--- a/net/ipv4/tcp_dctcp.c
+++ b/net/ipv4/tcp_dctcp.c
@@ -110,7 +110,7 @@ static u32 dctcp_ssthresh(struct sock *sk)

 static void dctcp_update_alpha(struct sock *sk, u32 flags)
 {
-       const struct tcp_sock *tp = tcp_sk(sk);
+       struct tcp_sock *tp = tcp_sk(sk);
        struct dctcp *ca = inet_csk_ca(sk);

        /* Expired RTT */
@@ -138,6 +138,7 @@ static void dctcp_update_alpha(struct sock *sk, u32 flags)
                 */
                WRITE_ONCE(ca->dctcp_alpha, alpha);
                dctcp_reset(tp, ca);
+               tp->snd_cwnd = dctcp_ssthresh(sk);
        }
 }

@@ -147,6 +148,7 @@ static void dctcp_react_to_loss(struct sock *sk)
        struct tcp_sock *tp = tcp_sk(sk);

        ca->loss_cwnd = tp->snd_cwnd;
+       tp->snd_cwnd = max(tp->snd_cwnd >> 1U, 2U);
        tp->snd_ssthresh = max(tp->snd_cwnd >> 1U, 2U);
 }



-- 

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

Re: [Ecn-sane] net-next dctcp mod question

[Jonathan Morton]

> 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).

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.

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.

 - Jonathan Morton

Re: [Ecn-sane] net-next dctcp mod question

[Dave Taht]

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

Re: [Ecn-sane] net-next dctcp mod question

[Dave Taht]

On Mon, Aug 5, 2019 at 12:53 PM Dave Taht <dave.taht@gmail.com> wrote:
>
> 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.
>

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