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