Re: Adding ECN to Transport and Recovery

Dmitri Tikhonov <> Fri, 08 June 2018 15:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B953A130EE9 for <>; Fri, 8 Jun 2018 08:08:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.611
X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] 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 PkZqYg1BOsSH for <>; Fri, 8 Jun 2018 08:08:38 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9017D130EDF for <>; Fri, 8 Jun 2018 08:08:38 -0700 (PDT)
Received: by with SMTP id k86-v6so8923386qkh.13 for <>; Fri, 08 Jun 2018 08:08:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=KXT8gogesKP9x0EIPllSJ2+p3zESi5kCHid3YPUEZkE=; b=KwFzY0q1JCTWKMyKZCLqFM34LBCoZDhvMpBlB2WMNJYE5pZ0uw1YJPJ18Yyb+bmuRg DD6Xk/bd5H0O58m7HZcz98NAqbSI2AtIfIsdBAtVEuFrOk5k412su9fp33ZmiuxoxceF X8+X83jPtbspDZB7LEAy8W4mvfd4iO1c0XeC8dufxlOvK420h0lYoTmtt9LuW42w5jy3 5hYGBjXdJw15nItrqE89Ov+//+Lp7JZXSYFAJjV/oPtU3mmcJPTTR96Jy48kwOGerbqx wtxhhxjN0rjmJ7ifYEOKcWWJxZn6NajIL3Hk1qCESkOuquNqkAFjZDrCs1ZveJqeykIN 8wdQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=KXT8gogesKP9x0EIPllSJ2+p3zESi5kCHid3YPUEZkE=; b=UJrezlmNog/2XEFwMaiSWfaTSDPtuzboE+b/KcGMhd8CNQDIwNfJizDLkHws67V70E fZuUhDhWa/2cg02776ODU+aaBX3Vwir81B464JA/L1f0scZGTTDC69Pffr2zEIZ/Cb2Q 5Xpq6LWwRlvK8X57l8E4yi+5Gcm9gDC3MMyPoU+R8kOmRdq30UcCAGeCyHBPw/oSZsoE LQ9L4AxVGTy+VzJdcu2CcZOW3OilvxF9MJQTYenDdZJgpfD/91e05aivDBcsexvfgx0A kDdDIX/OD9KRLCkp1eunjPp/W/Ak5G2pK0pdFwDxOAuSUHN/TgC+WsncZIFYH2QPPOCd kMBw==
X-Gm-Message-State: APt69E0PSN+Dl0QIq7juahZgvQvjDv6zIQJOzRIKoYEtwqwIUka46Qxd B6qK6EUnNPa0keZbtDtb2paqvB24
X-Google-Smtp-Source: ADUXVKJaYtbkXnwsxiJt8qeC7HaoNFF7PSnaDfK+4rrS5p5szXetsWOslJi7geGLtd/mHvef6RJNNQ==
X-Received: by 2002:a37:951:: with SMTP id 78-v6mr5492855qkj.445.1528470517694; Fri, 08 Jun 2018 08:08:37 -0700 (PDT)
Received: from ubuntu-dmitri ( []) by with ESMTPSA id u22-v6sm29637878qtk.18.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Jun 2018 08:08:37 -0700 (PDT)
Date: Fri, 8 Jun 2018 11:08:35 -0400
From: Dmitri Tikhonov <>
To: Magnus Westerlund <>
Subject: Re: Adding ECN to Transport and Recovery
Message-ID: <20180608150833.GB13418@ubuntu-dmitri>
Mail-Followup-To: Magnus Westerlund <>,
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.24 (2015-08-30)
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 15:08:42 -0000

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.