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 03:46 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 9CBD23A171E for <quic-issues@ietfa.amsl.com>; Mon, 22 Jun 2020 20:46:14 -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 zgLa6S-GfMYA for <quic-issues@ietfa.amsl.com>; Mon, 22 Jun 2020 20:46:13 -0700 (PDT)
Received: from out-19.smtp.github.com (out-19.smtp.github.com [192.30.252.202]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B25C3A171A for <quic-issues@ietf.org>; Mon, 22 Jun 2020 20:46:13 -0700 (PDT)
Received: from github-lowworker-f144ac1.va3-iad.github.net (github-lowworker-f144ac1.va3-iad.github.net [10.48.16.59]) by smtp.github.com (Postfix) with ESMTP id 9769752076A for <quic-issues@ietf.org>; Mon, 22 Jun 2020 20:46:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1592883972; bh=3xwtAwtPtuZL4XcocLvb0jVFSERie1ZgpG080By64rw=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Zx26QqhOlVE1SeCXlzIqn541MUtjuO8l58SCQLU9QNJGKW3TAF682o50G2+H9bPvb jSmp4kA0U47tpDh+FtZ3Q74YG9ppH/ePqBrRjuJ/ixmLxrxE1+FfEzsGzKhUoGUehr pPq31CxwrZpwifS4DnkFCei+pCvp7u3kt0IWC40c=
Date: Mon, 22 Jun 2020 20:46:12 -0700
From: Vidhi Goel <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKYS7LDMA6DZG6NE3GN47VOAJEVBNHHCMOWLJI@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/647890042@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_5ef17b04882cc_726d3f970cccd96c4319c5"; 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/HBrP7o6CkSDYnFExreacrijPi2k>
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 03:46:15 -0000

This is a great question and I incline towards sending the newest (tail) unacknowledged data first (same as TLP in TCP). Lets say we sent packets 1,2,3,4 & 5 at the same time and assume 1 & 5 were lost. Now, PTO fires.

1. Lets say, on PTO expiry, we retransmit the oldest packet i.e. 1. When the PTO timer fires a second time, only then we would send pn=5.
2. OTOH, if we retransmit the tail first, i.e. pn=5, it provides faster recovery, because an arriving ACK with largest pn=4 will mark pn=1 as lost and we will retransmit that immediately.

The unacknowledged packets at the head have the advantage of subsequent packets allowing them to recover via ACKs marking them as lost. Not so much for the tail packets.



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

v2.23.0 | Report a Bug | By Email