[quicwg/base-drafts] ACKing ACK (#291)

Martin Thomson <notifications@github.com> Fri, 10 February 2017 09:02 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 25D1E129506 for <quic-issues@ietfa.amsl.com>; Fri, 10 Feb 2017 01:02:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.617
X-Spam-Level:
X-Spam-Status: No, score=-0.617 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no 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 hsEk0n2D7UU7 for <quic-issues@ietfa.amsl.com>; Fri, 10 Feb 2017 01:02:32 -0800 (PST)
Received: from o10.sgmail.github.com (o10.sgmail.github.com [167.89.101.201]) (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 9606D129410 for <quic-issues@ietf.org>; Fri, 10 Feb 2017 01:02:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:reply-to:to:cc:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=dfet4tcdAukm834CoSU+CBgjv8k=; b=vz9IaKalxxthgFde 3XUOUHrmmPRA0FccAeyTJwVW1JYY+TgnRCFmpKz01jziDHVUwW8ZC5MSjx80/Rj7 oQiPcVfo4AOHBvDIXgSTEHsY5w3uqSQntNxcJmK4tYVIGWUB/VH2BYDCXC8NP5ix a2jYyW2HZ6TF60WrwUtfnTPepm0=
Received: by filter1134p1mdw1.sendgrid.net with SMTP id filter1134p1mdw1-26080-589D81A4-27 2017-02-10 09:02:28.22507641 +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 ismtpd0006p1iad1.sendgrid.net (SG) with ESMTP id GyU0L6wDRTKpsg1hw-fckQ for <quic-issues@ietf.org>; Fri, 10 Feb 2017 09:02:28.230 +0000 (UTC)
Date: Fri, 10 Feb 2017 01:02:28 -0800
From: Martin Thomson <notifications@github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/291@github.com>
Subject: [quicwg/base-drafts] ACKing ACK (#291)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_589d81a424f3a_79c33fdcea349138408596"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
X-SG-EID: l64QuQ2uJCcEyUykJbxN122A6QRmEpucztpreh3Pak2nrJqn5H7GWt7ykS0MHKJkMIwrkDr4Uq07jN GG9YLxhNiUbj4i9tCRpGyJcEDCnJ+us/w/mvuBxFbr+7y02ek8vPoWLt1ZkFaYtIQLaLYWCj0qx+J+ 4liSvqGOqYvBtRxYh198vQX2uOTG6Dr/FmScvhtCmT+thmFtSQ20kuLka916V5c8LDhm6IVTB8nksR w=
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/lQXDUn79AwL4TeMOZ1s6Vux9oPg>
Cc: Subscribed <subscribed@noreply.github.com>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.17
Reply-To: quic@ietf.org
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: Fri, 10 Feb 2017 09:02:34 -0000

The text says:

> However, since it is possible that an endpoint might only send packets containing ACK frames (or other non-retransmittable frames), the receiving peer MAY send an ACK frame after a reasonable number (currently 20) of such packets have been received.

"currently 20" seems pretty arbitrary.  That smells like something from the Google QUIC implementation.  We should be more concrete about this, if that behaviour even makes sense.

If an endpoint is receiving nothing but ACKs but is sending itself, then acknowledging those ACKs is probably fine.

An endpoint with nothing to say can generate a lot of ACKs over time, but if both endpoints are being quiet other than ACKs, it's probably time to shut up entirely.  Maybe we should say that the peer SHOULD generate an ACK frame only if it has other frame types to send.

Limiting the number of PING frames that a peer will respond to is a separate issue, and may motivate a limit with a number attached to it.


-- 
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/issues/291