Return-Path: 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 2829C130E4A for ; Thu, 20 Dec 2018 05:54:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.064 X-Spam-Level: X-Spam-Status: No, score=-8.064 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, 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 w86LdgghaejG for ; Thu, 20 Dec 2018 05:54:05 -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 38980130DFC for ; Thu, 20 Dec 2018 05:54:05 -0800 (PST) Date: Thu, 20 Dec 2018 05:54:04 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1545314044; bh=+07r1gEQyEwhmlv7OWfuMcpE25A8IFkT5V5L3AtKRcI=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=VvwgztqHX2cpP89VXY1i12yqkx9qcll1Y+Y+BVqRtlM8a6OYqstHryp20JJZjgDG6 zcY/xUnDKapJ6h6PZqgJ1LJsgCfA9V0SCluDUX7tDpLlz6b0HwtqYEdDwdD/qYmzBd UEPZywTq353kotCIxxEbpMJLf7jG1bSmBgs5l1TM= From: ianswett Reply-To: quicwg/base-drafts To: quicwg/base-drafts Cc: Subscribed Message-ID: In-Reply-To: References: Subject: Re: [quicwg/base-drafts] RTT variance may be included in threshold (#2213) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_5c1b9efc2c940_7cd63fb11ccd45bc1371aa"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: ianswett X-GitHub-Recipient: quic-issues X-GitHub-Reason: subscribed X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: quic-issues@ietf.org Archived-At: X-BeenThere: quic-issues@ietf.org X-Mailman-Version: 2.1.29 List-Id: Notification list for GitHub issues related to the QUIC WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2018 13:54:07 -0000 ----==_mimepart_5c1b9efc2c940_7cd63fb11ccd45bc1371aa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit ianswett commented on this pull request. > @@ -362,10 +362,10 @@ Using max(SRTT, latest_RTT) protects from the two following cases: * the latest RTT sample is higher than the SRTT, perhaps due to a sustained increase in the actual RTT, but the smoothed SRTT has not yet caught up. -Implementers MAY experiment with using other reordering thresholds, including -absolute thresholds, bearing in mind that a lower multiplier reduces reordering -resilience and increases spurious retransmissions, and a higher multiplier -increases loss detection delay. +Implementers MAY experiment with including RTT variance in the threshold, or To make this slightly harder still, Chromium's early experiments showed that loss was not correlated, but when an application is using the network, evidence shows loss is very correlated. So I don't think we can understand the prevalence and nature of reordering in a network without using the network in a realistic way, such as HTTP. -- 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/pull/2213#discussion_r243278596 ----==_mimepart_5c1b9efc2c940_7cd63fb11ccd45bc1371aa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

@ianswett commented on this pull request.

In draft-ietf-quic-recovery.md:

> @@ -362,10 +362,10 @@ Using max(SRTT, latest_RTT) protects from the two following cases:
 * the latest RTT sample is higher than the SRTT, perhaps due to a sustained
   increase in the actual RTT, but the smoothed SRTT has not yet caught up.
 
-Implementers MAY experiment with using other reordering thresholds, including
-absolute thresholds, bearing in mind that a lower multiplier reduces reordering
-resilience and increases spurious retransmissions, and a higher multiplier
-increases loss detection delay.
+Implementers MAY experiment with including RTT variance in the threshold, or

To make this slightly harder still, Chromium's early experiments showed that loss was not correlated, but when an application is using the network, evidence shows loss is very correlated. So I don't think we can understand the prevalence and nature of reordering in a network without using the network in a realistic way, such as HTTP.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_5c1b9efc2c940_7cd63fb11ccd45bc1371aa--