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

msvoelker <notifications@github.com> Fri, 29 May 2020 12: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 636253A08A7 for <quic-issues@ietfa.amsl.com>; Fri, 29 May 2020 05:56:09 -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 9SosnQ26v5pA for <quic-issues@ietfa.amsl.com>; Fri, 29 May 2020 05:56:07 -0700 (PDT)
Received: from out-17.smtp.github.com (out-17.smtp.github.com [192.30.252.200]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40AA83A0869 for <quic-issues@ietf.org>; Fri, 29 May 2020 05:56:04 -0700 (PDT)
Received: from github-lowworker-2300405.va3-iad.github.net (github-lowworker-2300405.va3-iad.github.net [10.48.17.39]) by smtp.github.com (Postfix) with ESMTP id 39D876E1019 for <quic-issues@ietf.org>; Fri, 29 May 2020 05:56:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1590756963; bh=JJmB9Bwj36VLLdte3e+lz8K5FZMzwjj6LBNSeXB/UD4=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=eZ9Ojp4hwyTRmXRhptDueUyu1WhEVRcpxYfVP3xUmtExvLOxZU2u10LIh/f0HR2xW OK3qDQ/XDHpPK1/ayzrTHy1OzPz7lckbQib0FNEKthbyQ4jLIYsKTp+VROJBKXz7V6 YMckTBFKgrz9bcD3vrkx+aBouC5lSg142sycdm0E=
Date: Fri, 29 May 2020 05:56:03 -0700
From: msvoelker <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK65R6E65BI7WLOLHOF43TTWHEVBNHHCKRI54E@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/420924379@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_5ed106632974e_69bb3fab3bccd9601036e6"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: msvoelker
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/0S6hxCXaNWGtye-DBnW4hA3ix6U>
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 12:56:17 -0000

@msvoelker 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.

Does this makes sense? (I merged both paragraphs in the section)

... 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. These frames might not be retransmitted if a probe packet containing them is lost. Additionally, a lost probe packet should not be treated as a signal of congestion. However, these probe packets do consume congestion window, which could delay the transmission of subsequent application data.

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