IETF Logo Mail Archive

Re: [quicwg/base-drafts] SHOULD implement adaptive packet threshold loss detection (#3571)

Igor Lubashev <notifications@github.com> Wed, 29 April 2020 16:30 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 800CC3A13CC for <quic-issues@ietfa.amsl.com>; Wed, 29 Apr 2020 09:30:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.554
X-Spam-Level:
X-Spam-Status: No, score=-1.554 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, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_HELO_NONE=0.001, 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 2nkZP2TB3_hI for <quic-issues@ietfa.amsl.com>; Wed, 29 Apr 2020 09:30:18 -0700 (PDT)
Received: from out-16.smtp.github.com (out-16.smtp.github.com [192.30.254.199]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 182A53A138B for <quic-issues@ietf.org>; Wed, 29 Apr 2020 09:30:17 -0700 (PDT)
Received: from github-lowworker-25680bd.va3-iad.github.net (github-lowworker-25680bd.va3-iad.github.net [10.48.17.61]) by smtp.github.com (Postfix) with ESMTP id 8D768121244 for <quic-issues@ietf.org>; Wed, 29 Apr 2020 09:30:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1588177817; bh=olcfbmDRxZR9I9k3iADBwaPOr3XqLiWrncmAemjN0Wg=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=orwyhyLTnU9J6b3E/e85ruUCxyWxcuR1gjAkeDib14LdJ8uUBmwNfOekdG3Qsz/VC JT97nmmDZbkiCkRGjaz4gFrXKzoS85Ag8VleT7AThZdGexqDvViOztGaOZOo7DYIG1 VIj/mdwjBAIECrCwFCoyX1cBiGdbA+dAV4Gyblcs=
Date: Wed, 29 Apr 2020 09:30:17 -0700
From: Igor Lubashev <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKY7FH7HALULIHBXRBN4WWGJTEVBNHHCHD36DQ@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3571/621322389@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3571@github.com>
References: <quicwg/base-drafts/issues/3571@github.com>
Subject: Re: [quicwg/base-drafts] SHOULD implement adaptive packet threshold loss detection (#3571)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5ea9ab9944ca3_46933f9fbcacd960301fa"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: igorlord
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/4FYPFSTrzv-oubF03YBnUpkHo1Y>
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: Wed, 29 Apr 2020 16:30:20 -0000

> What about simply noting that adaptive strategies such as X, Y, and Z have proven to be useful in TCP, and would apply equally to QUIC?

My thinking is that "adaptive strategies" would not only "apply equally to QUIC" but be "**significantly** more important for QUIC".  Operators are aware of the havoc that excessive reordering in their networks causes to TCP and have deployed middle boxes for restoring TCP ordering in such networks.  Such network "optimizations" are not possible with QUIC, so QUIC will see more TCP reordering.  We've seen such extreme reordering of QUIC in production.

-- 
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/3571#issuecomment-621322389

v2.30.2 | Report a Bug | By Email | System Status