[quicwg/base-drafts] Should we allow ACK-only packets to be declared lost? (#3451)

Martin Thomson <notifications@github.com> Tue, 11 February 2020 23:23 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 215AC12004C for <quic-issues@ietfa.amsl.com>; Tue, 11 Feb 2020 15:23:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.596
X-Spam-Level:
X-Spam-Status: No, score=-6.596 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, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, 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 tb0NSgRPINdN for <quic-issues@ietfa.amsl.com>; Tue, 11 Feb 2020 15:23:39 -0800 (PST)
Received: from out-4.smtp.github.com (out-4.smtp.github.com [192.30.252.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7DAA120837 for <quic-issues@ietf.org>; Tue, 11 Feb 2020 15:23:39 -0800 (PST)
Date: Tue, 11 Feb 2020 15:23:38 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1581463418; bh=h6J6X3oRL6HVSV46LfbsMLdkdfol8WEHrcFJKmOWX9U=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=kfpEVQL452iacajhwLfPbTWkKamf/+Z4w6aLgZHXfzyIPwWP9IaPBf8OriCLrqW6b 5gHlx86wu00pPAaU4yM0xCkTuwg0Ar+zC5Ga5AGnRhclxYmgm6PMXYtp/xDPk523Sa pmxIscsXZb+3RxU1uK796jvTGyXpUOCXXeMkyCtk=
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK53XETGLLDEXCQYO2V4KBU7VEVBNHHCDF6P4Q@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3451@github.com>
Subject: [quicwg/base-drafts] Should we allow ACK-only packets to be declared lost? (#3451)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e43377aaa048_3cd3fc4d6acd96c1069cd"; 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/mby0VkrnVXqVCjmSxE5fJ3wasp4>
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: Tue, 11 Feb 2020 23:23:42 -0000

After some discussion, the "in-flight" condition here leads to an odd requirement.

> A packet is declared lost if it meets all the following conditions:
> * The packet is unacknowledged, in-flight, and was sent prior to an acknowledged packet.
> * [other stuff]

This says that lost ACK-only packets cannot be declared lost.  This buries a potential signal that might drive a congestion controller.

This comes from TCP.  In TCP, detecting loss of an ACK is impossible, but in QUIC, we can.  But this requirement essentially forbids that.  Implementations don't seem to be consistent on this point.

@ianswett says that if we change this, we should also mandate the acknowledgment of ACK-only packets when sending an ACK for other ACK-eliciting packets.

We could simply say that this is good and recognize that this requirement is consistent with not requiring ACKs for these.  Or we could take the signal and declare them lost.

-- 
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/3451