IETF Logo Mail Archive

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

ianswett <notifications@github.com> Mon, 27 July 2020 15:55 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 86BE13A1A1E for <quic-issues@ietfa.amsl.com>; Mon, 27 Jul 2020 08:55:01 -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 0-S3INet0j4L for <quic-issues@ietfa.amsl.com>; Mon, 27 Jul 2020 08:54:58 -0700 (PDT)
Received: from out-18.smtp.github.com (out-18.smtp.github.com [192.30.252.201]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D25043A1A02 for <quic-issues@ietf.org>; Mon, 27 Jul 2020 08:54:40 -0700 (PDT)
Received: from github-lowworker-1b8c660.ash1-iad.github.net (github-lowworker-1b8c660.ash1-iad.github.net [10.56.18.59]) by smtp.github.com (Postfix) with ESMTP id 25FFF340ECB for <quic-issues@ietf.org>; Mon, 27 Jul 2020 08:54:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1595865280; bh=d/m240PpwgqnXdXbnzKfCU+kJLFvswAjTVlnzkvt5EA=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=J+TFbGsyGNaCh6BOSEcqqKzj8tyFxuIbdNhYMp/3Yj+m1ppr9+ZmFEWA+iZ/LZNUi n6zc1dBeXAG0nIw2wDgyEMYgKm87M8IIaOp6YDzEEQuSdfydh8PHERpRGGkQcfDN3U IN5ok2R1k88oVjDrhxq08dlkrGINA2ATHTKX6D3g=
Date: Mon, 27 Jul 2020 08:54:40 -0700
From: ianswett <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK47KVIPPZNCPHKATJ55FLM4BEVBNHHCPIHZLY@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/664480525@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_5f1ef8c016c96_11343f81280cd96842479"; 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
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/bPeHk9ZXOWk8q1GIb2gUQO8Ew18>
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: Mon, 27 Jul 2020 15:55:02 -0000

I wanted to clarify my comment on the PR about believing that 1 RTT is a preferable recommendation to 3*PTO.

We definitely don't want to discard this information BEFORE the packet is lost or acknowledged.  But after it's been declared lost, there's no need to wait longer than the reordering window to receive an acknowledgement, because an immediate ACK will be sent when the out of order packet arrives.  I tend to think an RTT is a plenty long reordering window in practice.

If nothing is inflight before and nothing sent after the packet is lost AND the late immediate ACK for the reordered packet is lost, then it could take longer than the reordering window to receive an ACK, but that seems like an edge case that's not very interesting.


-- 
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-664480525

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