IETF Logo Mail Archive

Re: [quicwg/base-drafts] recovery: clarifying the priority of Probe packet contents (#3780)

Eric Kinnear <notifications@github.com> Tue, 23 June 2020 04:24 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 C399A3A091F for <quic-issues@ietfa.amsl.com>; Mon, 22 Jun 2020 21:24:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.555
X-Spam-Level:
X-Spam-Status: No, score=-1.555 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, RCVD_IN_MSPIKE_H2=-0.001, 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 mTEQKTR93JI9 for <quic-issues@ietfa.amsl.com>; Mon, 22 Jun 2020 21:24:09 -0700 (PDT)
Received: from out-23.smtp.github.com (out-23.smtp.github.com [192.30.252.206]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DD3B3A1738 for <quic-issues@ietf.org>; Mon, 22 Jun 2020 21:24:09 -0700 (PDT)
Received: from github-lowworker-56fcc46.va3-iad.github.net (github-lowworker-56fcc46.va3-iad.github.net [10.48.102.32]) by smtp.github.com (Postfix) with ESMTP id 9695E66044D for <quic-issues@ietf.org>; Mon, 22 Jun 2020 21:24:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1592886248; bh=7ShZRBbYMA7/X2DzTdC+Mu2HC5YFKj4mVfnibEH/uuw=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=FUkMfnAxo7iqC7iYdFLAOEP52bxZ+PQBLb2QvwU8EIVhEk6rAl5qnfdUec6OuEGQh ATq9yCSsEaC8WzH204ZWn5KUWYj4T7ECCPYMg0NV+vdg6sfoNOPHUMLfqt+N20z52L X5h0hMYxGUoeMKIDA1JRnf7bbuNJ9nyBX7m4hvhI=
Date: Mon, 22 Jun 2020 21:24:08 -0700
From: Eric Kinnear <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK4LWYBVQPSAQO7GOGF47VSOREVBNHHCMOWLJI@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3780/647898608@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3780@github.com>
References: <quicwg/base-drafts/issues/3780@github.com>
Subject: Re: [quicwg/base-drafts] recovery: clarifying the priority of Probe packet contents (#3780)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5ef183e887394_36133fe5c36cd96c794e8"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: erickinnear
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/A-pI9Z04j25EvRGN6N8RUAfgbtY>
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: Tue, 23 Jun 2020 04:24:11 -0000

> That's correct, but a retransmission always has a higher packet number than earlier sent packets, so the contents of the packet don't matter, right?

This seems right to me; we're retransmitting frames, not packets.

> Do we have research that points more clearly to one choice being better than another?

If folks get a chance to experiment with this and publish their results, that would be super cool!

But it seems like that's somewhat orthogonal to getting this spec finished, since so far we've settled with "doing the default thing should get you functional QUIC". 

It seems like all options here work well enough that we don't need further text unless either we have some data or we have a principle of why one option is deterministically better?

-- 
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/3780#issuecomment-647898608

v2.23.0 | Report a Bug | By Email