Re: [quicwg/base-drafts] DPLPMTU merge tweaks (#3702)

Gorry Fairhurst <notifications@github.com> Fri, 29 May 2020 13:27 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 01C3C3A0864 for <quic-issues@ietfa.amsl.com>; Fri, 29 May 2020 06:27:45 -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 o1O9wPr38dqb for <quic-issues@ietfa.amsl.com>; Fri, 29 May 2020 06:27:43 -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 95EA73A0860 for <quic-issues@ietf.org>; Fri, 29 May 2020 06:27:43 -0700 (PDT)
Received: from github-lowworker-f045d1f.ac4-iad.github.net (github-lowworker-f045d1f.ac4-iad.github.net [10.52.19.54]) by smtp.github.com (Postfix) with ESMTP id 95C395213F6 for <quic-issues@ietf.org>; Fri, 29 May 2020 06:27:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1590758862; bh=2+2EfaL84GYtOdsscmfbpKFi3gh/JWY6Br5G/yUCBQ8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=yna8PVGpdU+VdQGzxNNcb5J+GosXBHyTeLlOQD6xwsekDTNO6rMNinklPZ4GtxFAQ FF01yKECt5brTteEh3cyJlVYBNZv4ii8ns/2/BUz5x7z/H3kn5hAprezLn7vjr/cA1 HKcyTq4jBOTOFXetbANGNM2bXcjFEohrwIw7MpzY=
Date: Fri, 29 May 2020 06:27:42 -0700
From: Gorry Fairhurst <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK2GFGSQVXEKEDUDK4V43TXM5EVBNHHCKRI54E@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3702/review/420948927@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3702@github.com>
References: <quicwg/base-drafts/pull/3702@github.com>
Subject: Re: [quicwg/base-drafts] DPLPMTU merge tweaks (#3702)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5ed10dce8647c_42493fb41d6cd96c1360e9"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: gorryfair
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/khcaiaIigBrLaBhKQ7HyQP55tDI>
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: Fri, 29 May 2020 13:27:45 -0000

@gorryfair commented on this pull request.



> +
+From the perspective of DPLPMTUD, QUIC transport is an acknowledged
+packetization layer (PL). A sender can therefore enter the DPLPMTUD BASE state
+when the QUIC connection handshake has been completed.
+
+
+### Sending QUIC DPLPMTUD Probe Packets
+
+DPLPMTU probe packets are ack-eliciting packets.  Probe packets that use the
+PADDING frame implement "Probing using padding data", as defined in
+Section 4.1 of {{!DPLPMTUD}}.  Endpoints could limit the content of probe
+packets to PING and PADDING frames as packets that are larger than the current
+maximum packet size are more likely to be dropped by the network.
+
+DPLPMTU probe packets consume congestion window, which could delay subsequent
+transmission by an application.

Nearly, could we say:

Probe packets are larger than the current maximum packet size and therefore more likely to be dropped by the network. Endpoints could therefore limit the content of probe packets to ACK-eliciting frames that are not retransmitted (e.g., using PING and PADDING frames).  Loss of a probe packet SHOULD NOT be treated as an indication of congestion and SHOULD NOT trigger a congestion control reaction (see section 3, bullet 7 of {{!DPLPMTUD}}.  However, probe packets do consume congestion window, which could delay subsequent transmission by an application.

-- 
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/3702#discussion_r432481539