[quicwg/base-drafts] Congestion control section in recovery migth be easier to understand if it was self-contained (#3088)

Johannes Rudolph <notifications@github.com> Sat, 12 October 2019 12:57 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 0968C120854 for <quic-issues@ietfa.amsl.com>; Sat, 12 Oct 2019 05:57:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.596
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Kbyfm05EzFxj for <quic-issues@ietfa.amsl.com>; Sat, 12 Oct 2019 05:57:32 -0700 (PDT)
Received: from out-23.smtp.github.com (out-23.smtp.github.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 209DC120033 for <quic-issues@ietf.org>; Sat, 12 Oct 2019 05:57:32 -0700 (PDT)
Received: from github-lowworker-5fb2734.va3-iad.github.net (github-lowworker-5fb2734.va3-iad.github.net []) by smtp.github.com (Postfix) with ESMTP id 75F82660076 for <quic-issues@ietf.org>; Sat, 12 Oct 2019 05:57:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1570885051; bh=4AQhYfrClAIIMJowkho/6hG72Z0toeEBlGfR5wCuxao=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=RY8XafJyf1koOxfkcxwd5ZylzNEBYrbW0bXacSLE6RTWAzz8lL8OB/On2YephNVIs F0t9cGtqT6IGzCwH/0+st6WLmNstLiwLdpeZPplGZkTcrA1scYL+RQU8tSoA1pF7yh DBtNMe5ubplKpFPg88i2/8hYswiLkDLXw5/VBlms=
Date: Sat, 12 Oct 2019 05:57:31 -0700
From: Johannes Rudolph <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK5ZSRW4YVUNZVHOLMF3V4HEXEVBNHHB4K6A3Q@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3088@github.com>
Subject: [quicwg/base-drafts] Congestion control section in recovery migth be easier to understand if it was self-contained (#3088)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5da1cdbb66856_75043fefaa4cd964779368"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: jrudolph
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/539sOLcCTTMW28oER5WwcqiW55A>
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: Sat, 12 Oct 2019 12:57:34 -0000

It starts like this:

> QUIC's congestion control is based on TCP NewReno {{?RFC6582}}.

The next sections below roughly describe the behavior of different phases of congestion control. More concrete pseudo-code is only given in the Appendix later on but it's not linked from the original section.

On first reading, I missed the Appendix and felt the text lacking for concrete enough explanations to implement the feature. The question is what to describe where and what the authoritative definitions should be. If you know the NewReno RFC by heart you can probably make the right inferences to figure out how everything should work in comparison but is that how it should be?

An alternative (more convenient for the reader / skimmer) approach could be to mention NewReno only in passing and then provide a complete and self-contained description of the algorithms in the congestion control section directly, maybe even inlining the pseudo-code. If that is deemed to verbose and would bore readers that know enough about those algorithms already, it would be good to provide some guidance how to read the algorithm and what the assumptions are in the introductory paragraph about congestion control.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: