Re: Adding ECN to Transport and Recovery

Ian Swett <> Fri, 08 June 2018 16:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 55C4B130F2C for <>; Fri, 8 Jun 2018 09:40:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -18.21
X-Spam-Status: No, score=-18.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KfEpTIfgv28F for <>; Fri, 8 Jun 2018 09:40:48 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BC0B0130F29 for <>; Fri, 8 Jun 2018 09:40:48 -0700 (PDT)
Received: by with SMTP id u124-v6so4318997ywg.0 for <>; Fri, 08 Jun 2018 09:40:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=v8HkgXLCuJag5xa8wNLM7L/OS5GkQt5iaBw1HdVCI7E=; b=NSryLvSlhDerRouzyB59q9R8F9v5HSx+ZG0QQ2DrW+LDvFX4xwiTrxclyppIWJ9Few Q9NBBydreovxhVH+GvaAqQ9fhXrJCwSN1c/dcTeCocDTe7xVPFb5w0h0lcyhG1dKvFiy 0nzcwbfweAdu97lMMn+ERH1T0t2QcX4Qm8uuE4VaG8fdJR91TCZlQW7WVxJ5JR+xyUnZ dyH9k1tevKtLcIbqwOvnOTZAqzlCGTpqOwKIbRqfL0dJWf2hdlr2UG9ZveNuUCImm2Qg 9CBhXMj6/TvXBWsln7v/wz+bFpcWG+rQSjAw/ruXxcZC8VMtLUwDBa9BHlUrCdriQzgG V6ww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=v8HkgXLCuJag5xa8wNLM7L/OS5GkQt5iaBw1HdVCI7E=; b=VJmmisNy+N47ELxvI5cQmK/w+OuAqKy8RcUWSweRnV4jZoeAPjyWfLsGGXZTryjv1A YfqZ5wBx5EiJZY3uEIG3tiJS2yOuZQdQnGf6pMaERA1nR5yob5o7gNCpn89nLcDlTQwz v6v1eTQ7E1HhacAq7Y2UbZ8nDxzJ8NtkiI4VcBTx8kMUJTwypl9Mxo3FfqeHp5vdUdsh 9Ujdk3QDAEnfsMwPVULsJ1gloBbaWCCX5voHau1PK9TUXCXzi8eHq64W11gv5hnxN2nR hhQOinrl8SXokJhDnK91cT/zJr9VILkSHK2gYGNj3e39BSwPMWcMpbYR0ZFI0YH7ixtV rWQw==
X-Gm-Message-State: APt69E23SP45dJDGBQPMErVhU9qpJ1uidIjWy8YlPmJHByWdDw8nWmph A+WO41DJcRyeznO8w0E81kmVs5Q5a7JvajAfVwTXSw==
X-Google-Smtp-Source: ADUXVKKMxNoHcMer712wqPyancIu347FYcsQBz+h+IpD/KrCaOUXyISycAauW/xQdvteifbFPyp/w22zHLo7MLdSmBs=
X-Received: by 2002:a81:2406:: with SMTP id k6-v6mr1000946ywk.151.1528476047650; Fri, 08 Jun 2018 09:40:47 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <20180608150833.GB13418@ubuntu-dmitri>
In-Reply-To: <20180608150833.GB13418@ubuntu-dmitri>
From: Ian Swett <>
Date: Fri, 8 Jun 2018 12:40:35 -0400
Message-ID: <>
Subject: Re: Adding ECN to Transport and Recovery
To: Magnus Westerlund <>, IETF QUIC WG <>
Content-Type: multipart/alternative; boundary="000000000000deed52056e240ff7"
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 16:40:50 -0000

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.

On Fri, Jun 8, 2018 at 11:08 AM Dmitri Tikhonov <>

> 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.