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

[Yongyi Yu <[e-mail]>]

Hi Igor,

Currently the data expired is treated just as normally received so the
receiver will enlarge the flow control window accordingly as usual.  And we
really miss out the case where some data blocks are so large that they
exceed the flow control window size. Will a negotiation to decide the
minimum flow control window size during handshake help deal with this,
since all data blocks then would have size not exceeding the minimum flow
control window size?

About the APIs, we hope to provide an additional API to receive data
blocks. But the receiver could also read a byte stream by buffering data
blocks received and reading content from them. This could be implemented by
the transport layer and the application layer could be not aware of it.

Thanks,
Yongyi.

From: "Lubashev, Igor"<[e-mail]>
Date: Wed, Sep 28, 2022, 00:11
Subject: RE: RE: [External] New Version Notification for
draft-chen-quic-quicu-01.txt
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]>

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]>[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]>[e-mail]>,
"Tommy Pauly"< <[e-mail]>[e-mail]>

Cc: "Ryan Hamilton"< <rch=[e-mail]>
rch=[e-mail]>, " <[e-mail]>[e-mail]"<
<[e-mail]>[e-mail]>, "陈鉴平"< <[e-mail]>
[e-mail]>, "景君羡"< <[e-mail]>
[e-mail]>, "刘天一"< <[e-mail]>
[e-mail]>

Are you trying to implement something like
<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-lubashev-quic-partial-reliability-02__;!!GjvTz_vk!SCWoZpCVuR1gPftuxMF-fSS9CnLF_2nRKJitWu1H7d-btWOpFeCmdioeIafLXaj7vRbOtpP7gGi3BCMLrwTi38kR$>*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://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-lubashev-quic-partial-reliability-03__;!!GjvTz_vk!SCWoZpCVuR1gPftuxMF-fSS9CnLF_2nRKJitWu1H7d-btWOpFeCmdioeIafLXaj7vRbOtpP7gGi3BCMLr-kT71BO$>*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]>*[e-mail]
<[e-mail]>*>
*Sent:* Friday, September 23, 2022 1:11 AM
*To:* Tommy Pauly < <[e-mail]>*[e-mail] <[e-mail]>*>
*Cc:* Ryan Hamilton <
<rch=[e-mail]>*rch=[e-mail]
<rch=[e-mail]>*>; <[e-mail]>*[e-mail]
<[e-mail]>*; 陈鉴平 <
<[e-mail]>*[e-mail]
<[e-mail]>*>; 景君羡 <
<[e-mail]>*[e-mail]
<[e-mail]>*>; 刘天一 <
<[e-mail]>*[e-mail]
<[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]>*[e-mail] <[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]>*rch=[e-mail]
<rch=[e-mail]>*>

Cc: "于涌溢"< <[e-mail]>*[e-mail]
<[e-mail]>*>, " <[e-mail]>*[e-mail]
<[e-mail]>*"< <[e-mail]>*[e-mail] <[e-mail]>*>, "陈鉴平"<
<[e-mail]>*[e-mail]
<[e-mail]>*>, "景君羡"<
<[e-mail]>*[e-mail]
<[e-mail]>*>, "刘天一"<
<[e-mail]>*[e-mail]
<[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]>*rch=[e-mail]
<rch=[e-mail]>*> wrote:



QUIC has support for unreliable data via the DATAGRAM frame, *RFC 9221*
<https://urldefense.com/v3/__https:/www.rfc-editor.org/info/rfc9221__;!!GjvTz_vk!VHC6upHgCOojEiYhln21JerQBPYz1cbPLifo7gevl5sFTM-5qEoTkN-TxpvuKG1MQfnSBiZsXrrQ2OC2qjWu1aws$>.
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]>*[e-mail]
<[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://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-chen-quic-quicu-01__;!!GjvTz_vk!SCWoZpCVuR1gPftuxMF-fSS9CnLF_2nRKJitWu1H7d-btWOpFeCmdioeIafLXaj7vRbOtpP7gGi3BCMLr-8Nui-W$>*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]>*[e-mail]
<[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]>*[e-mail]
<[e-mail]>*>, "Junxian Jing"<
<[e-mail]>*[e-mail]
<[e-mail]>*>, "Tianyi Liu"<
<[e-mail]>*[e-mail]
<[e-mail]>*>, "Yongyi Yu"<
<[e-mail]>*[e-mail]
<[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://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-chen-quic-quicu-01.txt__;!!GjvTz_vk!SCWoZpCVuR1gPftuxMF-fSS9CnLF_2nRKJitWu1H7d-btWOpFeCmdioeIafLXaj7vRbOtpP7gGi3BCMLr-yI1P_H$>*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://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-chen-quic-quicu/__;!!GjvTz_vk!SCWoZpCVuR1gPftuxMF-fSS9CnLF_2nRKJitWu1H7d-btWOpFeCmdioeIafLXaj7vRbOtpP7gGi3BCMLr5p48dO1$>*https://datatracker.ietf.org/doc/draft-chen-quic-quicu/
<https://datatracker.ietf.org/doc/draft-chen-quic-quicu/>*

Htmlized:
<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-chen-quic-quicu__;!!GjvTz_vk!SCWoZpCVuR1gPftuxMF-fSS9CnLF_2nRKJitWu1H7d-btWOpFeCmdioeIafLXaj7vRbOtpP7gGi3BCMLr8jsZIQp$>*https://datatracker.ietf.org/doc/html/draft-chen-quic-quicu
<https://datatracker.ietf.org/doc/html/draft-chen-quic-quicu>*

Diff:
<https://urldefense.com/v3/__https:/www.ietf.org/rfcdiff?url2=draft-chen-quic-quicu-01__;!!GjvTz_vk!SCWoZpCVuR1gPftuxMF-fSS9CnLF_2nRKJitWu1H7d-btWOpFeCmdioeIafLXaj7vRbOtpP7gGi3BCMLr2ccQ-Yz$>*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