Minutes IETF100: avtcore
Audio/Video Transport Core Maintenance
||Minutes IETF100: avtcore
AVTCORE Audio/Video Transport Core Maintenance WG Meeting
Date and Time: Thursday, November 16, 2017 - Morning Session I, 09:30 - 10:30+,
Chairs: Jonathan Lennox / Rachel Huang
1. Note Well, Note Takers, Agenda Bashing - (Chairs, 09:30, 5 min)
Jabber Scribe: Brian Rosen
Note taker: Magnus Westerlund
2. WG Status - (Chairs, 09:35, 10 min)
Status of working group documents:
RFC 8269 (was draft-ietf-avtcore-aria-srtp)
RFC 8285 (was draft-ietf-avtcore-rfc5285-bis)
RFC 8286 (was draft-ietf-avtext-splicing-notification)
[RFC Editor Queue: MISSREF: Bundle]
[RFC Editor Queue: MISSREF: Frame marking]
WG chairs going through agenda.
Roni Even, noted that in Payload WG, the Flexible FEC draft will start WG
last call in the near future.
Adam noted that Flex FEC is part of Cluster 238.
Joerg Ott was planning to do something, but not clear when. The
milestone is a long time past. Discussion if it is time to kill the
milestone. Ben Campbell (AD) wanted to know why the milestone should
not be killed?
draft-ietf-avtcore-multiplex-guidelines resurrected. Major editorial
changes. Next step is to update the document to address open editorial
issues. Mo Zanaty volunteered to review.
3. RTCP Feedback for Congestion Control (Colin Perkins, 10:05, 10 min)
Magnus Westerlund commented that there is a need for more text regarding
when to send the feedback message. For example if no RTP packets are
received, do you send any Feedback? Discussion of relation with
congestion control documents. Mo Zanaty agreed that more practical
information is needed,. considering intervals for feedback interval.
Colin thinks regular RTCP configuration is sufficient. Jonathan (as
individual) commented that This document plus the RTP specification
should be sufficient for an receiver implementor. The sender side will
need also the RMCAT guidance for a specific algorithm. Will a receiver be
expected to send always early feedback, to send as often as you can.
Roni Even asked about ECN. Zahed answered that it depends on the
congestion control algorithm if they have response. Harald commented that
RMCAT is about delayed based CC, all other information is fallback.
Jonathan asked if there are overlapp in information. Colin maybe note
that what has overlap. But in the end a implementation needs to do what
Jonathan noted that there may be important semantic differences that need
to be noted.
Jonathan (as chair) noted that we like to have some implementation
experience with the feedback messages before requesting publication.
Colin (as RMCAT WG chair) agreed that we like to have experience with at
least one CC candidate.
4. Frame Marking RTP Header Extension (Mo Zanaty, 09:45, 20 min)
Bernard Aboba asked that there was an issue when one had two or more
layers. In that context the I/B bit didn't really work. Mo, going through
change to see if that has resolved the issue.
Jonathan (as individual) in the context of LRR, while this constrain all
layers. Mo, no one could have higher layer that is not independent due to
high encoding cost, where base layer is Intra coded.
Bernard, jonathan you had case in your document of a temporal nested
case. Does these work with these changes. Yes, for the particular case
with 2 or more spatial layers, the switching up points would be marked.
Mo, there should be no restriction for practical useful layer
All issues should be resolved. Authors thinks it is ready for WG last
call. Bernard agreed that issues are resolved. Jonathan (as chair) lets
see what the WG says about Roni's proposal. But otherwise we continue to
a WG last call. Roni, noted that the Frame Priority do not block
progress. The Frame priority is an extension to this document.
5. Frame Priority Marking RTP Header Extension (Roni Even, 10:15, 10 min)
Jonathan (as individual) asked what is the difference between temporal
scalability and frame priority. Not the same use case.
Mo noted that this priority frame marking is not really targeting
artifact free decoding, only minimizing artifacts. Frame marking, has a
Discard bit, that is only for packet that will not effect the future
dimensioning. Roni stated that they attempted to use this in their
residential gateways. Targeting WIFI limitations and more streaming use
cases than conference.
Roni thinks there are no need to signal this as it is has backwards
compability. Mo: may violate MUST in frame marking draft. Jonathan noted
that frame marking should say MUST set to 00, receiver MUST ignore.
Jonathan would prefer signalling to indicate this.
Stephan Wenger noted that this is an old idea. There was an argument in
H.264 standardization that assigning specific meaning to the priority
levels. It is an encoder choice on how much impact a particular priority
level results in.
Jonathan (as chair) asking if this is something is interested in? Stephan
Wenger noted no real interest, but also not disinterest. The cost appears
to be the loss of the two bits. Mo, he resisted this in frame marking
draft, in the expectation that it would take to define how the sender is
setting the priority. If one is not defining setting the priority then
the usability of this is less. The middlebox will not be able to
determine the impact of dropping of a given priority. Colin, we should
define how the sender will priority, so that the middlebox knows what to
Delay decision of adopting until frame marking is done.
6. Quic Multiplexing with RTP (Colin Perkins, 10:25, 15 min)
Colin Perkins presenting the goals of ensuring that QUIC can be
multiplexed with STUN to enable Peer-To-Peer usage. Also interest be run
as part of WebRTC as replacment for the data channel.
Presenting the Option 5 that is the result of off-line discussion. Magnus
noted that there is an assumption of not needing connection in
Peer-to-peer use case. Mo noted that this is precluding us ever defining
Mo wondered if we are not creating a lot of different variants that will
exist in parallel. Colin, yes, this change of QUIC is short term to
ensure that STUN works. Long term we may have RTP in QUIC.
Harald noted that we likely need to update 7983, to ensure that the next
people that would like to fit are given the correct information. Colin
thinks this is a more complex matter. Especially as QUIC are likely to
want to use the full byte for QUIC.
Xavier Marjou do you have use case. Colin, noted that QUIC is a general
purpose transport protocol, so all possible applications are possible.
Adam Roach (as individual) it is reasonable to engineer so that it work
for STUN. Doing it for all is nuts. Colin protests that is one additional
change between. Adam noted that there are additional restrictions. Yes,
single connection. Colin noted that when there are enough packet types
defined, we are likely moved RTP inside of QUIC. Thus, alternatives exist.
Roni Even, I care about RTP co-existance with QUIC.
Nils Ohlm a second question will we get new protocols. Harald noted that
they have QUIC as data channel for WebRTC as running code. They don't
want wait until QUIC v2. So we need this.
Magnus noted that to actually preserve QUIC short packets from colliding
with STUN also that packet type filed should count down. The reason might
be middleboxes that run STUN to not have to bind all incoming flows to
remote IP + port after connection establishment, assuming not having
multiple QUIC connection with the same peer.
Discussion if and where RFC 7983 bis would be done. Not urgent.
7. RTCP XR Block for Effective Loss Index Reporting (Hui Zheng (Marvin), 10:40,
(On behalf of XRBlock)
Qin Wu presenting. Chairs noted this is for XRBLOCK WG so no consensus
can be determined.
Magnus Westerlund asked if this was a new metric or an established one.
It is a new one.
Colin commented that this fits the architecture and there is plenty of
8. Next steps and any other issues - (Chairs, 10:50, 5 min)