IETF Logo Mail Archive

Re: [quicwg/base-drafts] editorial: This sentence was hard to parse for me (recovery) (#3383)

Mike Bishop <notifications@github.com> Wed, 22 January 2020 17:44 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15F9212011C for <quic-issues@ietfa.amsl.com>; Wed, 22 Jan 2020 09:44:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Level:
X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.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 FtuQep4oXBpk for <quic-issues@ietfa.amsl.com>; Wed, 22 Jan 2020 09:44:35 -0800 (PST)
Received: from out-10.smtp.github.com (out-10.smtp.github.com [192.30.254.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB63C120108 for <quic-issues@ietf.org>; Wed, 22 Jan 2020 09:44:35 -0800 (PST)
Received: from github-lowworker-d31a065.va3-iad.github.net (github-lowworker-d31a065.va3-iad.github.net [10.48.17.70]) by smtp.github.com (Postfix) with ESMTP id 3C280121269 for <quic-issues@ietf.org>; Wed, 22 Jan 2020 09:44:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1579715075; bh=LPiaIhi3zBOnyy/vKsdOxRyroHoryzgwW6PbAzkyiqs=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=AlJPn/Be7xdwhHvEHvdvZxQGjkmoU2OiTLCQOYHW2H3DkjCAsvwwRUYj4RE1fN//u xxWr2ZMA1iH+27cmUiAdsYD4z4EzVISNywzOR0p1TvoRIxaUA9xdXbzLcOFa+9ivrR wlSJhIPXFlJhvxSmudGRmylCvBwYrZ50txVfb31A=
Date: Wed, 22 Jan 2020 09:44:34 -0800
From: Mike Bishop <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK3ZBSRU7A72CXXRZZ54GW6IFEVBNHHCCABNRQ@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3383/review/346779206@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3383@github.com>
References: <quicwg/base-drafts/pull/3383@github.com>
Subject: Re: [quicwg/base-drafts] editorial: This sentence was hard to parse for me (recovery) (#3383)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e288a02e6325_a523fd6676cd964153131"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: MikeBishop
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/393rnRSJfh4uJe-GjFW5SC7hOPY>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jan 2020 17:44:37 -0000

MikeBishop commented on this pull request.



> @@ -272,9 +272,10 @@ SHOULD NOT be used to update RTT estimates if it does not newly acknowledge the
 largest acknowledged packet.
 
 An RTT sample MUST NOT be generated on receiving an ACK frame that does not
-newly acknowledge at least one ack-eliciting packet.  A peer does not send an
-ACK frame on receiving only non-ack-eliciting packets, so an ACK frame that is
-subsequently sent can include an arbitrarily large Ack Delay field.  Ignoring
+newly acknowledge at least one ack-eliciting packet.  A peer does usally not

"does not usually" would also be fine.  But not in the middle.

> @@ -272,9 +272,10 @@ SHOULD NOT be used to update RTT estimates if it does not newly acknowledge the
 largest acknowledged packet.
 
 An RTT sample MUST NOT be generated on receiving an ACK frame that does not
-newly acknowledge at least one ack-eliciting packet.  A peer does not send an
-ACK frame on receiving only non-ack-eliciting packets, so an ACK frame that is
-subsequently sent can include an arbitrarily large Ack Delay field.  Ignoring
+newly acknowledge at least one ack-eliciting packet.  A peer does usally not
+send an ACK frame when only non-ack-eliciting packets are received. Therefore
+an ACK frame that contains only acknowledge for non-ack-eliciting packets is

```suggestion
an ACK frame that only contains acknowledgements for non-ack-eliciting packets
```
May require a rewrap

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3383#pullrequestreview-346779206

v2.29.0 | Report a Bug | By Email | System Status