[AVTCORE] draft-ietf-avtcore-rtp-over-quic: Section 8.4.1 Mapping QUIC Feedback to RTCP Receiver Reports ("RR")

[Bernard Aboba <[e-mail]>]

RoQ section 10.1 "Information to be exported from QUIC says:

"

   - *Datagram Acknowledgment and Loss*: Section 5.2
   <https://rfc-editor.org/rfc/rfc9221#section-5.2> of [RFC9221
   <https://www.rfc-editor.org/rfc/rfc9221>] allows QUIC implementations to
   notify the application that a QUIC Datagram was acknowledged or that it
   believes a datagram was lost. The exposed information SHOULD include enough
   information to allow the application to maintain a mapping between the
   datagram that was acknowledged/lost and the RTP packet that was sent in
   that datagram.¶
   <https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-over-quic/#section-10.1-2.2>

"

Since this only refers to Datagram Acknowledgment and Loss, this lead me to
wonder  about the implications for other transport modes (e.g.
frame/stream), particularly in scenarios where multiple SSRCs are sent over
the same QUIC connection.

RFC 3550 Section 6.4.2 defines the RTCP Receiver Report:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P|    RC   |   PT=RR=201   |             length            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     SSRC of packet sender                     |
       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report |                 SSRC_1 (SSRC of first source)                 |
block  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1    | fraction lost |       cumulative number of packets lost       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           extended highest sequence number received           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      interarrival jitter                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         last SR (LSR)                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   delay since last SR (DLSR)                  |
       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report |                 SSRC_2 (SSRC of second source)                |
block  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2    :                               ...                             :
       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
       |                  profile-specific extensions                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


As noted in Section 8.4.1, an RTCP RR packet can provide information
relating to multiple sources, each identified by their own SSRCs.   It is
possible for multiple SSRCs to be sent over the same QUIC connection.

Section 8.4.1 says:

Considerations for mapping QUIC feedback into *Receiver Reports* (PT=201,
Name=RR, [RFC3550 <https://www.rfc-editor.org/rfc/rfc3550>]) are:¶
<https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-over-quic/#section-8.4.1-1>

   - *Fraction lost*: When RTP packets are carried in QUIC datagrams, the
   fraction of lost packets can be directly inferred from QUIC's
   acknowledgments. The calculation SHOULD include all packets up to the
   acknowledged RTP packet with the highest RTP sequence number. Later packets
   SHOULD be ignored, since they may still be in flight, unless other QUIC
   packets that were sent after the RTP packet, were already acknowledged.¶
   <https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-over-quic/#section-8.4.1-2.1>



   - *Cumulative lost*: Similar to the fraction of lost packets, the
   cumulative loss can be inferred from QUIC's acknowledgments including all
   packets up to the latest acknowledged packet.



   - *Highest Sequence Number received*: In RTCP, this field is a 32-bit
   field that contains the highest sequence number a receiver received in an
   RTP packet and the count of sequence number cycles the receiver has
   observed. A sender sends RTP packets in QUIC packets and receives
   acknowledgments for the QUIC packets. By keeping a mapping from a QUIC
   packet to the RTP packets encapsulated in that QUIC packet, the sender can
   infer the highest sequence number and number of cycles seen by the receiver
   from QUIC acknowledgments.


[BA] As you note, for the sender to compute the info in the RTCP RR
(including Fraction Lost, Cumulative Lost, Highest Sequence Number
received, etc.) it is necessary for the sender to keep a mapping of QUIC
packets to RTP packet info (e.g. SSRC, sequence number).

Since Section 10.1 only mentions datagrams, is it envisaged that such a
mapping will be maintained for frame/stream transport? Does the existing
RoQ implementation support the mapping of QUIC ACKs to RTP info for
frame/stream transport?


   - *Interarrival jitter*: If QUIC acknowledgments carry timestamps as
   described in [I-D.draft-smith-quic-receive-ts
   <https://datatracker.ietf.org/doc/html/draft-smith-quic-receive-ts-00>],
   senders can infer the interarrival jitter from the arrival timestamps in
   QUIC acknowledgments.¶
   <https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-over-quic/#section-8.4.1-2.4>
   - *Last SR*: Similar to lost packets, the NTP timestamp of the last
   received sender report can be inferred from QUIC acknowledgments.¶
   <https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-over-quic/#section-8.4.1-2.5>
   - *Delay since last SR*: This field is not required when the receiver
   reports are entirely replaced by QUIC feedback.


[BA] Given that Section 10.1 only mentions datagrams, is there an
assumption that RTCP RRs/SRs are sent using QUIC datagrams? In some QUIC
implementations, datagrams are prioritized over reliable streams, which
might help ensure that RTCP traffic isn't subject to excess delays or
starvation.