Subject: [Moq] Fwd: New Version Notification for draft-dawkins-sdp-rtp-quic-questions-01.txt

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 26 Oct 2021 16:37:04 -0500

Dear MOQ subscribers,

Just to follow on James' excellent lead, I've also revised this draft,
which is an attempt to identify the requirements that RTP over QUIC will
place on SDP signaling for this type of media traffic.

As James said about our mutual draft, my understanding is that we're
expected to have conversations about "Media Over QUIC" on this mailing
list. If anyone has a different understanding, please let the mailing list
know, so that we can Do The Right Thing.

Otherwise, let's be thinking how to move this work forward in the IETF 112
timeframe.

Best,

Spencer

---------- Forwarded message ---------
From: <[email-masked]>
Date: Mon, Oct 25, 2021 at 12:38 PM
Subject: New Version Notification for
draft-dawkins-sdp-rtp-quic-questions-01.txt
To: Spencer Dawkins <[email-masked]>

A new version of I-D, draft-dawkins-sdp-rtp-quic-questions-01.txt
has been successfully submitted by Spencer Dawkins and posted to the
IETF repository.

Name:           draft-dawkins-sdp-rtp-quic-questions
Revision:       01
Title:          SDP Offer/Answer for RTP using QUIC as Transport - Design
Questions
Document date:  2021-10-25
Group:          Individual Submission
Pages:          13
URL:
https://www.ietf.org/archive/id/draft-dawkins-sdp-rtp-quic-questions-01.txt
Status:
https://datatracker.ietf.org/doc/draft-dawkins-sdp-rtp-quic-questions/
Html:
https://www.ietf.org/archive/id/draft-dawkins-sdp-rtp-quic-questions-01.html
Htmlized:
https://datatracker.ietf.org/doc/html/draft-dawkins-sdp-rtp-quic-questions
Diff:
https://www.ietf.org/rfcdiff?url2=draft-dawkins-sdp-rtp-quic-questions-01

Abstract:
   This document is a companion document to "SDP Offer/Answer for RTP
   using QUIC as Transport".  That document focuses on the description
   and registration of SDP "proto" attribute parameters with IANA, to
   allow applications that rely on SDP Offer/Answer to negotiate the
   QUIC protocol as an encapsulation for RTP.

   In writing that document, it became obvious that decisions about an
   appropriate SDP description would depend on decisions about the way
   RTP would be encapsulated in QUIC, and different proposals for those
   encapsulations had made different assumptions.  Given that none of
   these proposals have been adopted by an IETF working group yet, it's
   not appropriate to try to base a general-purpose set of "QUIC/RTP"
   IANA registrations on any one of them, so this document includes the
   questions that have come up, and (as discussions progress) suggested
   answers for those questions.

The IETF Secretariat

---

From: Maxim Sharabayko <[email-masked]>
Date: Wed, 27 Oct 2021 13:36:52 +0000

Hi Spencer and James,

I’d like to say without exaggeration that this is an outstanding work and an excellent summary!
I took the liberty of submitting a number of additions for consideration. Please see my PR [1].

One such suggestion is the "Distribution withing a platform" use case.
My description might be a bit clumsy though. So please let me know if that makes sense.

“
Distribution withing a platform

While a media is being contributed in real time via an ingest point to a streaming platform,
there may be a need to distribute the media between several servers and/or perform
a load balancing of the incoming traffic.
The platform may peform transcoding at one or several points, or distribute (route) the media as is
to one or many egress points. Such a distribution and load balancing may happen with or without
the access to the encrypted payload.”

- [1]: https://github.com/fiestajetsam/draft-gruessing-moq-requirements/pull/17

--
Regards,
Maxim Sharabayko
Senior Software Developer | Haivision

From: Moq <[email-masked]> on behalf of Spencer Dawkins at IETF <[email-masked]>
Date: Tuesday, 26. October 2021 at 23:37
To: MOQ Mailing List <[email-masked]>
Subject: [EXTERNAL] [Moq] Fwd: New Version Notification for draft-dawkins-sdp-rtp-quic-questions-01.txt
Dear MOQ subscribers,

Just to follow on James' excellent lead, I've also revised this draft, which is an attempt to identify the requirements that RTP over QUIC will place on SDP signaling for this type of media traffic.

As James said about our mutual draft, my understanding is that we're expected to have conversations about "Media Over QUIC" on this mailing list. If anyone has a different understanding, please let the mailing list know, so that we can Do The Right Thing.

Otherwise, let's be thinking how to move this work forward in the IETF 112 timeframe.

Best,

Spencer
---------- Forwarded message ---------
From: <[email-masked]<mailto:[email-masked]>>
Date: Mon, Oct 25, 2021 at 12:38 PM
Subject: New Version Notification for draft-dawkins-sdp-rtp-quic-questions-01.txt
To: Spencer Dawkins <[email-masked]<mailto:[email-masked]>>

