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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 [85.13.236.178]) (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 [31.185.128.124] (port=46000 helo=[192.168.0.6]) 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
Ingemar, 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. 2.1 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 separately. 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). 2.1.1 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? 2.1.2 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). 2.3 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? 2.4 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 doesn't. It suggests a generic ECN fall-back draft. It is hard to describe fall-back independent of any specific protocol. 2.6 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. Bob -------- Forwarded Message -------- Subject: Re: Re : Working group acceptance call draft-bagnulo-tcpm-generalized-ecn-04 Date: Sun, 25 Jun 2017 23:17:42 +0100 From: Bob Briscoe <ietf@bobbriscoe.net> To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>, tcpm@ietf.org <tcpm@ietf.org> CC: tcpm-chairs@ietf.org <tcpm-chairs@ietf.org>, marcelo bagnulo braun <marcelo@it.uc3m.es> Ingemar, 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 ECN++. 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. Bob 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/
- Quick review of ECN for QUIC: draft-johansson-qui… Bob Briscoe
- RE: Quick review of ECN for QUIC: draft-johansson… Ingemar Johansson S
- Re: Quick review of ECN for QUIC: draft-johansson… Bob Briscoe