Re: [quicwg/base-drafts] Add a MESSAGE frame optimized for sub-MTU payloads (#814)

Martin Thomson <> Mon, 02 October 2017 17:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B62F4133090 for <>; Mon, 2 Oct 2017 10:42:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.019
X-Spam-Status: No, score=-2.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_NONE=-0.0001, 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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YOm_c4D-hA0W for <>; Mon, 2 Oct 2017 10:42:12 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 077E8132F7D for <>; Mon, 2 Oct 2017 10:42:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed;; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=VMVzr3c+KhZnNCdP4zVXRvyOPO8=; b=u+XL8PDAgC+H73AD r50djDJVKrOm48igATP7z8CBGjPouAL2T9fIm4bJr4t1MDciEegkHzJqdfYEWhF6 4nMm7YFHmmQ3b4LrqPz96MMjoCzinsgWncfIr0cgULKmHOVLbpFKdP8raBuHDScH G47BBlAIqolxDIykaazA2gG6aCA=
Received: by with SMTP id filter0468p1las1-24129-59D27A72-4D 2017-10-02 17:42:10.879844406 +0000 UTC
Received: from ( []) by (SG) with ESMTP id f4wb35icQ9qa4BktdTYcDw for <>; Mon, 02 Oct 2017 17:42:10.718 +0000 (UTC)
Date: Mon, 02 Oct 2017 17:42:10 +0000
From: Martin Thomson <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/814/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Add a MESSAGE frame optimized for sub-MTU payloads (#814)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_59d27a729e18a_4a293fecdb422f2c380c4"; 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-SG-EID: l64QuQ2uJCcEyUykJbxN122A6QRmEpucztpreh3Pak3metgdjWLwTXf45GyNNo8gYMe7x8JMhTIxpL F3TfMJStZjmEXVLOdLyvDjWGCs11RESI9J7VA4HTVHBkY6E8X/U7NOnkD1Q5uO1Bv76WJzChL6/n6M Ga+ycQ/DiqFIcl17AotLXa44XQyw88Ly8gyuTEUOF4BeeFajQFAip+wlaTLTymaU8pYhvjiAOas2aS Q=
Archived-At: <>
X-Mailman-Version: 2.1.22
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 02 Oct 2017 17:42:13 -0000

This is a proposal, and our contribution guidelines state that issues are for problems.  Can you restate this in terms of a problem?  I think that you have most of that here.

I'm not expressing an opinion yet but this raises a lot of questions.  Answers to the following questions might help inform that opinion.

How are the proposed MESSAGE frames identified?  That would be needed to repair them.  Identifiers might be used at the application layer too, but I'm starting to join @mcmanus in his view that using the transport layer identifiers in application protocols is not a good idea.

Actually, can they be repaired?

How are these flow controlled?  I assume that only the connection flow control limit applies.  Or does your comment about immediate processing imply that you expect them to not need flow control?

How does a receiver limit the number of these frames?  Can they?

How does this remove length?

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