Minutes for XRBLOCK ======================================================================== Agenda IETF 88, Vancouver 1730-1830 Thursday, November 7, 2013 Note taker: Roni Evans, Keith Drage ------------------------------------------------------------------------ ** Action Items ********************************************************. Chairs * Talk to AD about expanding milestones (Dan already talked to Gonzalo and got the go-ahead to expand the milestones). * Poll on the list about adopting the following drafts as WG item. 1. draft-bi-xrblock-rtcp-xr-psi-dep-decodability 2. draft-huang-xrblock-post-repair-loss-count WebRTC related draft * Consider defining statistics for codecs used in webRTC/RTCweb like SVC draft-huang-xrblock-post-repair-loss-count * Change the name of the draft. (It's not RLE so don't use RLE) draft-bi-xrblock-rtcp-xr-psi-dep-decodability * Remove dependent from the name. XRBLOCK Status Update Presenter : Chairs ----------------------------------------------------------------------- - No comments. RTCP XR Report Block for Run Length Encoding (RLE) Presenter : Varun Draft : draft-ietf-xrblock-rtcp-xr-discard-rle-metrics draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric ----------------------------------------------------------------------- - Discuss has been cleared. * Varun will address comment from Benoit concerning bracket and name. Considerations for Selecting RTCP XR Blocks for RTCWEB Statistics API Presenter : Roni Evans Draft : draft-huang-xrblock-rtcweb-rtcp-xr-metrics ----------------------------------------------------------------------- Alan Clark: Motivation for combining loss and discard together was that they are needed at same time. Do we need just the total? Loss and discard has the same effect on the user. Jonathan: These do not have the same implication for the network operator. Alan: If the two occur together then more likely due to congestion. Coincidence of two contain useful information. Magnus Westerlund: Why this working group? Last time discussed in RTCWEB very limited interest in doing this. Why do we need extra metrics? Presenter: Interest is what is being reported by local network. Magnus: Then should be directed at W3C. Presenter: First want to get understanding of what we present to W3C. Justin: Hard to understand from stats API is what has impact on the user. Qualitative impact on the user is what we need to expose. Bernard: Gets particularly critical for things like OPUS where we have built in OPC. Varun: If include them then need definition of what is explicitly reported. Colin: The reason for burst loss relates to what is experienced in circuit breakers. Magnus: Repeated that the feedback needs to come from W3C rather than RTCWEB WG. Presenter: Reason is registration. Varun: All the metrics need to be in IANA registry.. Colin Perkins: Two ways in which interaction could occur. 1) Defining some metrics which are encoded locally which needs to be exposed in API 2) Some which need to be exposed by RTCP which RTCWEB need to deal with. Justin: Does not think W3C will care that much. Only thing they will do is figure out what identifiers are used to expose them. We need to decide which metrics should be provided. And why. Dan Burnett: +1 on Justin. The API spec already has a pointer to a registry (placeholder). W3C say this is the registry and the registry structure. This group says what are the useful bits of information. Jonathan: Alvestrand draft sets up an IANA registry with expert review. Chairs: Alvestrand's draft has already expired. Jonathan: If is expert review does not need a lot of interactions with W3C. Alan Clark: Why are the metrics different for RTCWEB rather than anything e lse that is a voice or video client. Why not generalise? Just say here are a set of metrics that are useful. Bernard: Because there are things that might not come through RTCP that we want to expose. Magnus: From comparison between RTCWEB and other endpoints they have similar requirements on what are useful Justin: RTCWEB allows to look at what would be needed for a future platform. Opportunity to enumerate these. Varun: Does not mind whether small scope or large scope. Are we missing any metrics from prior slide. Alan Wood: Forward error correction is used stream correction in RFC 1541. Counts number of losses per block. No IPR on stream repair metrics. No conclusions or decisions. Additional RTCP XR Metrics for WebRTC Statistics API Presenter : Varun Draft : draft-singh-xrblock-webrtc-additional-stats ----------------------------------------------------------------------- Alan Clark: Some codecs replace packet. Others do FEC and include lower rate in subsequent packet at lower rate. When this is used, which is used given that degradation has occurred. Presenter: Would use repaired. Justin: Opus has in-band FEC mechanism different. Might have some internal magic going on. Presenter: Generalise for codec repair stat. Colin Perkins: This is how RFC ??? works Magnus Westerlund: Packets retransmitted is sender property and packets repaired is receiver property. Need to be clearer about which is meant. Roni: Packets Retx is on received side? Yes. Jonathan Lennox: Sent more than one and discard one what is counted in stats? Jahed?: Is packet repaired the transmitted or the quality or what? Can make a big list but is not necessarily a useful list. What do they mean. Presenter: Reports are based on SSRC groups so can do this. Jahed? When get should adjust quality or network or what? Chair: Need some material on meaning. Justin: Packets repaired upper bound will be packets lost. Alan Clark: One of the useful things out of this discussion is that this group has not done anything on how codecs work. Need to consider metrics to deal with this type of codec. Bernard: Need to know what layer (in video) the losses occur on. In respect to feedback need counts on what feedback is being sent. Presenter: Could do OPUS but then if could generalise. Justin: May be solving wrong problems. Where do we need to insert expansion. Focus on qualitative level - how many gaps we have in playout. Chairs: No-one saying a stupid idea. Discuss further on list and let's keep on working on it. Proposal – define statistics for codecs used in webRTC/RTCweb like SVC. RTCP XR Report Block for Post-Repair for Non-RLE Loss Count Metrics Presenter : Rachel Draft : draft-huang-xrblock-post-repair-loss-count ----------------------------------------------------------------------- Alan Clark; Find naming confusing. Repaired loss count and unrepaired loss count may be clearer. Also reference to RLE is confusing and may be simpler to remove entirely. Joanthan Lennox: Scenarios where do not know the border of frame due to losses. Do not know how many packets are repaired as lost. Any guidance on this? Colin Perkins: Confused by concealment? Varun: Frame discarded versus frame lost can be used to interpret. Chairs who had read draft: 4 people. - Any strong objections to adopting? - None. * Chairs will talk to AD about expanding the milestones. * Chairs will Poll the WG for adopting the draft as a WG item. * Name of the draft needs to be changed (It's not RLE). RTCP XR Report Block for MPEG2 TS PSI dependent Decodability Statistics Metrics Presenter : Qinn Draft : draft-bi-xrblock-rtcp-xr-psi-dep-decodability-02 ----------------------------------------------------------------------- - Presented the draft * Not all comments were reflected, authors will update the draft. Alan CLark: PSI dependence implies depends on program string. Remove "dependent". On the PMT error replace with PMT error 2. Need to indicate which is or have both there. Chairs: Did you get any MPEG guys to look at the draft to see if it makes sense? Alan Clark: We have experience and this makes sense. (Alan) * Chairs will talk to AD about expanding the milestones. * Chairs will Poll the WG for adopting the draft as a WG item. No one had issues adopting the draft.