AVTCORE Audio/Video Transport Core Maintenance WG Meeting ==================================================== Date and Time: Thursday, November 16, 2017 - Morning Session I, 09:30 - 10:30+, UTC+08 Room: Orchard 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: Published RFCs: RFC 8269 (was draft-ietf-avtcore-aria-srtp) RFC 8285 (was draft-ietf-avtcore-rfc5285-bis) RFC 8286 (was draft-ietf-avtext-splicing-notification) draft-ietf-avtcore-multi-media-rtp-session draft-ietf-avtcore-rtp-multi-stream-optimisation draft-ietf-avtext-rid [RFC Editor Queue: MISSREF: Bundle] draft-ietf-avtext-lrr-07 [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. draft-ietf-avtcore-mprtp 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 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 is signalled. 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 combinations. 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 do. 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 RTP v3. 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, 10 min) (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 space. 8. Next steps and any other issues - (Chairs, 10:50, 5 min)