[quicwg/base-drafts] Restructure RTT section (#2567)

Jana Iyengar <notifications@github.com> Sat, 30 March 2019 20:07 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 E30DC12026C for <quic-issues@ietfa.amsl.com>; Sat, 30 Mar 2019 13:07:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.001
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id FYeGq7wh6COw for <quic-issues@ietfa.amsl.com>; Sat, 30 Mar 2019 13:07:00 -0700 (PDT)
Received: from out-16.smtp.github.com (out-16.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 216BD12025A for <quic-issues@ietf.org>; Sat, 30 Mar 2019 13:07:00 -0700 (PDT)
Date: Sat, 30 Mar 2019 13:06:59 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1553976419; bh=vhrQ1NbMtvwyzYywS70ffC2x+nGgtVYOxcc4+GFA6W8=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=n93+eKERjp8CjHNKyihwxtys7pWxulHJItkqVhEyrrXTOdpAto0+D4nsVu8/PwK60 34SpIab8MsvAcLCohVHL6ChTQLsKAE+soWri8BhkxZt+//1EkYDy/R6Zj2aHfKnZ5o QJqlTxjmxERJy+6Wq/9RJ9fAsqS25ODfA4sfcGM8=
From: Jana Iyengar <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abc64203f5af7005a446d0294e41cb03df284fc71292cf0000000118b78e6392a169ce19786ea0@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2567@github.com>
Subject: [quicwg/base-drafts] Restructure RTT section (#2567)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c9fcc63384ae_23c73fa84d4d45c412616de"; 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/fK4qHcKPR6Yai5gTO9hSJb4zo5o>
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: Sat, 30 Mar 2019 20:07:02 -0000

>From #2506, @martinthomson had a suggestion for restructuring the RTT estimation section.

The baseline concepts here are:

- the observed RTT (latest_rtt in the code), which includes any processing delays on the receiver end

- minimum RTT, which is set to the minimum observed RTT for the path. this doesn't include any processing delays on the receiver end, which might inflate the value a little, but we assume that receivers will immediately acknowledge a packet at some point (usually this is a good idea for a new path, and handshaking more or less depends on that)

- ack delay, which captures the processing time and any forced delays on the receiver. This is limited to the maximum value the receiver advertises. This value is self-reported, so any error needs to result in using less network capacity, not more, or it could be used to increase network load inappropriately. The goal here is to have an RTT estimate that is larger. Thus, the design is such that if ACK delay is under-reported, or the maximum is set lower than the reality, this will result in an inflated RTT estimate. If this is over-reported, the maximum will cap the value and again cause the RTT estimate to be driven up also.

- The final RTT calculation. This is calculated based on the observed RTT and the adjusted ack delay. The value is smoothed so that some history is retained.

This structure matches the code, but I think that changes aren't really necessary.

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