[quicwg/base-drafts] d08172: Include max_udp_payload_size in packet size discus...

Martin Thomson <noreply@github.com> Wed, 13 May 2020 00:51 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 AEE973A0B0F for <quic-issues@ietfa.amsl.com>; Tue, 12 May 2020 17:51:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.273
X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.173, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id exHwMONJWaKe for <quic-issues@ietfa.amsl.com>; Tue, 12 May 2020 17:51:24 -0700 (PDT)
Received: from out-4.smtp.github.com (out-4.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 928DD3A0B0A for <quic-issues@ietf.org>; Tue, 12 May 2020 17:51:24 -0700 (PDT)
Received: from github-lowworker-2ef7ba1.ac4-iad.github.net (github-lowworker-2ef7ba1.ac4-iad.github.net []) by smtp.github.com (Postfix) with ESMTP id 8AE5EC60686 for <quic-issues@ietf.org>; Tue, 12 May 2020 17:51:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1589331083; bh=BwTFF/8sIcsnMTnFbeusQo6eetwAy4NSrYoXLyTSX3g=; h=Date:From:To:Subject:From; b=AkbqnOIjENCa4TkZ3EEc9u8RpslQ+8XHE42+/y/WYRYDC3O0/oCbNA3qNKwxtHzrc 83ui7y/a+/SXVEyOv6AxZVUoBn+sYp7pC+pWWkn2qiz2l3oz198+q1REIl8iz0wiPn e5Sy/WbQBu0+BBALHO6GqzMJ5LUsI1Oqkb5T4pRU=
Date: Tue, 12 May 2020 17:51:23 -0700
From: Martin Thomson <noreply@github.com>
To: quic-issues@ietf.org
Message-ID: <quicwg/base-drafts/push/refs/heads/max-udp-pmtud/000000-d08172@github.com>
Subject: [quicwg/base-drafts] d08172: Include max_udp_payload_size in packet size discus...
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-GitHub-Recipient-Address: quic-issues@ietf.org
X-Auto-Response-Suppress: All
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/DRpr3QIitjtZn-8h-KZacUwRo20>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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, 13 May 2020 00:51:26 -0000

  Branch: refs/heads/max-udp-pmtud
  Home:   https://github.com/quicwg/base-drafts
  Commit: d081726ce4ab18213d9cd65fe19cbb82ef2e52e0
  Author: Martin Thomson <mt@lowentropy.net>
  Date:   2020-05-13 (Wed, 13 May 2020)

  Changed paths:
    M draft-ietf-quic-transport.md

  Log Message:
  Include max_udp_payload_size in packet size discussion

This isn't a complete dissertation on how clients might choose to use
larger packet sizes.  In particular, it doesn't capture the whole
discussion about starting at a higher size being a way to raise the 1280
to something higher, with the requisite cost being that you might have
failures.  Deciding to put that in would be much harder.

What this does is just say that the transport parameter acts as a
further limit on packet size and that you won't know that prior to
knowing.  That means that you are guessing about the network path AND
your peer when you decide to send >1200 (to be fair, the former really
only applies for IPv4, and it's not much of a guess).

Closes #3638.