Minutes interim-2022-avtcore-02: Thu 10:00
minutes-interim-2022-avtcore-02-202205191000-00

Audio/Video Transport Core Maintenance (avtcore) Working Group
CHAIRS: Jonathan Lennox
Bernard Aboba

Virtual Interim Agenda
Thursday, May 19, 2022
10 AM - noon Pacific Time
17:00 - 19:00 UTC

Meeting link:
https://meetings.conf.meetecho.com/interim/?short=144e158a-fc0a-4d67-855c-0f50babca848

Slides:
https://docs.google.com/presentation/d/1ot8QMaR6lRSz4ULcJlXkqQHkyKlzsV382447s962QeA/

<hr />
Preliminaries (Chairs, 10 min)
Note Well, Note Takers, Agenda Bashing, Draft status, IPR declarations
IETF 114 will be a hybrid meeting.  Who will be there in person?
Possible: Mathis Engelbart, Spencer Dawkins, Mo Zanaty, Stephan Wenger, Roman
Shpount, Joerg Ott

Bernard: An IPR declaration has been received relating to cryptex. Is there any
objection to proceeding with the document due to this? No objections raised.

Cryptex (Sergio Garcia Murillo, 10 min)
https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-cryptex
https://github.com/juberti/cryptex/issues
Sergio: On GENART review are there are any preferences on the Section 4
proposed changes? Bernard: The choices look very similar. Sergio: I have a
slight preference for the secdond choice.

Sergio: ARTART Review (Section 5.2 Receiving).
Issue is with "The implementation SHOULD stop and report an error if it
considers use of this specification mandatory for the RTP stream" Bernard: SDP
reflects the ability of the Offerer and Answerer to receive cryptex. The policy
in the API is "negotiate" (send without cryptex if the other peer doesn't
support receiving it) or "require" (fail the negotiation if the other side
doesn't support receiving cryptex). Is this a situation where both sides
indicated support for cryptex, yet cryptex isn't being received? Or are we
talking about cryptex not being negotiated in a situation where a peer requires
it? Sergio: will double check.

Frame Marking RTP Header Extension (Mo Zanaty, 5 min)
https://datatracker.ietf.org/doc/html/draft-ietf-avtext-framemarking
Mo: The IESG seems to be changing their view of Experimental status.
Is WG still thinking this is experimental?
Jonathan: maybe informational? check IESG?
Bernard: There are multiple forwarding RTP header extensions in use today:
framemarking, Generical Framemarking Descriptor, Dependency Descriptor, all
implemented in the Chromium code base at some  point. Mo: Framemarking header
extensions are "experimental" in the general sense. Stephan: not recommended
for informative with current text Mo: propose new text and see if people like
it.

RTP Payload for SCIP (Daniel Hanson, 10 minutes)
https://datatracker.ietf.org/doc/html/draft-hanson-avtcore-rtp-scip
Bernard: The term "end-to-end" is used differently in SCIP than in SFRame. Here
the conferencing server is considered a trusted endpoint? Daniel: Yes. Bernard:
When you say that things like bundle, RTP/RTCP multiplexing, feedback are
"beyond the scope of SCIP" are  you saying that these things could be
negotiated (e.g. not prohibited)? Daniel: The existing specifications can be
reused. A SCIP implementation could negotiate them (or not). Mike: what is next
step? Bernard: reviewer feedback (SDP Directorate, ARTART, SECDIR, etc.), then
request for IESG publication Mike: will upload revision with changes. Bernard:
After that is uploaded, we will initiate directorate reviews.

RFC7983bis (B. Aboba, 10 min)
https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rfc7983bis
Bernard: ready for WGLC? any concerns?
Jonathan: ready for last call.
Bernard: any concern with QUIC grease?
Jonathan: ask QUIC WG if there is knob to turn if off
Bernard: It is negotiated as a transport parameter, but typically no knob in
QUIC APIs to influence that. Mo: its fine for last call. I suspect that QUIC
bit greasing will fail to be deployed widely.

QUIC congestion control for RTP (D. Baldassin, 10 min)
https://datatracker.ietf.org/doc/html/draft-engelbart-rtp-over-quic
David: The results presented with respect to SCReaM under New Reno were
influenced by a bug in SCReaM. Reran the tests after fixing the bug, now
results of SCReaM under New Reno and SCReaM are very similar, indicating
sending rate is application-limited. Spencer: thank you for reporting these
results. did you document the environment that you were using anywhere? David:
not really. We used the same setup as in
https://www.in.tum.de/fileadmin/w00bws/cm/papers/epiq21-rtp-over-quic.pdf

Spencer: I look forward to your results from the next experiment you described
in your slides. Jonathan: We always thought running SCReAM over NewReno would
be terrible, but your results are saying NewReno is application-limited and
doesn't really have an effect? David: right Bernard: remember that this was a
single-stream experiment. Simulcast, for instance, might be different, because
it implies multiplicative increase, not additive increase.

RTP over QUIC (J. Ott, M. Engelbart, 15 min)
https://datatracker.ietf.org/doc/html/draft-engelbart-rtp-over-quic
Mathis: We are using a flow identifier (described in
draft-ietf-masque-h3-datagram) to differentiate RTP sessions. New draft
supports RTP both over QUIC datagrams and reliable streams. Note: Context ID of
earlier h3-datagram drafts has been removed. Only Quarter Stream ID left in
current draft. Review by MASQUE WG? Sergio: how do you map RTP onto a QUIC
reliable stream? Mathis: one ADU per RTP packet (separate stream for each ADU).
No RFC 4571 length field. Srinivas: regarding how RTCP timestamp. Mathis: map
RTCP packet for CC feedback and RTCP timestamp won't be discarded. Spencer: On
slide 47, is "exporting statistics" to the application Mathis: Yes, it's what
QUIC exposes to App Bernard: will do WG adoption after next revision Joerg: can
we do WG adoption without security section? Spencer: I'd encourage the chairs
to call for WG adoption earlier. People (including me and the nice people at
W3C Web Transport WG) are treating this draft as a baseline, but AVTCORE hasn't
adopted it yet - relying on an individual draft isn't a good plan. This draft
is in sufficiently good shape for WG to work on it. Suggest WG to adopt earlier
rather than later. Jonathan: do you say personally you think WG should adopt
it? Spencer: absolutely. Jonathan: will discuss with Bernard and come back

WebTransport Liaison (Will Law, 15 min)
Will Law: The WebTransport API is a Javascript API for use by applications
running in browsers. In a browser, an application cannot have tight integration
with the QUIC stack. For example, we have WHATWG Streams send/receive queues
(which should be short) as well as QUIC send/receive queues, typically
operating in another process for security reasons. Will Law: WebTransport API
does not provide low level access to some of the information that has been
indicated as useful for congestion control. We have added stats such as
smoothedRtt, minRtt, rttVariation. But we do not have latest_rtt, ecn or ACK
info, or pkt_departure/pkt_arrival time. Mathis: Maybe do experimental and see
what parameters are needed. Will: what will be the necessary info via the
browers to the JS application? Mathis: not sure if RTT measurements are
necessary at this moment. Roman: get aggregated packet arrival or average in a
given period, actual or inter-packet arrival may be a ideal approach Mo:
broswer QUIC stack will have some sort of congestion control already, but it
may fight with application congestion control. So the application needs to
obtain stats on the underlying cc in the browwer. JS might need to work around
this. Will: are there candidate CC for JS app? Bernard: The RMCAT WG defined
several algorithms which were published as Experimental RFCs, plus there is a
draft on Google Congestion Control. Stefan: First, it is important to
understand the role of QUIC cc in a web browers. I have personally tried
NewReno as a QUIC CC algorithm for an RTC application and it works reasonaly
well. But adding the missing packet departure and arrival info would be useful,
at least for Google Congestion Control (gcc). Sergio: it is still a good idea
to have low level cc for browser JS app. I don't think you can ship "circuit
breaker" CC in a browser QUIC implementation.

SDP for RTP over QUIC (S. Dawkins, 10 min)
https://datatracker.ietf.org/doc/html/draft-dawkins-sdp-rtp-quic
Spencer: working on draft-dawkins-sdp-rtp-quic, tracking
draft-engelbart-rtp-over-quic (which I'd love to see adopted)

Keeping broader issues in separate GitHub repo
(https://github.com/SpencerDawkins/sdp-rtp-quic-issues) Proposing three
resolutions - looking forward to input from working group in the Github repo
and mailing list. What AVP profiles to register - Issue 5
https://github.com/SpencerDawkins/sdp-rtp-quic-issues/issues/5 Streams,
Datagrams, or both? - Issue 8
https://github.com/SpencerDawkins/sdp-rtp-quic-issues/issues/8 and Issue 3
https://github.com/SpencerDawkins/sdp-rtp-quic-issues/issues/3 Signaling
media-friendly congestion control? Issue 1 -
https://github.com/SpencerDawkins/sdp-rtp-quic-issues/issues/1 No time for Q&A

RTP Payload for V3C (Lauri Ilola, 10 min)
https://datatracker.ietf.org/doc/html/draft-ilola-avtcore-rtp-v3c
Lauri:Looking for additional authors/contributors?
Shuai:what is the status in 3GPP?
Srinivas: video swg. still under discussion.

Wrapup and Next Steps (Chairs, 10 min)

----------------- Jabber conversation history below:
Jonathan Lennox
I plan to be at IETF in person10:04:58
Mathis Engelbart
I plan to be there in person10:05:24
spencerdawkins
I'm likely to be in person at IETF 11410:05:35
Mo Zanaty
+1 in person10:05:43
spencerdawkins
Oh, no. Still CoViD-19 ...10:06:21
Stephan Wenger
likely there in person10:06:23
Jonathan Lennox
I am getting the phenomenon where I can't hear unless my audio is enabled, it
seems. So I'm leaving my mic on.10:09:39 Roman Shpount I'm likely will be there
in person10:11:33 Joerg Ott Likely in person10:36:38 Mathis first11:02:34
Stefan Holmer +1 to what Sergio says. Also random (non-congestion induced)
loss11:06:02 Joerg Ott Guess what we have done ;we re-ran all
experiments11:08:28 Yes to Jonathan11:11:08 Well, whatever you would decide to
be your sensible ADU (you could split a frame voluntarily)11:11:40 Sergio
Garcia Murillo what is the benefit of using a quic stream vs a quic
datagram?11:12:09 Jonathan Lennox Transport-level reliability, and avoiding
having to do reassembly at the RTP layer, I'd guess?11:12:54 Joerg Ott QUIC
stream doesn't require the datagram extension11:12:57 Transport layer
reliability (+ many folks did exactly this in the past)11:13:11 And this was
brought up during the last meeting as something to document11:13:38 Sergio
Garcia Murillo but basically you are preventing any RTP over QUIC stream
interorability with DTLS/SRTP (i am thinking in a mixed SFU model)11:13:44
Joerg Ott There are many different use cases; not all protocols combinations
will fit all purposes11:14:09 This is negotiable in the end11:14:34 (e.g., in
SDP)11:15:12 @Sergio: Understand the mixed MCU model (RTP topologies will
likely raise even more fundamental issues)11:16:34 We haven't looked into ICE
signalling yet11:21:21 Jonathan Lennox I don't think ICE inside QUIC makes very
much sense...ICE outside QUIC is the scope of 7983bis discussed earlier but
would also need additional signaling of some sort to get peer-to-peer QUIC
working.11:23:01 Sergio Garcia Murillo yes, my question is how setting up ICE
outside QUIC interacts with the flow identifier11:23:42 Joerg Ott right11:23:44
This is an open question at this point11:24:01 Sergio Garcia Murillo i think
that at the end my question is what does each of the different flows defined by
the flow-id means in terms of rtp terminology11:26:04 Joerg Ott It's different
RTP sessions (if they contain RTP)11:27:50 effectively a replacement for
port-based multiplexing11:28:32 Sergio Garcia Murillo rtp session as defined in
https://datatracker.ietf.org/doc/html/rfc7656#page-1411:28:49 ?11:28:50 Joerg
Ott (how to fold this into ICE may be a bit more tricky)11:28:53 According to
section 3 of RFC355011:30:16 Roman Shpount yes, you can do bandwidth control in
the browser11:34:00 spencerdawkins So, W3C Web Transport is looking at two
levels of congestion controllers, (browser and not-browser), and the
"not-browser" ALSO has two levels of congestion controllers itself? EXCELLENT
... 11:42:13 Jonathan Lennox I think having browser-based measurements of
packet departure and arrival times are the important think for getting this to
work in JS - you don't want to be measuring these timestamps in the browser,
that'll be very vulnerable to application delays.11:46:02 Stefan Holmer agree,
jonathan11:48:28 Jonathan Lennox There's a tradeoff between how much data the
browser provides vs. the assumptions it makes about what the bwe algorithm
needs. Raw packet departure and arrival times are the fewest assumptions but
the most data. 11:49:44 Stefan Holmer and making sure there's a possibility of
picking a browser-based cc algorithm that is unlikely to be limiting the cc in
the app11:49:49 Sergio Garcia Murillo i kind of agree, but I also think that
taking account application delay is interesting in order to reduce the end to
end delay11:49:52 Shuai Zhao @Jonathan, for note purpose, the agreement for
item 7: RTP over QUIC, is that WG will discuss the possibility of early WG
adoption without new revision?11:50:08 Roman Shpount It should be
UDP/QUIC/RTP/AVPF11:50:26 Sergio Garcia Murillo +1 to UDP/QUIC/RTP/AVPF11:50:53
Jonathan Lennox Shuai: That was the consensus as I understood it, yes.11:50:55
Stefan Holmer @sergio, yes, but i wouldn't necessarily want the cc algorithm to
deal with that.11:50:57 what i do want to avoid is having to send the same
timestamps twice, once in the quic protocol and once in the app layer11:51:56
Sergio Garcia Murillo @stefan not really sure, would love to experiment the
behaviour of browser vs js app feedback, maybe we are complicating the browser
implementation unnecesarily11:52:34 but yes, if the timestamps are available in
quic feedback, let's reuse them11:53:04 Joerg Ott thanks much, Spencer11:53:23
Jonathan Lennox Another question for Spencer: if we're looking at different
QUIC flow-ids are different RTP sessions, they'd presumably need to have
separate media groups (m= lines) in SDP?11:54:21 Sergio Garcia Murillo but then
what is the difference of a flow id and a mid?11:54:54 seems redundant11:55:03
Jonathan Lennox This is basically another grouping layer at a level above
BUNDLE.11:55:07 Roman Shpount Why would it be needed?11:55:24 Jonathan Lennox
For BUNDLE (Unified) mid is an RTP stream, this is an RTP session.11:55:26
Well, if it's a think that the protocol supports, presumably it should be
signalable. If it's not needed, there's no need to put it in the
protocl?11:55:58 (Correction, mid isn't an RTP stream, it's more complicated
than that, but it's smaller than a session.)11:56:37 Roman Shpount The question
is if we need multiple RTP sessions over the same QUIC connection11:56:52 Joerg
Ott You should nevertheless be able to provide a mapping from RTP
sessions/streams to flow-ids so a receiver knows what to expect where for
demuxing11:57:22 Jonathan Lennox I don't know if we need it; Jörg mentioned it
as a possibility.11:57:35

Joerg Ott
One point of many discussions was saving port numbers. We do all kinds of
multiplexing11:57:52 QUIC gives us an opportunity to do this (what we did
before over UDP). So why lose this property?11:58:11 Jonathan Lennox It seems
kind of redundant with BUNDLE, though there are cases where BUNDLE isn't
applicable or desirable.11:58:38 But if we do do it, we need to figure out what
it looks like in SDP.11:59:16 Roman Shpount I see. I think WebRTC without
bundle does not get a lot of use11:59:28 Joerg Ott The main problem we thought
of that you may not just have RTP sessions. But this needs careful
considerations11:59:31 Mathis Engelbart @Roman I think the question also
includes if we need RTP and non-RTP on the same connection. I think it might be
useful to share the connection e.g. for shared congestion control, which would
otherwise compete against each other.11:59:38 Roman Shpount We definitely need
RTP and non-RTP at least as data channel replacement

12:00:17