Notes from XRBLOCK WG Meeting ================================== Date and Time: TUESDAY, July 22, 2014 1300-1400, Afternoon Session I ================================== Note Takers : Roni Evans & Keith Drage (THANK YOU!!) ================================== Action Items : 1. draft-ietf-xrblock-rtcp-xr-post-repair-loss-count - The chairs will confirm this consensus on the list and forward the document to the IESG. No one at the room stood up to request another WGLC. 2. draft-huang-xrblock-rtcp-xr-video-lc - Author/Editor will clarify/add the use-cases - WG to review the type of stats covered and discuss whether the document should be split into 2 drafts (e.g. repair - Author to clarify what DMBF is.. Clarify exactly what is measured. - Author to evaluate if the name should be lost rather than damage if the semantics is actually loss not damage. - Author will update the draft as an individual draft. - The chairs will call for adoption on the ML after the draft update/discussion. 3. draft-huang-xrblock-rtcweb-rtcp-xr-metrics - The chairs will call the adoption of the draft on the ML. - The chairs will distribute the fact to WebRTC ML. - WG will look into the PM registry to register the metrics - WG will discuss whether some of the other metrics in the stats draft that is expired should be in this draft. 4. WG closure discussion - Relatively strong objection to closing the WG. - Will re-visit the discussion in 2 IETFs or so. ================================== ================================== Detail note by Keith Drage ================================== 3. RTCP XR Report Block for Post-Repair Loss Count Metrics - Rachel (10 min) ---------------------------------------------------------------------------- https://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcp-xr-post-repair-loss-count/ Slides: http://www.ietf.org/proceedings/90/slides/slides-90-xrblock-0.pptx Presenter: Rachel Huang Slide 1 Slide 2 Slide 3 Slide 4 Chairs: Anyone see need to redo WGLC. No input from room Chairs: Will take this to the list to check, but otherwise will proceed to publication request. 4. RTCP XR Block for for Loss Concealment Metrics Reporting on Video Applications - Rachel (10 min) ------------------------------------------------------------------------------------------ https://datatracker.ietf.org/doc/draft-huang-xrblock-rtcp-xr-video-lc/ Slides: http://www.ietf.org/proceedings/90/slides/slides-90-xrblock-1.pptx Presenter: Rachel Huang Slide 1 Slide 2 Chairs sought reminder on how the document was created. Slide 3 Slide 4 Colin Perkins: Retransmission is primarily to repair packet loss rather than conceal packet loss. May want to split this up. Currently define as concealment and repair. Slide 5 Steve Bozko: Are we counting how many blocks were not received, or looking at impact on the frame as not sure on what has not been received. Presenter: Looking for opinions. Steve: Can envisage looking for blocks not received. CHairs sought input on how many had read: 3 to 4 people. Varun: Can we say lost rather than damaged. Want to see at end how many were really lost versus concealed. Colin Perkins: Not clear what damaged means in this context. Probably mean lost rather than damaged. Slide 6 Chairs: What are opinions about this work being useful? Uwe: Would like to better understand the use case. Presenter: May help better understand the QoE of the user. Chairs: anyone believe should not do this? Anyone believe should do this, Colin Perkins: Do not believe it is harmful. Sees no reason to stop the work. Roni Even: Complementary to the audio loss concealment. Need more input about what should be recorded, but otherwise makes sense to proceed. Chairs: Spin next version as individual submission and add some information about use case. Then ask on mailing list question about adopting. Chairs ask for those willing to contribute. 3 hands. Plus some more identified offline. 5. RTCWEB Statistics consolidated I-D - Varun (15 min) ------------------------------------------------------- https://datatracker.ietf.org/doc/draft-huang-xrblock-rtcweb-rtcp-xr-metrics/ Slides: http://www.ietf.org/proceedings/90/slides/slides-90-xrblock-3.pdf Presenter: Varun Slide 1 Slide 2 Slide 3 Slide 4 CHairs: How does this compare to making this a web page. Presenter: See next slide. Slide 5 Washing w3C decided not to proceed with stats registry. Al Morton: IPPM working group might be able to support this with worldwide registry for performance metrics. Bernard: This registry is not just for XRBLOCK but covers all of RAI. Al Morton: But it is all metrics. Colin Perkins: Has not been following W3C closely. Could reuse IPPM but would need some coordination with W3C. Dan Romascanu: Still need some coordination. W3C at some point will put this into a working document. Bernard Aboba: It is all a WIKI page right now - can edit in what you want and see if it stays there or put it in a document that people actually review. Has not been updated in a year and a half. Dan: 2015 Bernard: That has been the plan for well over a year. Dan: Creating a registry does no harm. Provides an anchor for the time being and provides more stability than a WIKI. Go on in this manner until W3C plans become a reality, Al Morton: Lots of standardised metrics. Lots of them have variability in them. Point of the registry is that they are rigidly standardised - i.e. it is exactly these things that are being monitored. Chairs: Should we adopt this as a milestone? No objection. 6. Next Steps ------------- Chairs: Are about to adopt last few work items. If something important does not show up then will conclude the WG in one or two IETF cycles. Alissa: As usual will keep list open but the WG will cease. Varun: What will happen if new XRBLOCKs are identified. Chairs: WG can be resussitated if necessary. Discuss if occurs and list an decide where to go from there. Colin Perkins made a plea for dormancy rather than closure so new owrk could be performed. Keith Drage: Identified list will continue to exist, and suggested that another way was with a directorate and AD sponsored. Alissa: Stated normal state of things would be to close the WG, but these things need to be discussed. Jonanathan Lennox: Need somewhere where broader community review is helpful. Chairs: Our state is not yet empty, so do not need this discussion yet. Varun: Identified that there may well be more work in future for webrtc. Close: 13:47 ================================== Detail note by Roni Evans ================================== 3. RTCP XR Report Block for Post-Repair Loss Count Metrics - Rachel (10 min) Presented by Rachel Colin does not have any open comments after the last update. Dan: the document went through SDP directorate review No objection to send to publication but Dan will take it also to the list. 4. RTCP XR Block for for Loss Concealment Metrics Reporting on Video Applications - Rachel (10 min) New draft on video lost concealment Dan asked if there was an audio and video metrics that were split. Roni – there is an audio only in RFC7294 Colin: retransmission split between conceamentl and repair. Retransmit is concealment Steve B. ; DMBF – what is the measurement, the receiver may not know how the loss is spread. So not sure about it Varun – can we say lost instead of damaged on DMBF Colin: not sure what damaged means in this context. UWE: what is the use case for this report how is it used, is it for QOE Rachel –yes Dan: should we do it Colin: it is not harmful Roni: complement the audio in RFC7294 Dan: add use case and get feedback on the metrics. 5. RTCWEB Statistics consolidated I-D - Varun (15 min) Not sure how to proceed with this document. Al: suggest to add it in the ippm metric registry. There is an example of how to add it. Will send a pointer Colin: there is the w3c stat registry but need to do it with w3c Dan: still will need to have coordination with w3c. Varun: herald draft expired so what to do with the rtcp metrics from that draft. Should we move it to this document. Do we create a registry by ourselves. Dan: make sense to have it as an anchor, we should continue with the document until W3C stabilizes on a method. Need to synchronize between. Shida asked for adoption as a WG document. Keith: milestone? Shida: yes, will create a milestone and post also on the rtcweb mailing list. 6. Next Steps Colin: not close the WG either dormant or allocate the work to other WG. There may be more XR blocks. Alissa: keep the mailing list open and see if there is new work. Colin: there may still be a trickle of document. It is a living protocol. At least assign to one of the RTP WGs. Alissa: we can decide when we are done. No need to discuss now. Dan: this is what I meant, the stack is not empty.