Re: [quicwg/base-drafts] QUIC's Initial Congestion Window specification is incorrect (#3997)

mirjak <notifications@github.com> Fri, 14 August 2020 12:24 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 D53E63A1080 for <quic-issues@ietfa.amsl.com>; Fri, 14 Aug 2020 05:24:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.555
X-Spam-Level:
X-Spam-Status: No, score=-1.555 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_20=1.546, 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 mgC0dviezus9 for <quic-issues@ietfa.amsl.com>; Fri, 14 Aug 2020 05:24:44 -0700 (PDT)
Received: from out-18.smtp.github.com (out-18.smtp.github.com [192.30.252.201]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CBB03A107F for <quic-issues@ietf.org>; Fri, 14 Aug 2020 05:24:44 -0700 (PDT)
Received: from github-lowworker-f144ac1.va3-iad.github.net (github-lowworker-f144ac1.va3-iad.github.net [10.48.16.59]) by smtp.github.com (Postfix) with ESMTP id A96EE340E1B for <quic-issues@ietf.org>; Fri, 14 Aug 2020 05:24:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1597407883; bh=eroEG5+6x6bD+53OCCcOtYQU7ch2ATFQoIoRvHnJSCk=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Y96RQtzB7n3o3H7W0/KX3ie0qQoGRG69cWHYKung3YT3xlsXLtUpUSHkOxYLT/5IA PFsKD0tfU7oopbmfu5hv/jLoiF8FP3yJGT4qz3Oc7EylTEQOwrxW8eJ9sYly2/eZc0 i716krSLw2R59pldGl4d9TtqeGrIVcVfw06dO4IE=
Date: Fri, 14 Aug 2020 05:24:43 -0700
From: mirjak <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK7PFYSHVB5IHX55D5V5IJRYXEVBNHHCQ5AU7A@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3997/674048845@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3997@github.com>
References: <quicwg/base-drafts/issues/3997@github.com>
Subject: Re: [quicwg/base-drafts] QUIC's Initial Congestion Window specification is incorrect (#3997)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5f36828b97153_8ff19641456a4"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: mirjak
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/XMfPqIjmiB7ZnmCvQZnmXGI84B8>
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: Fri, 14 Aug 2020 12:24:46 -0000

Gorry you wrote
 "Retransmission with a
more appropiate PMTU does not change the IW, which then sends too many
segments/packets."

However, if you retransmit because you have experienced loss in the initial round, don't you anyway have to decrease your congestion window?

About this RFC6928 says: 
"Furthermore, to limit any negative effect that a larger initial
   window may have on links with limited bandwidth or buffer space,
   implementations SHOULD fall back to RFC 3390 for the restart window
   (RW) if any packet loss is detected during either the initial window
   or a restart window, and more than 4 KB of data is sent."

So understanding would be that you are actually already supposed to kind or "reset" the initial window, no?


-- 
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/3997#issuecomment-674048845