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

MikkelFJ <notifications@github.com> Fri, 14 December 2018 18:02 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 A297A1311E6 for <quic-issues@ietfa.amsl.com>; Fri, 14 Dec 2018 10:02:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.46
X-Spam-Level:
X-Spam-Status: No, score=-9.46 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, 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 ykeZz07mxeFC for <quic-issues@ietfa.amsl.com>; Fri, 14 Dec 2018 10:02:19 -0800 (PST)
Received: from out-4.smtp.github.com (out-4.smtp.github.com [192.30.252.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DF6B130DD7 for <quic-issues@ietf.org>; Fri, 14 Dec 2018 10:02:19 -0800 (PST)
Date: Fri, 14 Dec 2018 10:02:18 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1544810538; bh=UMNKIqaAiOjtMu9XitxvH51dKNfXCXEfU7HyZoXuqIU=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=fRs/7RKjoB+FEx2Q7WBTdNVmNIMG2Gxldwt58mjbR4kThS8XCI1xvJprlHzzFQoF9 ovBe1YxLLxng31BGhRx62UDHFPvpNg5fkzSYEOVZ4rGAaNbWLCXkWJZKr4vcTa88bQ 1tHnXs1PAPyo8Oq7vnQAf7ECyyX53Ez9vvnWyjoY=
From: MikkelFJ <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab1c148dfd1981035d77f5a15be91ffccfe82acf9e92cf00000001182bb22a92a169ce174df843@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/447404494@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_5c13f02ae0dd_4a63fdc3b0d45c4520521"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: mikkelfj
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/Aads9BKKYJcI_3SPoBIda_H6qAM>
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, 14 Dec 2018 18:02:22 -0000

With 0-RTT in check, I think the early RTO shouldn't be viewed as a failure recovery mechanism but more like a sample mechanism for discovering uncharted territory. In that light, it could go down to 10ms as long as it is only until first contact. However, because the Initial is not small (1200+ bytes), a too small original RTO would be wasteful.

So the question becomes: what is acceptable latency, what is the likely error rate, and how much bandwidth is wasted by aggressive probing.

If, for example, some common scenarios has a 66% packet loss and RTO is 100ms, you have to wait about 200ms extra to connect, even if the RTT is small, like 4ms (say noisy WLAN).

On the other hand, if the latency is high, like 500ms and the loss is small, you would be sending 5x the necessary data to connect, so 5x1200 bytes, but if you loose a packet, connectivity starts a 600ms instead of 500ms.

You could also imagine a very conservative initial RTO like 1000ms but at the same time send out small probe packets every 10ms until a valid RTT estimate is achieved, but that has its own problems in complexity and trust.


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