IETF Logo Mail Archive

Re: [quicwg/base-drafts] Only send one immediate ACK after reordering (#3357)

Gorry Fairhurst <notifications@github.com> Wed, 29 January 2020 16:54 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 CC0A91200BA for <quic-issues@ietfa.amsl.com>; Wed, 29 Jan 2020 08:54:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.454
X-Spam-Level:
X-Spam-Status: No, score=-6.454 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_20=1.546, 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 vO6J9ncomTrc for <quic-issues@ietfa.amsl.com>; Wed, 29 Jan 2020 08:54:51 -0800 (PST)
Received: from out-23.smtp.github.com (out-23.smtp.github.com [192.30.252.206]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E252612009C for <quic-issues@ietf.org>; Wed, 29 Jan 2020 08:54:50 -0800 (PST)
Received: from github-lowworker-6b40fdd.va3-iad.github.net (github-lowworker-6b40fdd.va3-iad.github.net [10.48.16.64]) by smtp.github.com (Postfix) with ESMTP id D1396661E9A for <quic-issues@ietf.org>; Wed, 29 Jan 2020 08:54:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1580316889; bh=FNojKrHQjfNXxlaUt8Bh4ql/8HbsJlwOvmpNQLdiwGE=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=itG9gFKq4FofYH7lI+CE2BJZJd+XXX72GwZoHc1LRKM+LKNGwEuLD1jCJyuzK1MBT LE9i8BnTavHSf4wMC95Q04RcxmHHPyFqne2hDdCD4Nynvm/wNToTpZBKHAGF3cobWI XKXMwiNZdycSk7VUMPKLMoW5zesgID15qhxqyGzI=
Date: Wed, 29 Jan 2020 08:54:49 -0800
From: Gorry Fairhurst <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK357N6N2NHRBEESGGF4H3VVTEVBNHHCBYECWE@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3357/579853801@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3357@github.com>
References: <quicwg/base-drafts/issues/3357@github.com>
Subject: Re: [quicwg/base-drafts] Only send one immediate ACK after reordering (#3357)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e31b8d9c1e1c_326d3fd9862cd96411361"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: gorryfair
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/oIKEYWt_EoBnERa3jwDCRbxpdt0>
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, 29 Jan 2020 16:54:56 -0000

I think it could have other effects - it will impact the robustness to loss/congestion on the return path compared to the way TCP operates. Sending one isolated ACK here isn't the same, although you could argue that the ACK information is indeed repeated "ACK Delay" or "N packets" later. If we relax the number of packets per ACK this may need a little more thought to avoid delaying congestion detection when there is loss?

-- 
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/3357#issuecomment-579853801

v2.23.0 | Report a Bug | By Email