Re: [quicwg/base-drafts] PMTUD details (#614)

martinduke <notifications@github.com> Tue, 10 October 2017 19:06 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 C33561344E1 for <quic-issues@ietfa.amsl.com>; Tue, 10 Oct 2017 12:06:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.019
X-Spam-Level:
X-Spam-Status: No, score=-7.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 GLG9s0UO-K6Y for <quic-issues@ietfa.amsl.com>; Tue, 10 Oct 2017 12:06:08 -0700 (PDT)
Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2-ext4.iad.github.net [192.30.252.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E56871344BF for <quic-issues@ietf.org>; Tue, 10 Oct 2017 12:06:07 -0700 (PDT)
Date: Tue, 10 Oct 2017 12:05:20 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1507662367; bh=81f8+s7tiwTVNd7vTkh0vaQImu2xpVrILCRDwplq1nQ=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=xCu4MryFGY2BiHMacZEOTgBMRKUf6sCYU4J2VTeoTqO56ieAz74y20N/0w2DSrG+j UML7Y+kfuv2ypSgliFapvHhq9dO/VSovbdKzoizUeUB47gSqZPYfGYamudMuFF7F17 PxfJYFsYbT+rz2rvy8KOxdxP2BI4o07FZjPl696Y=
From: martinduke <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abb31d421efef45947de74caaaf21dc08977f0bb2492cf0000000115f4dbf092a169ce0df98160@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/614/335575067@github.com>
In-Reply-To: <quicwg/base-drafts/issues/614@github.com>
References: <quicwg/base-drafts/issues/614@github.com>
Subject: Re: [quicwg/base-drafts] PMTUD details (#614)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_59dd19f04cae7_7483feb10e80f2c519eb"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinduke
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/HXQgV4etj8pKdxufpEICNJKeu5s>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.22
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, 10 Oct 2017 19:06:10 -0000

I had another look at my RFC4821 notes. Here are some observations:
- In my opinion, someone familiar with other aspects of QUIC can read RFC 4821 and implement PLPMTUD with no more difficulty than they would with TCP or SCTP. So strictly speaking, no additional text in the QUIC spec is necessary.
- Section 6 discusses necessary protocol properties, and QUIC has them. Section 6 specifically mentions padding as a nice-to-have. PR #849, in its current state, makes this explicit.
- It would be possible to state explictly that search_low (7.2) should be the IPv6 minimum packet size, as that is the minimum size in QUIC. However, I personally find this redundant.
- It is possible to recommend an aggressive probe sizing strategy (7.3) since QUIC probe retransmissions are unnecessary. Again, I find this redundant.

I believe the current PR adequately cues the reader on relevant considerations without laboriously repeating RFC 4821. I am also persuadable that the original text is fine and the PR is unnecessary. However, I am interested if others find the current language, in conjunction with 4821, to be insufficient, and if so what pieces are ambiguous.

-- 
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/issues/614#issuecomment-335575067