Re: [quicwg/base-drafts] kInitialRtt of 100 msec is too aggressive (#2184)

Praveen Balasubramanian <notifications@github.com> Mon, 25 March 2019 22:24 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 848D3120117 for <quic-issues@ietfa.amsl.com>; Mon, 25 Mar 2019 15:24:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.001
X-Spam-Level:
X-Spam-Status: No, score=-8.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_HI=-5, 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 vvWHMLryhtNO for <quic-issues@ietfa.amsl.com>; Mon, 25 Mar 2019 15:24:16 -0700 (PDT)
Received: from out-6.smtp.github.com (out-6.smtp.github.com [192.30.252.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9BC6120105 for <quic-issues@ietf.org>; Mon, 25 Mar 2019 15:24:15 -0700 (PDT)
Date: Mon, 25 Mar 2019 15:24:14 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1553552654; bh=Xv4em3yKzdp+CHZzVy2TeO8EIS4MqT6KifLl2zzuvN8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=eX/Qc7VBD8wfYJkmw+XpNEey+4EuxWxPvJntTYXEUchk/4Zs7MhtPOg6BtN/o2OHP BoJjeeU8cD8ByPbMPJv5H1ulFalGI1tBfGVFJ37JuuF/J7a6OCSIAlmO1kKdelX/6F G2oSjd3RKXmTYldcm4CiJz2aIIoHeAgWsYHTGiKo=
From: Praveen Balasubramanian <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab2b89140568c2ece1f14c14b00f0d39b27a39b6c092cf0000000118b1170e92a169ce174df843@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2184/476400711@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2184@github.com>
References: <quicwg/base-drafts/issues/2184@github.com>
Subject: Re: [quicwg/base-drafts] kInitialRtt of 100 msec is too aggressive (#2184)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c99550e93f4b_a7f3f99f40d45bc6498c"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: pravb
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/OVyRPNIIVy3cQp1tWE1kLW0LI18>
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: Mon, 25 Mar 2019 22:24:17 -0000

Please see  https://www.rfc-editor.org/rfc/rfc6298.txt Appendix A for a discussion of why the 1 second minimum was suggested for TCP. Based on data quoted there, 2.5% connections will experience spurious retransmissions if initialRTO < 1 second. Since QUIC will always get an RTT sample when handshake completes, we don't need any provision to reset the InitialRTT higher even if there were timeouts.


Orthogonal to this particular issue but a total timeout of 4 seconds (or anything less than 9 seconds) is going to be a problem for VM live migrations. It's assumed that the blackout period for live migration can last as long as 9 seconds because historically TCP would always retransmit at least once after 9 seconds. I guess its not a problem for browsers but if QUIC is used in other HTTP and non-HTTP libraries then connections will break during LM. 

-- 
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/2184#issuecomment-476400711