IETF Logo Mail Archive

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

Vidhi Goel <notifications@github.com> Tue, 23 June 2020 04: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 234C43A173B for <quic-issues@ietfa.amsl.com>; Mon, 22 Jun 2020 21:41:43 -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 Bh1Tw2yiTPvr for <quic-issues@ietfa.amsl.com>; Mon, 22 Jun 2020 21:41:41 -0700 (PDT)
Received: from out-26.smtp.github.com (out-26.smtp.github.com [192.30.252.209]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A79AA3A1739 for <quic-issues@ietf.org>; Mon, 22 Jun 2020 21:41:41 -0700 (PDT)
Received: from github-lowworker-d1d6e31.ash1-iad.github.net (github-lowworker-d1d6e31.ash1-iad.github.net [10.56.105.50]) by smtp.github.com (Postfix) with ESMTP id B6D99282047 for <quic-issues@ietf.org>; Mon, 22 Jun 2020 21:41:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1592887300; bh=TMRd27u/gJ7ZtO8YvmsEee6ihENGVZiBsL57y+FkXfg=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=RNKJmT/mfPBZz010n/ETBOT4dTuQRRE98hyLhXS0Qf9r5EPx/dy5+tqY+2mUO3+fI ufnoLsnGbEZhbiFww6MXZig0tKaJqNdKkg/Hj05cIyi2UqEjP5o9MLAQrhkbyR7DFs COOOT/lSzxp4oqQ/bQx+2leO4vtWZmJFGj755Akg=
Date: Mon, 22 Jun 2020 21:41:40 -0700
From: Vidhi Goel <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKYRKJ7B7RDWDW25FQN47VUQJEVBNHHCMOWLJI@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/647903349@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_5ef18804a72db_26003febc42cd964189436"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: goelvidhi
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/GcwxX9B32wze8G5idapNjtKvRXs>
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:41:43 -0000

> So, a tail packet (with no packets after it) wouldn't be marked lost until after some earlier packets were retransmitted.
> 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? Or am I misunderstanding your argument?

I am not saying that the contents matter. What I am saying is if we send a PTO probe for the tail packet, we would recover faster as it doesn't have to wait for the retransmissions for earlier packets (1 as 6). With this approach we would be able to retransmit both tail (via PTO) and head (via ACK for pn 4) faster than the other approach.

That being said, I am neutral towards making any change to the draft and leaving it to implementors is a fine option.

-- 
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-647903349

v2.23.0 | Report a Bug | By Email