Re: Adding ECN to Transport and Recovery

Kazuho Oku <> Fri, 08 June 2018 22:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 17A7D130EC7 for <>; Fri, 8 Jun 2018 15:17:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DyjzUMW2k2pf for <>; Fri, 8 Jun 2018 15:17:15 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BDBF1131064 for <>; Fri, 8 Jun 2018 15:17:15 -0700 (PDT)
Received: by with SMTP id w7-v6so7279283pfn.9 for <>; Fri, 08 Jun 2018 15:17:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3dF+8nOA5Jej/IkC0HzTm89UKbvrh6SfNOg4A902+og=; b=ic3wIFBRuLXtDNhkKRim+3Cp52Fn/e42ZVEDfVQZsky7+mbAqEICUW9sVLFPRoz77G esXARDN9UHoDQqtQKMAR5W4d65gn7Mo4cOfAbiJoLJDh8vEqNCoTYqiNm1SxuDZzYHcn usfmFQerZc2uNPiJ0ZAF02qSJ85DkkNqd4Tz7st8DO0pl5k4hP9+CCvcWb3LXfqdNejf aNV69amItb5olFzrlZWniNNBQ1TCwfoYAne0j9rJIspbubStgDiUqNwWAXjbzY14d9AO 7K1nt7RveUMLZD+Oc23irHk3Jd+e7IGeRK2gAqXRcIFlfeXrVBC6d8+GQAhVgdMUDFrf iwTw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3dF+8nOA5Jej/IkC0HzTm89UKbvrh6SfNOg4A902+og=; b=KSU4AWL1X52IXt55CJa7f42+8lzeOT9zg5nHHjc1gG555NDMkRJW5Vhkk/zi97NZ4/ a1WOmeNFHv5wBjNTSgjRoRBIWTkLDLqSoZzpBw6avIYStoH9X6LrK/w3Ev2Cm2V2/5Ic atexHRMyzAkdvAdr8f4fCheIa+nghYBfhB2/riBM9aPPWK9ZvAB7G9UhMk/cRNg/H3pV U3SxMDGQuxh3okzBBCS9jikVs1Lj7mZSJvX4hyGAXGLHanMh37q0fz2A0l3VmZulnjOh tL6jr3NB0Haj1F49SQ/o+6MMjCXklAGhFRT3UymBfNoPDhLbJfFdt0Ou+1jE6bVp2h72 4V3A==
X-Gm-Message-State: APt69E343fl+y91dGc+2rmQB15MVL7/fnc+0AIbTrF9SMtxS+ddIPA5H 1jqhp8k6ktkSVFYOLvsEICA9nLm1Kgz6KI8gomI=
X-Google-Smtp-Source: ADUXVKI/vZ+3/tBDyb5ilZH3etPD9IvWKq1Q1yDC7xGDfVI+VNwK/dVAJ4NwLHM8tLhxcHg8Fkz3ifaEgfj81+cP/vg=
X-Received: by 2002:a63:6e08:: with SMTP id j8-v6mr6684428pgc.428.1528496235075; Fri, 08 Jun 2018 15:17:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a17:90a:1181:0:0:0:0 with HTTP; Fri, 8 Jun 2018 15:17:14 -0700 (PDT)
In-Reply-To: <>
References: <> <> <20180608150833.GB13418@ubuntu-dmitri> <>
From: Kazuho Oku <>
Date: Sat, 9 Jun 2018 01:17:14 +0300
Message-ID: <>
Subject: Re: Adding ECN to Transport and Recovery
To: Ian Swett <>
Cc: Magnus Westerlund <>, IETF QUIC WG <>
Content-Type: text/plain; charset="UTF-8"
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: Fri, 08 Jun 2018 22:17:21 -0000

2018-06-08 19:40 GMT+03:00 Ian Swett <>rg>:
> 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 2^61.
> 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.

> On Fri, Jun 8, 2018 at 11:08 AM Dmitri Tikhonov
> <> wrote:
>> On Fri, Jun 08, 2018 at 04:51:36PM +0200, Magnus Westerlund wrote:
>> > My understanding of the views at the interim was that eliminating the
>> > additional ACK_ECN frame was desired.
>> That is my understanding as well.
>> > I will next update the pull request to use an updated ACK frame with a
>> > signaling bit for the present or absence of the ECN counters. The plan
>> > is to steal a bit in the ACK Block count and make that into a fixed
>> > 7-bit field rather than a variable length encoding.  Limiting an ACK
>> > Frame to 128 ACK blocks.
>> Even though I don't have strong feelings about this, I wonder if there
>> is another way.  The ACK frame (Section 7.15 of
>> [draft-ietf-quic-transport-12]) is all varints.  Changing a field to a
>> fixed encoding would go against the "flavor of the frame," if one may
>> say so.  Perhaps we could keep the varint encoding and interpret the
>> decoded value as an ORed block count with the ECN bit (the low bit)?
>> Introducing an artifial limit to where there was none is a separate
>> discussion.  Perhaps 128 blocks is really enough for all practical
>> purposes.  And yet: at some point the block limit was removed as we
>> went from gQUIC to IETF QUIC...
>>   - Dmitri.

Kazuho Oku