IETF Logo Mail Archive

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

Christian Huitema <notifications@github.com> Mon, 17 December 2018 06:23 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 1AB46128CE4 for <quic-issues@ietfa.amsl.com>; Sun, 16 Dec 2018 22:23:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.459
X-Spam-Level:
X-Spam-Status: No, score=-9.459 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_IMAGE_ONLY_32=0.001, 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 1ZxaL2CISds8 for <quic-issues@ietfa.amsl.com>; Sun, 16 Dec 2018 22:23:12 -0800 (PST)
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 3D064128BCC for <quic-issues@ietf.org>; Sun, 16 Dec 2018 22:23:12 -0800 (PST)
Date: Sun, 16 Dec 2018 22:23:10 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1545027790; bh=y/VnxsasalhyWJBZ7XfFrdH3OCDCjWIBa3y2RFi2ySA=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=tGRCTXTJfSOnDFwwyX8iVVcyb3j9KkRhc0cJR/+ITj3iPpRzAuubN2dykvnIbsOnZ 3Kr7VVvwvSBM/7ln/uNVARTbPwHj3akR+Z2X0n2vjGaP0+W5fKaYhUpkhOWVnJDEm4 3eURlfr+oGHYLPNaJREaZ9EEqCmWIzJA4bD9GetM=
From: Christian Huitema <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abb0bf526ac4a9e79f796acca2cfbd681b9e0a8c5992cf00000001182f02ce92a169ce174df843@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/447735381@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_5c1740cef0f23_35b23ff48d4d45c411316f"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: huitema
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/4YhgFzSFJ0tEwvnZI_GA2pN7Z5w>
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, 17 Dec 2018 06:23:14 -0000

It depends how many times a client is going to retransmit. It is all a matter of tradeoffs. Suppose that we transmit 4 times at 100 ms interval; on a geo stationary satellite link the response will come after 600ms. That means all connection attempts will fail. If the client does exponential back off, it will transmit at 0, 100, 300, 700. Then the satellite connection will work most of the time. But the client will only certify a failure after 1100 ms. 

So no, we don't need to optimize for the worst case. But we need to make sure that the worst case does not always fail. If nodes want optimization, they can remember the RTT of commonly used destinations and use that instead of the default.

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

v2.23.0 | Report a Bug | By Email