IETF Logo Mail Archive

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

ianswett <notifications@github.com> Fri, 10 February 2017 19:56 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 955D3129540 for <quic-issues@ietfa.amsl.com>; Fri, 10 Feb 2017 11:56:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.887
X-Spam-Level:
X-Spam-Status: No, score=-3.887 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_32=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, RP_MATCHES_RCVD=-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 g5iswyusdBsQ for <quic-issues@ietfa.amsl.com>; Fri, 10 Feb 2017 11:56:23 -0800 (PST)
Received: from o9.sgmail.github.com (o9.sgmail.github.com [167.89.101.2]) (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 5C6AE129442 for <quic-issues@ietf.org>; Fri, 10 Feb 2017 11:56:23 -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=qavgKcYXCK41jtJQFdJISPMZ02U=; b=URu/sYJcgu8o12O6 cZ725By53FiH2WvLQDsUMGLh8QM4u4IvdsCEURxnmzCZdFKrVn6F+HT0CDNKgn8Q smjdkAU67jRIOYnhkOEilIZvmONeJr/V+TCkt2b2dh3g9hlVMMWJneww7CQoht2f ZutGc0vx3JRYfNn8zoTQmY0X+BE=
Received: by filter0814p1mdw1.sendgrid.net with SMTP id filter0814p1mdw1-20203-589E1AE2-2C 2017-02-10 19:56:18.37172508 +0000 UTC
Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2a-ext-cp1-prd.iad.github.net [192.30.253.16]) by ismtpd0005p1iad1.sendgrid.net (SG) with ESMTP id qQW4VUspSVm05tJn7sbW1A for <quic-issues@ietf.org>; Fri, 10 Feb 2017 19:56:18.349 +0000 (UTC)
Date: Fri, 10 Feb 2017 11:56:18 -0800
From: ianswett <notifications@github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/291/279050032@github.com>
In-Reply-To: <quicwg/base-drafts/issues/291@github.com>
References: <quicwg/base-drafts/issues/291@github.com>
Subject: Re: [quicwg/base-drafts] ACKing ACK (#291)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_589e1ae21ccf_6a053f7fefd0d140741b8"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ianswett
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: l64QuQ2uJCcEyUykJbxN122A6QRmEpucztpreh3Pak2gbvk8t8pCTfeS71paLAvBKOiiz+4Hu+hmBr xSaWtbvSxaW6vQR7ZW7It5TlXbVEMVe24KVBr5NpU090m+T7kh1hXXqULitp19x866rG6Fn9aASMe5 fU9+wi0fZkYWHa+N6iYaee3NV8gEybj5N0HGvyHU/p9EKtotoU+4Al3mV8qDaMfSqDRmNH+hrHA0XM 8=
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/c8oSSwDdX9GqGFclIBWNqXuS_-A>
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 19:56:25 -0000

Your nose is correct.  That being said, acking every 20 acks has worked out relatively well, so it may make sense to change this to "the receiving peer SHOULD send an ACK frame after 20 ack only packets."  

If both endpoints are being quiet, the rule that "a receiver MUST NOT generate an ack in response to every packet containing only ACK frames." causes them to stop sending packets quite quickly.  The recommended acking behavior could be specified more explicitly, either here or in the recovery doc, if you think it's warranted.

What's the motivation for limiting PING frames?

-- 
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#issuecomment-279050032

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