[AVTCORE] Review of RTP over QUIC (draft-ietf-avtcore-rtp-over-quic-01)

[Vidhi Goel <[e-mail]>]

Hello Authors,

I have read and reviewed draft-ietf-avtcore-rtp-over-quic-01 and below are my comments.

General comment - I think this draft will be really helpful for developers of real time applications in migrating to QUIC (from UDP and DTLS). The current draft touches on some important aspects such as multiplexing, de-depulication of RTCP feedback fields etc. But it needs some more details and clarifications regarding sections like congestion control, connection migration, multi path capability.

Specific comments - I am providing my comments section wise and there are a mix of minor nits, typos and major comments.

Section 1. - A very big advantage of migrating to QUIC would be connection migration and MPQUIC. I think this should be mentioned in the intro and later described the impact of each of these on RTP. 
Section 3. - Current text - Such new media transport protocols may be covered elsewhere, e.g., in the MOQ WG. I don’t think reference to MOQ is needed here. 
Section 6. - Multiplexing RTP/RTCP and non RTP (eg. HTTP) - since this will be discussed on Dec 15th interim, I will leave out my comment until a decision has been made.
Section 6.1 - Current text - If it is known to either the sender, that a packet, which was not yet successfully and completely transmitted, is no longer needed.... Typo in the first part where “either” is not needed.
Section 7. - Typo in the word “additional” -  QUIC layer to the application instead of exchanging addtional
Section 7.1 - The list of replaceable RTCP reports appears without any pretext before “Receiver Reports”. A simple line that says what is coming next would solve it.
                   - Under Receiver reports->Fractions lost, current text - Later packets SHOULD be ignored, since they may still be in flight, unless other QUIC packets that were sent after the datagram frame,. Why only sent after the datagram frame (and not stream) - maybe reframe the sentence to say RTP packet instead?
		   - Under Receiver reports->Highest Sequence Number received - This field is not clear. It would be clearer if it’d say what does this field mean in RTP and can QUIC provide the exact same feedback from its ACKs.
		   - Negative acknowledgements - Probably make the recommendation clearer that since QUIC can provide all the information that a negative ack provides, there is no need to use RTCP negative Ack.
   		   - ECN feedback - same comment as above, clearly state that reporting of ECN feedback should be done via QUIC instead of RTCP feedback.
Section 7.2 - English nit in current text - A QUIC receiver can also not calculate. Suggestion, Nor can a QUIC receiver calculate..
Section 8 - This section needs some work IMO with regards to,
	1. What spec should one comply to for a real time congestion controller? (I don’t think RFC 9002 is the right compliance for real time CCs)
	2. Is bandwidth estimation the only thing needed by media codecs or does QUIC CC need to do more than that?
	3. If a real time CC can’t comply to 1., does it need to use both real time CC as well as QUIC CC?

Section 10.2 - This is a sub section for impact of connection migration and it would be good to add one for MP QUIC as Multipath offers more benefits than migration. And, both the sections should clearly state if the RTP layer needs to do anything on path change.
		     - This line caught my attention - Application layer congestion control mechanisms (and also packet repair schemes such as retransmissions) need to be prepared to cope with such spikes.  Isn’t this something they already deal with UDP anyway? I wasn’t sure the reason for mentioning this explicitly.


Common to the entire draft - I think the word “unreliable” before datagrams doesn’t really add to the value of the draft as we all know datagrams are not retransmitted and the word “unreliable” doesn’t bring anything good to the table. Perhaps that can be removed at some places. The word congestion control is well known in the community but I think most real time drafts use the word “rate adaptation algorithm” and that word makes more sense to me than congestion control. Happy to hear what the authors (and others) think.


I can send out a PR for some of these comments.


Thanks,
Vidhi