Audio/Video Transport Core Maintenance (avtcore) Working Group

CHAIRS: Jonathan Lennox
Bernard Aboba

Virtual Interim Agenda
Date: Thursday, December 15, 2022
Time: 08:00 - 10:00 Pacific Time

Notes: https://notes.ietf.org/notes-ietf-interim-2022-avtcore-04-avtcore

Meeting link:
https://datatracker.ietf.org/meeting/interim-2022-avtcore-04/session/avtcore

Remote instructions:
https://meetings.conf.meetecho.com/interim/?short=28f86c31-b45b-488f-ae63-02effa56b9bc

Slides:
https://docs.google.com/presentation/d/1ZFOJnLKGFrqoLBmtaaEgMb_mcCdVV-fIXtymGud_tlc/

Notes by: Mo Zanaty, Spencer Dawkins

1. Preliminaries (Chairs, 15 min)

Note Well, Note Takers, Agenda Bashing, Draft status, CfAs

• Note-takers were dragooned, and the Note Wells were noted (Really
  Well)
• The agenda escaped unbashed
• Jonathan provided draft status and pinged authors for updated draft
  versions on the call
• Action Item for Chairs approve the adopted v3c draft (this got
  fumbled a bit).
• Action done: V3C WG draft posted:
  https://mailarchive.ietf.org/arch/msg/avt/YbJAMD9GoB_yks9bkDYDOyLwJuk/

2. RTP Control Protocol (RTCP) Messages for Green Metadata (Yong He, 10 min)

https://datatracker.ietf.org/doc/html/draft-he-avtcore-rtcp-green-metadata

• Yong gave a brief overview of these messages and replied to comments
  received during Call For Adoption.

• Jonathan requested "no bikeshedding about names on this call"

• Stephan pointed out that the current name (Green Metadata) is
  already known in the ISO community
• Can seek comments on renaming the draft on the list.
• Is saving 32 bits per FCI entry worth it? We think not
• Does the media sender need to do anything if it reduces resolution
  or frame rate due to congestion? No, the sender has provided a
  maximum, and as long as the sender stays under the maximum, no
  action is required
• Action Item for Authors The authors have an action to submit a
  working group version after closing on the title in mailing list
  discussions

3. MAX_STREAMS and the Frame/Stream Model (B. Aboba, 10 min)

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

