[quicwg/base-drafts] Section 9.4 of Transport contains transport and congestion control functions (#2654)

Gorry Fairhurst <notifications@github.com> Thu, 25 April 2019 19:19 UTC

Return-Path: <bounces+848413-a050-quic-issues=ietf.org@sgmail.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 6AB9E1200D8 for <quic-issues@ietfa.amsl.com>; Thu, 25 Apr 2019 12:19:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.001
X-Spam-Level:
X-Spam-Status: No, score=-3.001 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, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_NONE=-0.0001, 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 N9lmVv4KhHjV for <quic-issues@ietfa.amsl.com>; Thu, 25 Apr 2019 12:19:41 -0700 (PDT)
Received: from o1.sgmail.github.com (o1.sgmail.github.com [192.254.114.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 831BC120126 for <quic-issues@ietf.org>; Thu, 25 Apr 2019 12:19:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:reply-to:to:cc:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=1A1U9nsHBnLVYdGy77EZejOkGdQ=; b=vpKxqKZXzRVZlN/N wkrxsbnRdBkExXY4KtGm65UrdIU6cSeANTFs8uy+XeQCC+HXO8z8MbNo5t1J3m0e DOIBt9BOSUH6yL2ppNJ74Hx4sdLsArvdAq8/BQjZEkRUhX+KA3Nuo+qoCwuj/iOq aI8mO5mys4o1KvJ4Wrl8P5XQTd8=
Received: by filter0796p1las1.sendgrid.net with SMTP id filter0796p1las1-32093-5CC2084B-B 2019-04-25 19:19:39.28756566 +0000 UTC m=+242169.701007761
Received: from github-lowworker-6313c1a.cp1-iad.github.net (unknown [140.82.115.71]) by ismtpd0015p1iad1.sendgrid.net (SG) with ESMTP id ACYZrjdNR5mB-9VR7l8OsQ for <quic-issues@ietf.org>; Thu, 25 Apr 2019 19:19:39.112 +0000 (UTC)
Received: from github.com (localhost [127.0.0.1]) by github-lowworker-6313c1a.cp1-iad.github.net (Postfix) with ESMTP id 0E924380071 for <quic-issues@ietf.org>; Thu, 25 Apr 2019 12:19:39 -0700 (PDT)
Date: Thu, 25 Apr 2019 19:19:39 +0000 (UTC)
From: Gorry Fairhurst <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK2ZEFAWMKB4DNGOISV2Z45MXEVBNHHBUEMLGE@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2654@github.com>
Subject: [quicwg/base-drafts] Section 9.4 of Transport contains transport and congestion control functions (#2654)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5cc2084bd354_7ae53f986c2cd960228060"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: gorryfair
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
X-SG-EID: l64QuQ2uJCcEyUykJbxN122A6QRmEpucztpreh3Pak2/e4xl21nykPSn+n1TbqdjHQWOsdbbKD9tri IoGMoZ413HryyO8nrkUMt/u8kl+0Wp6R4rh9OGdXX5kOD13oFt0L+Om1OAquZMJDzZKtEpDddjQ1Z+ TczpN0dK9o9YZI8M+NrKXZQ72OxID2H5k5vbxry/l+XBc0Rl1ULo0SmR0Gq2V7M09peGhXGeej/bLC I=
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/SNyHnnVdov26lSydf-OmGMoJpEc>
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, 25 Apr 2019 19:19:45 -0000

To me, section 9.4 contains a mixture of transport and congestion control functions (choice of path parameters - RTO, window, etc). The abstract suggests that these are a part of a different I-D. I also have comments on the intention for dealing with path changes:
---
Section 9.4:
NiT: “On confirming a peer's ownership of its new address, an endpoint
   SHOULD immediately reset the congestion controller and round-trip
   time estimator for the new path.”
- To be clear, does this reset require setting the CC to the initial value for a connection? I think so.
—
CC:   “An endpoint MUST NOT return to the send rate used for the previous
   path unless it is reasonably sure that the previous send rate is
   valid for the new path. “
- This is a congestion control semantic. (I’m surprised this is a part of QUIC transport, rather than the CC & recovery draft). I think the normal transport assumption is that a change of path implies a loss of congestion state and other path CC parameters. This is therefore a “significant” departure from conventional approaches considered safe - extending this to “reasonably sure”. How do people quantify reasonably sure, where is the information to say that the connection should not use the Initial window?
---
CC: “if the new path capacity is significantly reduced, ultimately this relies on the congestion controller responding to congestion signals and reduce send rates appropriately.” 
-  I’d suggest this could be a significant change too what has been practice with TCP CC? And it would often not be a huge performance implication to initialise IW and build from there.
---
CC:   “While multiple paths might be used during connection migration, a
   single congestion control context and a single loss recovery context
   (as described in [QUIC-RECOVERY]) may be adequate. “
- I think the transport I-D should not make these claims, because this also seems like a CC decision. I actually do not understand this specific claim, as currently presented.
---


-- 
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/2654