Re: Adding ECN to Transport and Recovery

"Brian Trammell (IETF)" <> Sat, 09 June 2018 11:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6C39D1294D0 for <>; Sat, 9 Jun 2018 04:25:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gsJuSPHPn7Pm for <>; Sat, 9 Jun 2018 04:25:30 -0700 (PDT)
Received: from ( [IPv6:2001:8e0:40:325::36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1E66B130E4D for <>; Sat, 9 Jun 2018 04:25:28 -0700 (PDT)
Received: from (localhost []) by localhost (Postfix) with ESMTP id A8D18340D93; Sat, 9 Jun 2018 13:25:24 +0200 (CEST)
Received: from localhost (localhost []) by localhost (ACF/6030.2023); Sat, 9 Jun 2018 13:25:24 +0200 (CEST)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS; Sat, 9 Jun 2018 13:25:23 +0200 (CEST)
Received: from [] (account HELO []) by (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 57684075; Sat, 09 Jun 2018 13:25:23 +0200
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Subject: Re: Adding ECN to Transport and Recovery
From: "Brian Trammell (IETF)" <>
In-Reply-To: <>
Date: Sat, 9 Jun 2018 13:25:23 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <20180608150833.GB13418@ubuntu-dmitri> <> <> <>
To: Christian Huitema <>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <>
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 09 Jun 2018 11:25:34 -0000

+1 to two frame types; IIRC the suggestion was to add ECN data to the "normal" ACK frame, then have a diminished ACK frame for situations where there is no ECN information to report. The concern here is that having an ACK and an ACK-ECN frame reinforces the incorrect idea that ECN is somehow optional to implement for QUIC, which it should not be.

Half-serious suggestions for the smaller ACK frame included SMACK (small ACK), SHACK (short ACK), or ACK-ICN (Implicit Congestion Notification).



> On 9 Jun 2018, at 02:36, Christian Huitema <> wrote:
> On 6/8/2018 3:17 PM, Kazuho Oku wrote:
>> 2018-06-08 19:40 GMT+03:00 Ian Swett <>
>> :
>>> As Dmitri said, the num blocks is currently a varint, it's not a single byte
>>> like it was in GQUIC, so stealing a bit from it is a bit awkward and would
>>> not change the limit on the number of ack blocks from 256 to 128, and
>>> instead it would decrease it from 2
>>> 62 to 261
>>> .
>>> Can you make the least significant bit of the ACK frame type indicate
>>> whether the ECN section is present, such as by using the 0x0d and 0x0e code
>>> points?  This is basically equivalent to defining two types, admittedly, but
>>> by making the least significant bit the indicator, one could write up the
>>> text as a single frame if people prefer that.
>> +1 to using different frame types. We do not want to introduce
>> complexity for conserving the frame types. That was the conclusion of
>> the extension discussion, wasn't it?
>> I would prefer having different frame types, unless we find a very
>> clean way of encoding ACK and ACK_ECN using a single frame type.
>> Stealing bits from a varint encoding is a haphazard approach that
>> comes with a complexity.
>> Personally, I doubt if we will ever run out of frames types,
>> considering how we have done so far with TLS ContentType and HTTP/2
>> frame type. And if we do run out, we have the luxury of renumbering
>> unlike TCP or TLS, because QUIC encrypts the frame types.
> +1. It is much simpler to have two frame types. And in fact is would be better to not try to be too smart, Ian's suggestion of allocating two consecutive types differing by one bit is cute, but it will create incompatibility with the previous versions for which 0xE means "path challenge". Not a very big deal but still annoying, especially if one attempts to support multiple versions while testing the new one.
> -- Christian Huitema