Re: [quicwg/base-drafts] Clarify when to send acks (#907)

janaiyengar <notifications@github.com> Wed, 08 November 2017 07:15 UTC

Return-Path: <bounces+848413-a050-quic-issues=ietf.org@sgmail.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 ABDAD131542 for <quic-issues@ietfa.amsl.com>; Tue, 7 Nov 2017 23:15:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.02
X-Spam-Level:
X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 MixbuMHRRUjh for <quic-issues@ietfa.amsl.com>; Tue, 7 Nov 2017 23:15:21 -0800 (PST)
Received: from o7.sgmail.github.com (o7.sgmail.github.com [167.89.101.198]) (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 8FF20131576 for <quic-issues@ietf.org>; Tue, 7 Nov 2017 23:14:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=QlGbcAwSTqGWdYd81HgsgSFQ0Oo=; b=FzmIgSEieAtohHhE MGESIGUPY2PaoOx+dOx7q3iJdZI/wDCj0dk+GZ/EdnQlCFZF5/kic9Gytpu2S5WD WZyhXiW2d6THgKnuWXA5tu1NrzCT7aJc7l8rAZ7T1dliJWnbHn/Vv1bKAtXHcs+5 SJtzIUPqqU/0cZ4slpO249Gv3CA=
Received: by filter0495p1iad2.sendgrid.net with SMTP id filter0495p1iad2-27547-5A02AEF1-9 2017-11-08 07:14:57.406793069 +0000 UTC
Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2b-ext-cp1-prd.iad.github.net [192.30.253.17]) by ismtpd0009p1iad2.sendgrid.net (SG) with ESMTP id Zt9tRJqFRHeAKrFBiaHCzg for <quic-issues@ietf.org>; Wed, 08 Nov 2017 07:14:57.421 +0000 (UTC)
Date: Wed, 08 Nov 2017 07:14:57 +0000
From: janaiyengar <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab09ab74267a64725b51c830cbb41f68848cc743d492cf00000001161a70f192a169ce10373813@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/907/review/75002449@github.com>
In-Reply-To: <quicwg/base-drafts/pull/907@github.com>
References: <quicwg/base-drafts/pull/907@github.com>
Subject: Re: [quicwg/base-drafts] Clarify when to send acks (#907)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5a02aef1459fc_6b003f8708c8cf347525dd"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: janaiyengar
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
tracking:
X-SG-EID: l64QuQ2uJCcEyUykJbxN122A6QRmEpucztpreh3Pak1RTYGdrNV2taAPMUcSVHbel/txYB5YbPaXXY ibwybUsLuKkeTnQjwuWQkF0DmvhxT9WU+Y16R/s6xgSXcwizyb8zSzaXhtGvYlZA2YO+UWh078h8WQ r0oYxKYRC+om3CehBibct+22yWi999w5OfBFlU3++bY5u74KJY9H+Rrw7U68wCkvyo1gtC+w7CFRLi E=
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/1XCshu4R4E6kj-qkPIvUaC7XmqM>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.22
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, 08 Nov 2017 07:15:24 -0000

janaiyengar commented on this pull request.



> @@ -2427,6 +2407,32 @@ ACK Block (repeated):
   packets preceding the largest packet number, as determined by the
   preceding Gap.
 
+### Sending ACK Frames
+
+Implementations MUST NOT generate packets that only contain ACK frames in
+response to packets which only contain ACK frames. However, they SHOULD

Yeah, agreed. I don't think there's a good reason to not ack these packets when an ACK frame is being sent anyways.

> @@ -2427,6 +2407,32 @@ ACK Block (repeated):
   packets preceding the largest packet number, as determined by the
   preceding Gap.
 
+### Sending ACK Frames
+
+Implementations MUST NOT generate packets that only contain ACK frames in
+response to packets which only contain ACK frames. However, they SHOULD
+acknowledge packets containing only ACK frames when sending ACK frames in
+response to other packets.  Implementations MUST NOT send more than one ACK
+frame per received packet that contains frames other than ACK frames.  Packets
+containing non ACK frames MUST be acknowledged immediately or when a delayed
+ack timer expires.
+
+To limit ACK blocks to those that have not yet been received by the sender, the
+receiver SHOULD track which ACK frames have been acknowledged by its peer.  Once

Perhaps a suggestion, but I think we should encourage receivers to re-ack as much as they can, for resilience and performance. How about something like: "In every ACK frame, a receiver SHOULD attempt to acknowledge all received packets whose acknowledgement is not yet known to have reached the sender. However, a receiver MAY avoid re-acknowledging all of them in subsequent ACK frames, and it may track outstanding acknowledgements to do so. Note that doing so reduces the connection's resilience to loss of acknowledgements." I think the wording could be improved, but something like this?

> +
+To limit ACK blocks to those that have not yet been received by the sender, the
+receiver SHOULD track which ACK frames have been acknowledged by its peer.  Once
+an ACK frame has been acknowledged, the packets it acknowledges SHOULD NOT be
+acknowledged again.
+
+A receiver that is only sending ACK frames will not receive acknowledgments for
+its packets.  Sending an occasional MAX_DATA or MAX_STREAM_DATA frame as data is
+received will ensure that acknowledgements are generated by a peer.  Otherwise,
+an endpoint MAY send a PING frame once per RTT to solicit an acknowledgment.
+
+To limit receiver state or the size of ACK frames, a receiver MAY limit the
+number of ACK blocks it sends.  A receiver can do this even without receiving
+acknowledgment of its ACK frames, with the knowledge this could cause the sender
+to unnecessarily retransmit some data.  When this is necessary, the receiver
+SHOULD acknowledge newly received packets and stop acknowledging packets

lowest packet number isn't necessarily the one that was the oldest. What you want really is to discard acks for the earliest received packets. I'm not concerned about the SHOULD here, I think that's fine... but I'm also fine with replacing that with a "can".

> @@ -2427,6 +2407,32 @@ ACK Block (repeated):
   packets preceding the largest packet number, as determined by the
   preceding Gap.
 
+### Sending ACK Frames
+
+Implementations MUST NOT generate packets that only contain ACK frames in
+response to packets which only contain ACK frames. However, they SHOULD
+acknowledge packets containing only ACK frames when sending ACK frames in
+response to other packets.  Implementations MUST NOT send more than one ACK
+frame per received packet that contains frames other than ACK frames.  Packets
+containing non ACK frames MUST be acknowledged immediately or when a delayed
+ack timer expires.
+
+To limit ACK blocks to those that have not yet been received by the sender, the
+receiver SHOULD track which ACK frames have been acknowledged by its peer.  Once

Hm. I think this is captured in the "to limit receiver state below". Do we need any more text here? I think it may still be valuable to state the first sentence in my suggestion above perhaps?

-- 
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/907#discussion_r149586679