Re: [Cake] cake in dd-wrt

[Dave Taht <dave.taht@gmail.com>]

On Wed, Aug 21, 2019 at 3:21 AM Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>
> Dave Taht <dave@taht.net> writes:
>
> > Jonathan Morton <chromatix99@gmail.com> writes:
> >
> >>> On 20 Aug, 2019, at 9:39 pm, Sebastian Gottschall <s.gottschall@newmedia-net.de> wrote:
> >>>
> >>> …a heavy bittorrent downloader will still steal the bandwidth of my scp session.
> >>
> >> If you can identify the Bittorrent packets, you can mark them CS1, and
> >> switch on Cake's "diffserv3" mode (as it is by default).  Then the
> >> Bittorrent packets will still be able to use full bandwidth if it's
> >> available, but will be limited to 1/16th of the total if there is
> >> contention.
> >
> > I regard the whole CS1 thing as having never been particularly
> > successful for a variety of reasons - in particular because
> > we seemed to be the only ones attempting to use it with rigor.
> >
> > I would like to patch in and submit "LE" support to mainline cake.
> >
> > The RFC retires CS1 - which I wouldn't retire - but see:
> >
> > https://www.rfc-editor.org/rfc/rfc8622.html
>
> Yeah, getting support for that upstream might be a good idea :)

I'd put out a patch on a endian-brain-fart day, which I think was
correct?, but didn't get back to it.

Another cleanup thought is to constify the cake invsqrt cache. (and actually
put in totally correct values)

> > Also it seems like a good idea to also submit the NS bit
> > exclusion from the ack filter to mainline as well.
>
> What's that?

https://github.com/chromi/sce/blob/sce/net/sched/sch_cake.c#L1274

A cleaner way would be to have it be

#ifndef TCP_FLAG_ESCE
#define it (I forget where it's defined)
#endif

#define CAKE_FILTER_FLAGS (TCP_FLAG_ECE | TCP_FLAG_CWR | TCP_FLAG_ESCE)

and use that.

>
> -Toke
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake



-- 

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