Re: [quicwg/base-drafts] Flow Control Tuning (#3216)

Martin Thomson <notifications@github.com> Thu, 28 November 2019 02:45 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 B91941208E9 for <quic-issues@ietfa.amsl.com>; Wed, 27 Nov 2019 18:45:58 -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 7U2hOXGYxnuo for <quic-issues@ietfa.amsl.com>; Wed, 27 Nov 2019 18:45:57 -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 E5BB61208C4 for <quic-issues@ietf.org>; Wed, 27 Nov 2019 18:45:56 -0800 (PST)
Received: from github-lowworker-f045d1f.ac4-iad.github.net (github-lowworker-f045d1f.ac4-iad.github.net [10.52.19.54]) by smtp.github.com (Postfix) with ESMTP id ED61E660767 for <quic-issues@ietf.org>; Wed, 27 Nov 2019 18:45:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1574909155; bh=GGbcUhDE7lvz1UYk8Uyt/rPMe8W4x3VFwlEg8pT4OPI=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=YjU2b0qj0PB/sYiF8Fq8N3AaNdMKlY1NwkP2ALYGwwo4lhJeYuSG4AtNHabTDh3QQ xUPOOlL9dSkyKFm99e4i0PJP1KIDh7dnNfpPnq/I/lf3hWRQqv1Gsic2UleSexSMAQ fzqsSAhl/rA6ckP2DqHkkbLFaI9fiei8YiHcdAJw=
Date: Wed, 27 Nov 2019 18:45:55 -0800
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK3TF7E4UBR2E4FKH5F35RTWHEVBNHHB6D3C4A@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3216/559319078@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3216@github.com>
References: <quicwg/base-drafts/issues/3216@github.com>
Subject: Re: [quicwg/base-drafts] Flow Control Tuning (#3216)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5ddf34e3de5fc_10093ff49e0cd9601281f5"; 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/vLxFQZZEcgHX48x3iHeYKvrXB6E>
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: Thu, 28 Nov 2019 02:45:59 -0000

After briefly discussing this with Gorry, I think that we concluded that advice about the frequency of flow control updates would help.

Where flow control limits broadly correspond to the congestion window size, those updates would need to be sent about as often as acknowledgments in order to ensure that flow control didn't stall unnecessarily.  That would be the upper limit; larger flow control limits need proportionally fewer updates.  If flow control limits are very large, updates could be far less frequent.

I don't think that we have an algorithm here, but it seems like this advice would go a long way to avoiding the worst problems.

There's a question then about where this advice goes.  I am inclined to keep this in the transport doc as long as our response only extends to advice in the abstract.

-- 
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/3216#issuecomment-559319078