[Cake] (SCE) Some Congestion Experienced

[Dave Taht]

Jonathan Morton <chromatix99 at gmail.com> writes:

>> On 6 Jan, 2019, at 8:43 pm, Dave Taht <dave.taht at 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 at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake