[quicwg/base-drafts] Transport: (PL)PMTU text (#3217)

Gorry Fairhurst <notifications@github.com> Mon, 11 November 2019 17: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 []) by ietfa.amsl.com (Postfix) with ESMTP id 9AE9A12084D for <quic-issues@ietfa.amsl.com>; Mon, 11 Nov 2019 09:56:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Status: No, score=-7.999 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_IMAGE_ONLY_32=0.001, 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id KT-c4udNnNE3 for <quic-issues@ietfa.amsl.com>; Mon, 11 Nov 2019 09:56:33 -0800 (PST)
Received: from out-20.smtp.github.com (out-20.smtp.github.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1D93120968 for <quic-issues@ietf.org>; Mon, 11 Nov 2019 09:56:16 -0800 (PST)
Date: Mon, 11 Nov 2019 09:56:15 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1573494975; bh=aSEk6j3DYNswa53GZjXn+LQk3VUQd5T7PqgLYYDXjG8=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=YclK9ZJbjkCZxAdqgiEPOefhP8QuXdE0cpni/TPPuMXo/UH7vtoeCa1H5SReciZ9/ Bb7BBo0zhXHYu9zSdgydCvefeplbv4QN4cVAuZrwdSZf7GgWAI58SFldazHxMiqJ+w UX47cT5q7J/XAA7RfMbyI0FRNq3IQDjqvMrlm4wk=
From: Gorry Fairhurst <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKYA2AUKRUUKUPOEG45323JT7EVBNHHB6D3HQ4@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3217@github.com>
Subject: [quicwg/base-drafts] Transport: (PL)PMTU text (#3217)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5dc9a0bfdf9f8_35513fd5ececd964955574"; 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/jnyir02DibLG5u_RZF0ZvA2kr2I>
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: Mon, 11 Nov 2019 17:56:37 -0000

These comments relate only to the PMTU text in -24, relative to the current DPLPMTUD text as that now progresses to WGLC.

/This can also be used to construct PMTU probes (see
   Section 14.3.1). /
- Is this necessary? Or can padding frames be used to make (PL)PMTU probes?.
- My confusion here may be linked to not understanding the intent of 14.3.1

/Further validation can also be provided:

   o  An IPv4 endpoint could set the Don't Fragment (DF) bit on a small
      proportion of packets, so that most invalid ICMP messages arrive
      when there are no DF packets outstanding, and can therefore be
      identified as spurious.

   o  An endpoint could store additional information from the IP or UDP
      headers to use for validation (for example, the IP ID or UDP
- I suggest the above text is spurious, since the checks advocated in DPLPMTUD and the QUIC fields provide a way to detect this. While it is possible too toggle the DF field, I do no think the IETF should endorse this, because it can have other side effects and this is not the place to propose that method.

/An endpoint MUST NOT increase PMTU based on ICMP messages.  /
- DPLPMTUD already specifies. This has always been the case, so please either delete or cite DPLPMTUD or the two core IP specs.

Section 14.3.1
I didn’t understand section 14.3.1. Maybe that isn’t good since I do understand PMTUD and PLPMTUD. Perhaps this section requires some reworking to explain the goal.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: