[quicwg/base-drafts] STOP_SENDING is an application protocol concept (#758)

Martin Thomson <notifications@github.com> Mon, 04 September 2017 04:47 UTC

Date: Sun, 03 Sep 2017 21:42:33 -0700
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab9ed04c62a2833b2d79fa29fae357ef05e0a1db5492cf0000000115c49bb992a169ce0f31fcaa@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/758@github.com>
Subject: [quicwg/base-drafts] STOP_SENDING is an application protocol concept (#758)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_59acd9b962a50_acb3ff70d1cfc3444824"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/6vzImpEVJH4iEOkC9seh22v7f08>

Objectively, it makes very little sense for the frame to be defined at the transport layer.  There are minor advantages to the current arrangement in terms of generality (if we can agree that the concept is properly generic), and in performance (it can be sent at the transport layer without being subject to HOLB, though this might be removed by having it sent on a new stream).  However, neither of those benefits are significant enough to justify the cost of it being out of place.

Raised as a consequence of discussion on #722. This being just my opinion.

-- 
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/758

[quicwg/base-drafts] STOP_SENDING is an applicati… Martin Thomson
Re: [quicwg/base-drafts] STOP_SENDING is an appli… Mike Bishop
Re: [quicwg/base-drafts] STOP_SENDING is an appli… Mike Bishop