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

From: ianswett <[email-masked]>
Date: Mon, 02 Oct 2017 00:42:34 +0000 (UTC)

In the future, QUIC wants to support a wide variety of applications.  Some of those benefit from unreliable or semi-reliable transmission.

Examples include WebRTC, MOSH, and IoT protocols.  These applications use sub-MTU sized unidirectional message payloads heavily.

QUIC provides these applications many benefits, including fast and secure connection establishment, security, reliability(if desired) and a common congestion control context to share with other applications.

Additionally, there may be cases where the QUIC HTTP mapping would benefit from a less stream-oriented transmission of data, such as QPACK and QCRAM state updates.  Moving them over to a MESSAGE frame type would be an optimization, but potentially a simplifying one.

Benefits:
1) Removing framing overhead from STREAM frames(stream id, length)
2) Messages can be immediately processed, they require no temporary memory and greatly reduce processing overhead.

Negatives:
1) Adds a new frame type

SST(http://www.brynosaurus.com/pub/net/sst.pdf) made a similar optimization and I think it would be valuable in QUIC.

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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 02 Oct 2017 17:42:10 +0000 (UTC)

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:
https://github.com/quicwg/base-drafts/issues/814#issuecomment-333608790

---

From: ianswett <[email-masked]>
Date: Mon, 02 Oct 2017 11:03:15 -0700

Thanks for the comments.  I rephrased it to fit the guidelines.  

I'm wrong about length, it's just like a stream frame in that regard.  But it does remove offset.

-- 
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-333615437