[AVTCORE] Requests for specific feedback on the RoQ presentation at IETF 119 AVTCORE

[Spencer Dawkins at IETF <[e-mail]>]

Dear AVTCORE,

If I understand correctly, we should be seeing WGLC for
https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-over-quic/ Real
Soon Now. This was our first session where we had no open PRs and only one
open issue, and the chairs asked "Are we almost finished with this
specification?" and got a thumbs-up from the room.

There were three points where Mathis and I were hoping for feedback, but
the session time slot did not allow discussion, so it seems reasonable to
ask here, on the mailing list.

   - We have been thinking of multiplexing other protocols with RTP/RTCP on
   the same QUIC connection in general terms, but we are understanding that
   this may not be the best way to proceed. We are very interested in
   feedback on specific protocols that people would like to multiplex with
   RTP/RTCP over QUIC. Bernard Aboba and Peter Thatcher talked about
   multiplexing the WebRTC data channel with RoQ, and that was helpful, but
   are there other obvious suspects?
   - We got a question about NAT traversal/RoQ peer-to-peer support, and it
   occurred to me that we have added Section 13, Directions for Future Work
   <https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-over-quic-09#name-directions-for-future-work>.at
   Bernard's suggestion after the last interim meeting, and we've gotten some
   feedback in GitHub on what's included in version -09 of the draft, but we
   invite people to look at what we're anticipating, and provide feedback
   where appropriate.

Thanks!

Best,

Spencer

(Notes from HedgeDoc <https://notes.ietf.org/notes-ietf-119-avtcore?edit>
on this presentation inserted here for convenience)

4. RTP over QUIC (M. Engelbart, J. Ott, S. Dawkins, 20 min)

https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-over-quic

Mathis Engelbart presenting updates and open issues.

Bernard raised concerns about running the WebRTC data channel over QUIC,
multiplexed with RoQ. Peter Thatcher agreed that using the current API
would be a mistake, but multiplexing could make sense.

Spencer said from his perspective, we have been thinking about multiplexing
other protocols with RoQ in general, and feedback about specific protocols
that would be usefully multiplexed with RoQ, like the feedback Bernard and
Peter are giving in this session, is extremely helpful.

“Are we almost finished with this specification?” - thumbs up from the
group.

Peter asked how far can the RoQ and SDP for RoQ specification go if there
are no solutions for peer to peer QUIC? Will the WG be happy with a
specification that only supports client to server?

>From Peter Hatcher in Zulip: FWIW, I’m not opposed to RoQ being published
without p2p. I just wanted to make sure everyone is OK with that. My fear
is that we’ll call RoQ done and then the p2p piece will fall through the
cracks between the AVTCORE WG and the QUIC WG.

Spencer confirmed with Jonathan that SDP is not blocking for WG last call
but likely is blocking for PUBREQ. Spencer notes that the authors have
considered further developments that are ongoing or expected to happen and
what potential impact that can have.

Spencer pointed out that the current revision of RoQ has a new section 13
<https://mengelbart.github.io/rtp-over-quic-draft/draft-ietf-avtcore-rtp-over-quic.html#name-directions-for-future-work>,
on Future work, added at Bernard’s suggestion during the last interim. This
describes things we have legitimate issues for, but do not have a path for
yet (like NAT Traversal), or do not have experience with (like connection
migration and QUIC multipath). Spencer doesn’t think it’s worth blocking
RoQ publication for these topics, and they can be described in other
specifications while we are getting implementation and deployment
experience.

Joerg Ott stated that we can go to WG last call before IETF 120, and work
on that feedback in a timely way. “This work has already dragged out way
too long” (Spencer notes that the individual draft -00 was submitted in
July 2021, which is far enough in the past that one might reasonably expect
we are finished).

Magnus stated that we should go to WG last call. Signalling is seperate,
and RoQ can be extended for future capabilities. Peer to Peer is all about
establishing the QUIC connection, while RoQ is about mapping onto a QUIC
connection, so it’s fine for them to progress independently.

>From Lucas Pardue in Zulip: +1 WGLC soon