Re: [quicwg/base-drafts] MUST ACK each ack-eliciting packet once (#3092)

Mike Bishop <notifications@github.com> Thu, 24 October 2019 19:34 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 D4192120025 for <quic-issues@ietfa.amsl.com>; Thu, 24 Oct 2019 12:34:14 -0700 (PDT)
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 eMn3BKE5onAM for <quic-issues@ietfa.amsl.com>; Thu, 24 Oct 2019 12:34:13 -0700 (PDT)
Received: from out-7.smtp.github.com (out-7.smtp.github.com [192.30.252.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 203ED120020 for <quic-issues@ietf.org>; Thu, 24 Oct 2019 12:34:13 -0700 (PDT)
Date: Thu, 24 Oct 2019 12:34:12 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1571945652; bh=kRfOORERhv14owXgHErKYd8JOAJT0rP09BqXyxPoU6E=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=gal3JyYjfvsCi+o2WXZhgTS0g4tmC81b0HmKGEDUf2W57BieDzwoRENRRzP5BBtIq hnKIxhEpiFHlvmVU8aS5Qjgcjt0j/dkKpsPOEjnx1vTH/hoI4ktbuDIIzVXf4ZK2hV 9fqL9W5xDBOMsBPMYV8I9kuKJF4OPOIu4h/0H1f4=
From: Mike Bishop <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK6YOM7TYALCOKWP5DN3X46UJEVBNHHB4ODZTE@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3092/review/306812844@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3092@github.com>
References: <quicwg/base-drafts/pull/3092@github.com>
Subject: Re: [quicwg/base-drafts] MUST ACK each ack-eliciting packet once (#3092)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5db1fcb430645_5173fd0764cd96c951e9"; 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/B_uyRFxIWD5lPq7NdS9JVXn5qec>
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: Thu, 24 Oct 2019 19:34:15 -0000

MikeBishop commented on this pull request.



> +Every packet SHOULD be acknowledged at least once, and ack-eliciting packets
+MUST be acknowledged at least once within the maximum ack delay. An endpoint

No, it doesn't, because you have no guarantee that you received every ACK the peer sent.  This requires the peer to put every packet into an ACK frame sent in at least one packet; there's no requirement to ensure that it's delivered reliably to the peer.  Thus, if you haven't received an ACK, that doesn't mean the peer didn't received the packet anyway.  It could be delayed and still in transit, or the ACK might have been lost.

That said, there's no actual difference between "MUST ack every packet, but not reliably" and "SHOULD ack every packet" from the other side's point of view.  This is something that could be bench-tested on an implementation, but can't be ascertained about the peer over a lossy network.

> @@ -3007,25 +3007,26 @@ guidance offered below seeks to strike this balance.
 
 ### Sending ACK Frames {#sending-acknowledgements}
 
+Every packet SHOULD be acknowledged at least once, and ack-eliciting packets
+MUST be acknowledged at least once within the maximum ack delay. An endpoint
+communicates its maximum delay using the max_ack_delay transport parameter;
+see {{transport-parameter-definitions}}.  max_ack_delay declares an explicit

It's probably correct to start the sentence with a lower-case letter, since this is a literal name of a protocol element, but it looks weird.  Consider rephrasing to avoid the question.

-- 
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/3092#pullrequestreview-306812844