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

Junho Choi <notifications@github.com> Tue, 23 June 2020 09:53 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 3BCD03A183F for <quic-issues@ietfa.amsl.com>; Tue, 23 Jun 2020 02:53:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.697
X-Spam-Level:
X-Spam-Status: No, score=-1.697 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_28=1.404, 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 ZBXufYnxrlnD for <quic-issues@ietfa.amsl.com>; Tue, 23 Jun 2020 02:53:31 -0700 (PDT)
Received: from out-21.smtp.github.com (out-21.smtp.github.com [192.30.252.204]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1F363A1842 for <quic-issues@ietf.org>; Tue, 23 Jun 2020 02:53:31 -0700 (PDT)
Received: from github-lowworker-c73936b.ash1-iad.github.net (github-lowworker-c73936b.ash1-iad.github.net [10.56.112.13]) by smtp.github.com (Postfix) with ESMTP id B85EEA011D for <quic-issues@ietf.org>; Tue, 23 Jun 2020 02:53:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1592906010; bh=9QRRisSWYZTf0c3z+3ilJq18CvohnEV5NzUMUcvUT9s=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=06k1vo7ZwPUGH/7o2py4IxUheZ7lbPN6GoyRbzvKX9i1gRzqs5NQzHyWAKWcHyI4B 3u1pg6I85yrKUBwqe08OCFTnph7jkqi+T8pU+8H3jauvA9yfs4ZH/CAW8nQPd+ZpSj 9200O3hsOnSMzB6ocO/nmitvnmu2VJUKiu/pNSGI=
Date: Tue, 23 Jun 2020 02:53:30 -0700
From: Junho Choi <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKZEWEWBYOT7GKLZDN547WZBVEVBNHHCMOWLJI@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/648037106@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_5ef1d11aa864b_f3d3fef9bacd96862586"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: junhochoi
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/8OOjD0EBsyiBUyR8DcqSaw1-1yw>
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 09:53:36 -0000

My point is what to send in Probe packet, not a usual retransmission detected by loss detection algorithm. 

recovery 6.3.4 has the following sentence:

   A) When the PTO timer expires, and there is new or previously sent
   unacknowledged data, it MUST be sent.  A probe packet SHOULD carry
   new data when possible.

   B) A probe packet MAY carry retransmitted
   unacknowledged data when new data is unavailable, when flow control
   does not permit new data to be sent, or to opportunistically reduce
   loss recovery delay.

   C) Implementations MAY use alternative strategies
   for determining the content of probe packets, including sending new
   or retransmitted data based on the application's priorities.

While B) can be a research topic which one is better to retransmit if there is multiple loss reported (oldest or newest), I wonder if A) and C) seems conflicting because that new data MUST be sent limits C) to pick up a strategy to send which data to retransmit.

I think there is some history why A) is in the first place and I believe it's from TLP definition. As many people pointed out, QUIC's monotonic packet number property will make better ACK ranges report coming back when we send a Probe packet.

This makes less importance on sending a new data as MUST. If so, I think we don't need to have a new data transmission as MUST.


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