Is there any plan to support datagram in QUIC protocal?

[Tao Cui]

For some scenarios, retransmission of lost packet is not necessary.

I noticed that there was a discussion within the IETF standard group about QUIC supporting unreliable datagram extension.

So is there any plan for gquic version of the QUIC protocol to support this extension?

Regards,
Tao

[Nick Harper]

There aren't any plans to support datagram in a gquic version, since gquic is being replaced by IETF QUIC. I believe there are plans to support the datagram extension in Google's implementation of IETF QUIC.

--
You received this message because you are subscribed to the Google Groups "QUIC Prototype Protocol Discussion group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to proto-quic+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/proto-quic/0bb8d11f-b934-4fd5-9633-1fcec140243dn%40chromium.org.

[Ian Swett]

There's no IETF specification, but newer versions of gQUIC do support what it calls MESSAGE frames(functionally identical to DATAGRAM) and they are actively used in production, so the functionality does work.

It should be available in version 46 and later per this comment: https://source.chromium.org/chromium/chromium/src/+/master:net/third_party/quiche/src/quic/core/quic_versions.h;l=111

That being said, I'd recommend developing any new application on IETF QUIC + DATAGRAM, since Google QUIC will not be supported long term.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/proto-quic/CAFvk8pynrqBW8mF59Mab5U3JatD4J01FiAY_0XjyQDea-Xr9tg%40mail.gmail.com.

[Thomas Cui]

Brilliant! 

Thanks!

[Tinker Tan]

Hi, Ian

Is it possible to support MESSAGE_FRAME( QUIC Transport) in old version like version 43?

If I want to support it  in version 43 by myself, what do I need to pay attention to ?

在2020年12月1日星期二 UTC+8 上午12:51:32<Ian Swett> 写道：

[John Antypas]

Good morning all....

I'm new to this, but since the question of future features has been brought up, I'm also looking at an extension -- the ability to pass "opaque" objects before encryption set -- metadata for the lower-layer transport if you will.  These would be available to DPI, but the content of QUIC would remain encrypted.  We'd use this to clue in transport interfaces about various QOS needs.

What is the preferred "toolkit" people use to start this work?  Any guidance?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/proto-quic/1d574186-12e6-4063-9343-23bbaa4e059an%40chromium.org.

[Ian Swett]

We're actively trying to move all Q043 clients to IETF QUIC, so it's nothing we'd do.

You should be able to enable the MESSAGE frame code in Q043 and as long as you know both sides speak this Q043+MESSAGE format or you change the version so it's slightly different, then I'd expect it to work.

[howard liao]

where is the IETF QUIC implemented by google?  is it outsourced yet?

[howard liao]

what's the roadmap to IETF QUIC for google?  kickoff a new project and replace gquic with IETF QUIC completely or just evolute to IETF QUIC from current chromium quic.

[Ian Swett]

IETF QUIC has been default enabled in Chrome and has been in the Chromium source for a few months now.

Some more details are in the Chromium blog post: https://blog.chromium.org/2020/10/chrome-is-deploying-http3-and-ietf-quic.html