IETF Logo Mail Archive

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

mirjak <notifications@github.com> Wed, 12 February 2020 15:43 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 D5BB31200F8 for <quic-issues@ietfa.amsl.com>; Wed, 12 Feb 2020 07:43:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.682
X-Spam-Level:
X-Spam-Status: No, score=-3.682 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_24=1.618, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_MED=-2.3, 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 Vy1qwyhcSMxv for <quic-issues@ietfa.amsl.com>; Wed, 12 Feb 2020 07:43:00 -0800 (PST)
Received: from out-28.smtp.github.com (out-28.smtp.github.com [192.30.252.211]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47B4B1200E7 for <quic-issues@ietf.org>; Wed, 12 Feb 2020 07:43:00 -0800 (PST)
Received: from github-lowworker-2ef7ba1.ac4-iad.github.net (github-lowworker-2ef7ba1.ac4-iad.github.net [10.52.16.66]) by smtp.github.com (Postfix) with ESMTP id 302558C0037 for <quic-issues@ietf.org>; Wed, 12 Feb 2020 07:42:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1581522179; bh=kN9/MopwicGnXLlG4zdPEnbF4LzvzEhTiNzFUETKydU=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=ATEv2mG2/X1O/ajwG1z+czRuAo3evkZhxlR5MQTN2EchWoUxx+ZyY33AwQZ6eMJt/ oKtuj/CXCShZnQfBVbJo3AgoBF4q+h2bdEDhbcdMuu2WwT1dnwk2cSeUq45HW38wg/ rjokv/WFlaDxBrRjqEi0IiBN5dsQCYXHVoR4Csog=
Date: Wed, 12 Feb 2020 07:42:59 -0800
From: mirjak <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK76RAMPPBEMBGBBQMV4KFHYHEVBNHHCDF6P4Q@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/585267457@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3451@github.com>
References: <quicwg/base-drafts/issues/3451@github.com>
Subject: Re: [quicwg/base-drafts] Should we allow ACK-only packets to be declared lost? (#3451)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e441d0321257_4ad53fd6c5ccd964292515"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: mirjak
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/nmb1snY7YQrxTFZfvA0-vjxiyW4>
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: Wed, 12 Feb 2020 15:43:03 -0000

I agree with Martin, there is no reason to ignore loss of ACKs as a signal. What you do with this information is a different question. There have been proposals for "ACK congestion control" in the past which basically means that you may adjust your ACK rate (e.g. if you send an ACK for every second packet you could easily reduce that rate if possible by your indicated max ack delay). I'm not saying we should specify any "ACK congestion control" but we should definitely make it possible to enable future experimentation on this.

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

v2.23.0 | Report a Bug | By Email