• Bernard has filed an issue for the WebTransport API (#446) to allow
  the application to influence MAX_STREAMS, and added an issue for
  RTP over QUIC about whether we need to provide a warning in our
  specification.
• Bernard has experimented with Javascript for concurrency (multiple
  RTP streams on a single QUIC stream) - await() is blocking, so don't
  do that
• Is MAX_STREAMS limit a problem? Most likely if you aren't closing
  streams and cleaning up resources.
• Conferencing looks like the most obvious place where we could have a
  problem, with more and more simultaneous video streams being
  supported.
• Mo - is MAX_STREAMS about a limit on maximum stream ID, or about
  maximum open streams?
• Stream ID numbers are not reusable unless you close and reopen a
  connection.
• Action Item for Mo Zanaty Mo takes an action to follow up on
  details here. (Answer: maximum number of streams, including closed
  ones)
• Chromium apportions bandwidth based on the number of open streams,
  so close streams you're not using them.
• There may be a reason to add a note in our spec about this.

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

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

• Planned Usages:
• Action Item for Authors : Authors to discuss planned usages on
  the mailing list.
• Bernard Aboba questions whether SIP and WebRTC are planned usages.
  SIP implementations are slow to change; took a long time to deploy
  SIPS: in handsets, PBXes, SIP trunking. P2P QUIC had an origin trial
  in Chromium based on the ORTC API, but no current implementations.
  So may be better to think of Web applications, rather than just
  WebRTC.
• Jonathan Lennox notes that some people (notably Jonathan Rosenberg)
  hoped to evolve SIP deployments to better use web infrastructure.
• Peter Thatcher notes that leveraging web (not WebRTC) infrastructure
  is a good goal. Mobile apps doing voice and video should also be a
  planned usage, separate from "SIP" or Web.

• Stephan Wenger agrees with Peter's point. ALso, the slide is overly
  standards-centric. Define use cases based on applications, not call
  control etc. standards. Still want a drop-in replacement for RTP
  over UDP without standardized call controls, as this is what large
  segments of the industry are using.

• Topologies:

• Roman Shpount suggests to stay away from multicast which complicated
  RTP. Demux of multiple RTP streams over a single "channel" needs to
  be specified.

• Jonathan Lennox does not see a need to mention all topologies, but
  just mention those that will be in scope for RTP over QUIC.

• QUIC Extensions:

• Action Item for Authors : Authors to ask on the AVTCORE
  mailing list if anyone is interested in the timestamp extension.
• Bernard Aboba notes IETF WEBTRANS WG could not make the timestamp
  extension mandatory or even recommended in WebTransport, since it is
  not widely implemented. However, W3C WebTransport is interested in
  it, since it can enable estimation of the one-way delay, which the
  application couldn't otherwise get at. This can be helpful for
  asymmetric networks (e.g. cable internet).
• Peter Thatcher is interested to see the timestamp extension progress
  and deploy it to aid congestion control.
• Joerg Ott said the author of the timestamp extension (Christian)
  wants to know if there is more interest to devote more effort on
  this.
• Mo Zanaty is interested in the timestamp extension for the same
  reasons as Peter and Bernard.

• Harald Alvestrand notes that timestamps may be useful for knowing
  what to send next, independent of congestion control.

• AVT Profiles:

• Jonathan Lennox sees issues with the secure profiles where keying
  needs to be defined, so would not recommend this.
• Roman Shpount brings up the case of tunneling DTLS-SRTP over QUIC.

• Jonathan Lennox thinks Roman's use case belongs in the MASQUE WG.

• ALPN and Congestion Control:

• Bernard Aboba agrees with proposed ALPN "rtp-mux-quic" not "h3", but
  notes this is orthogonal to congestion control. In WebTransport API
  (constructor), the application can provide a hint about the desired
  kind of congestion control, but this doesn't affect the ALPN.
• Peter Thatcher hopes congestion control does NOT depend on ALPN, but
  rather we get a good congestion control for all traffic including
  real-time media.
• Vidhi Goel agrees with Peter.

5. RTP over QUIC (J. Ott, M. Engelbart, 20 min)

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

• Talking about multiplexing - we've talked about this previously, but
  not in much detail, and not including WebTransport.
• We have a lot of levels where we can do RTP/RTCP multiplexing (and
  they don't all fit on one slide!)
• Jonathan - one use case people are interested in, is call control
  and media on the same connection (if your call control and media go
  to the same box, that makes load balancing easier, for example)
• This may be related to rfc7983 bis, though RTP over QUIC won't need
  to multiplex with STUN/TURN/ZRTP/DTLS, only perhaps RTCP and data.
• Sam - transport parameter that allows you to say what a stream
  carries when you open a new stream - would that help?
• Three options - "WebTransport", "Partial WebTransport" with our own
  multiplexing, or just support multiplexing RTP/RTCP and assume we
  can add other protocols when we need to.
• WebTransport requirements - indicate client origin and describer
  server endpoint location using a URI
• Bernard - When an application constructs a WebTransport while
  allowing pooling, this can result in multiple sessions over a single
  QUIC connection. However, pooling is an optimization; the
  application might get a distinct connection instead if pooling isn't
  supported in the browser or on the server. So multiplexing of RTP
  sessions using the WebTransport SessionId is more viable for
  non-browsers than for browsers.
• Does it make sense to rely on WebTransport (hence, h2 and h3) in
  order to get RTP over QUIC done?
• Bernard: In the WebTransport API, an application can specify whether
  it is willing to failover to H2 or not. So it is possible to define
  RTP over WebTransport only for HTTP/3, if there are required
  features that HTTP/2 cannot provide.
• RTP/RTCP-only for now, and figure out how to multiplex any other
  protocols in other documents that describe multiplexing per-protocol
  for a new protocol?
• Bernard - what's "partial WebTransport"? You don't need to implement
  all of HTTP/3 to support WebTransport, just a few headers. So no
  need for a separate profile.
• Jonathan - define a single raw RTP session over WebTransport, and
  have WebTransport handle all of the multiplexing stuff? Defining our
  own multiplexing is probably a bad idea.
• Mathis - would that be enough?
• Jonathan - how much do we care?
• Mathis - having multiple RTP sessions over one QUIC connection to
  simplify congestion control.
• Bernard: Today in WebRTC, it is nearly universal to bundle audio &
  video are bundled and mux RTP and RTCP. Why not design for the
  common use case?
• Bernard - how do we move forward on these issues?
• Jonathan - probably need to move forward on alternatives, so we can
  evaluate alternatives better
• Action Item for Authors - Mathis and Joerg to start a mailing
  list discussion
• The chairs noted that we do have time for another virtual interim
  before IETF 116 in March, if we need one

6. Codec Agnostic Payload Format (Y. Fablet, 20 min)

https://github.com/youennf/codec-agnostic-rtp-payload-format

• Youenn provided an overview of an architecture for media that is
  encrypted end-to-end
• Moving the packetizer from the encoder to the media encryptor
• If we use WebCodecs API, and focus on video for now, we can make
  some progress.
• Need to know whether to forward a packet or not, and the indicator
  that tells you this can't be encrypted
• SFUs probably need to repacketize (for example, clients with
  different MTU sizes) - Youenn would like feedback on this.
• We have a need for multiple encrypted transforms (SFrame, SPacket,
  etc.), and we have an architecture. Are we ready to start working on
  solutions?
• Harald - I'm working on a different use case, but there's overlap
  between what we're doing, and handling encrypted packets without
  decrypting them is important
• Peter - I agree that it's important
• Chairs - you've made a lot of progress and given us capabilities
  that we didn't have before - please keep working on this.
• Youenn - I'll do that.
• Peter's slides - major decision is what metadata to include.
• Don't have time to go over specifics, but there's more information
  on the slides
• Jonathan - a minimal implementation that we could look at would be
  very useful. With WebCodecs and WebTransport, this could be done in
  Javascript.

7. Wrapup and Next Steps (Chairs, 15 min)

• The chairs thanked everyone for coming, and noted that we have a lot
  to talk about
• "See you at IETF 116"

Zulip Logs

Roni Even10:04
I am on my phone

Stephan Wenger10:09
I'm juggling two calls. If you have anything specific for me and I don't
respond, please put it in the chat.

Jonathan Lennox10:10
Stephan, can you update the EVC draft?

Stephan Wenger10:11
I have no audio right now.

Lauri Ilola10:11
Seems you cant hear me

10:11
https://datatracker.ietf.org/submit/status/130061/

Stephan Wenger10:11
EVC draft will be revved as soon as RFC 9324 is published; any day now.
Mid Jan the latest, probably earlier

10:12
I get audio: 0 kbps. Anyone else?

Nils Ohlmeier10:14
I'm getting 10-20 kbps audio

Stephan Wenger10:16
Had to reboot my Mac. And I thought rebooting helps only with Windows
PCs?????

Youenn Fablet10:17
@Stephan, if you are using Safari, feel free to file a bug in
bugs.webkit.org and send me a sysdiagnose (youenn@apple.com)

Stephan Wenger10:18
Green Metadata is Leonardo's sin, but it's known now

Rui Paulo10:32
max_streams is not about open streams

Joerg Ott10:33
No

Rui Paulo10:33
rfc9000 "A count of the cumulative number of streams of the
corresponding type that can be opened over the lifetime of the
connection. "

Jan-Ivar Bruaroey10:35
To clarify: the await/then issue isn't about a technical difference, but
about whether the JS sender blocks writing more bytes on the successful
queuing of bytes it just wrote. pipeTo() backpressure uses await
writer.ready for this reason which resolves ahead of writer.write(), for
better concurrency

Vidhi Goel10:37
Though max_streams is cumulative, quic implementation increases that
limit anytime streams are closed. So, it tries to maintain some number
of streams always open

Joerg Ott10:39
MVP

10:39
MVP

Mo Zanaty10:39
@Vidhi, any spec ref to justify such implementation? It sounds wrong
from a brief scan of RFC 9000.

Joerg Ott10:40
@Mo: It is treated as a sliding window according to some discussions on
the moq list, IIRC

Stephan Wenger10:46
can we PLEASE use zoom for future calls

Shuai Zhao10:49
I don’t think Stephan has audios

Stephan Wenger10:50
I'm going to shoot this computer!

Dale Worley10:50
Stephan: Nobody can hear you.

Stephan Wenger10:50
+1 to Peter's pont. ALso, the slide is overly standards-centric. Define
applications not be call control etc. standards.

10:50
I still want a drop-in replacement for RTP over UDP without standardized
call controls, as this is what large segments of the industry are using

10:51
can we PLEASE PLEASE PLEASE use zoom henceforth

10:52
Trying to clear my queue

Joerg Ott11:00
QUIC TS could be used as an improvement if available but certainly would
not be mandated

11:00
At the last IETF, Christian Huitema was trying to see how much interest
there was in QUIC TS

Rui Paulo11:00
would quic timestamps interact with rtp's timestamps ?

Joerg Ott11:01
within the QWUIC WG

11:01
there was limited response at this point

Rui Paulo11:01
@joerg, that may have been because of an application, but it seems like
RTP could be a motivating factor

11:03
we don't hear any echo, btw.

Joerg Ott11:05
lucky you, at least then I was intelligible

Harald Alvestrand11:14
Is QUIC over TCP even defined?

Rui Paulo11:14
I hope not :-)

Harald Alvestrand11:17
So QUIC over TCP is QUIC over UDP over MASQUE? Stack ALL the layers!

Sam Hurst11:19
HTTP/3 doesn't specify the congestion control, the QUIC transport layer
does?

Rui Paulo11:21
@Sam, that is correct.

Vidhi Goel11:24
The examples of NADA and Scream shouldn’t be taken as the only options

Sam Hurst11:30
Is this multiplexing question more of a general topic, and possibly not
unique to running RTP over QUIC? Maybe it's more generally useful to
define some transport extension which specifies a generic stream type
like that defined by H3 for unidirectional stream types?

Sergio Garcia Murillo11:32
what's the use case of multiplexing multiple RTP sessions over the same
QUIC connection?

Jan-Ivar Bruaroey11:38
but allowPooling defaults to false?

11:39
So if I create two new WebTransport(url); in the same document, they
fail? Not sure that is correct

11:39
also iframes

11:44
A WebTransport session is a session of WebTransport over HTTP/3. There
may be multiple WebTransport sessions on one connection, when pooling is
enabled.

Vidhi Goel11:45
I would argue against over webtransport or http as there are
applications that don’t do either.

11:47
If you want to just take the multiplexing logic from webtransport, then
I think it needs to very clear

Jonathan Lennox11:47
Bernard, I think you've lost audio

Mo Zanaty11:49
Are we ending in 10 min at 10am PST?

Spencer Dawkins11:59
Mo, I heard a chair say maybe we can run over a bit ...

Mo Zanaty12:00
Spencer, I have a conflicting meeting starting now, so thanks for taking
over the minutes.

Harald Alvestrand12:11
need to go!