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 8623E3A0C2D for ; Wed, 22 Jul 2020 21:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.1 X-Spam-Level: X-Spam-Status: No, score=-3.1 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_32=0.001, 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 Jyyge3t4I_Vl for ; Wed, 22 Jul 2020 21:23:14 -0700 (PDT) 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 210A53A0C2B for ; Wed, 22 Jul 2020 21:23:14 -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 2DAF7661024 for ; Wed, 22 Jul 2020 21:23:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1595478193; bh=3xET2Dxx9zKVUNEwlDwVfxmahuGNqXF0WCju5tDQ7vg=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=0Hvm5KCgZehzYunk1h7FZqWXacSnusVGldT33nkiSnt12hIES4EvqXlnqBWzHl7l6 Ud5QMo6X7KCH+I41J88khYLtZFXtwoqHauTl0/rD2dQePZxgepDlaga/Ihx8ofriSL zH0DHZpts+EOePLbfBX4PmCqXho03CcywdKp1uxY= Date: Wed, 22 Jul 2020 21:23:13 -0700 From: Marten Seemann Reply-To: quicwg/base-drafts To: quicwg/base-drafts Cc: Subscribed Message-ID: In-Reply-To: References: Subject: Re: [quicwg/base-drafts] It's unclear if persistent congestion is a per-PN-space property (#3939) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_5f1910b11de23_fa13f94690cd96472324"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: marten-seemann 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: Thu, 23 Jul 2020 04:23:16 -0000 ----==_mimepart_5f1910b11de23_fa13f94690cd96472324 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit > * When receiving an acknowledgement, mark a hole in the sentmap for the packet being acked. I don't think this is trivial, quite the opposite actually. A "hole" would be extra state (note that just the absence of a packet at a certain PN does not constitute a hole, since you could've skipped that PN to mitigate the optimistic ACK attack), and that additional state has to be cleaned up. In my implementation, when a packet is acknowledged, I know I can delete it and get rid of all state associated with it. Deviating from this, just to be able to do do persistent congestion detection across packet number spaces, seems like a lot of hassle to me. As @janaiyengar described, any packet loss during the handshake will half the congestion window, and with #3943, it will even reduce the congestion window to half the bytes in flight (which will commonly be less than the cwnd during the handshake). Simple Reno-style congestion control will therefore lead to behavior that is very similar to actually doing persistent congestion detection across packet number spaces, without all the additional complexity. -- 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/3939#issuecomment-662811684 ----==_mimepart_5f1910b11de23_fa13f94690cd96472324 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

  • When receiving an acknowledgement, mark a hole in the sentmap for the= packet being acked.

I don't think this is trivial, quite the opposite actually. A "hole" w= ould be extra state (note that just the absence of a packet at a certain = PN does not constitute a hole, since you could've skipped that PN to miti= gate the optimistic ACK attack), and that additional state has to be clea= ned up.

In my implementation, when a packet is acknowledged, I know I can dele= te it and get rid of all state associated with it. Deviating from this, j= ust to be able to do do persistent congestion detection across packet num= ber spaces, seems like a lot of hassle to me.
As @janaiyengar described, any packet loss during the handsh= ake will half the congestion window, and with #3943, it will even reduce t= he congestion window to half the bytes in flight (which will commonly be = less than the cwnd during the handshake). Simple Reno-style congestion co= ntrol will therefore lead to behavior that is very similar to actually do= ing persistent congestion detection across packet number spaces, without = all the additional complexity.

&m= dash;
You are receiving this because you are subscribed to this thre= ad.
Reply to this email directly, view it on GitHub,= or unsubscribe.3D""

= ----==_mimepart_5f1910b11de23_fa13f94690cd96472324--