Quick review of ECN for QUIC: draft-johansson-quic-ecn-03

Bob Briscoe <ietf@bobbriscoe.net> Sun, 25 June 2017 23:31 UTC

Return-Path: <ietf@bobbriscoe.net>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 4268F1270B4 for <quic@ietfa.amsl.com>; Sun, 25 Jun 2017 16:31:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 8mZLgcGVvOWg for <quic@ietfa.amsl.com>; Sun, 25 Jun 2017 16:31:06 -0700 (PDT)
Received: from server.dnsblock1.com (server.dnsblock1.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D54CC126C22 for <quic@ietf.org>; Sun, 25 Jun 2017 16:31:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:MIME-Version:Date:Message-ID:Cc: Subject:From:To:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=RJ2QNLibBu4Lk9vjuQJYEAwHWS9jhNdsI0lVK+dZgqk=; b=Bk8jFHIBrGbEsptd5trFi4Wkqq jk1G38n3p3cY15AkfkOImZEu47MSMORFYHC86ilo1TIbFWA39bXdquGgEu4p+FfHb5XY8Hu8xN8cT mx9DoaiLTHg7Ny7oM4eN6cW7MygnBNMwnkDidBN2ANiMnSWmDqqrHnv1Hz5lI68K4Twk8w5oM55m7 xhOUS/RUYKJXXYSRumPon3rrQD7d6t5zfIgwF/A9/75hHbj7z+Z/fivUHoBeSc3xj5wx4oFbYWxhe FxRTOZHL5Y29YZrUpArDD8uEpsqB2FgeL8YEG0GFDD8zPk0OpMnugR/2TpU9hp6n0xGC9yQk6dPR3 vY2XcEZg==;
Received: from [] (port=46000 helo=[]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from <ietf@bobbriscoe.net>) id 1dPGzd-0001fb-Th; Mon, 26 Jun 2017 00:31:04 +0100
To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
From: Bob Briscoe <ietf@bobbriscoe.net>
Subject: Quick review of ECN for QUIC: draft-johansson-quic-ecn-03
Cc: QUIC IETF mailing list <quic@ietf.org>
Message-ID: <0062c1c4-254c-651f-c091-7f85fc1a28fa@bobbriscoe.net>
Date: Mon, 26 Jun 2017 00:31:01 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------D985351030404B53F1E60F6E"
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/UtfgKna7sQ1q29Xje5OvkeyazJ0>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 25 Jun 2017 23:31:09 -0000


As just promised (on tcpm - pasted below) here's a rushed write-up of 
the high order bits of my review of your draft-johansson-quic-ecn-03.
This is purely a list of my immediate reactions to sentences in the 
draft. I will need longer to think about the protocol as a whole, 
whether this is the best approach, whether there might be a better 
approach, and the open issues you list.

It would be useful to first describe how the protocol would work across 
a network without Byzantine middlebox behaviour and without hobbled 
operating systems that cannot access the ECN field of IP packets. Then 
separately describe fall-back in the face of various ECN failures 

Preferably, let's try to think of a way to support ECN on the very first 
QUIC connection setup datagrams (see comments pasted below about copying 
the techniques in draft-bagnulo-tcpm-generalized-ecn, which depends on 
draft-ietf-tcpm-accurate-ecn for this capability).

In a similar vein, you might want to look at (and even cite) RFC7860 for 
requirements about ECN feedback (it was specifically about TCP, but 
there is stuff there relevant to QUIC too).

The argument for sending an ECN negotiation frame in a packet on its own 
only only makes sense if loss is more likely for packets with a non-zero 
IP-ECN field. Therefore, this should not necessarily be a long-term 
requirement on the protocol.

Why always use CE to test traversal of the IP-ECN field? Setting the ECT 
codepoint that will be used throughout the connection also tests for 
zeroing the ECN field, without risking losing visibility of a CE marking 
introduced in the network.

Define "a failed challenge/response phase". Can't it fail for a 
half-connection, not necessarily for the whole connection?

The mode mechanism of RFC6679 needs to be described, not just 
referenced. Note that draft-ietf-tsvwg-ecn-experimentation intends to 
update RFC6679 in this respect (removing the use of the ECN nonce).

Nit: You assign the names E1 and E2 for the fields for the length of 
each encoding of ECT(0) and ECT(1). It would be less illogical if they 
were called E0 and E1.

The feedback gives the number of marked bytes. It needs to specify which 
headers are (not) included in the byte count. And if a datagram with 
zero bytes is ECN-marked, how do you propose to feed that back (in 
AccECN it feeds back marked packets and marked bytes)?

It says 1 octet overhead if ECN is not supported. Can't the ends send no 
ECN feedback at all if they have disabled ECN during the challenge response?

It suggests using a given pattern to detect the need for fall-back. 
That's a good idea. I think any particular connection should only need 
to include two IP-ECN codepoints in the pattern: the relevant ECT 
codepoint and CE.

You might also want to look at this expired I-D: 
draft-moncaster-tcpm-rcv-cheat which uses CE randomly to verify that the 
receiver feedback is not cheating. You might be able to integrate that 
into the path traversal testing, although I accept that a deterministic 
pattern allows the remote peer to detect problems, whereas a random one 

It suggests a generic ECN fall-back draft. It is hard to describe 
fall-back independent of any specific protocol.

Nit: s/remark/re-mark/ because remark means something different.

A couple of months ago, we were discussing using timestamps on feedback, 
so that fewer ACKs could be sent without losing timing info. Are you 
planning to include that idea in this draft?

That's it for now.


-------- Forwarded Message --------
Subject: 	Re: Re : Working group acceptance call 
Date: 	Sun, 25 Jun 2017 23:17:42 +0100
From: 	Bob Briscoe <ietf@bobbriscoe.net>
To: 	Ingemar Johansson S <ingemar.s.johansson@ericsson.com>om>, 
tcpm@ietf.org <tcpm@ietf.org>
CC: 	tcpm-chairs@ietf.org <tcpm-chairs@ietf.org>rg>, marcelo bagnulo braun 


The draft already says this work shoul be transferable to SCTP. I might
also add a note that it could also benefit QUIC, altho I'd like to see
some detail before presuming this will work.

Coincidentally, I just read your ECN in QUIC draft yesterday. And, also
coincidentally, one of my main comments was going to be that it seems
disappointing that it only "sends an ECN negotiation frame when
connection setup is completed." Retransmission timeouts have to be
conservative during connection set-up whatever the protocol. So the
background level of congestion loss will then lead to unnecessarily
protracted intermittent delays, which will particularly hit short QUIC
flows. So I was going to suggest that you might be able to protect QUIC
connection setup from random congestion loss by an approach similar to

I cannot guarantee that I will have time to write up the other comments
from my review in time for you to use it before the IETF deadline (I am
about to take a week off, returning on 3 Jul). But I will try to do a
quick summary for the QUIC list now.


On 25/06/17 19:03, Ingemar Johansson S wrote:
> Hi
> I support this work.
> In addition, parts of the findings and recommendations in this TCP generalized ECN work may also be useful for the specification of the ECN support in QUIC, currently outlined in (https://tools.ietf.org/id/draft-johansson-quic-ecn-03.txt ).
> Regards
> Ingemar Johansson

Bob Briscoe                               http://bobbriscoe.net/