From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id CE2FE3CB35 for ; Sun, 6 Jan 2019 15:21:13 -0500 (EST) Received: by mail-lj1-x22c.google.com with SMTP id x85-v6so36430573ljb.2 for ; Sun, 06 Jan 2019 12:21:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Ey4Wkc9viW5XrBK4ky5mrpcprd6SEYCOP8xA/vIl8Xw=; b=JA3FNQsQma/VxoMQhaqN7JLSTrpTjjNZwt1qPC49wZCDz/EDnjKoWLmY2pr6WOyWZh 1RCOsj9vqasRGOOip1aFokGNKxG7SWuawI3hk6w13xn9OZm6kSpkjU3ixTGet7EymG34 FbbTV36NL1tZCka7E/+DP9/HrbgXuPrN0/EV/RXHXy/iv97eSs8wBlnEI/6hdarOIoBi mmwT+us0O7wJbVqZ9AyRBE9JZKA5L40lyWpMYw1kL3SWRp7DQi9KZIGFeZpHFPxkACj9 8NgW0Wl4QKvsSuYwEI+cVean/bWwzWknAKb58CHKsfai8jyv3FKNy3GOhbQAy1QmtY1a ER6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Ey4Wkc9viW5XrBK4ky5mrpcprd6SEYCOP8xA/vIl8Xw=; b=HbCwLYI+NSpwf59/JMrCb913K/89/6L+1j1AXTQr76eYhCtvWRtCz4RMkf8GoAzi9v x/Bxcmm9j76rbMsGoqGxtRkRisnWvRooqReNOn/yACLjFnmvC6CrT+6Javs23IdJ7Q9s 0OmX0nyOPw43zIxEdEjlivHiXqeiz42xVwFPQnARBYuF1w7KFXJHisOAVo5YWAzRSrSU r8AakfZJibouodz6rBRvQLyrdusxdJkbj4VWBzFApjNAgMbZvySGNOwpJ+tOTk5IlM80 mSS7AvldgLsZ2yjdYhsuYys4FdVdvWG8wRbH0+iaKhZtyGKn7mOZiDO0nOXH+/nWYuJR PskA== X-Gm-Message-State: AA+aEWbmlv863moOdhiLJnh0/3gWXAceaf0zPGXQ5iQh2ZGbnkZlzD1A teaJ9NoOAhCIlOGCIoYJ7P8= X-Google-Smtp-Source: ALg8bN464r78qN15rWyieWcwAsubuOl0cuWgwoA+I7tHmUTnjWxtDD8Qv99oH710n1rVpOIFwnd3MQ== X-Received: by 2002:a2e:8992:: with SMTP id c18-v6mr32616711lji.17.1546806072603; Sun, 06 Jan 2019 12:21:12 -0800 (PST) Received: from jonathartonsmbp.lan (83-245-238-230-nat-p.elisa-mobile.fi. [83.245.238.230]) by smtp.gmail.com with ESMTPSA id b17-v6sm13611617ljj.93.2019.01.06.12.21.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 06 Jan 2019 12:21:11 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jonathan Morton In-Reply-To: Date: Sun, 6 Jan 2019 22:21:10 +0200 Cc: Cake List Content-Transfer-Encoding: quoted-printable Message-Id: <83285668-C297-4371-8760-B4A5CE138C30@gmail.com> References: To: Dave Taht X-Mailer: Apple Mail (2.3445.9.1) 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: Sun, 06 Jan 2019 20:21:14 -0000 > On 6 Jan, 2019, at 8:43 pm, Dave Taht wrote: >=20 > 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