IETF Logo Mail Archive

Re: [quicwg/base-drafts] Suggest endpoints may recognize acks after loss is declared (#3956)

Martin Thomson <notifications@github.com> Fri, 24 July 2020 02:07 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 AB0213A0789 for <quic-issues@ietfa.amsl.com>; Thu, 23 Jul 2020 19:07:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.555
X-Spam-Level:
X-Spam-Status: No, score=-1.555 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, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.001, 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 O7e7IstQVdvc for <quic-issues@ietfa.amsl.com>; Thu, 23 Jul 2020 19:07:13 -0700 (PDT)
Received: from out-25.smtp.github.com (out-25.smtp.github.com [192.30.252.208]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E0693A0787 for <quic-issues@ietf.org>; Thu, 23 Jul 2020 19:07:13 -0700 (PDT)
Received: from github-lowworker-ca5950c.va3-iad.github.net (github-lowworker-ca5950c.va3-iad.github.net [10.48.17.57]) by smtp.github.com (Postfix) with ESMTP id 99302840DDC for <quic-issues@ietf.org>; Thu, 23 Jul 2020 19:07:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1595556432; bh=cLAW8o19T62cbWwzIXW4Nuvbuy5fvP4NyVsxv60py9I=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=OBWqhyjUOEeFN4luea54SzwjILnErxRbTZFOnIGXYjLuU08utho7xDieWbliTKfIn mma6aRhSdRtctwVtFLDzndjZGw79LN0Xwq6/ZIS7C/HKsrjQDGHzYerQl9N+9HGLag d3hN4k4rMddjEdCCkX2iqEfB50dDCycvJKX6p6/4=
Date: Thu, 23 Jul 2020 19:07:12 -0700
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKYNURNYKTOL3LMOVK55EYRVBEVBNHHCPIHZLY@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3956/663316576@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3956@github.com>
References: <quicwg/base-drafts/issues/3956@github.com>
Subject: Re: [quicwg/base-drafts] Suggest endpoints may recognize acks after loss is declared (#3956)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5f1a425089a5d_79293fea7cecd960178948"; 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
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/AgBtGMxxlIXTAtyAv514WqniNM4>
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: Fri, 24 Jul 2020 02:07:15 -0000

I have to agree.  We had to implement late acknowledgment by marking "lost" packets and retaining them.  I believe that this was very helpful in reducing the amount of redundant information we send.

Failing to retain packets that were marked as lost was also the cause of a bug. As the lost packet was removed from our outstanding calculation (a different value to the "in-flight" counter we use for congestion control), we believed that there were no packets outstanding and we didn't try to send anything when the next PTO fired.  As the loss detection timer is shorter than the PTO timer, we believed that there was nothing to send often (and we don't check all sources of frames, which would have told us otherwise).

-- 
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/3956#issuecomment-663316576

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