Re: Adding ECN to Transport and Recovery

Kazuho Oku <kazuhooku@gmail.com> Fri, 08 June 2018 22:17 UTC

Return-Path: <kazuhooku@gmail.com>
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 17A7D130EC7 for <quic@ietfa.amsl.com>; Fri, 8 Jun 2018 15:17:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 DyjzUMW2k2pf for <quic@ietfa.amsl.com>; Fri, 8 Jun 2018 15:17:15 -0700 (PDT)
Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDBF1131064 for <quic@ietf.org>; Fri, 8 Jun 2018 15:17:15 -0700 (PDT)
Received: by mail-pf0-x22d.google.com with SMTP id w7-v6so7279283pfn.9 for <quic@ietf.org>; Fri, 08 Jun 2018 15:17:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3dF+8nOA5Jej/IkC0HzTm89UKbvrh6SfNOg4A902+og=; b=ic3wIFBRuLXtDNhkKRim+3Cp52Fn/e42ZVEDfVQZsky7+mbAqEICUW9sVLFPRoz77G esXARDN9UHoDQqtQKMAR5W4d65gn7Mo4cOfAbiJoLJDh8vEqNCoTYqiNm1SxuDZzYHcn usfmFQerZc2uNPiJ0ZAF02qSJ85DkkNqd4Tz7st8DO0pl5k4hP9+CCvcWb3LXfqdNejf aNV69amItb5olFzrlZWniNNBQ1TCwfoYAne0j9rJIspbubStgDiUqNwWAXjbzY14d9AO 7K1nt7RveUMLZD+Oc23irHk3Jd+e7IGeRK2gAqXRcIFlfeXrVBC6d8+GQAhVgdMUDFrf iwTw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3dF+8nOA5Jej/IkC0HzTm89UKbvrh6SfNOg4A902+og=; b=KSU4AWL1X52IXt55CJa7f42+8lzeOT9zg5nHHjc1gG555NDMkRJW5Vhkk/zi97NZ4/ a1WOmeNFHv5wBjNTSgjRoRBIWTkLDLqSoZzpBw6avIYStoH9X6LrK/w3Ev2Cm2V2/5Ic atexHRMyzAkdvAdr8f4fCheIa+nghYBfhB2/riBM9aPPWK9ZvAB7G9UhMk/cRNg/H3pV U3SxMDGQuxh3okzBBCS9jikVs1Lj7mZSJvX4hyGAXGLHanMh37q0fz2A0l3VmZulnjOh tL6jr3NB0Haj1F49SQ/o+6MMjCXklAGhFRT3UymBfNoPDhLbJfFdt0Ou+1jE6bVp2h72 4V3A==
X-Gm-Message-State: APt69E343fl+y91dGc+2rmQB15MVL7/fnc+0AIbTrF9SMtxS+ddIPA5H 1jqhp8k6ktkSVFYOLvsEICA9nLm1Kgz6KI8gomI=
X-Google-Smtp-Source: ADUXVKI/vZ+3/tBDyb5ilZH3etPD9IvWKq1Q1yDC7xGDfVI+VNwK/dVAJ4NwLHM8tLhxcHg8Fkz3ifaEgfj81+cP/vg=
X-Received: by 2002:a63:6e08:: with SMTP id j8-v6mr6684428pgc.428.1528496235075; Fri, 08 Jun 2018 15:17:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a17:90a:1181:0:0:0:0 with HTTP; Fri, 8 Jun 2018 15:17:14 -0700 (PDT)
In-Reply-To: <CAKcm_gM_OHgWcJ+ktAg9BCQx1rtHc9GFg2bZG40-NcO2MoVG9w@mail.gmail.com>
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>
From: Kazuho Oku <kazuhooku@gmail.com>
Date: Sat, 9 Jun 2018 01:17:14 +0300
Message-ID: <CANatvzySuzK9EO13m_UQxb4wZkYW=+6By3QMU5gKXhq69gaUag@mail.gmail.com>
Subject: Re: Adding ECN to Transport and Recovery
To: Ian Swett <ianswett=40google.com@dmarc.ietf.org>
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>, IETF QUIC WG <quic@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/OCbUmN_vBQcBB25MdQ8cSgaLiK0>
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: Fri, 08 Jun 2018 22:17:21 -0000

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.

>
> On Fri, Jun 8, 2018 at 11:08 AM Dmitri Tikhonov
> <dtikhonov@litespeedtech.com> wrote:
>>
>> 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.
>>
>



-- 
Kazuho Oku