Re: Adding ECN to Transport and Recovery

Christian Huitema <huitema@huitema.net> Sat, 09 June 2018 00:36 UTC

Return-Path: <huitema@huitema.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 AD0DE130DFA for <quic@ietfa.amsl.com>; Fri, 8 Jun 2018 17:36:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 u7pYnd8CRk5Q for <quic@ietfa.amsl.com>; Fri, 8 Jun 2018 17:36:43 -0700 (PDT)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 490BE130DE4 for <quic@ietf.org>; Fri, 8 Jun 2018 17:36:43 -0700 (PDT)
Received: from xsmtp05.mail2web.com ([168.144.250.245]) by mx37.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1fRRrz-0006V6-Jj for quic@ietf.org; Sat, 09 Jun 2018 02:36:40 +0200
Received: from [10.5.2.31] (helo=xmail09.myhosting.com) by xsmtp05.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1fRRrt-0006pn-VB for quic@ietf.org; Fri, 08 Jun 2018 20:36:38 -0400
Received: (qmail 15159 invoked from network); 9 Jun 2018 00:36:32 -0000
Received: from unknown (HELO [192.168.0.104]) (Authenticated-user:_huitema@huitema.net@[172.56.42.97]) (envelope-sender <huitema@huitema.net>) by xmail09.myhosting.com (qmail-ldap-1.03) with ESMTPA for <quic@ietf.org>; 9 Jun 2018 00:36:32 -0000
To: quic@ietf.org
References: <26584f2a-230b-c55e-db16-d32225c8ee4d@ericsson.com> <5a82e9ef-971f-6510-866c-9886e73796a9@ericsson.com> <20180608150833.GB13418@ubuntu-dmitri> <CAKcm_gM_OHgWcJ+ktAg9BCQx1rtHc9GFg2bZG40-NcO2MoVG9w@mail.gmail.com> <CANatvzySuzK9EO13m_UQxb4wZkYW=+6By3QMU5gKXhq69gaUag@mail.gmail.com>
From: Christian Huitema <huitema@huitema.net>
Openpgp: preference=signencrypt
Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= xsBNBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAHNJ0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PsLAeQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1bOwE0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAcLBfgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8=
Message-ID: <790ec098-9ec9-5eff-4785-d71d9ac92059@huitema.net>
Date: Fri, 8 Jun 2018 17:36:28 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <CANatvzySuzK9EO13m_UQxb4wZkYW=+6By3QMU5gKXhq69gaUag@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------57303DE16CC9EE879A1B9469"
Content-Language: en-US
Subject: Re: Adding ECN to Transport and Recovery
X-Originating-IP: 168.144.250.245
X-AntiSpamCloud-Domain: xsmtpout.mail2web.com
X-AntiSpamCloud-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-AntiSpamCloud-Outgoing-Class: unsure
X-AntiSpamCloud-Outgoing-Evidence: Combined (0.38)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5opjpzIzbmRh96R8q3B8Ik9602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiVifAQXhO2+HSibRNEjbiq3Ks7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pB1c1FPznmLv13i1NL5aXaHx/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8lRJSPf/SXbEnDSsal/zZzc4n9VZdr7RAFD5mRwooUYhwMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjpVMhqNcdjhoIlgrKzBvjTmdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJgawbllbHk+xyUKopM6rc KCaQX/lIXcRWtobViGg9fpU1moK5+umQAfdUHagyvOVYOLJMkQ9To4JqzagQVo4NfUcW/npAtc21 1XqrIPm5MJVz1HQkoj+jjvmw3UQ3Zextr+7/jg66NXUoieIpLIJirIV7hPvBDpgDmC+XXO9ws5qS dbWrmlMqpoC2dVXCySAVqutd2F/yaZGqnwJYwSpQ91YE7tCqypI5WX0qWh4YQLCQTFu6teL8aiVr EyEjJND2br8Ks0SqCpRWIiXMtOo8/pI8jnU4taLGlA8rnD8bXLXekflWG4A3HDBzBq/sLmCzQKHY 6H+wSCoVvwvquzDDiP1kW3XKN6SjV/ce7POAEs6Ydub/YU/cH64QiTAnRDmAKMFEHS3+vt/Njsed NDmPw/Ld14/y82ebPziYNS9mrGcHWFhVQvKDd9aHm1tzPaYBnxycJOQKmrvtOUL1jquCMfd5HnMi k4ibTRVHi8subW0=
X-Report-Abuse-To: spam@quarantine6.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/nIkF2cGU9xJQCaaiPkVG_8cRAOY>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.26
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: Sat, 09 Jun 2018 00:36:46 -0000

On 6/8/2018 3:17 PM, Kazuho Oku wrote:

> 2018-06-08 19:40 GMT+03:00 Ian Swett <ianswett=40google.com@dmarc.ietf.org>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.

+1. It is much simpler to have two frame types. And in fact is would be
better to not try to be too smart, Ian's suggestion of allocating two
consecutive types differing by one bit is cute, but it will create
incompatibility with the previous versions for which 0xE means "path
challenge". Not a very big deal but still annoying, especially if one
attempts to support multiple versions while testing the new one.

-- Christian Huitema