From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.taht.net (mail.taht.net [176.58.107.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 1A3D93B29E for ; Sat, 19 Jan 2019 09:34:02 -0500 (EST) Received: from dancer.taht.net (unknown [IPv6:2603:3024:1536:86f0:eea8:6bff:fefe:9a2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id B50002289E; Sat, 19 Jan 2019 14:34:00 +0000 (UTC) From: Dave Taht To: Jonathan Morton Cc: Dave Taht , Cake List References: <83285668-C297-4371-8760-B4A5CE138C30@gmail.com> Date: Sat, 19 Jan 2019 06:33:21 -0800 In-Reply-To: <83285668-C297-4371-8760-B4A5CE138C30@gmail.com> (Jonathan Morton's message of "Sun, 6 Jan 2019 22:21:10 +0200") Message-ID: <87lg3gogy6.fsf@taht.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Cake] (SCE) Some Congestion Experienced X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2019 14:34:02 -0000 Jonathan Morton writes: >> On 6 Jan, 2019, at 8:43 pm, Dave Taht 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