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

MikkelFJ <notifications@github.com> Tue, 22 October 2019 11:36 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 6EF8A12008C for <quic-issues@ietfa.amsl.com>; Tue, 22 Oct 2019 04:36:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.596
X-Spam-Level:
X-Spam-Status: No, score=-6.596 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_IMAGE_ONLY_28=1.404, 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 9hiYnb3ktwyY for <quic-issues@ietfa.amsl.com>; Tue, 22 Oct 2019 04:36:22 -0700 (PDT)
Received: from out-4.smtp.github.com (out-4.smtp.github.com [192.30.252.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6481E12002E for <quic-issues@ietf.org>; Tue, 22 Oct 2019 04:36:22 -0700 (PDT)
Received: from github-lowworker-292e294.va3-iad.github.net (github-lowworker-292e294.va3-iad.github.net [10.48.102.70]) by smtp.github.com (Postfix) with ESMTP id AF9E6C61FB1 for <quic-issues@ietf.org>; Tue, 22 Oct 2019 04:36:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1571744181; bh=e9iGehavlAzemLDOxzYinVHN+/7HNiyHQ6Su9VgwLpo=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=j7rQbT+sVJV9koa1WH7EOv7TWFuaCrn0MP+X1pOpgm6AVzwqpqQOk3+wGJEDOZjSI /i9yb+B8mGElbUcZqF9CX+LEPc30c8koTqYn4TxV30dZySoqk17blujweUR9MRAAgp XcNshZiqeSSqk6PwyMHKIwQRt4m+c+OEovEbUHJE=
Date: Tue, 22 Oct 2019 04:36:21 -0700
From: MikkelFJ <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK5ED2KY6LSLDIXFELF3XQVELEVBNHHB4ODZTE@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/305135859@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_5daee9b5a061d_2d1e3fde3d2cd96c2172c"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: mikkelfj
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/T7bKHqQJtXjh989CgNkyxTou6Nw>
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: Tue, 22 Oct 2019 11:36:24 -0000

mikkelfj commented on this pull request.



> @@ -3007,9 +3007,6 @@ guidance offered below seeks to strike this balance.
 
 ### Sending ACK Frames {#sending-acknowledgements}
 
-An ACK frame SHOULD be generated for at least every second ack-eliciting packet.
-This recommendation is in keeping with standard practice for TCP {{?RFC5681}}.
-
 An endpoint MUST NOT excessively delay acknowledgements of ack-eliciting

I can see this works on average - but if you opt to max out on max delay to minimize transmissions in one direction you could find you self in trouble. A MUST would then force to send more frequently than optimal whereas SHOULD would allow for occasionally dropping the ball. Dropping the ball frequently would be be bad, of course, suggesting that ACKs are not sent often enough.

-- 
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#discussion_r337463479