Add a MESSAGE frame optimized for sub-MTU payloads

[ianswett]

Problem
Unreliable and semi-reliable message transmission within QUIC has high overhead for small streams. The overhead is in the form of bytes on the wire(ie: Stream ID is not necessary) as well as state tracking to allow retransmission and cancellation of streams. For example, one has to track whether a stream was delivered, and then if it's lost, decide whether to retransmit or reset the stream.

For use cases where the message payload exceeds a single packet, an identifier is necessary to associate the data fragments with one another and state is required to reassemble the message. As such, QUIC's stream model provides the right functionality already, with minimum overhead.

Examples potential users 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.

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

Proposed Design Outline

1. Does not contribute towards MAX_STREAM_ID, since it does not have a stream id.
2. Not repaired at the transport layer, but may be resent by the application.
3. Immediately passed up to the application, so no QUIC transport flow control is necessary

Obviously the design is flexible, but I believe making these subject to flow control and any sort of max stream id style limit would increase the overhead to that of streams.

[martinthomson]

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?

[ianswett]

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.

[igorlord]

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.

[larseggert]

Is this something required for QUICv1? If not, I would propose shelving it for now.

(This is not a statement about the quality of the proposal.)

[ianswett]

In my opinion, no partial reliability proposals are a requirement for v1, since one can do partial reliability today, it's just suboptimal in some ways.

Note this is already tagged quicv2 :)

[ianswett]

Now that we have an extension mechanism, this is an excellent candidate.

[LPardue]

I'd like to see this to support something I've been cooking up. However, it would be good to understand if it is still classed as v2. (version doesn't affect my interest, more my timeline)

…

On Tue, Jun 26, 2018 at 11:53 PM ianswett ***@***.***> wrote: Now that we have an extension mechanism, this is an excellent candidate. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#814 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGRFtfSHAsvmUwX8iQvqJf4nOQ-sGH3rks5uAruHgaJpZM4PqF_2> .

[MikeBishop]

Work with @ianswett and write a draft?

[ianswett]

Yes, let's write up an extension draft. I'm happy to work with you Lucas.

[LPardue]

Sure. I think the "exercising QUIC extension" aspect is trivial, the harder part is agreeing the problems to be solved

[tfpauly]

@ianswett, @MikeBishop

We've written up a version of a proposal for this extension here, also: https://tools.ietf.org/html/draft-pauly-quic-datagram-00

Happy to have this draft be joined by people and used as well

[LPardue]

FWIW the DATAGRAM draft was adopted as an extension by the QUIC WG and therefore the quicv2 label on this issue has been overtaken by events.