Re: Adding ECN to Transport and Recovery

Ian Swett <ianswett@google.com> Sat, 09 June 2018 15:28 UTC

Return-Path: <ianswett@google.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 17731130EA0 for <quic@ietfa.amsl.com>; Sat, 9 Jun 2018 08:28:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.309
X-Spam-Level:
X-Spam-Status: No, score=-16.309 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 TZGEaLEBhUuT for <quic@ietfa.amsl.com>; Sat, 9 Jun 2018 08:27:59 -0700 (PDT)
Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (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 17BA9130E9E for <quic@ietf.org>; Sat, 9 Jun 2018 08:27:59 -0700 (PDT)
Received: by mail-yw0-x231.google.com with SMTP id u124-v6so5058364ywg.0 for <quic@ietf.org>; Sat, 09 Jun 2018 08:27:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zppV3DHx7ouu95jAElVdyG1z+URLzIMWrGpksUCRUNk=; b=PwS17KHkfHcsnkUXUPZmf/QPHCIQAw8nngmbn8t+hkC3rwXudLtGcW7cqQh9C11U/0 YlOUOyboghHRe614FJhpWSeohVDAEWe2hiZ2uMCkwicDvLcMD7tFu3Xu/AE3O+1fG2zm C5vfP8xR16l2DoZRks3BFVN722PXrpZJmblhJT6veb9SSf9bYQcQcx47cRc7yEdNeNQN AicYWh2uNFHOqk32rOh49EOf1E9YjJwDtLfxhQRaGgJvaxfNqyAqSP16klrrGOscknQ7 RezYAIIFFWTGXK0ZznD6JUUUKZmJ/pt3MXIBgYaHjs6o1vkRIlULiwVXKzZIO2Ud2g+e IFzw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zppV3DHx7ouu95jAElVdyG1z+URLzIMWrGpksUCRUNk=; b=XzOYRXMfasbSwqNIlhqpjjPxvu/FaP2H4VvZwJk/5ByGmLmKdNiyKHymRANXdc29/y gxQYckw02+k/7AoOENo+aOSMsX45yhXqpHRyJ+LVL7BZfvC8t1PQkzKxWhPKDodDAebi H50+kicms2xhtOxI4Xl/FIR6RsbNAY/FPHWKOw0TeiavELXZbSGlQoibR5+OojOcqSRC GAnFP2QuUlNkGjT3wQK0aBJSfTt04aHgUDdK9F7uUGAocLtup7LBBIlAmxvMfCXsKA76 fJr0u4j8B82TW8flpXQZF6VMf3q67KAEQ3ux1rmzSzZLCG4QpBAHGD40sHkIx5/12G/H cQnA==
X-Gm-Message-State: APt69E0yhTAav1TiqzJ3mSeYR9Lp09Jp6SK/sWAmBWxyVgAcDQFDChRj 7uDlRPXEgQxjUZqcIZnmz1QxRogolgJD6PXNqaikRA==
X-Google-Smtp-Source: ADUXVKJ9hjGc7wSvzZxZQgWbpxGMfJNtNnZKphSYB16Fd3Uh1kk8X9topxy9ZpBTfVaJy+OZB8hG9hfdfJYun0XsUPc=
X-Received: by 2002:a81:2406:: with SMTP id k6-v6mr3183939ywk.151.1528558077727; Sat, 09 Jun 2018 08:27:57 -0700 (PDT)
MIME-Version: 1.0
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> <790ec098-9ec9-5eff-4785-d71d9ac92059@huitema.net> <73B82E99-EFEE-4DBC-A2CA-8FA381F33C5E@trammell.ch>
In-Reply-To: <73B82E99-EFEE-4DBC-A2CA-8FA381F33C5E@trammell.ch>
From: Ian Swett <ianswett@google.com>
Date: Sat, 9 Jun 2018 11:27:45 -0400
Message-ID: <CAKcm_gN-s0XVsGL2LLusvcm5_hp-Z5_9OFMkwph5m_bGMDbAtQ@mail.gmail.com>
Subject: Re: Adding ECN to Transport and Recovery
To: Brian Trammell <ietf@trammell.ch>
Cc: Christian Huitema <huitema@huitema.net>, IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003ea0f4056e37290b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/7oU8a2eWo_JVQM0x9lH7vzL18xo>
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 15:28:01 -0000

QUIC is complex enough, I think we should just call them ACK and ACK_ECN.
A few implementations sending at least one ACK_ECN frame per connection
will dispel any belief that ACK_ECN is optional.  A small amount of use
will be a lot more valuable than clever naming.

On Sat, Jun 9, 2018 at 7:25 AM Brian Trammell (IETF) <ietf@trammell.ch>
wrote:

> +1 to two frame types; IIRC the suggestion was to add ECN data to the
> "normal" ACK frame, then have a diminished ACK frame for situations where
> there is no ECN information to report. The concern here is that having an
> ACK and an ACK-ECN frame reinforces the incorrect idea that ECN is somehow
> optional to implement for QUIC, which it should not be.
>
> Half-serious suggestions for the smaller ACK frame included SMACK (small
> ACK), SHACK (short ACK), or ACK-ICN (Implicit Congestion Notification).
>
> Cheers,
>
> Brian
>
> > On 9 Jun 2018, at 02:36, Christian Huitema <huitema@huitema.net> wrote:
> >
> > 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>
> >> :
> >>
> >>> 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 261
> >>> .
> >>>
> >>> 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
>
>