Re: [quicwg/base-drafts] QUIC Transport: Flow Control (#3722)

evolodina <notifications@github.com> Thu, 04 June 2020 14:29 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 81D2C3A00C3 for <quic-issues@ietfa.amsl.com>; Thu, 4 Jun 2020 07:29:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.483
X-Spam-Level:
X-Spam-Status: No, score=-1.483 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_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.001, 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 PY-lJwV5eO-t for <quic-issues@ietfa.amsl.com>; Thu, 4 Jun 2020 07:29:46 -0700 (PDT)
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 01DEE3A0CEE for <quic-issues@ietf.org>; Thu, 4 Jun 2020 07:29:38 -0700 (PDT)
Received: from github-lowworker-0f78100.ash1-iad.github.net (github-lowworker-0f78100.ash1-iad.github.net [10.56.25.48]) by smtp.github.com (Postfix) with ESMTP id EDD308C0522 for <quic-issues@ietf.org>; Thu, 4 Jun 2020 07:29:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1591280977; bh=D+k0t3DhcUqUf0iPGxpf/4rn2bzJxH3UEyrQYQCqaII=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=IG0zTaxd8hzZ+uU4VHfTkFmx9vivkxp9v0R6OxAunqjKasfn+VBzcj6ichx3P3u3L mMlv+tWKH42OghZBEhxkD9O29miL9OjKGJ25ZJpbvnPtyJcUQ/8FgmuLFddJJ2NBsJ srnbLUAmPHo2PqiB3BFMdf5CKr7uEHMknUGwSpog=
Date: Thu, 04 Jun 2020 07:29:37 -0700
From: evolodina <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK3BRIMKTNUBJP6NJOV44TTFDEVBNHHCLGB6ZU@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3722/638885306@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3722@github.com>
References: <quicwg/base-drafts/issues/3722@github.com>
Subject: Re: [quicwg/base-drafts] QUIC Transport: Flow Control (#3722)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5ed90551de2c6_7723f80732cd96c11597b"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: evolodina
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/wZ6lVm0Ykh2AShtqhmVWtiLjr0c>
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, 04 Jun 2020 14:29:48 -0000

> Section: Flow Credit Increments
The following could be taken as a general guidance, when the ID says: “As an optimization, an endpoint could send frames related to flow control only when there are other frames to send or when a peer is blocked, ensuring that flow control does not cause extra packets to be sent.”
>
> - I do not agree. This appears an optimisation for minimising resource use. It will I expect have a serious negative impact on performance where the path RTT is large, and that case also needs to be mentioned. This is an area where guidance is needed, since the way TCP operates is not described in the RFC series and mistakes in this part of the code can have very serious impacts on the performance and dynamics of applications, as well as the patterns of traffic on the wire.

Even if RTT < 40ms we saw a negative impact of this optimization in our quic implementation

-- 
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/3722#issuecomment-638885306