Minutes for XRBLOCK ======================================================================== Agenda IETF 86, Orlando, FL 1510-1710 TUHURDAY, March 14, 2013. Note taker: Alan Clark, Varun Singh and Kevin Gross (Thank You!) ------------------------------------------------------------------------ ** Action Items ******************************************************** Use of RFC6390 template Dan: Need to define, create Instructions, comprehensive guidance of what a new metric is. (Who, When and Where) RTCP XR Report Blocks for Synchronization Delay and Offset Chair: Moderate a discussion to find a way forward for the draft (Either splitting it or keeping it as a single draft with limited scope). RTCP XR Report Block for Jitter Buffer Author / Kevin: discuss the definition of jitter buffer operation. RTCP XR Report Blocks for for Concealment metrics Author: Discuss on the list whether "enhanced" is the appropriate name, if not come up with name that WG agrees on. Chairs: When ready take the draft through WGLC. Update on discussions about RTCP-XR metrics in RTCWEB WG: Interested in creating a draft listing userful / relevant metrics for end-to-end communication. ####################################################################### Note Well, Note Takers, Jabber Scribes, Agenda Bashing, WG Status Update Presenter: Chairs ----------------------------------------------------------------------- - No agenda bashing. - Dan reminded authors it was essential to respond to requests for IPR disclosure promptly ####################################################################### Use of RFC 6390 templates for XRBLOCK documents Presenter : Benoit Clare Reference : RFC6390 ----------------------------------------------------------------------- Overview - Need to have consistent metrics. - Collector needs consistent semantics. - Needs to cross-correlate metrics across working groups and areas. - Need to consider using the template in RFC6390 Guidelines when considering new performance metrics development. - All drafts from XRBLOCK will go through SDP directorate and Performance Management Directorate. Section 5.4.4 - aspects of each measurement Simple exercise to match RFC6390 guidance to XRBLOCK drafts Dan: We don't need to reformat already-defined references. Must use it for new references. Some are in the middle - reusing existing references. Roni: We use RFC3611 IANA registry. Will there be a central registry? Benoit: We will search for all performance metrics. Someday, not immediately, we will have a registry. We may start with a wiki. Collin: Support templates, good and important. Surprised it is being imposed as a DISCUSS. Procedurally flawed. Benoit: I agree it is late and that we will have a transition problem but we know where we want to go. Glen: When did we make this agreement? Benoit: A few months ago. Glen: It is not late. What makes a metric new? We need a definition. Benoit: If anything semantic in the normative part of the draft change, it is a new metric. Alan Clark: Key criteria is that we should not be redefining a metric that is already defined in another standard as this could lead to confusion and inconsistency. Benoit: Agreed. Roni: Are we going to have some guidance on how to do this? Dan: Yes. Roni: There are normative and informative parts. Which are necessary? Dan: Only normative but not final on that. I-D on summary-statistics to be reviewed by author and Benoit Friday morning. Benoit: there is some osmosis between standard organizations, ITU-T is starting to refer to RFC6390 ####################################################################### RTCP XR Report Blocks for Synchronization Delay and Offset Presenter : Rachel Huang Draft : draft-ietf-xrblock-rtcp-xr-synchronization-02.txt ----------------------------------------------------------------------- Dan: Do we need a second WGLC? Rachel: Yes Colin: Limiting to one RTP session makes it useless to today's typical case with audio and video are run separately. Useful only for new webRTC. Another alternative is to tie into bundle but we don't know when that will be ready. Dan: We need to change the scope of the document. Colin: Initial synchronization delay metric (half of the draft) is unaffected. Question is, is webRTC going to be the dominant approach? Qin: Adding an identifier may be difficult. Glen: I like the idea of splitting into two documents. Shida: We'll take this decision to the list. Dan: Rough consensus in room to split document. Colin: limit the scope and just do approach 1 or split the draft and wait for the MSID to resolve to pursue the second approach. Qin: It may not make sense for multiplex. We need to analyze this Jonathan Lennox: Maybe instead of using SSRC, use CNAME or something else to implicitly refer to media streams. Dan (as individual): Will be confusing to keep document as it is with two metrics each with a different scope. Prefer to split the documents. Glen - If what Colin says is right, and adopting single session would be useless Colin - would be ok for some emerging approaches that multiplex audio and video into a single RTP session (RTCweb) Dan: The proposal on splitting the documents will be taken to the list. ####################################################################### RTCP XR Report Block for Jitter Buffer Presenter: Qin Wu Draft: draft-ietf-xrblock-rtcp-xr-jb-08.txt ----------------------------------------------------------------------- Document has been edited to provide a clear description of jitter buffer operation. Defines "expected arrival time" and "nominal delay". Kevin: I have sent a proposal to the list. Dan: Can we go over the proposal after the meeting and make sure all is fine? Qin, Alan: Yes Dan: WGLC can be run after the revised I-D is submitted. ####################################################################### RTCP XR Report Blocks for QoE Presenter: Glen Zorn Draft: draft-ietf-xrblock-rtcp-xr-qoe-06.txt ----------------------------------------------------------------------- Glen: outlined draft. There had been discussion on whether to use IANA registry with separate values for each MOS calculation algorithm or to use SDP to indicate the algorithm type and put a single parameter into the IANA registry - SDP signaling has been extended to allow the indication of a calculation ID. Described three offer-answer usages Is "direction" attribute in SDP used to indicate media stream or RTCP direction. Colin: This approach seems reasonable. Needs to be reviewed by an SDP expert. ####################################################################### RTCP XR Report Blocks for Concealment metrics Presenter: Clare Bi Draft: draft-ietf-xrblock-rtcp-xr-loss-conceal-04 ----------------------------------------------------------------------- Clare: Explained that merged consecutive seconds draft with this draft but video loss concealment in a separate draft. Dan: Is there someone working on the second draft? (video loss concealment) Qin: We decided at the last meeting to split some material into a second draft. There was material from the current draft but that the video draft had not been started. Claire : Issue [ definition of "Enhanced" vs simpler methods. ] Alan: Original idea behind enhanced. Predict what was in the missing packet. This was difficult previously and is now more common. G.711 includes this capability Paul Covedale: What's called enhanced here are today's basic techniques. Alan: Discussion started with RFC3611 Paul: Are metrics independent of PLC Alan: Trying to express effectiveness of PLC. May be better of with silence insertion for non-speech. Paul: Need to have a subjective measurement of PLC performance Dan: I don't know if we got a conclusion from this discussion Paul: Do you have a basic definition to go with enhanced definition? Dan: Paul, can you suggest some wording to the draft Colin: Silence insertion is basic. Enhanced is anything else. Colin: The definition is clear. We can argue whether "enhanced" is the right word. We should pick a different word. Dan: How close are we to completion? Qin: We close this issue and then it is ready for WGLC in two weeks. ####################################################################### Update on discussions about RTCP-XR metrics in RTCWEB Presenter : Roni Even ----------------------------------------------------------------------- Reviewed status of discussions in RTCWeb on requirements for RTCP XR and other statistics reporting. Described motivation for using RTCP XR and concluded that XR Blocks are useful for performance monitoring. Colin : browsers have the option to use RTCP XR blocks but must signal their use. Browsers must be able to handle receiving RTCP XR blocks. At this time RTCWeb are not mandating RTCP XR at this time however there are enough hooks that if this added in the future, browsers should not break. API's for accessing metrics would be a W3C issue. Dan: Browsers must not break when they receive XRBLOCKs? Colin: It's just a robustness thing. They don't have to do anything. Roni: Metrics can be retrieved through browser API and sent to servers Dan: Believe that RTCWeb may be wrong - it is not about browser to server but browser to browser. RTCWEB has much bigger issues. A informational draft indicating minimal useful metrics would be helpful. Colin : Agree with Dan - metrics will be useful. Documenting how RTCP XR could be used would be useful for future RTCWeb extensions Roni : Requirements are based on Harald’s draft. Roni : does define how metrics could be retrieved by the application from the stats API however would also be useful to have XR metrics for end to end communication. Colin: I agree that over time, people will want more metrics. If there are useful metrics for RTCWEB it would be good to write that up. Roni: There is no API to retrieve XRBLOCK reports. Need to go to W3C to explain why these are useful. Varun: We could write a document listing what should be in the statistics registry. List which XRBLOCKS would be sufficient. Dan: Is anyone interested in writing this? Roni: There was a draft in progress be Rachel and me which would be a good starting point. Dan: Who is interested in helping? - 5-6 hands. ####################################################################### Open Discussion Moderated by : Chairs ----------------------------------------------------------------------- Glen: About IPR disclosures confirmation - despite the fact that author have fulfilled IPR requirements, it has to be done again. This is nonsense. Dan: We can discuss it, but it has to happen. As chairs we are obliged to wait. Colin : Chairs are stating the policy correctly. Dan : We are making a change/clarification. We are asking for earlier reviews from SDP and monitoring directorates. Kevin : Will drafts discussed today need to be revised for RFC6390 compliance? Dan : If work between Qin and Benoit goes as expected, yes. Dan : looks as if we may complete current work Varun : It may make sense for the group to go dormant if there is no new work. Colin : RTCWEB deployment may create new work. RMCAT may be another.