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

[Sebastian Moeller <moeller0@gmx.de>]

Hi Pete,

if I were to design a high priority lane cutting through all the clutter of other's flows in the LL-queue, I would create a tunnel that asserts ECT(1) but does not react to CEs and simply would employ some FEC to deal with the expected packetloss more gracefully (to take over the queue it should sufficie to suffer less from packet loss than the rest). 
	Et voila, L4S should effectively ceed the LL-queues 15/16th capacity to my data, mwuahaha...

Best Regards
	Sebastian



> On Mar 19, 2021, at 10:18, Pete Heist <pete@heistp.net> wrote:
> 
> ...
> 
> 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