AVT Working group, Tuesday July 27th 2010, 17:10-18:10 ======================================= Chairs: Keith Drage, Roni Even Agenda ------ [Slide pack avt-0.pdf] Only slides 1 to 5 presented, rest to be presented in Friday session. Keith presents the agenda for Tuesday and Friday. There were no questions nor comments. MPEG2TS preamble breakout will be Thursday 11:45-12:45 AVT status presentation on Friday. ECN --- Slide pack avt-3.pdf] Colin Perkins presents ECN for RTP over UDP/IP. Relates to draft draft-ietf-avt-ecn-for-rtp-02 [Slide 5, "Fragmentation and Reasembly: RTCP"] Major update of mixers translators section. Personal note: Rescaling of RTCP in transcoders may impact on ConEx functionality (needs a closer look). Question to the group: is scaling the right thing to do? Ingemar Johansson: rescaling could have some impact on the congestion. Colin: that's something we have to check. [Slide 8, "Open Issues and Next Steps"] Quick check revealed 10 or so people had read the draft, and it was expected that the document should be ready for WGLC before the next meeting. Keith: is the new registration table requested from IANA and covering ICE still required, and if so should it be AVT or MMUSIC? Colin: yes, Keith: Should it be in a separate document? Colin: Should be done in this document. Keith will check with MMUSIC chairs and WG that they are OK with this. [Back to slide 5, "Fragmentation and Reasembly: RTCP"] Ali Begen: scaling depends on the pattern you follow for sending the RTP packets in the first place. Bob Briscoe: it seems it is not about the number of bytes, but the number of packets. Should be otherwise, scale according to number of bytes instead. Splicing for MPEG2-TS --------------------- [Slide pack avt-1.pdf] Relates to draft draft-xia-avt-splicing-for-mpeg2ts-ps-01 Ning Zong presents the splicing problem statement [Slide "Potential Solution"] Dave Oran: all the examples are about video, what about the audio? Roni: it is not about the actual splicing. The problem is that you have already the information. Dave: the output stream is totally different from the input. It looks like there's only one splice point, there may be more. Colin: the presentation is ignoring the MPEG2 stuff, just focusing on the RTP packets. Roni: the problem is how do you create the new stream, or you just do the splicing in the initial stream? Dave: this is a solution, not a problem statement. Roni: kind of agree. Dave: is the splicing exceeding SCTE-30 marking? If not, the splicing would be detected anyway. Roni: yes. Dave: understand the problem statement now, which he didn't reading the draft. Jonathan Lennox: you need to rewrite RTP headers forever, without touching the body. [Slide "Next Steps"] Question: do people think there is a problem? Colin: it seems there is a problem. You are changing the number of RTP packets, so the problem is rewriting the headers forever. It's annoying, but it's feasible. The translation is feasible; it may be useful to document how you do that. It is a general problem of inserting an RTP stream to another stream in the middle and can be addressed as a general case and not splicing specific. Bill VerSteeg: the industry is moving to different technology for carrying MPEG2. Question as to whether the draft should be general or specific to the MPEG 2. To be general would need to know the splice points which are different for each encoding. Jonathan: the process could be described as: there is a stream, then something happens -- ADs -- then everything gets back to normal. Dave: you need to know for how long the splice lasts. Keith: Requested authors to please improve the draft in the light of the comments made. In particular the problem statement needs to be made clearer. We will then consider whether to adopt in future. Monitoring Architecture for RTP ------------------------------- [Slidepack avt-2.pdf] Relates to draft draft-hunt-avt-monarch-01 Roni presents about the scope of a monitoring architecture for RTP. [Slide 4, "In more detail (1b) - scope of monarch-00"] Al Morton: you are not going to define all metrics? Colin: initially the problem with metric drafts is that people abandoned metrics that were not reusable. It will be important to find a way to define reusable metrics. Dan Romascanu: instead of speaking of the architecture of the whole building we should speak of the architecture of only one floor. [Slide 7, "Questions"] Question: do we want the narrow scope or the broad scope? Colin: it is a nice draft. Draft -00 is too broad, -01 too narrow. -01 was preferred. Roni: can you send this comment to the list? Dan: Work will be useful. Focus on what you have expertise in. But on the other hand we don't have a generic monitoring architecture in the OPS area. Ali: how much interest there is in this? How many XR are actually used. Roni: it's a chicken and egg. A lot of XR reports are available in draft form, need to decide a way to go forward. Qin Wu: we want an RTCP monitoring architecture. How to report these metrics to the monitoring center is not clear. Liked -00 better because he wanted the full picture. Roni: talk to Dan, may want to use SNMP. Colin: Historically we have bundled too many metrics into a single report. Fine for one application but does not allow reuse. We have not defined application specific metrics. RTP has a monitoring architecture; the point is how to define useful metrics. RFC 1889 provides the monitoring architecture for RTP and this is looking at ways of enhancing. Dan referred to RFC 4710, RFC 4711 and RFC 4712 in the OPS area. Ingemar: in 3GPP there are people working in QoE metrics. Reuse metrics. Keith: is it SA4? Ingemar: not sure. Roni: send comments to the list. Anwar Siddiqui: scope question. Are you going to write a protocol, or just an architecture? Roni: no protocol. Colin: there are protocol pieces in the draft, but it's just about how to use existing protocols. Keith: how many people would be interested in some future conference calls between now and the next IETF meeting to discuss further? 9-10 indicated interest AVT working group Friday July 30th 2010, 09:00 - 11:30 ====================================== Introduction and Status Update ------------------------------ [Slide pack avt-0.pdf] Slide 4 and slide 6 onwards presented. Chairs - Cullen will not be presenting the application-id work WG Status: - 2 RFC's published: 5764 and 5761 - 4 docs in RFC editor queue - 5 docs in IESG processing (some blocked on revised IDs) - 1 document dropped - 3 documents for proto write-up (one completed last night)- new Cisco IPR statement received on SVC - 1 completed WGLC - Several new and existing payload drafts -- need volunteers to review them. Currently only one active reviewer -- Magnus will be back, but not yet. Colin will review MIDI draft. Ingmar: Regarding payload drafts, mainly interesting for authors - difficult to get others to really work on them; would it be okay to just have the template? Roni: basically right - but some people doing their first don't get the structure right, but you also have to look at the content to be sure the content is adequate (though it's very simple in many cases). Colin: might be useful to have a review template, at least for last call review. Roni: We'll look at this. Referred to draft-ietf-avt-rtp-howto. - 3 candidate drafts not yet adopted for WG milestones. 1 draft admitted as a WG item but WG draft not submitted yet. - A selective transmission scheme as individual draft has been submitted; please look at it. - RAMS base document has been submitted for publication. Still need the CNAME port mapping, and RTCP port for SSM since they are companion drafts. - List of other topics (see chair slides) that need prioritization so WG can allocate resources appropriately. Please let chairs know what your preferences are. Ali: Asked for status on multicast acquisition (draft-ietf-avt-multicast-acq-rtcp-xr) has it completed WGLC - is it still ok? Answer: yes Guidelines for Choosing RTCP CNAMEs ----------------------------------- Ali Begen presenting. [Slide pack avt-4.pdf] draft-ietf-avt-rtp-cnames-00 - see Ali's slides for background and problem statement. CNAMEs should be unique within an RTP session; RFC 3550 recommendation for forming them doesn't necessarily accomplish this. - Draft updates the guidelines for CNAMES from RFC3550 - distinguishes persistent CNAMES from per-session CNAMES Jonathan Lennox: What is actual per-session CNAME scope? What about correlating audio/video. Persistent might mean you have the same CNAME over time. Does per-Session apply for multiple simultaneous sessions? Colin Perkins: I believe the draft says per "multimedia session"; you obviously need to use the same CNAME for lipsync. Per-session should say "per multimedia session" so the reader does not get confused about audio/video correlation. Colin Perkins: For each RTP endpoint you didn't necessarily mean that - you mean "everything you want to synchronize with Roni: Still keeping ASCII, we're not changing the RFC3550 structure, right? Ali: Yes - ready for WGLC? Keith: The important question is whether there are open issues. Ingmar: What about if two hosts use the same CNAME? Shared names that come up on satellite, etc. (e.g. cloned MAC addresses) Colin: It breaks in the same way as 3550; don't do that. Roni: Draft won't solve all the problems but will be better than RFC3550, just improves probability that it won't go wrong. Peter Musgrave: Any security concerns on persistent CNAMES? Ali: If you want privacy, use per-session CNAMEs. There is some coverage in the draft. Dave: If you want privacy, use SRTP and encrypt the RTCP. Colin: That does not solve the problem. Stephan: Does this document have to update 3550? Roni: Yes, but it keeps the same structure. Roni: So, ready for WGLC? Stefan Wenger: The correlation with RFC 3550 needs to be dealt with. Roni: Yes, the draft updates RFC 3550. Keith: send email if you don't think it's ready for WGLC, otherwise it's going to happen. RTCP Port for Multicast Sessions -------------------------------- Ali Begen presenting. [Slide pack avt-5.pdf] draft-ietf-avt-rtcp-port-for-ssm-00 - see Ali's slides for problem statement and description of solution. - Two possible issues - soliciting advice Should we mandate the use of the new attribute or keep it optional? If it does not exist, the +1 rule will apply. Jonathan Lennox: what about mandatory vs. optional. Colin: Need to say what happens if it's absent in any case Jonathan Lennox: Updating SSM (RFC 5760)? Ali: Yes Lennox: Then it can be mandatory, otherwise has to be optional Ali: Consensus on this issue to cover optional. Should we allow optional address in the attribute? Any reason why RTCP should be multicast in a different group? a=multicast -rtcp:42000 IN IP4 233.252.0.3 Colin: Nobody has come up with a need in the last 15 years Jonathan Lennox: Probably don't want to do this for ASM. Colin: Should update rtcpssm so people will find it. Ali: Consensus on 2nd question not to include optional address. Roni: Do a small update, and then do WGLC. Any other issues? Colin: This is an SDP draft, needs MMUSIC review. Keith: We'll ask MMUSIC to review it as part of WGLC Keith: Once we get the update we'll do the WGLC and check with MMUSIC about their review. Again if there are other open issues, send email. Port Mapping Between Unicast and Multicast RTP Sessions ------------------------------------------------------- Ali Begen presenting. [Slide pack avt-10.pdf] draft-ietf-avt-ports-for-ucast-mcast-rtp-02 - This was split out of RAMS, it's a normative reference for it, needs to go forward quickly - There are multiple approaches. Had a breakout in Anaheim and some issues came up. - Now there is the WG current draft, an alternative approach, and a third draft as well to consider. - see Ali's slides for problem description and solution based on cookies Open issues discussion: - Which keep-alive method should we choose? Answer: Guidelines for keepalive usage are already with IESG, use them (draft-ietf-avt-app-rtp-keepalive). - Should we stick with 4585 packet format for cookie request and response? (Yes) How do we set the media sender SSRC? Use client’s SSRC in both packet sender and media sender SSRC fields. Ali: Currently documented in draft and same as already specified in RAMS. - Should the client use the same SSRC/CNAME in both sessions so the reports received in two sessions can be linked? (Yes) Colin: If you use the same SSRC, then they become one RTP session and you have no issue. Need to be careful with the terminology. If a single RTP session be sure to say that. - Should the server respond if a cookie request is rejected? (Yes, with an empty Cookie). No comment from working group. - Should the server indicate the expiration date for the Cookie explicitly in the response message? (Yes) Jonathan Lennox: How is time specified for expiration? Are you assuming it uses some notion of current time. Ali: No. Relative time from now. You should refresh your cookie well before the timeout. Token-based Port Mapping (Ali Begen): [Slide pack avt-11.pdf] draft-begen-avt-token-for-portmapping-00 - alternative to cookie approach. Prior solution was to get cookie in advance, but still some people are unhappy; there is overhead. - see Ali's slides for problem description and solution. Bill VerSteeg: Even though I'm a co-author on the cookie draft, likes the token approach better. Token retrieval is done once, based on your IP; valid until the server decides it's invalid. Need only one token no matter how many unicast sessions you want. Colin Perkins: The token validates your public IP address? What happens if your NAT gives you multiple IP addresses (i.e. what about Carrier grade NATs?) Bill Ver Steeg: Carrier Grade NAT is typically between the service-provider's network and the public Internet, whereas this device is typically in the service-provider's network. If that's not true we should fall back to cookies. Colin: if you document those restrictions/assumptions then you're ok Roni: if token is invalid you might send back a different one. Dave: I'm going to argue both sides of the issue. One the one side, it's ugly to have solutions that make topological assumptions. On the other hand, anything that breaks carrier-grade NATs I'm in favor of. Ali: we need to decide whether token has better tradeoffs than cookie, who needs lots of cookies, trimmers, refreshes, etc. Jonathan Lennox: if you're the service provider and deploying servers, you have good topological notion but is it really true that you're behind the Carrier Grade NAT? Colin: It might be possible to unify the solutions; i.e. make the port optional in the cookies, if it's not present it applies to all ports. Combining them is probably not more complicated than either one individually. Ali: Consensus seems to be do the union. Colin: Tastier cookies! Roni: Do we mean that the response has either token or cookie Colin: token+port=cookie Jonathan Lennox: In SDP do you have some notion. Jonathan Lennox: What is the grouping/correlation? Ali: All that share token. Jonathan Lennox: As a client how do I know if an existing token will work with a different server? Do we need an "issuer id"? Is there some way to identify whether two sessions are using the same token? Bill (Eventually): We could add that, we need to think about it Colin: There's nothing RAMS-specific about this; you can write the draft in a simpler way if you don't talk in those terms. Ports on client and server: server ports must be different (to prevent RTCP ambiguity). Roni: Tradeoff with token is that it can be rejected if you send token to the same place. Colin: In SDP put something in - by the way: nothing in here is RAMS-specific. Roni: General to multicast/unicast. Colin: The solution is actually completely general - request a cookie then use a cookie. Can write the draft in a simpler way if you don't' tie it to RAMS, or even multicast/unicast use cases. Jonathan Lennox: On SDP need to be careful about per m= version session-wide. Portmapping-req attribute: must be at media level, not session. Colin: Why not? Jonathan: It would have to apply to every m= line. It clearly doesn't make sense in this case (because you can't have a feedback target for the multicast group) but you can imagine cases where multiple m= lines all have the same token server. Chairs: Hearing that WG support for a combination approach. See on list if this should replace the current WG draft, then write it up if people agree. Jonathan Lennox: Some discomfort on the topological restriction issue. Chairs: Proposed procedure - update the individual draft (and achieve consensus on that) then consensus call to whether to replaced the WG draft with the combined proposal in the individual draft. This approach got WG support. Multipath RTP (MPRTP) --------------------- Joerg Ott presenting. [Slide pack avt-9.pdf] draft-singh-avt-mprtp-00.txt - see Joerg's slides for problem statement and solution - Non-goal: solve the rate adaptation problem Jonathan: But shouldn't we make it possible to use existing rate adaptation solutions. Joerg: Yes; we're looking at TFRC. Colin: Where you have delays and multiple streams, doesn't this complicate the sender scheduling enormously Joerg: Yes. Roni: Are you seeing this as a new RTP profile? Joerg: We're thinking about a new profile, or extension headers; we'd like to avoid the problem of combinatorial explosion of profiles. Roni: Part of it will have to address this specific signaling, how it will work if I don't understand MPRTP signaling. Joerg: Part of it is you need to have an in-band indication if you support MPRTP. You can start off with a single path and add more as needed. Bill: Have you given any thought to the multicast case? Joerg: We didn't want to do everything at once, it should be added in a future revision; the same things should be applicable to SSM, for instance, except you need to figure out how to handle receivers with incompatible capabilities. In-path discovery of support for MPRTP. Prospective spec: interaction with SDP, SIP, RTSP; ICE; in-band mechanisms. Ingemar: Brian Ford was active several years ago with multiple-stream support. On structured stream transport. Joerg: I'm familiar with the work; I didn't think he was doing multiple-path support. I need to go back and look at his work We've been carrying out some experiments, stress-testing multiple receivers. They behave badly. We will need RTP/RTCP extensions for sub-flows, packet allocation, and receiver aggregation. Probably best to define this as a receiver-side spec. Leave the algorithms open. Open questions: does it make sense to think about this in AVT? Colin: in Multipath TCP, you don't care what order things arrive in, as long as it's quickly; for media, you do Joerg: we need to figure out algorithms, scheduling is tricky; canned media can do some scheduling games. Colin: we have things like layered and multiple-description codecs, which can do smart things if they know the multiple paths, to what extent do we want to expose that? Joerg: we're not defining APIs, your implementation can exploit that if it wants, but we don't want to require it. Colin: tries to do some of the things using multiple sessions doe with layered coders etc. should this be exposed to the application . Conclusion: There was interest in the working group in this work but for the moment would progress as an author draft. RTCP XR Report for Real-time Video Quality Monitoring ----------------------------------------------------- Qin Wu presenting. [Slide pack avt-6.pdf] draft-wu-avt-rtcp-xr-quality-monitoring-00 - see slides for problem description and solution Want measures for video quality for operator; RFC 3611 doesn't define any such metrics. Network-dependent factors that affect RTP streams uniformly aren't enough to measure video quality. Drive for this comes from operators: diagnose problems, root cause analysis, and validate SLA compliance. Network-dependent metrics (packet loss, delay, jitter) don't completely capture video QoE. Proposal: six new report blocks: RTP flow sync, A/V sync, summary metrics Request for WG item. Keith: Need to discus where this goes in the priority queue. Colin: Metrics are good. At some point someone in the IETF should do video metrics; these seem like a plausible set of metrics (though I'm not an expert), we can quibble about details I'm sure. Specifc points - to perceptual quality there are lots of candidates and be clear which one you are really using. you have to be careful how you name them and be specific about what you measure. Also need to decide if this goes in the old architecture or if we do this like the monarch draft. This seems to follow RFC 3611, not monarch. But this seems like a plausible starting point for video metrics. Qin: Yes perceptual metrics need more definition and input from SG 12 in ITU-T. For monitoring architecture scope is not clear. Believes this draft follows. Roland Schott: Good idea to do this but some concerns on scalability for multicast. We need to do multicast monitoring. Metric should be in line with standards for monitoring systems. Roni: Supports what Colin said. Prior work focused on MPEG2. Need something general Values should be based on standards from other standards bodies. Bill Ver Steeg: A lot of this looks good; we may be looking too deeply into the protocol, and we need to separate stuff that's normally in the clear from stuff that's normally encrypted Some of this might be looking really deeply into the media - what about crypto. Dave Oran: This is endpoint monitoring - can be done after decryption in cases that it needs to look at media. Bill: In a set-top box, it's hard to get at the encrypted stuff. Dave: It's hard in general. Ali: What happened to similar draft by Alan Clark from before. Why was it killed? Roni: it wasn't killed, but it was told to be less MPEG-2 specific. Colin: Prior work was all jumbled. We've been around this area in the past; these drafts mix metrics, e.g. I-frames, jitter buffers, packet loss. Monitoring architecture gives guidance on how things can be combined. I think that's why the previous work didn't go forward; we were trying to work out how to do that. Keith: Before we do this, we need to work out the monitoring architecture. Roni: And the prioritizing of the work. Keith: No new milestones at the moment. RTCP Receiver Report for Feedback Storm Suppression --------------------------------------------------- Qin Wu presenting. [Slide pack avt-7.pdf] draft-wu-avt-retransmission-supression-rtp-02 - see slides - first time to present in AVT - second version of draft. Want to provide RTCP receiver report to prevent massive NACK/FIR implosion. No NACK suppression in the SSM scenario. Problem: packet loss in upstream link of distribution source. Proposal: define new RTCP messages to handle this behavior. Request to accept draft as WG item; encourage more review of draft and feedback Dave Oran: Seems reasonable work has my support. I think this is pretty good stuff; there's some stuff in the draft about scenarios and use cases that are less persuasive, but others are more persuasive. I've already built the hack version that the draft thinks is a bad idea. In the draft as currently written, there is nothing that trips over my IPR, but I'll work with the authors to avoid my IPR, or if we want those functions we'll file an appropriate IPR disclosure. Colin: I've read this draft, Seems reasonable. Bill: I read the draft, it's going down the right path, there are nits we can pick at but we can discuss this on the list. Roni: We should do another revision of this draft, and then decide whether to take it as a WG item based on priority of other items. Keith: The fundamental question is if we want to do this work. (Show of hands: some interest in the work, none opposed. Judged as working consensus for support but significant portion of don't-cares. Chairs: Need to work to get a milestone. Seems there is WG support for this. Will not adopt the draft yet. Dave: I said on the list, I'm willing to help on getting this draft through. Extended Rapid Acquisition of Multicast RTP Sessions ---------------------------------------------------- Ingemar Johansson presenting. [Slide pack avt-7.pdf] draft-johansson-avt-mcast-based-rams-03 - see slides for problem description and mechanism. Proposal based on 3 weeks of measurement from (non-RAMS-enabled) Swedish IPTV network. Number of zappings per minute: 350 users, in some cases you get 70 zappings per minute to the same channel. Ali: We need to know whether they're changing within the same several hundred milliseconds. Ingemar: Some of my colleagues have that data. Many users change channels at the same time (add breaks, end of programs), peak between 7 PM - 11 PM, change channel many times in short periods. Dave: When you do this, you need to know how many are DVRs -- DVRs don't need rapid channel change. Ingemar: This data is only set top boxes. Proposed extension to RAMS: 3xx redirect extension, two new TLV fields for RAMS-R and RAMS-I, carrying information for multicast group to tune in to. Fast channel-change server uses RAMS unicast when request rate is low, switch to ERAMS when request rate is high. Peak load goes down in proportion to number of users that share the same ERAMS group. Provide graceful degradation under load. Request for this to be a WG item. Ali: Need finer grained distributions. Bill VerSteeg: We discussed it this morning; I found the analysis fascinating and spot-on from a technical and theoretical standpoint, we need to analyze existing systems, I've rarely found more than 7-8 users that hit the same channel within the same few hundred milliseconds. I'm not sure this applicable to today's deployments. Colin: There was a paper in IMC a few years back analyzing channel-change behavior for a quarter-million households, I believe the data set is available (Telefonica). Bill: I'll put that link to the list. Keith: would this be informational or proposed standard? Ingemar: It would need to be standards track. Defines a protocol. Roni: I think we need more analysis of user behavior from the references we got, to see if it makes sense and the uses cases. It sounds like people think the technical topic is interesting, but they need more input about usefulness. Keith: We need to figure out where this fits in our priorities -- suggest carrying on with it as an author draft, taking this input. MPEG2-TS preamble discussion ---------------------------- draft-begen-avt-rtp-mpeg2ts-preamble-05 draft-xia-avt-mpeg2ts-preamble-02 Keith returned to the subject of the MPEG2-TS preamble to get some feedback from the working group. MPEG2-TS breakout didn't form any conclusions. Appeared only about 50% of those present had read the two drafts. Ingemar: I've read the draft, but have no experience of the actual hardware limitations. Have people seen enough technical information to make a decision, or do they want more technical information? Roni: There's a difference between what's written on the draft, and the discussion on the list. Hands: Very few either in terms of seen enough for a decision or want more technical discussion. Keith: no consensus; it's your responsibility as members of the IETF to decide what's the best forward for the Internet, and you must all form an opinion on the best way forward. (Note discussions on list are raising comments that would appear to justify a revision of both drafts.) Close of meeting, unless there's anything else anyone wants to raise.