Name:           draft-dawkins-sdp-rtp-quic-questions
Revision:       01
Title:          SDP Offer/Answer for RTP using QUIC as Transport - Design Questions
Document date:  2021-10-25
Group:          Individual Submission
Pages:          13
URL:            https://www.ietf.org/archive/id/draft-dawkins-sdp-rtp-quic-questions-01.txt
Status:         https://datatracker.ietf.org/doc/draft-dawkins-sdp-rtp-quic-questions/
Html:           https://www.ietf.org/archive/id/draft-dawkins-sdp-rtp-quic-questions-01.html
Htmlized:       https://datatracker.ietf.org/doc/html/draft-dawkins-sdp-rtp-quic-questions
Diff:           https://www.ietf.org/rfcdiff?url2=draft-dawkins-sdp-rtp-quic-questions-01

Abstract:

The IETF Secretariat

***[EXTERNAL] This message comes from an external organization. Exercise caution when opening attachments or clicking links, especially from unknown senders.***

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Wed, 27 Oct 2021 16:38:36 +0200

Hi Spencer,

Great to see a proposal in this direction! I was tempted to
propose something similar, so I will be willing to collaborate. Do you have
any github project were we could propose changes or raise issues?

Here are some of my preliminar thoughts:

- We should only support RTP over quick datagram, what about
webtransport support?
- IMHO the name should be UDP/QUIC/RTP/AVPF (SAVPF is for SRTP which we
don't use as the security is provided by the underlying QUIC transport)
- We need to define how ICE and QUIC over RTP interact together (should be
fairly simple)
- Do we want to specify how to reuse an established QUIC (or web
transport connection) for sending RTP within it? This may be impacted by
the ability to do datagram multiplexing.
- How about Datachannels over QUIC?

Last, even if this list is for media over quic, this proposal seems that
could be better suited for avtcore or mmusic discussion.

Best regards
Sergio

El mar, 26 oct 2021 a las 23:37, Spencer Dawkins at IETF (<
[email-masked]>) escribió:

> Moq mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/moq
>

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 27 Oct 2021 08:02:04 -0700

Sergio said:

"We should only support RTP over quick datagram, what about
webtransport support?"

[BA] Currently there are issues with WebTransport support for Web realtime
communications in the client -> server direction, summarized here:
https://docs.google.com/presentation/d/1SG1FUvn9UKGx_gAqWnCzPHlsIXkDUXctZPs7blfqS5k/

While the metrics issue is unique to WebTransport, the issues with QUIC
congestion control will also affect realtime media directly over QUIC.  The
biggest issue is slow recovery of media quality after packet loss. Without
probing similar to what is done in WebRTC today, recovering media quality
will be slow, particularly when simulcast or SVC is used.

"We need to define how ICE and QUIC over RTP interact together (should be
fairly simple)"

[BA]  The basics of QUIC over ICE were demonstrated in the RTCQuicTransport
Origin trial:
https://developers.google.com/web/updates/2019/01/rtcquictransport-api

I don't think that RTP adds any complexities.

A specification for QUIC multiplexing with STUN/TURN is available here:
https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rfc7983bis

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Wed, 27 Oct 2021 17:36:43 +0200

> will be slow, particularly when simulcast or SVC is used.

With RTP over QUIC we can do probing and bwe as in WebRTC. The main issue
is how the rtp bwe and the quic congestion control interact when running
simultaneously,  as we would get the worse of both worlds. Typically could
be bypassed by the native quic apps by removing the quic congestion control
and rely on the rtp bwe instead.

This approach however won't work for webtransport on browsers as the rtp
bwe would be done in the app js and the browser can't trust the js app to
do the right thing.

Best regards
Sergio

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 27 Oct 2021 09:24:01 -0700

Sergio said:

"With RTP over QUIC we can do probing and bwe as in WebRTC. The main issue
is how the rtp bwe and the quic congestion control interact when running
simultaneously,  as we would get the worse of both worlds. Typically could
be bypassed by the native quic apps by removing the quic congestion control
and rely on the rtp bwe instead."

[BA]  Yes, there is a potential conflict between RTP and QUIC congestion
control, particularly with respect to recovery.  My expectation is that
native apps will remove QUIC congestion control in order to use something
closer to what is done in WebRTC (including mechanisms such as probing, to
allow faster recovery).  This is already done in server -> client low
latency streaming use cases such as game streaming or remote desktop.

"This approach however won't work for webtransport on browsers as the rtp
bwe would be done in the app js and the browser can't trust the js app to
do the right thing. "

[BA] Right.  Where media is sent Client -> server I think there is going to
be a problem.  Use cases that might be affected are video conferencing or
low-latency video upload, particularly if the client is sending simulcast
and/or SVC.  If there is loss and the client drops a layer, the client
won't be filling the congestion window so the BWE won't recover fast
enough. Adding back a simulcast or SVC layer is a "multiplicative
increase", not an "additive increase".  Without probing as there is in
WebRTC, app won't know when simulcast and/or SVC layers can be added back.
As a result, the JS application will be stuck sending low quality video.

On Wed, Oct 27, 2021 at 8:36 AM Sergio Garcia Murillo <
[email-masked]> wrote:

>> [BA] Currently there are issues with WebTransport support for Web
>> realtime communications in the client -> server direction, summarized here:
>>

---

