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

ianswett <notifications@github.com> Thu, 24 October 2019 21:56 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 BC7781200B9 for <quic-issues@ietfa.amsl.com>; Thu, 24 Oct 2019 14:56:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Level:
X-Spam-Status: No, score=-8 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, 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
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 XstK3b8wzWSl for <quic-issues@ietfa.amsl.com>; Thu, 24 Oct 2019 14:56:05 -0700 (PDT)
Received: from out-1.smtp.github.com (out-1.smtp.github.com [192.30.252.192]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 738BC12009C for <quic-issues@ietf.org>; Thu, 24 Oct 2019 14:56:05 -0700 (PDT)
Received: from github-lowworker-25680bd.va3-iad.github.net (github-lowworker-25680bd.va3-iad.github.net [10.48.17.61]) by smtp.github.com (Postfix) with ESMTP id AF5BFC604B5 for <quic-issues@ietf.org>; Thu, 24 Oct 2019 14:56:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1571954164; bh=pd3Ka4lBr9QEtOd+HEagRR12jvtbz2g0TdCG0dlvL0Q=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=W/LokR9UPRgbRWLPxjNYOzh/OwWrprnkNHqpBdDAQr4rVEpBwDxYguR0lhmiGVOMW i89yUhqD6985TtWKcVE0M1Ao6i0kGATaXsJerO4OANbxJGlmS7kGjwILv8PqVlPC7n /S/YBuRgTfflc+c2hu/YqsIAVupR1OlNq2vm+LOc=
Date: Thu, 24 Oct 2019 14:56:04 -0700
From: ianswett <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK2J3KZI6P46WREJ5HF3X5PIJEVBNHHB3IPO4M@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/306885812@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_5db21df4a02ef_54773f83b72cd95c576c6"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ianswett
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/RCZKOI_Vyi0GtQDGEVwWa73aAcc>
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: Thu, 24 Oct 2019 21:56:08 -0000

ianswett commented on this pull request.

Thanks for your comments @janaiyengar.  One follow-up question about whether we should always arm the PTO even if the amplification factor has been hit on the server side?  That does have the benefit of forcing the client to send a padded Initial ACK-only packet.

> @@ -495,11 +495,9 @@ a PATH_RESPONSE to seed initial_rtt for a new path, but the delay SHOULD NOT
 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.
+data it can send is limited to three times the amount of data received,
+as specified in Section 8.1 of {{QUIC-TRANSPORT}}. If no data can be sent,

Are you suggesting we always arm the PTO and if we've hit the amplification factor, the server should send a PING-only packet?  That actually sounds easier than not arming it and prompts the client to send a padded Initial ACK, but I'm not sure if that's what you're suggesting?

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