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

Igor Lubashev <notifications@github.com> Wed, 20 December 2017 04:38 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 5A955124D85 for <quic-issues@ietfa.amsl.com>; Tue, 19 Dec 2017 20:38:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level:
X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-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 hNcpa4vsC3Tp for <quic-issues@ietfa.amsl.com>; Tue, 19 Dec 2017 20:38:08 -0800 (PST)
Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2-ext7.iad.github.net [192.30.252.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECB6112025C for <quic-issues@ietf.org>; Tue, 19 Dec 2017 20:38:07 -0800 (PST)
Date: Tue, 19 Dec 2017 20:38:07 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1513744687; bh=PvIeuRJqkYaYSGl4VY7DIinPy3GKS059exbN2sgq3Gk=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=ZCp8x9BDEIQWTT4JdQhcdnjnbmc+fAP6dGErTOTSie0pjRKzAFqfCSs6pPRis0cBg k5UVcP3v9zsumxYWIZpzDCb0hYabcQtWd/uWzMhbPx6uduQJkIVXvqK0Sz0M5hWo8Y FclN/byyqUuLTCbMyKydayTCB+eaLf6rEjFjeBEY=
From: Igor Lubashev <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab40df11c19e3b2bcad2ad11da4d74fbd563aa2b3a92cf000000011651ab2f92a169ce0f9d30eb@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/814/352962869@github.com>
In-Reply-To: <quicwg/base-drafts/issues/814@github.com>
References: <quicwg/base-drafts/issues/814@github.com>
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_5a39e92f3fdaf_77503fef6225af301557c5"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: igorlord
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/ppVN1zS5wLjbX-fPHBmke4pviDU>
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, 20 Dec 2017 04:38:09 -0000

> Immediately passed up to the application, so no QUIC transport flow control is necessary.

So MESSAGE frames are congestion controlled but not flow controlled?  That means a receiver that is slower than the sender and the network will be dropping MESSAGEs, and that's ok?  It looks similar to UDP, of course, but it may be an opportunity to devise some feedback to let the sender make an intelligent decision about not causing "buffer bloat" on the receiver and wasting bandwidth on MESSAGEs that will likely be dropped.

Note: since MESSAGE frames can share a packet with STREAM frames, the packets have to be ACKed by the receiver, even if MESSAGEs end up being dropped.

-- 
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/814#issuecomment-352962869