From: Joerg Ott <[email-masked]>
Date: Thu, 28 Oct 2021 18:43:07 +0200

Hi,

we just finished a small initial study on congestion control in
QUIC vs. in RTP vs. in both places and their interaction.  These
early results suggest the suspected, i.e., the interaction of
two congestion control loops may be problematic and that
prioritization or some other way of sharing available capacity
(as, e.g., determined by QUIC) and then scheduling reliable
stream and datagram frames accordingly is needed.

We also confirm that one can reuse QUIC state information to
replace dedicated RTCP signaling for congestion control.

This paper will appear in the EPIQ workshop in December:
https://www.in.tum.de/fileadmin/w00bws/cm/papers/epiq21-rtp-over-quic.pdf

Overall, the RTP over QUIC designs submitted as drafts appear
reasonably workable; more experiments in progress, there is
still a way to go.

Best,
Jörg

On 27.10.21 18:24, Bernard Aboba wrote:
> Sergio said:
> 
> "With RTP over QUIC we can do probing and bwe as in WebRTC. The main 
> issue is how the rtp bwe and the quic congestion control interact when 
> running simultaneously,  as we would get the worse of both worlds. 
> Typically could be bypassed by the native quic apps by removing the quic 
> congestion control and rely on the rtp bwe instead."
> 
> native apps will remove QUIC congestion control in order to use 
> something closer to what is done in WebRTC (including mechanisms such as 
> probing, to allow faster recovery).  This is already done in server -> 
> client low latency streaming use cases such as game streaming or remote 
> desktop.
> 
> "This approach however won't work for webtransport on browsers as the 
> rtp bwe would be done in the app js and the browser can't trust the js 
> app to do the right thing. "
> 
> [BA] Right.  Where media is sent Client -> server I think there is going 
> to be a problem.  Use cases that might be affected are video 
> conferencing or low-latency video upload, particularly if the client is 
> sending simulcast and/or SVC.  If there is loss and the client drops a 
> layer, the client won't be filling the congestion window so the BWE 
> won't recover fast enough. Adding back a simulcast or SVC layer is a 
> "multiplicative increase", not an "additive increase".  Without probing 
> as there is in WebRTC, app won't know when simulcast and/or SVC layers 
> can be added back.  As a result, the JS application will be stuck 
> sending low quality video.
> 
> On Wed, Oct 27, 2021 at 8:36 AM Sergio Garcia Murillo 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> 
> 
>     El mié., 27 oct. 2021 17:02, Bernard Aboba <[email-masked]
>     <mailto:[email-masked]>> escribió:
> 
>         Sergio said:
> 
>         [BA] Currently there are issues with WebTransport support for
>         Web realtime communications in the client -> server direction,
>         summarized here:
>         <https://docs.google.com/presentation/d/1SG1FUvn9UKGx_gAqWnCzPHlsIXkDUXctZPs7blfqS5k/>
> 
>         While the metrics issue is unique to WebTransport, the issues
>         with QUIC congestion control will also affect realtime media
>         directly over QUIC.  The biggest issue is slow recovery of media
>         quality after packet loss. Without probing similar to what is
>         done in WebRTC today, recovering media quality will be slow,
>         particularly when simulcast or SVC is used.
> 
> 
>     With RTP over QUIC we can do probing and bwe as in WebRTC. The main
>     issue is how the rtp bwe and the quic congestion control interact
>     when running simultaneously,  as we would get the worse of both
>     worlds. Typically could be bypassed by the native quic apps by
>     removing the quic congestion control and rely on the rtp bwe instead.
> 
>     This approach however won't work for webtransport on browsers as the
>     rtp bwe would be done in the app js and the browser can't trust the
>     js app to do the right thing.
> 
>     Best regards
>     Sergio
> 
> 
> 
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 28 Oct 2021 15:26:57 -0500

Dear All, but replying to Serio's email,

> any github project were we could propose changes or raise issues?

Thanks for the kind words. Here's what I think:

The GitHub repos for the drafts James and I announced on this mailing
list are at https://github.com/SpencerDawkins/sdp-rtp-quic-questions and
https://github.com/fiestajetsam/draft-gruessing-moq-requirements

If people have issues or PRs that are about the text in one of these
drafts, both repos are open for contributors, and if you aren't sure which
draft is the best fit, take your best guess, and let James and I work that
part out.

> could be better suited for avtcore or mmusic discussion.

I understand why that seems right. I expect that's where we'll end up.

What I thought *I* was doing, was

   - focusing on the SDP description necessary for RTP over QUIC(*), which
   ought to end up in MMUSIC, and
   - leaving the RTP mapping for QUIC to the RTP whizzes in AVTCORE

But there are some things that I need to know about the RTP mapping for
QUIC, in order to get the SDP description right, so right now, it might be
too early to head off to AVTCORE, MMUSIC, or both.

I did ask the AVTCORE and MMUSIC chairs about using this mailing list for
discussion of my drafts (on 14 September), and didn't hear any objections,
so here we are 🙂

Best,

Spencer, saying some things that James might agree with

(*) the draft on the SDP description itself is in Github, at
https://github.com/SpencerDawkins/sdp-rtp-quic.