Re: [quicwg/base-drafts] What to ack in an ACK frame (#764)

martinduke <notifications@github.com> Wed, 06 September 2017 22:01 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 7AA28132A8E for <quic-issues@ietfa.amsl.com>; Wed, 6 Sep 2017 15:01:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.8
X-Spam-Level:
X-Spam-Status: No, score=-4.8 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_H2=-2.8, 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 fZjOJIruqGpr for <quic-issues@ietfa.amsl.com>; Wed, 6 Sep 2017 15:01:19 -0700 (PDT)
Received: from o5.sgmail.github.com (o5.sgmail.github.com [192.254.113.10]) (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 7BAD7126B6E for <quic-issues@ietf.org>; Wed, 6 Sep 2017 15:01:19 -0700 (PDT)
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=HThYpOJ6KkFkSoDskC4wxndZwgU=; b=FvbK7vlW2kai5bod X9Jj4yxnYba6DgftQYHXiofdwkz5FDq6Pr4Xcmz6O7h5REGr81LLs3tH/ON61Tle lHlsCatLN1WSUVqVLijXByW3WgBLfIgd/ilCHIinPSGaFlmJa/JjryyB2hYXoLGy 2TCzDysaVOEHNweWmNmaKgYR6rg=
Received: by filter0632p1mdw1.sendgrid.net with SMTP id filter0632p1mdw1-16015-59B06F8C-1A 2017-09-06 21:58:36.544094913 +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 ismtpd0006p1iad1.sendgrid.net (SG) with ESMTP id TBwoTWhgSMWj9LSqpf6h9w for <quic-issues@ietf.org>; Wed, 06 Sep 2017 21:36:34.266 +0000 (UTC)
Date: Wed, 06 Sep 2017 22:01:13 +0000
From: martinduke <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab69570d1ff30c0cbc010928a765bf172979d8441592cf0000000115c82c6292a169ce0f3e649b@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/764/327619265@github.com>
In-Reply-To: <quicwg/base-drafts/issues/764@github.com>
References: <quicwg/base-drafts/issues/764@github.com>
Subject: Re: [quicwg/base-drafts] What to ack in an ACK frame (#764)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_59b06a6221081_3fe63f8c9924dc3054079"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinduke
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: l64QuQ2uJCcEyUykJbxN122A6QRmEpucztpreh3Pak0mcN38lDZUYSEpHotM5l9RRc+TNqQh8L84HO N1AWHXCjRCKDbQ8qgz8F3nZ62RaZwt6IVl82TMYM4aivnQStq+AQ782volSVdc+bZC8OmLa3dC4T+/ u+zI56NzrUPEZHBfKEQi8PXw7ZKUswnR6rTlAuM7MxVYklHqK4n1Vlm927ids3mSIneesODT/+3u5h Y=
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/wR07S4h-lR9YtVBNNJVO-RILMbw>
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, 06 Sep 2017 22:01:21 -0000

Yes, it is clear that we should not include Ack blocks that have already been acked, and that we SHOULD include timestamps exactly once per packet. There is no stated recommendation on in-flight acks. Possibilities:
    (i) Do not repeat them in subsequent acks
    (ii) Repeat them only if they do not require additional ack blocks
    (iii) Repeat them only if they require neither additional ack blocks nor longer block lengths.
    (iv) Always repeat them until acked

These have significant pros and cons. The benefits of not adding more ACK overhead are obvious. The benefits of repeating acks are obvious. However,

(A) Repeating in-flight acks may increase largest_acked so that we cannot include certain unsent timestamps.
(B) _not_ repeating in-flight acks may create packet number gaps too large to send subsequent ack blocks.

These are subtle issues, and the algorithms to optimize the outcomes are not simple at all. Some sort of implementation guidance, or even narrowing of what is allowed in the frame, would be helpful.

-- 
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/764#issuecomment-327619265