Re: [quicwg/base-drafts] max_packet_size in 0-RTT (#3447)

Martin Thomson <notifications@github.com> Fri, 21 February 2020 04:31 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 37305120233 for <quic-issues@ietfa.amsl.com>; Thu, 20 Feb 2020 20:31:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvqh8-KtF0Cp for <quic-issues@ietfa.amsl.com>; Thu, 20 Feb 2020 20:31:44 -0800 (PST)
Received: from out-5.smtp.github.com (out-5.smtp.github.com [192.30.252.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 842AC120152 for <quic-issues@ietf.org>; Thu, 20 Feb 2020 20:31:44 -0800 (PST)
Date: Thu, 20 Feb 2020 20:31:43 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1582259503; bh=wFH6sG9JT0exKN9ZFUkTgBQS7uHa7hwLHOljhzOCnA8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=UTvymOS1u0vlgqVYYuenU3Ufr//Xq5ri4Wwf6XvvU9WxrcB1QW9zSE+A/DtytRC0u tweJ5WyLiXVtvjToXU6hIi2uI+IpbYrVaTbd8rbNIe/5C1tespn+cY8fHdeswBW43v 0SZpa2IjS80tEGuLyeYEKOSImiVbqQp59Yi9nHSQ=
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK7RGBP7JFGNHAL5ZT54LSH27EVBNHHCDDCFOU@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3447/589493084@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3447@github.com>
References: <quicwg/base-drafts/issues/3447@github.com>
Subject: Re: [quicwg/base-drafts] max_packet_size in 0-RTT (#3447)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e4f5d2f7a6a6_627c3f821dccd95c179412"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
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/CaMz3DA5-_uRG2r6jRHB_kyKxQI>
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, 21 Feb 2020 04:31:46 -0000

I don't like @kazuho's proposed change.  The point of this is to express a limitation of the endpoint.  If the endpoint only has X bytes of memory for receiving packets, then it can use this limit.  Absent this, we can't ever hope to have big endpoints talking to little ones.  We will end up with middleboxes (hello CoAP).

If the limit exists at a server and the client ignores it for 0-RTT, then the effect is that 0-RTT doesn't get through.  I would rather just say that client's are expected to remember it and then if they don't they can wear the consequences.  But that can be a protocol violation.

The problem here is that we now have protection for Initial packets and no way to signal that there is a limit.  Our only real protection there is that the limit manifests in much the same way as having a lower MTU because Initial packets don't get through.

This matters especially if clients start remembering or inferring path MTU.  I don't remember us ever expressly allowing this sort of thing, but it seems like a reasonable thing that might happen when probing can be quite costly and wasteful.

-- 
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/3447#issuecomment-589493084