From nobody Fri Aug 14 05:24:47 2020 Return-Path: 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 ; 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 ; 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 ; 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 ; 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 Reply-To: quicwg/base-drafts To: quicwg/base-drafts Cc: Subscribed Message-ID: In-Reply-To: References: 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: X-BeenThere: quic-issues@ietf.org X-Mailman-Version: 2.1.29 List-Id: Notification list for GitHub issues related to the QUIC WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 12:24:46 -0000 ----==_mimepart_5f36828b97153_8ff19641456a4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 ----==_mimepart_5f36828b97153_8ff19641456a4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

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, view it on GitHub, or unsubscribe.

----==_mimepart_5f36828b97153_8ff19641456a4--