Re: RE: [External] New Version Notification for draft-chen-quic-quicu-01.txt

[Roberto Peon <[e-mail]>]

W.r.t. past implementation of PR stuff: there was a partial implementation of partial reliability which didn’t get used because there were other pressing problems (like getting H3 working/standardized), and there was a separate implementation for video which predated H3 (and many things QUIC).

I’d like to echo Igor’s suggestion to focus on flow-control. This is, without a doubt, the hardest part. This gets interesting when you think about connection-level flow control vs stream flow control, and ensuring that you can reasonably use the channel bandwidth. An approach where you don’t change flow control at all (and instead fake acks or similar) can work, but may end up with a bunch of operational complexity as you debug why the bandwidth isn’t being used like you think it should be. (Thankfully, this won’t be worse than just using the reliable stuff).

I do like the breakdown of a stream into data-blocks. In prior conversations near the dawn of the quic working-group, we (or maybe I) called these “atoms”.
At the time, I was imagining that this would be done with two, associated, streams. One which has the data, and another which points to the data stream, and has fixed-size records which describe atom (data-block) boundaries.
Another way to think about this is that you de-mux the video container into a metadata-stream, and media streams which have “raw bitstream” payloads.

In my explorations, it was interesting to see that this actually reduced the on-the-wire size for the video while allowing for re-sync.

I’ll be following this with great interest!
-=R

From: QUIC <[e-mail]> on behalf of Lubashev, Igor <ilubashe=[e-mail]>
Date: Tuesday, September 27, 2022 at 9:13 AM
To: Yongyi Yu <[e-mail]>
Cc: Tommy Pauly <[e-mail]>, Ryan Hamilton <rch=[e-mail]>, [e-mail] <[e-mail]>, 陈鉴平 <[e-mail]>, 景君羡 <[e-mail]>, 刘天一 <[e-mail]>
Subject: RE: RE: [External] New Version Notification for draft-chen-quic-quicu-01.txt
Yongyi, Without going into the question of whether partially reliable streams are necessary (as Matt said, Meta implemented them but is not using that implementation in production), here are a few comments I have. ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
ZjQcmQRYFpfptBannerEnd
Yongyi,

Without going into the question of whether partially reliable streams are necessary (as Matt said, Meta implemented them but is not using that implementation in production), here are a few comments I have.


  1.  Have you thought about the interaction of you draft with stream and connection flow control?  95% of the time I spent on my design was spent on thinking of ways to augment flow control to avoid extra round trips just to open a flow control window, while still ensuring that the resulting protocol is resilient against an adversarial endpoint forcing the peer to commit an unreasonable amount of resources (memory) to the connection.


  *   1. Our proposal splits a QUIC stream into many data blocks by Boundary Frame. The receiver would provide data to the application layer only when a data block is completely received. Therefore, the application layer needn't be aware of the gap at the expiration point or discard data already read.
  *   2. Because the stream is split into blocks, the sender could send or expire data by data blocks. Then the transport layer could track the message boundaries instead of the application layer.


  1.  Section 4.4 Data Receiving of your draft is saying the same.  It seems wrong to have the transport protocol specify the behavior of the QUIC library APIs so precisely.  It is ok to try to enable a particular library API, but the transport protocol’s specification ought to limit itself to the semantics of bytes on the wire.

Very best,


  *   Igor


From: Yongyi Yu <[e-mail]>
Sent: Tuesday, September 27, 2022 11:04 AM


Hi Igor,

Thanks for your replying. Our proposal indeed shares similar ideas with yours, but there are also some difference. We'd like to update our draft to clarify the difference in detail, and to briefly summary here, there are three major points.

1. Our proposal splits a QUIC stream into many data blocks by Boundary Frame. The receiver would provide data to the application layer only when a data block is completely received. Therefore, the application layer needn't be aware of the gap at the expiration point or discard data already read.

2. Because the stream is split into blocks, the sender could send or expire data by data blocks. Then the transport layer could track the message boundaries instead of the application layer.

