Re: [quicwg/base-drafts] PTO MUST send new data or retransmit data if possible (#3057)

Martin Thomson <notifications@github.com> Tue, 24 September 2019 02:40 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 5DE0E1200E9 for <quic-issues@ietfa.amsl.com>; Mon, 23 Sep 2019 19:40:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.899
X-Spam-Level:
X-Spam-Status: No, score=-7.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 r1qDLOKva-9c for <quic-issues@ietfa.amsl.com>; Mon, 23 Sep 2019 19:40:02 -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 DADC9120086 for <quic-issues@ietf.org>; Mon, 23 Sep 2019 19:40:01 -0700 (PDT)
Received: from github-lowworker-f62aa54.va3-iad.github.net (github-lowworker-f62aa54.va3-iad.github.net [10.48.17.68]) by smtp.github.com (Postfix) with ESMTP id 1C0B6A0990 for <quic-issues@ietf.org>; Mon, 23 Sep 2019 19:40:01 -0700 (PDT)
Date: Mon, 23 Sep 2019 19:40:01 -0700
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK55SMJ7YW37HQX6DA53S2THDEVBNHHB3IPO4M@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3057/review/292146858@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3057@github.com>
References: <quicwg/base-drafts/pull/3057@github.com>
Subject: Re: [quicwg/base-drafts] PTO MUST send new data or retransmit data if possible (#3057)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d898201cb69_2a763fa2928cd95c589a9"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
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/gVEbv8mYvGtfEbXC0hGvNJVcn2E>
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, 24 Sep 2019 02:40:05 -0000

martinthomson commented on this pull request.



> @@ -496,10 +496,8 @@ be considered an RTT sample.
 
 Until the server has validated the client's address on the path, the amount of
 data it can send is limited, as specified in Section 8.1 of {{QUIC-TRANSPORT}}.
-Data at Initial encryption MUST be retransmitted before Handshake data and
-data at Handshake encryption MUST be retransmitted before any ApplicationData
-data.  If no data can be sent, then the PTO alarm MUST NOT be armed until
-data has been received from the client.
+If no data can be sent, then the PTO alarm MUST NOT be armed until data has
+been received from the client.

Do you mean "until the path has been validated"?  "data" is highly non-specific.

>  
-When there is no data to send, the sender SHOULD send a PING or other
-ack-eliciting frame in a single packet, re-arming the PTO timer.
+It is possible the sender has no new or previously-sent data to send.
+As an example, consider the following sequence of events: new application data
+is sent in a STREAM frame, deemed lost, then retransmitted in a new packet,
+and then the original transmission is acknowledged.  When there is no data to
+send, the sender SHOULD send a PING or other ack-eliciting frame in a single
+packet, re-arming the PTO timer.

Still not working for me.

I get the need for the client to send extra Initial packets again in the case where it has nothing to say, but that should be a special provision.

If p1 is acknowledged and p2 contained nothing new, then let it lie.  You don't need to know whether it was lost or not.

I get that this packet will stay outstanding unless you have something new to say, but you are only sending a PING to deal with an accounting discrepancy.  That only becomes relevant when you go to send the next packet.  Is there any way that this sort of blip can end up consuming the entire congestion window?

-- 
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/pull/3057#pullrequestreview-292146858