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

Gorry Fairhurst <notifications@github.com> Wed, 04 March 2020 10:34 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 3A45A3A0B97 for <quic-issues@ietfa.amsl.com>; Wed, 4 Mar 2020 02:34:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.1
X-Spam-Level:
X-Spam-Status: No, score=-3.1 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_MESSAGE=0.001, MAILING_LIST_MULTI=-1, 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 4pesh0dUuCub for <quic-issues@ietfa.amsl.com>; Wed, 4 Mar 2020 02:34:56 -0800 (PST)
Received: from out-5.smtp.github.com (out-5.smtp.github.com [192.30.252.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 091513A0BE2 for <quic-issues@ietf.org>; Wed, 4 Mar 2020 02:34:56 -0800 (PST)
Received: from github-lowworker-6349a71.ac4-iad.github.net (github-lowworker-6349a71.ac4-iad.github.net [10.52.18.20]) by smtp.github.com (Postfix) with ESMTP id 0F636960241 for <quic-issues@ietf.org>; Wed, 4 Mar 2020 02:34:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1583318095; bh=uldZn+6s4aiyYHDLo6kH2pKD1U4KXkGrMbuW34J2wYE=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=enwbpm4Ion2mwipvHSIFhlskllbyU5XwKvPCi1e38e5A5xupiTakA5oZ4QA1gQKk1 wIqBpfgiHCXz0cU2xXxH6MPM+ayk8Qq2Q8jBh4HzdJsIyofYaaA7ua14j3MmNL4qog WKn5+FC+pIbKVv0J9ajYQcwrXbKWFFm5NFOxsCPI=
Date: Wed, 04 Mar 2020 02:34:55 -0800
From: Gorry Fairhurst <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKZTRE4PPLJV2B2WUDV4NNSU5EVBNHHCBYECWE@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/594444311@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_5e5f844f878_10623fadcaacd96c108210"; 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/2QlZyb4de4e8kqofE2HYdER1khU>
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, 04 Mar 2020 10:34:58 -0000

I think it will impact the robustness to loss/congestion on the return path compared to the way TCP operates, but the use of PTO generally mitigates this...

There are cases where relying only on the PTO would delay congestion detection, such as when there is a significantly reduced path RTT at the same time as loss (we could think of scenario where this is a result of re-routing for the path).

I’m also interested in a case where there is loss in both directions (which can also happen in congestion collapse). The reduction of ACK information could result in unnecessary duplicated data (because the sender does not receive ACK range info). This issue seems most severe when there are too few ACKs per RTT. 

It seems there is merit in ensuring there are sufficient ACKs per RTT - e.g., a rule that sends ACKs at least every (say) 1/8 RTT would seem wise.

Overall, I am in favour of the proposal to change the response after loss/reorder. QUIC currently generates a lot more ACK traffic (in volume) than TCP.  ACK after loss event are common with RENO overflowing a router buffer (we are looking at this now). This proposed change is likely to really help reduce ACK traffic volume on the return path.  

If the arguments for this seem valid, I think related issue #3304 needs to be considered again. 


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