Re: [quicwg/base-drafts] Samples for RTT estimation (#2067)

janaiyengar <notifications@github.com> Fri, 30 November 2018 03:41 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 0F515126CB6 for <quic-issues@ietfa.amsl.com>; Thu, 29 Nov 2018 19:41:39 -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 2z8NHEdFYFof for <quic-issues@ietfa.amsl.com>; Thu, 29 Nov 2018 19:41:37 -0800 (PST)
Received: from out-2.smtp.github.com (out-2.smtp.github.com [192.30.252.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C414126C01 for <quic-issues@ietf.org>; Thu, 29 Nov 2018 19:41:37 -0800 (PST)
Date: Thu, 29 Nov 2018 19:41:36 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1543549296; bh=K0ny5wWHQpFq3jJ6H28Wv6jYLy4Gbisp7iWW7F3yDvU=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=C2xV+ZLGa0P0wym1X9BR11uTVWUTjUrLQF0xL7/xg/vuNSs5n/f/G36bcopqcyUVt eg2jmc5QMczkNxVxOzFf/QtbbQ4LroDl6gpzP/7vRi6qoVzclBw7/IxykLvAdTy8vl +sFI8mZobBESg0b7P2Q+vp4WqFl7hHn77R2jIxCU=
From: janaiyengar <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab5e46b943b37bebcf51382333b7e69753304cdc3c92cf000000011818737092a169ce16faa2ff@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2067/443080711@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2067@github.com>
References: <quicwg/base-drafts/issues/2067@github.com>
Subject: Re: [quicwg/base-drafts] Samples for RTT estimation (#2067)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c00b170801fd_4e403f80c76d45c076628"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: janaiyengar
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/HtHOH40l0WIwQdvL44Xe4H7od04>
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, 30 Nov 2018 03:41:39 -0000

For context, the entire paragraph is:
```
   For fairly modest congestion window sizes, research suggests that
   timing each segment does not lead to a better RTT estimator [AP99].
   Additionally, when multiple samples are taken per RTT, the alpha and
   beta defined in Section 2 may keep an inadequate RTT history.  A
   method for changing these constants is currently an open research
   question.
```

It is true that counting each packet causes us to retire history faster.  Where this matters is when the sender might RTO or TLP too soon, since too late is usually not a problem. This might happen still, but our deployment experience so far has not shown this to cause any undue issues. Specifically, a QUIC sender detects and handles spurious timeouts better than TCP senders did when RFC 2988 (the precursor to RFC 6298) was written.

It may be possible to tweak these constants to make them better for the "correct" timescale, but as @ianswett (and RFC 6298) points out, that is very much open research issue. The numbers in 6298 come from 2988 which was based on measurement studies from 1999 (the end-to-end path properties in the refs section of 6298).

-- 
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/2067#issuecomment-443080711