Audio/Video Transport Core Maintenance (avtcore) Working Group ====================================================== CHAIRS: Jonathan Lennox Rachel Huang AGENDA Thursday, 22 March 2018 at 13:30-14:15 (Park Suite) ------------------------------------------------- 1. Note Well, Note Takers, Agenda Bashing - (Chairs, 13:30, 5 min) Note takers: Bo Burman, Bernard Aboba Jabber: Magnus Westerlund Status of working group drafts: draft-ietf-avtcore-multi-media-rtp-session-13 draft-ietf-avtcore-rtp-multi-stream-optimisation-12 draft-ietf-avtext-rid-09 draft-ietf-avtext-lrr-07 [RFC Editor Queue: MISSREF: Bundle] draft-ietf-avtcore-mprtp (expired) Jonathan: Suggest taking it off the milestones Bernard: Don't think that we have an option. Part of the issue is that this is not only multi-path RTP, it is multi-path ICE. Colin: These are presumably separable parts, but you need both. Jonathan: As individual I think it would make sense to take multi-path ICE to either ice or dispatch WG Ben (as AD): IETF is contribution-driven. Bernard: If you don't charter it to be successful, it will not be. Ben (as AD): Would not object to any multi-path contribution. Colin: Think the suggestion is to drop it unless someone brings more work. Jonathan: Will bring this decision to the list. Encourage to do appropriate work. draft-ietf-avtcore-multiplex-guidelines Colin: That work stalled. Roni decided it was important, but then it stalled again. Not sure there is real value. Roni: Volunteered to do it and will continue with that. Magnus: There was an update before last meeting, but more editing is needed. draft-ietf-avtext-framemarking-06 Mo: There were some comments, mostly editorial. Didn't see a hard need to do something differently or specify in a certain way. Jonathan: I think as receiver you need to know. Mo: We can add some clarification text. For the I bit, do you want to prohibit I bit on layers when base layers have it. The conclusion was that it is per layer. Will add clarifying text why things can be one way or the other. There is also a new IPR declaration with FRAND terms. Ben: Please see to that the IPR disclosure gets to the list. 2. RMCAT Feedback Message Work Status (Colin Perkins, 13:35, 20 min) draft-ietf-avtcore-cc-feedback-message-01 Colin: Any concerns with using 1/1024 of a second for Arrival Time? Jonathan (as individual): Could you get rounding errors, e.g. when comparing to send times that could typically be in microsecoonds? Colin: Probably, but may not be significant. Jonathan (as individual): What if you have reordering on the wire, could you derive "later" from RTCP? Colin: Tend to think it is not worth it because it would be too late for congestion control to work with it. Jonathan (as individual): What if something has been off for a long time, what to do when it comes back? Colin: Suspect that is ambiguous and would have to be clarified. Jonathan (as individual): You should send feedback for every source that supports congestion control; how do you know? Colin: Suspect that there would be parameters in SDP, but that is probably all we need. We will need to specify some signaling, but the rest would be congestion control algorithms. Jonathan: Can anyone volunteer? Harald, Bernard and Magnus volunteers. Zahed: We have a github if anyone wants to provide editorials. Can send link to the list. Jonathan: Bring any technical issues to the list. Harald: Hope we can have WGLC before IETF 102. 3. Frame Priority Marking RTP Header Extension (Roni Even, 13:55, 15 min) draft-even-avtcore-priority-markings-01 Roni: Have tested it in WiFi routers and it provides good results for non-scalable streams. Colin: No objection to opt in the work. The issue has been how you do the marking. Have not seen anything in the draft how you consider doing that. Roni: It marks within a single stream. Colin: Don't think that works. Which marking is which priority, if you have equipment from different vendors. Roni: Marking is done by the encoder. Jonathan: What would be the typical ratios of how much is marked and how much is not? Magnus proxying for Tom Petersen from Jabber: Should the spec consider streams that may have FEC or is it out of scope? Roni: You can probably use it to mark the FEC stream too. Bernard: FEC is typically hop-by-hop, so a middlebox would not forward it but re-create it. Probably not so frequently implemented by the video people I know. Jonathan: Streaming ecosystem is different. Mo: This can applied to video, audio or FEC if it is inband FEC. Jonathan: Is there interest? Mo: Have no objection, but there is coupling between components and it could be hard to standardize the understanding needed to set good percentages for marking. Not clear to an arbitrary vendor or receiver what to mark. Jonathan: If a receiver could specify the expected marking ratios, would that help? Mo: If there is no coupling between sender and receiver, don't see how it could work. 4. Next steps and open mic - (Chairs, 14:10, 5 min) No topics.