IETF Logo Mail Archive

Re: Consensus Calls for Late Stage Documents

Jana Iyengar <jri.ietf@gmail.com> Wed, 15 January 2020 23:11 UTC

Return-Path: <jri.ietf@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 8538E120855 for <quic@ietfa.amsl.com>; Wed, 15 Jan 2020 15:11:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 Wz1H61_Uiop8 for <quic@ietfa.amsl.com>; Wed, 15 Jan 2020 15:11:22 -0800 (PST)
Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (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 9139F120639 for <quic@ietf.org>; Wed, 15 Jan 2020 15:11:22 -0800 (PST)
Received: by mail-lj1-x236.google.com with SMTP id l2so20408054lja.6 for <quic@ietf.org>; Wed, 15 Jan 2020 15:11:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vN/TiegxCLIqTsw0yZKTXtZn0+uk8CvvvbiSymW/ab8=; b=dDIxPo76H96vmOc+etN314E4M41AjfYHTHwp95pr5DEyGcojwnFl4/7VwCHW+RZzDO sTIKyPbCiCkTUBsGUzRPLH4YGgXLtoagii6/6yOhCD7lA/0aQEFnhZpccqfD9OgnJJpd FtxaeFsyaCWffa7evM5iIrY4diECaSUDCjIVZ8Ornx+y5fGgJqlLxwznwokfSJ6U1AX2 9PvcPW9lCP5z7jTcRA6uZ/YWKIOnQQDLbbxCpVln3jPujxy7vsKy+wMimUEMGKnqH0rw +Q55LhFHC0SRirQGtk48YMVm8bhcp+WO/kSyl7i3Ca/rKXJ2SuK4ZI5f1THrgr/OBZfP FdQA==
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=vN/TiegxCLIqTsw0yZKTXtZn0+uk8CvvvbiSymW/ab8=; b=rHEKY3yqcDtmwvyxZKfd14G5JuGSs1prJGMc6fEKoLBJ8ce0P5rAlfDQ8xZip89AlM A2EvyJniSJs/82ouNhvL7F5QIlTFmpvGQLusqIu5xtwIw+Jza7WHdXgRPA1CJ7amiBgv WOVX8oG+sdTf1om/wT/QE6R4GR0U4pHFTuh584RsjvNEGwrYeOo8pDH7DP+GzXpyF2fd CRjKpLOa+2xdQv1jTdrHd0jWHPigUhvTgceBxj+gA/op74pDvH90UR/0gCdHphF+vcJ0 ykFdmHvXJfWaxTHifF2p2YmUWlgyeAo6saGUFOTpg1N1IYKdlfEI4sZ3cYJP4nRpJnqV f/Sw==
X-Gm-Message-State: APjAAAXrvpAz38vF6SxOlULYoXpVbIy9wPDf3lTMjTFDRu1aC2zqn+Ai r3hYf6sFfTx8MfaVBvZggHchn6z6bVejbY3ZTas=
X-Google-Smtp-Source: APXvYqwW5B2ma8t/9QNjPr2I28tFSz8dB3WhVwl2HiqAqFqm+3ESPoILscvAeQFPGYtPY7Yf/j0H2QjWyWOlAIGYmPY=
X-Received: by 2002:a2e:8015:: with SMTP id j21mr432956ljg.172.1579129880823; Wed, 15 Jan 2020 15:11:20 -0800 (PST)
MIME-Version: 1.0
References: <43D8DACA-C1C4-449A-A4BC-4F0E6F8F1CAB@mnot.net> <247B1759-7D5C-436D-B6C5-BC2AF2479366@apple.com> <CACpbDccumYO5jmhFbq-MiFtw-zmHn2TpLP+hdeUSskdn5UmDcw@mail.gmail.com> <02B7142E-B5EF-418F-9F52-0105FD770755@apple.com> <CACpbDccADNWdBdPSVkVNLwEWJ8g6ZuD8AHzP_doqA96CZgdRwA@mail.gmail.com> <60DC738C-6465-4797-BCFC-227944E8CB93@apple.com>
In-Reply-To: <60DC738C-6465-4797-BCFC-227944E8CB93@apple.com>
From: Jana Iyengar <jri.ietf@gmail.com>
Date: Wed, 15 Jan 2020 15:11:09 -0800
Message-ID: <CACpbDcctOtTbkL0GKkeaoGiiT+9U_tRvO0u-GZ1jKdsAMOSOuA@mail.gmail.com>
Subject: Re: Consensus Calls for Late Stage Documents
To: Tommy Pauly <tpauly@apple.com>
Cc: Christoph Paasch <cpaasch@apple.com>, Eric Kinnear <ekinnear@apple.com>, Mark Nottingham <mnot@mnot.net>, Rui Cunha Paulo <rpaulo@apple.com>, Lars Eggert <lars@eggert.org>, Vidhi Goel <vidhi_goel=40apple.com@dmarc.ietf.org>, IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000099cd1d059c35d3e8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/6gixAzV-DKFAaQVjhMPcIPCRnBA>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 15 Jan 2020 23:11:25 -0000

Tommy,

Responses inline.

That definitely makes sense that we don't want to spend too much time in
> the text on a non-recommended case, such as not pacing. Let's use the new
> PR to discuss any text reworking that can get closer to that goal, while
> clarifying the recommendations.
>

SG.


> With regards to #3232, one of the things we found in testing was that it
> could (a) still allow an implementation to be vulnerable to too much
> bursting (the original problem), but more importantly (b) locked receivers
> into an ack pattern of acking every other packet. My main concern is that
> this causes problems if receivers want to experiment with and change acking
> strategies going forward in way that otherwise would be fine.
>

These are good points, thank you for raising them. If the PR does not help
with the original problem, I'm ok with holding off on merging. I'm much
less convinced that we need to specify anything as elaborate as PR 3351,
however.

I'm curious to understand more about your testing -- do you want to
continue this discussion on the original issue (3094) so we can find a way
forward?

- jana

v2.23.0 | Report a Bug | By Email