[Cake] (SCE) Some Congestion Experienced

[Cake] (SCE) Some Congestion Experienced

[Dave Taht]

I am thinking of making a go at jon's alternate ecn approach in the
ietf, before the dual-q draft gets any further. It's not just that the
latest draft specifes that all classic traffic get 1/4th the
bandwidth, but the total lack of analyzable source code and the frand
patent...

 https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-tsvwg-aqm-dualq-coupled

thing is, I can't remember what he called it (EWR?), nor when/where it
was discussed. Nor if there was a novel solution to the ece bit on the
ack side?

It turns out to be really easy to gradually mark packets by modifying
the one line in item 3 (ce_threshold) here:

https://lists.bufferbloat.net/pipermail/codel/2018-August/002367.html
-- 

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

Re: [Cake] (SCE) Some Congestion Experienced

[Jonathan Morton]

> On 6 Jan, 2019, at 8:43 pm, Dave Taht <dave.taht@gmail.com> wrote:
> 
> thing is, I can't remember what he called it (EWR?), nor when/where it
> was discussed. Nor if there was a novel solution to the ece bit on the
> ack side?

I think I was calling it ELR - Explicit Load Regulation.

My current thinking on the feedback from receiver to sender is to use a new TCP option containing the ratio of ECT(0) to ECT(1) seen in the past (approximate) RTT.  If we specify that option to subsume TCP Timestamps - which we can use to reliably determine RTT windows - then we should be able to obtain 16 bits of data without actually enlarging the header, because Timestamps is usually preceded by two padding bytes for 32-bit alignment of the data fields within the header.  If the receiver doesn't support the option, then we can seamlessly fall back to standard behaviour with the old Timestamps option.

The only other "spare" data field I'm aware of is the Urgent pointer, which is 16 bits and has no RFC meaning when the URG flag isn't set.  Relatively few applications use URG at all, and even those probably use it only sparingly, and not at all within pure acks.  That might avoid needing to allocate a TCP option number, but we'd still need to figure out a reliable way to negotiate its use between the endpoints.

 - Jonathan Morton

Re: [Cake] (SCE) Some Congestion Experienced

[Dave Taht]

Jonathan Morton <chromatix99@gmail.com> writes:

>> On 6 Jan, 2019, at 8:43 pm, Dave Taht <dave.taht@gmail.com> wrote:
>> 
>> thing is, I can't remember what he called it (EWR?), nor when/where it
>> was discussed. Nor if there was a novel solution to the ece bit on the
>> ack side?
>
> I think I was calling it ELR - Explicit Load Regulation.
>
> My current thinking on the feedback from receiver to sender is to use
> a new TCP option containing the ratio of ECT(0) to ECT(1) seen in the

There are no TCP options left. However the QUIC standard is becoming
HTTP 3, and there is certainly room in QUIC to provide more than a
single bit of congestion feedback. 

> past (approximate) RTT.  If we specify that option to subsume TCP
> Timestamps - which we can use to reliably determine RTT windows - then
> we should be able to obtain 16 bits of data without actually enlarging
> the header, because Timestamps is usually preceded by two padding
> bytes for 32-bit alignment of the data fields within the header.  If
> the receiver doesn't support the option, then we can seamlessly fall
> back to standard behaviour with the old Timestamps option.

Hmm.

> The only other "spare" data field I'm aware of is the Urgent pointer,
> which is 16 bits and has no RFC meaning when the URG flag isn't set.

The biggest barrier to urgent has always been strict firewalls not
allowing it.

> Relatively few applications use URG at all, and even those probably
> use it only sparingly, and not at all within pure acks.  That might
> avoid needing to allocate a TCP option number, but we'd still need to
> figure out a reliable way to negotiate its use between the endpoints.
>
>  - Jonathan Morton
>
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake