Thanks for your replying. I agree "partial reliability" fits our draft better, since we do retransmit lost data and provide in-order transmission. And, our proposal could be compatible with H3, should we clarify the behavior in the draft? Please do let me know if you have any further advice.
Thanks, Yongyi. From: "Tommy Pauly"<[email protected]> Date: Thu, Sep 22, 2022, 11:32 Subject: Re: [External] New Version Notification for draft-chen-quic-quicu-01.txt To: "Ryan Hamilton"<[email protected]> Cc: "于涌溢"<[email protected]>, "[email protected]"<[email protected]>, "陈鉴平"<[email protected]>, "景君羡"<[email protected]>, "刘天一"<[email protected]> I noticed that this draft does reference RFC 9221, and DATAGRAM frames. If I’m understanding correctly, it seems like this is trying to define an approach for what’s more commonly referred to as “partial reliability”, which was something DATAGRAM explicitly didn’t try to include. If this is the case, I think it would be useful to reframe the document in terms of that, since the heavy use of “unreliable” is quite confusing. It also isn’t clear to me how this proposal would work with specific application protocols on top of QUIC — is this something that’s meant to be compatible with H3, or is it for entirely separate use cases? Best, Tommy On Sep 21, 2022, at 3:17 PM, Ryan Hamilton <[email protected]> wrote: QUIC has support for unreliable data via the DATAGRAM frame, RFC 9221 <https://www.rfc-editor.org/info/rfc9221>. It seems that this new proposal attempts to add unreliable data support not to QUIC, but to QUIC *streams*. QUIC streams, of course, offer a reliable, in-order, sequence of bytes. Did you consider starting with DATAGRAMs, and building from there instead? Cheers, Ryan On Wed, Sep 21, 2022 at 1:14 AM 于涌溢 <[email protected]> wrote: > Deal all, > > We would like to introduce an extension of the QUIC protocol for > unreliable data transmission called QUIC Unreliable (QUICU) . The following > draft is submitted for your consideration and comments. We would also like > to present this at IETF 115 to discuss further. > > To summarize on this draft: it describes an extension of the QUIC protocol > for unreliable data transmission called QUIC Unreliable (QUICU), which > mainly through the definition and use of three new types of frames, namely > the Expire Offset Frame, Boundary Frame, and Correlation Frame. The main > purpose of this extension is to reduce data delivery delay. Through > controlling the timing and scope of packet losses, QUICU reduces useless > transmission to improve transmission efficiency, reduces head-of-line > blocking to improve transmission timeliness, which are beneficial to > delay-sensitive applications, especially audio and video applications. This > document describes the motivation, the operations, and the wire formats of > the three new types of frames. > > Link to html: > https://datatracker.ietf.org/doc/html/draft-chen-quic-quicu-01 > > Please feel free to reach us for any comments or questions on this. > > Thanks, > Yongyi. > > ---------- Forwarded message --------- > From: [email protected] > Date: Mon, Sep 19, 2022, 20:54 > Subject: [External] New Version Notification for > draft-chen-quic-quicu-01.txt > To: "Jianping Chen"<[email protected]>, "Junxian Jing"< > [email protected]>, "Tianyi Liu"<[email protected]>, > "Yongyi Yu"<[email protected]> > A new version of I-D, draft-chen-quic-quicu-01.txt > has been successfully submitted by Yongyi Yu and posted to the > IETF repository. > > Name: draft-chen-quic-quicu > Revision: 01 > Title: An Unreliable Extension to QUIC > Document date: 2022-09-19 > Group: Individual Submission > Pages: 10 > URL: > https://www.ietf.org/archive/id/draft-chen-quic-quicu-01.txt > Status: https://datatracker.ietf.org/doc/draft-chen-quic-quicu/ > Htmlized: > https://datatracker.ietf.org/doc/html/draft-chen-quic-quicu > Diff: https://www.ietf.org/rfcdiff?url2=draft-chen-quic-quicu-01 > > Abstract: > QUIC Unreliable (QUICU) is an extension of the QUIC protocol for > unreliable data transmission, mainly through the definition and use > of three new types of frames, namely the Expire Offset Frame, > Boundary Frame, and Correlation Frame. The main purpose of this > extension is to reduce data delivery delay. Through controlling the > timing and scope of packet losses, QUICU reduces useless transmission > to improve transmission efficiency, reduces head-of-line blocking to > improve transmission timeliness, which are beneficial to delay- > sensitive applications, especially audio and video applications. > > This document describes the motivation, the operations, and the wire > formats of the three new types of frames. > > > > > The IETF Secretariat >
