Audio/Video Transport Core Maintenance (AVTCore) Working Group Minutes IETF 82 Chairs: Magnus Westerlund Roni Even Note Takers: Al Morton AVTCore Status Update These are the minutes for the AVTCore WG. The WG has published 2 RFCs, Currently, two document are in IESG processing (draft-ietf-avt-srtp-non- mandatory, draft-ietf-avtcore-srtp-vb-audio) Colin: There were a bunch of comments, this is going to be discussed in the security area meeting. Roni presents the milestone review (milestones need to be updated) ECN for RTP over UDP presented by Collin Perkins (draft-ietf-avtcore-ecn-for-rtp-05) There was a WGLC on 04 version. New version 05 has been submitted to address the issues brought up. Two open issues remain: 1. ECN interaction with ICE Colin presents the process to check for ECT capable path using ICE. In some cases these steps can add additional setup time, which is undesirable. He proposes a method in which, once the call has been answered, media should be sent without ECN once the normal ICE exchange has been completeed. Alternatively, once STUN has verified then ECN is enabled. Jonathan Lennox: I like this approach. 2. Support for Multicast - ECN required for ALL receivers or none falling back to non-ECN does not scale for large groups, Bill Ver Steeg rasied the concern that this is conservative. With a large group, the chance of one rceiver not supporting ECN is quite large. Colin is aware of the problem, says that it is a fariness issue. He proposes to add a note to the draft identifying this problem and the fairness issue. He invites others to experiment with ECN for large groups. He does not want to hold up the draft for just this issue. Next steps: WGLC of new version -06 once open issues have been solved and new version submitted. Jonathan: There were some other minor issues, I think we should discuss offline RTCP Extension for Feedback Suppression Indication presented by Qin Wu (draft-ietf-avtcore-feedback-supression-rtp-08) All changes since 05 version were editoirial. One open issue discussed on the list is the Second Loss issue: When a receiver gets a TPLR message, expecting a retransmission packet which gets lost from DS/Media Srouce. Is it then relevant to ask for retransmission? And if so, which RTT should be used for timeout? Qin presents two options to solve this issue. Either to create a new report block to carry RTT3, or to use the solution currently desribed in draft. Colin: doing this with timers and RTT sounds wrong. Why not just treat TPLR just as you treat any other packet? Jorg Ott: You are creating an overlay between different RTP entities, which is solved in another draft. Magnus: (as individual): I agree, for this draft it is ok to just surpress this one. We can solve this issue in the future. Roni: So we are going the way proposed by Magnus. Deal with TPLR the same way as NACK and look at timer solution in long term No comments from room Monitoring Architecture for RTP presented by Qin Wu (draft-ietf-avtcore-monarch-06) Qin Wu presenting overview and change history of document, there were three updates since IETF81. Issues from the list: 1. Is there a secturity issue with monitoring? The security section says that it introduces no secutiry vulnerabilities beyond those descibred in 3611. There are issues with monitoring: Forwaring monitor reports to translaters presents risk. Third party monitors present risk Colin: I agree that forwaring monitor repors is a leak, might not be risk. Why just translators? Qin: Agree, not limited to translators, will revise text. 2. There has been a suggestion to add definitions for additional terms. Qin finds this request to be reasonable and proposes a number of definition (looking for feedback) Magnus: I think the term Sample Metrics is a bad name. Too easy to confuse with something that is an example Qin proposes to start WGLC Magnus: from my perspective, it seems ready. Any comments? Roni: the new version is quite recent, please review it. RTCP for inter-destination media synchronization presented by Ray van Brandenburg (draft-ietf-avtcore-idms-02) Recent work on the draft was to broadened scope to include Video walls, Networked speakers and Phased array transducers. Increased presentation timestamp to 64 bits. Cullen: What level of precision is needed? Aiden Williams: phased arrays need sub-millisecond accuracy to do beam steering, need 64 bits for sufficient accuracy in timestamp, previous references on the list. Need one-way delay for sync, how to get it? RTT/2 will not work. Three options have been proposed –Use existing IDMS reports before streaming starts –Start streaming with null data and use existing IDMS reports –Create new XR block to report on one-way (sender->receiver) delay Proposal 1 - Collin says IDMS report before streaming will not work different timing for data packets than for media packets. RTCP timing rules don't allow it. Prioritization of packets will distort timing measurement. Proposal 2 - start streaming RTP packets with Null media. Collin - is it necessary to send null media? just send media and its out of sync. Aiden Williams says need synchronization for quick switching (eg 10 ms) applications. Proposal 3 - doesn't solve the clock sync problem, but new XR block for one-way delay Collin - the sync problem is more general, Clock synchronization might be worth a separate draft since it's a general problem. Aiden Williams: Take timing out of this draft and make a separate one. RTP Multiplexing Architecture presented by Collin Perkins (draft-westerlund-avtcore-multiplex-architecture-00) Colin presents the rationale for this draft. Early implementations of RTP made extensive use of the group-based features of RTP. More recent VOIP and conferencing systems did not do much in the area of group-communication. Even more recently, work on e.g. RTCWEB/Clue, has rekindled interest in these features. This draft provides guidance on how to do this. Colin presents number of issues: RTP Multiplexing points for multiple streams RTP topologies and resulting issues When to use multiple SSRC in a single session versus when to use multiple sessions The draft proposes a number of general guidelines RTCWEB and CLUE are looking at this, but not exactly this model, may be controversial (Mary Barnes got this clarification) Cullen: We already talked about this in the last meeting. There seemed to be consesus. You might not like this consensus. To me the purpose of this is not clear. Colin: This is a very broad topic, there is not a single use case Cullen: We already discussed this. People are not buying it. What are we going to do with that discussion? Colin: We can argue about the details of the recommendations. What we are discussing now, is whether there is a purpose to having such a document Harald: I have two problems with draft. 1) a lot of text spent on kicking in open doors. 2) The draft walks a very tight line between giving recommendations and specifying them. The authors of this draft seem to dictate them. A lot of this stuff should be left to the implementation. Colin: We shouldn't be discussing specific of these recommendation. We should be discussing whether we should be making recommendations Ted: The way this is constructed is not helping us. Last time we talked about a quick short-term solution and then a well thought- out long-term solution. This draft does not seem like this long-term solution. Cullen: Current draft is not usable advice Magnus: Thanks for feedback. Please point to specific section with which you disagree. It is a large document, please be clearer. (not sure who): I agree with Cullen. Please state pro/cons for each approach, instead of (dictating) a certain approach. Harald: I don't like a draft that says 'thou shallt not..' Jon: I don't think a topic like this warrants a milestone. It just adds to confusion. Maybe we shouldn't do this. Collin - maybe we need an issues draft, maybe the editor should be from EITHER camp. Roni: Continue discussion on the list Multiple RTP Sessions on a Single Lower-Layer Transport presented by Magnus Westerlund (draft-westerlund-avtcore-transport-multiplexing-01) Reason for multiplexing flows in single sessions is NATs. Additional delay for each NAT traversal, risk of failure, etc. The problem this draft is trying to solve is enabling applications to select between using multiple sessions and not having to pay extra cost of transport differentation. Does the WG believe the problem of solving multiple RTP sessions over a single transport flow should be solved? Cullen: Same as last meeting. Why are we posing the same questions again? Colin: If I undestand consensus from last time, it was that we should go ahead and propose something The draft gives requirements, evaluate solutions and provides recommendations. Magnus presents list of requirements Matthew Kaufman: Most of these problems with RTP are the result of its multicast origins. Why not remove Multicast requirement? Colin: Matthew, what would you remove then? Matthew: There are problems unique to specific multicast topologies Jonathan: Some networks treat RTP different than other protocols. That implies DPI(Deep Packet Inspection). Why not add a requirement to not break DPI? Stephan: Magnus, can you repeat what you mean by incremental deployment Magnus: You want to be able to use both types concurrently, so multiple sessions as well as single session. Cullen: I don't mind reusing bits as long as we don't break deployments. Why do we need a requirement saying 'Enable same SSRC in multiple RTP sessions?' Magnus: you might not use them, but some people do Cullen: We should go through each extension to see whether it is used. Cullen: Add requirement: don't use more bandwidth than required Harald; I would like to reformulate req 3: "don't create new security risks" Hadriel: Not every extension will make use of this. So incompatibility might not be a problem. Fallback solutions are always possible. Mathew: Because this is just an optimization for a certain scenario,do not care for requirements 2, 3, 6, 7, breaking some stuff is not important. You can simply choose not to use these optimizations (not sure): How do we make sure that this remains an optimization. And not default behaviour in a few years time? Colin: If you want to define a new RTP, ok go ahead. But if we want to optimize RTP, then we should at least try to be compatible. Magnus: I repeat, this is just one way. Not THE way. Magnus presents a solution/requirement matrix. Cullen: I don't agree with a lot of this. lets examine mux shim, green in block 8, it can't be right Magnus: the consensus in Quebec was to do both: single sessions and multiple sessions on single transport flow. Is this still true? Do we really need both? Ted: This question is better answered after Jonathan's presentation Authors recommend a solution based on Multiplexing Shim, AND single session proposal in Jonathan Lennox presentation. Harald: The good thing about multiple solutions, is that I can choose the one I like. Multiple RTP Session on a Single Lower-Layer Transport, part 2 Jonathan Lennox presenting (draft-lennox-rtcweb-rtp-media-type-mux-00). We want to be able to send RTP sources of multiple media types over a single transport flow for the reasons Magnus has mentioned Saying we want to send multiple RTP sessions is assuming the solution. Just send sources of multiple media types in one media session. No new RTP-level standardization work needed (just ignore one SHOULD in RFC 3550). The SDP-level standardization work is roughly equivalent for every transport mechanism. The BUNDLE group semantics is probably the right approach, unless we want to jettison backward compatibility. Propose to not support pure-transport translation between multiplexed and non multiplexed streams. Jonathan: Above assumes multi-point. Colin: You seem to be requiring a very complicated middle-box. You may want to support very simple middle-boxes and then fix the signalling. Jonathan: self-reporting and cross-reporting are only useful for pure-transport translations. This is not specific to media type muxing, so probably should be in seperate draft Magnus: Let's take this discussion offline Roni: Let's go back to Magnus' question on whether to do both approaches or just one. Hadriel: I need more input Harald: When we have two video streams arriving at one destination, no matter how they are packaged, we need to know which is which. That is independent of whether they are in a single session or not. Roni: We'll take Magnus' question to the list. Cullen: How many people are interested in this? (about 20 people raise hands) Cullen: I want to see at least 20 people comment on this on the list before we call consensus. Roni: Noted. Duplicating RTP Streams, Collin Perkins presented for Ali Begen (draft-begen-avtcore-rtp-duplication-00) Packet loss is unavoidable (e.g. congestion, outages). A redundant stream can carray FEC-like data or packet duplicates. This document explains how RTP streams are to be duplicated without breaking RTP/RTCP rules Colin presents a number of different scenarios (temporal vs. spatial, merging at receiver vs. merging in network) and some recommendations on how to deal with them. Colin: For time-shifted redundancy case, open issue is how we should correlate duplicate streams Jonathan: There seem to be a few cases where you need to see difference between oringial packet and duplicate. But not in all cases. Magnus' proposal for single sessions can't make that distinction. Is that important? Colin presents open issues: How to correlate streams? Can we use standard RTP synchronization? Or timestamp alignment? How do RTCP reports work in case of network merging? Network stream merging - Harald - asks clarification - if loss, then RTP translator has to be able to create packets, so needs security key. Hadriel- re-ordering problem with original stream loss - Colin - need to reconstruct timing to avoid this Colin: Is there interest in pursuing this work in AVTCORE? Jonathan: Why is this in AVTcore and not in AVText? Hadriel: Most of the time packet loss is due to congestion. So you're only making the problem worse by duplicating packets Dave: In the temporal case, you have different routing you can have lossless if the time offset is greater than the route convergence time at the cost of twice the bandwidth. In the case of spatial redundnacy, you might have different network planes. Hadriel: is that a realistic scenario? That clients have control over the network route? Dave Oran - can send over parallel network planes - Cisco is shipping this.Can't discuss further. Multipath RTP (draft-singh-avt-mprtp-03) was not presented since we ran out of time.