[quicwg/base-drafts] CC state after a change of path? (#2685)

Gorry Fairhurst <notifications@github.com> Fri, 10 May 2019 08:29 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 0E340120198 for <quic-issues@ietfa.amsl.com>; Fri, 10 May 2019 01:29:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.392
X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id DFXU85o1us1V for <quic-issues@ietfa.amsl.com>; Fri, 10 May 2019 01:29:12 -0700 (PDT)
Received: from out-20.smtp.github.com (out-20.smtp.github.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2782012017A for <quic-issues@ietf.org>; Fri, 10 May 2019 01:29:11 -0700 (PDT)
Date: Fri, 10 May 2019 01:29:10 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1557476950; bh=wFrZbC74EeLxKo/N2oci3/oB0a9gO9Nsr3/taGlHv1c=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=tY1gt6rEtW+HfzNQw7EJxDL6RYzhA4U/4WcKZ8AoTwr8ktPH7IAxsZX7Cpv9YQUIL SlJS87h7TJOyg1/P5NkumHVhfy0RQE8dwq7FlFeZjGSvNFE5glsAhDJb5EGzN3El+k P2jxd7DSt6BUWJz2GzjkunLBv0NiiuYOk6tzpnB0=
From: Gorry Fairhurst <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK3T3OY2GSHT7GYPKI524JUNNEVBNHHBUYMJPU@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2685@github.com>
Subject: [quicwg/base-drafts] CC state after a change of path? (#2685)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5cd536561898d_52b63f9cba2cd96830809a"; 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
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/YLq8HE-m4gJ7wAU95HasohJ9Hc0>
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, 10 May 2019 08:29:13 -0000

I think a normal transport assumption is that a change of path implies a (potential) loss of congestion state, and that the endpoint should reset the path CC parameters. 

Transport-ID: “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.”

• Does the "reset" require setting the CC to the initial window value for a connection? I think so.
• Why not MUST? 

Transport-ID:  “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 could therefore be seen as a “significant” departure from conventional approaches considered safe - and extends this to “reasonably sure”. 
• Is there a rationale for extending this to “reasonably sure”, because this seems bolder than permitted for a new TCP connection. How do people quantify reasonably sure, and why not just in this case grow from the Initial window? 

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: