Re: [Ecn-sane] re-marking ECT(1) to ECT(0) (was: mosh ecn bits washed out)

[Pete Heist <pete@heistp.net>]

...

On Fri, 2021-03-19 at 09:56 +0100, Sebastian Moeller wrote:
> Hi Pete,
> 
> > On Mar 19, 2021, at 09:25, Pete Heist <pete@heistp.net> wrote:
> > 
> > Meaning, the negotiation succeeds and ECT(0) is set going up, but
> > zeroed on packets by the time they come down?
> > 
> > The negotiation can also be blocked with iptables --ecn-tcp-remove,
> > which just zeroes out ECE and CWR, preventing negotiation
> > (https://git.netfilter.org/iptables/tree/extensions/libipt_ECN.c),
> > but
> > I doubt that's very commonly done.
> 
>         Oh, that looks interesting, probably not too hard to extend
> this to also allow to selectively only re-map ECT(1) and or ECT(0). I
> wonder what TCP Prague would do if its ECT(1) flows are switched to
> ECT(0) in transit?

I suspect it would then dominate all traffic in the C queue, or any
other RFC3168 signalling queue
(https://github.com/heistp/l4s-tests/#unsafety-in-shared-rfc3168-queues
). That might be an easy way to game the dual queue for higher
throughput.

Pete

> Best Regards
>         Sebastian
> 
> > 
> > On Thu, 2021-03-18 at 13:00 -0700, Dave Taht wrote:
> > > mosh, which has long had excellent support for ecn, appears to be
> > > getting the
> > > ecn bit washed out along my path from california to england.
> > > 
> > > ecn survives up that way, but not down.
> > > 
> > > Just a single data point thus far.
> > > 
> > 
> > 
> > _______________________________________________
> > Ecn-sane mailing list
> > Ecn-sane@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/ecn-sane
>