Re: [quicwg/base-drafts] It's unclear if persistent congestion is a per-PN-space property (#3939)

Jana Iyengar <notifications@github.com> Thu, 23 July 2020 03:56 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 4A7913A0C07 for <quic-issues@ietfa.amsl.com>; Wed, 22 Jul 2020 20:56:55 -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 tHwJHB7QCbFC for <quic-issues@ietfa.amsl.com>; Wed, 22 Jul 2020 20:56:54 -0700 (PDT)
Received: from out-24.smtp.github.com (out-24.smtp.github.com [192.30.252.207]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB3833A0C04 for <quic-issues@ietf.org>; Wed, 22 Jul 2020 20:56:53 -0700 (PDT)
Received: from github-lowworker-d1d6e31.ash1-iad.github.net (github-lowworker-d1d6e31.ash1-iad.github.net [10.56.105.50]) by smtp.github.com (Postfix) with ESMTP id 2C38D6A095C for <quic-issues@ietf.org>; Wed, 22 Jul 2020 20:56:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1595476611; bh=q1m+Lw+ZMMeFv6DB3f0m3vlDg60R7WYc8dvjV2YML50=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=0ao3HfgjwmvCXLGm4sZiUrPiiwWAB1JSwsdQLQ8d9oZkQdBX7pwyJVN+d/8OL49dR U1bEP+YvodrKcaJReoUf6qajHfDwdKc8X7JsW0XbC6aPa4GYc+HEmQ2bBUC39QEe+y twNJzeEHG5ykhT+Hma/YXVhFA+5FhIGIpnnR8lDs=
Date: Wed, 22 Jul 2020 20:56:51 -0700
From: Jana Iyengar <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK6EB2PWXWYHERN67ON5ETVYHEVBNHHCPC6CX4@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3939/662806831@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3939@github.com>
References: <quicwg/base-drafts/issues/3939@github.com>
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_5f190a831bcdf_4e743f970f4cd96c8537d"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: janaiyengar
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/3qVoPZ5q5kWF8uGNUzoMBry1yE4>
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, 23 Jul 2020 03:56:55 -0000

It shouldn't be, because congestion is a network/connection-level property. That said, @marten-seemann and I were discussing this offline, and I'm now coming to terms with the fact that it's hard to do this globally across packet number spaces.  

Basically we have no current model to track packet transmissions across packet number spaces, and implementations do not typically do this either. I think this is hard to do across PN spaces... or at least, I've not been able to figure out a reliable way to do it. 

I'm now thinking that we might want to disable persistent congestion until the handshake is confirmed. That is a departure from TCP, but I might argue that is still ok. In practice, we still have a congestion window reduction that occurs on losses in this period. Also, in practice, since the handshake will involve only a few packets in flight, losses should cause the cwnd to reduce to a small enough value.

Thoughts?

-- 
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-662806831