3. With the introduction of Correlation Frame, we can combine multiple QUIC streams into single data stream while avoiding head of line blocking. This feature could be quite useful in many scenarios, e.g., transmitting both video and audio data through single HTTP response.

Please do let me know if you have any further advice, and please do not hesitate to point out if I make any mistakes.

Thanks,
Yongyi.

From: "Lubashev, Igor"<[e-mail]<mailto:[e-mail]>>
Date: Mon, Sep 26, 2022, 00:29
Subject: RE: [External] New Version Notification for draft-chen-quic-quicu-01.txt
To: "Yongyi Yu"<[e-mail]<mailto:[e-mail]>>, "Tommy Pauly"<[e-mail]<mailto:[e-mail]>>
Cc: "Ryan Hamilton"<rch=[e-mail]<mailto:rch=[e-mail]>>, "[e-mail]<mailto:[e-mail]>"<[e-mail]<mailto:[e-mail]>>, "陈鉴平"<[e-mail]<mailto:[e-mail]>>, "景君羡"<[e-mail]<mailto:[e-mail]>>, "刘天一"<[e-mail]<mailto:[e-mail]>>
Are you trying to implement something like https://datatracker.ietf.org/doc/html/draft-lubashev-quic-partial-reliability-02<https://datatracker.ietf.org/doc/html/draft-lubashev-quic-partial-reliability-02> or https://datatracker.ietf.org/doc/html/draft-lubashev-quic-partial-reliability-03<https://datatracker.ietf.org/doc/html/draft-lubashev-quic-partial-reliability-03>?  (The -02 and -3 versions have somewhat different properties, and some people prefer -02 version.)


  *   Igor

From: Yongyi Yu <[e-mail]<mailto:[e-mail]>>
Sent: Friday, September 23, 2022 1:11 AM
To: Tommy Pauly <[e-mail]<mailto:[e-mail]>>
Cc: Ryan Hamilton <rch=[e-mail]<mailto:rch=[e-mail]>>; [e-mail]<mailto:[e-mail]>; 陈鉴平 <[e-mail]<mailto:[e-mail]>>; 景君羡 <[e-mail]<mailto:[e-mail]>>; 刘天一 <[e-mail]<mailto:[e-mail]>>
Subject: Re: [External] New Version Notification for draft-chen-quic-quicu-01.txt

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"<[e-mail]<mailto:[e-mail]>>
Date: Thu, Sep 22, 2022, 11:32
Subject: Re: [External] New Version Notification for draft-chen-quic-quicu-01.txt
To: "Ryan Hamilton"<rch=[e-mail]<mailto:rch=[e-mail]>>
Cc: "于涌溢"<[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>"<[e-mail]<mailto:[e-mail]>>, "陈鉴平"<[e-mail]<mailto:[e-mail]>>, "景君羡"<[e-mail]<mailto:[e-mail]>>, "刘天一"<[e-mail]<mailto:[e-mail]>>
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 <rch=[e-mail]<mailto:rch=[e-mail]>> 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 于涌溢 <[e-mail]<mailto:[e-mail]>> 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<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: [e-mail]<mailto:[e-mail]>
Date: Mon, Sep 19, 2022, 20:54
Subject: [External] New Version Notification for draft-chen-quic-quicu-01.txt
To: "Jianping Chen"<[e-mail]<mailto:[e-mail]>>, "Junxian Jing"<[e-mail]<mailto:[e-mail]>>, "Tianyi Liu"<[e-mail]<mailto:[e-mail]>>, "Yongyi Yu"<[e-mail]<mailto:[e-mail]>>
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<https://www.ietf.org/archive/id/draft-chen-quic-quicu-01.txt>
Status:         https://datatracker.ietf.org/doc/draft-chen-quic-quicu/<https://datatracker.ietf.org/doc/draft-chen-quic-quicu/>
Htmlized:       https://datatracker.ietf.org/doc/html/draft-chen-quic-quicu<https://datatracker.ietf.org/doc/html/draft-chen-quic-quicu>
Diff:           https://www.ietf.org/rfcdiff?url2=draft-chen-quic-quicu-01<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