Re: Benjamin Kaduk's No Objection on draft-ietf-quic-recovery-33: (with COMMENT)

Lucas Pardue <lucaspardue.24.7@gmail.com> Fri, 08 January 2021 02:26 UTC

Return-Path: <lucaspardue.24.7@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 82A113A1058; Thu, 7 Jan 2021 18:26:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Level:
X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=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 KVNA1Dnc4DRt; Thu, 7 Jan 2021 18:26:38 -0800 (PST)
Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) (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 1B1A93A1057; Thu, 7 Jan 2021 18:26:38 -0800 (PST)
Received: by mail-ej1-x636.google.com with SMTP id jx16so12474213ejb.10; Thu, 07 Jan 2021 18:26:38 -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=w3Pl+tze83bU7j1MZ3V7cO1f5od7sZskMhGR9daFxVw=; b=K6vIRBHnykHNKC+lg36ph0xmCXXJkf1E3KU8+KJUTsetoyxLidhmPNxfZ8YqCZBIUd OzxeKObXJeoJgsbXNuhcmfyc7FM9h49xG+k+3akWhCLWM9wowtKi0RjE3lNXh3mird9Q A1oO/SUsbJHoMGEXKyNN929ad/IfkMyzjlwMLVFFkN7LcCPEjjbL+ltP08oR4Ekg77b6 PXXOeRQ4imRRGB2mLQU4x0rW4bCAtRTdNI+tmxo6PRLLF4vPwPp+j1/G81eanRKExUNM hMe4PV+exeovHcVwJGlphsZAfDFgrnLUBfUxyQ5YFjKrher9lx7HXCCPdeg+Quj1oIu+ NXew==
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=w3Pl+tze83bU7j1MZ3V7cO1f5od7sZskMhGR9daFxVw=; b=ahdBEqx3YF2VdRDHr7oR2W0B1cn/eXb1hpAkDxQ6QFX1iiuQaMGv05RB9zdPkRvsGu vM57EpJ14E+qyzP2ONHzYaUxF95ZIc3EadSMHwSA6BUSgeTSSH1oy0m/QfTtIGDsW3Fz mbyXZR2uMD5M6VRdOekldjVeoTPTVZsA3Ti6uSVP3+l1qklDEw5EB4/a7RJcRE4CP6Cu u7LESA50BfVo2d55hScvl/1GShNsa/TUTLvwYvprt6PoBo39g6rzgPbYDqkPKqcikNN8 2UWdBH4jmy32Er4SHJtiFIQ/1ox5499HNn57xQIj5TX7OyDOK04Fx1ZzuzEo6XxnBMIj YVwg==
X-Gm-Message-State: AOAM530eAFXAioUEu1Mri/WHGYKDBOThwCuX+KcVQ9NfQgZrOnOgv1el +ULmzm47rFGIpnZm16jix0JnnswuRIJgEM2DtY8=
X-Google-Smtp-Source: ABdhPJzl3BAJE49U7O79bMC0/JXfTqBa7a1eoBl2hezCHZUXP4SuCI+8955n9yk7alMs5LIpGc+2pP08hBjIDuCKRWo=
X-Received: by 2002:a17:906:1db2:: with SMTP id u18mr1231592ejh.440.1610072796421; Thu, 07 Jan 2021 18:26:36 -0800 (PST)
MIME-Version: 1.0
References: <161000026946.20455.1758845698481772459@ietfa.amsl.com>
In-Reply-To: <161000026946.20455.1758845698481772459@ietfa.amsl.com>
From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Fri, 8 Jan 2021 02:26:25 +0000
Message-ID: <CALGR9oZoTgNz_ewPMWX380r4Feo=0b8G59BXJdt9DRE27b9i2Q@mail.gmail.com>
Subject: Re: Benjamin Kaduk's No Objection on draft-ietf-quic-recovery-33: (with COMMENT)
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: The IESG <iesg@ietf.org>, draft-ietf-quic-recovery@ietf.org, WG Chairs <quic-chairs@ietf.org>, QUIC WG <quic@ietf.org>, Lars Eggert <lars@eggert.org>
Content-Type: multipart/alternative; boundary="00000000000017e22d05b85a49fe"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/fLlwgkTta9qa-76UWJETz-LSKDM>
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: Fri, 08 Jan 2021 02:26:41 -0000

Hi Ben,

Thanks for the review. I've created GitHub issues for each of these, see
the links inline.

On Thu, Jan 7, 2021 at 6:17 AM Benjamin Kaduk via Datatracker <
noreply@ietf.org> wrote:

> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-quic-recovery-33: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-quic-recovery/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Another well-written QUIC document; thank you!
> (The last version of -recovery I read was quite some time ago, perhaps the
> -09, and left me scratching my head quite often.  This one is quite clear.)
>
> I put my usual editorial suggestions up at
> https://github.com/quicwg/base-drafts/pull/4685
>
> Section 5.2
>
> > Endpoints SHOULD set the min_rtt to the newest RTT sample after
> > persistent congestion is established.  [...]
>
> Earlier we said that min_rtt was the minimum value observed "over the
> lifetime of the path", which seems in conflict with this behavior unless
> we somehow declare that the path is re-established after a persistent
> congestion event.  Perhaps we could finesse the wording a bit in the
> former location (given that we go on to allow re-establishing (or
> refreshing) the min_rtt at other times as well)?  (Appendix A.3 might be
> affected as well, if changes are made.)
>

https://github.com/quicwg/base-drafts/issues/4708


> Section 5.3
>
> > After the handshake is confirmed, any acknowledgement delays reported
> > by the peer that are greater than the peer's max_ack_delay are
> > attributed to unintentional but potentially repeating delays, such as
> > scheduler latency at the peer or loss of previous acknowledgements.
>
> I don't think I understand how loss of previous acknowledgements could
> induce a peer to delay sending an ack longer than its max_ack_delay
> after an ack-eliciting packet.
>

https://github.com/quicwg/base-drafts/issues/4709


> Section 6.2.1
>
> > A sender SHOULD restart its PTO timer every time an ack-eliciting
> > packet is sent or acknowledged, when the handshake is confirmed
> > (Section 4.1.2 of [QUIC-TLS]), or when Initial or Handshake keys are
> > discarded (Section 4.9 of [QUIC-TLS]).  [...]
>
> If I understand correctly, "handshake is confirmed" and "handshake keys
> are discarded" occur simultaneously, thus it is redundant to list both.
>

https://github.com/quicwg/base-drafts/issues/4710


> Section 6.2.3
>
> > Endpoints
> > that do not cease retransmitting packets in response to
> > unauthenticated data risk creating an infinite exchange of packets.
>
> We may want to be more precise about what "unauthenticated data" means
> here, since in -transport we say that even Initial packets are
> "authenticated" in some sense.
>

https://github.com/quicwg/base-drafts/issues/4711


> Section 6.2.4
>
>
> > When a PTO timer expires, a sender MUST send at least one ack-
> > eliciting packet in the packet number space as a probe.  [...]
> > [...]
> > When the PTO timer expires, an ack-eliciting packet MUST be sent.  [...]
>
> These look redundant to me (which, of course, does not necessarily mean
> that there is no value in having both).
>

https://github.com/quicwg/base-drafts/issues/4712


> Section 7.7
>
> > Endpoints can implement pacing as they choose.  A perfectly paced
> > sender spreads packets exactly evenly over time.  For a window-based
> > congestion controller, such as the one in this document, that rate
> > can be computed by averaging the congestion window over the round-
> > trip time.  Expressed as a rate in bytes:
>
> I cringed a little when I saw a rate being expressed as a unit
> expression with no time denominator, but am not sure how it might be
> improved.  The best I can come up with is "bytes/time".
>

https://github.com/quicwg/base-drafts/issues/4713


> Section 8.1
>
> I guess in some sense the observed RTT is also a signal under the
> control of a (Dolev-Yao) attacker, in addition to the loss and ECN
> signals.
>

https://github.com/quicwg/base-drafts/issues/4714


> Appendix A
>
> Should we say explicitly that '^' in the pseudocode is used to indicate
> exponentiation?
>

https://github.com/quicwg/base-drafts/issues/4715

Cheers,
Lucas
On behalf of QUIC WG Chairs