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

Magnus Westerlund <notifications@github.com> Wed, 25 October 2017 12:17 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 4302F1377B3 for <quic-issues@ietfa.amsl.com>; Wed, 25 Oct 2017 05:17:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.52
X-Spam-Level:
X-Spam-Status: No, score=-6.52 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, RCVD_IN_SORBS_SPAM=0.5, 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 gBhMW1Qux9OC for <quic-issues@ietfa.amsl.com>; Wed, 25 Oct 2017 05:17:12 -0700 (PDT)
Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2-ext8.iad.github.net [192.30.252.199]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E47613B2B2 for <quic-issues@ietf.org>; Wed, 25 Oct 2017 05:17:12 -0700 (PDT)
Date: Wed, 25 Oct 2017 05:17:11 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1508933831; bh=vkqiOP01CXs/u8twu+94pSkBYhZm3yBMmjfygFXBg9k=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=LcylTCc0LgwPa1xEsmvYPX8/HGcc6o4wyt/d9ymP6ddUd17GH8zgHGNnFj9xwnESl gS0fVJOwonfet79BA3dUs6pSWCqYzP5qxJTXobt8+JQvw01wzxoFiuno4qyXBdyRKN UfHDAs/XIVjTSzul3zlWNE3QxxgEivLOJST3iMyU=
From: Magnus Westerlund <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab1d59bb7eff234a261a76cbf11b8c69c50939f17992cf00000001160842c792a169ce0df98160@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/339310716@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_59f080c762521_34493fe4eafb6f30305f9"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: gloinul
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/Njt3e4ZWQpjDiXQ_NB12Nx03fvI>
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: Wed, 25 Oct 2017 12:17:14 -0000

@martinduke I have also re-read RFC 4821. And I first of all I think being explicit on the things you consider redundant is the better approach. This from the aspect, that if we can spend time to write a sentence or two, and save time and get more consistent behavior from implementations it is well spent time in my view. 

Additional issues worth discussing in the text are:

- ICMP verification for any received Message to too Big (Not only relevant for PMTUD). This is likely rather straightforward, but do require the QUIC implementation to be able to match the truncated part of the encrypted QUIC packet against itself. This likely implies storing X number of bytes of the encrypted packet for this verification. Or will we actually use any encryption that will be able to perform partial decryption and use that to verify that these initial bytes matches valid QUIC headers?
  
- Issues with setting DF bit from user land (as SHOULD requirement) in 4821. It is somewhat discussed in RFC4821, but clearly an issue for many QUIC implementations. What advancements since 4821 is it worth bringing up here? 

- Storage and reuse of PMTUD information in stack instance releated to differnet paths. Applies for multi-path as well as implementations opening a number of connections. At a minimum a clear definition of what QUIC semantics corresponds to a path, and thus can have different MTU values.
 
- For user-land QUIC implementation it can actually be a bit of a challenge to correctly know how much headers would be added. A challenging example would be QUIC over ICE in a WebRTC context. Where it is actually the ICE stack that controlls which path and what headers and NAT/FW traversal mechanism are in place, such as TURN that changes the header overhead between candidate pairs. This is in relation to RFC 4821 Section 5.1. 
 

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