Agenda IETF 84, Vancouver 1300-1500 WEDNESDAY, August 1, 2012. Room: Regency B Chairs: Dan Romascanu > Shida Schubert Minutes: Hendrik Scholz hs@123.org, Roni Even ron.even.tlv@gmail.com 1300 XRBLOCK Status Update (Chairs, 15) WGLC documents presented by chairs. Agenda was accepted without changes. 1315 RTCP XR Report Block for Discard Metric Reporting (Qin, 15) Draft: draft-ietf-xrblock-rtcp-xr-discard-05 Presenter: Qin Draft was reviewed after IETF83/Paris and version -03 will be basis for WGLC. It was agreed before IETF84 that discarded packets due to duplication are a separate category. A discussion started whether to define what RTP duplication is. Must duplicate packets have the same SSRC? Qin Wu: there is no standard how to deal with duplicate packets Colin Perkins: against using definition of RTP replication in this document Colin Perkins: sending RTP packets multiple times is a bad idea and breaks applications. Draft should not talk about RTP replication as something that should be done. Kevin Gross: identified himself as author of slide #3 and is asking about the motivation for the monitoring parameters. No technical objections (yet) and only addressed technical problems mentioned by others. More information on applicability is needed. No need for WGLC but need a new revision. Summary: we need more elaborations in the draft. Dan Romascanu proposed: no change to reporting block, update the draft on the open issue, and do another WGLC Colin: another WGLC required to make sure that everybody agrees with content. Roni Even: text with guidelines on how to deal with duplication required in draft. Dan: action item for Qin: propose changes to text on mailing list. Dan will do WGLC to be safe regarding changes. 1330 RTCP XR Blocks for QoE Metric Reporting (Glen, 15) draft-ietf-xrblock-rtcp-xr-qoe-02 http://tools.ietf.org/id/draft-ietf-xrblock-rtcp-xr-qoe Glen Zorn presenting. Two use cases described: audio+video in one RTP stream or in two streams. Open issue: channel mapping not well defined. How to identify layers for layers codecs. Changes to be done: update document to include payload type of reported media and update channel identifier description. open question: do we need to report QoE per layer in case of layered stream? Al Morton: calculation algorithms (CAlg) list in draft is a good start but not enough. Algorithms such as G.107 MOS require more detailed information about configuration, thus more space to define CAlg is required. Had this problem in IPPM. Glen asked Al to give input regarding needed configuration bits. Glen: linear code space might not work due to amount of different configuration. A discussion about calculation algorithm configuration and space requirements followed. Discussion to continue on list. Dan: waiting for input from al to update draft then might issue WGLC. Roni: we might need accurate information on what configuration we need before doing WGLC. Paul Coverdale supports Al Colin: proposes use of registry for calculation algorithms (CAlg) instead of including complete configuration in report block. Dan and Glen agree that proposing a list of common configurations makes sense. Al to send one. Not yet ready for WGLC. Need to decide how to list the information in the document, IANA registry or not. 1345 RTCP XR Blocks for Synchronization Delay and (Hitoshi, 10) Offset Metrics Reporting draft-ietf-xrblock-rtcp-xr-synchronization-00 document: http://tools.ietf.org/id/draft-ietf-xrblock-rtcp-xr-synchronization presenter: Hitoshi Asaeda -00 WG draft submitted based on individual -07 draft. Presented changes between -04 from IETF83 and -07 (-00 is identical) Hitoshi presents discussion summary on sizing of synchronization offset. Result was to use 64Bit NTP timestamp and incorporated in -07 version. next steps: address issues as they arrive Colin commented that he read the draft and found it to be OK. 1355 RTCP XR Report Block for TS Decodability Statistics (Glen, 10) Metric reporting draft-ietf-xrblock-rtcp-xr-decodability-00 document: http://tools.ietf.org/id/draft-ietf-xrblock-rtcp-xr-decodability presenter: Glen draft adapted by WG, metrics based on ETSI TR 101 290 Glen suggests using 32Bit instead of 16Bit for length of each metric. Proposes to make ETSI TR 101 290 a normative reference. Dan: reference should be normative. Qin: bandwidth requirements for RTCP may be a problem, thus proposes 16Bit fields Dan: Should the fields always be 16Bit or should just some be optimized? Hendrik Scholz suggests to use 32Bit to allow easier aggregation (e.g. for SLAs) as 16Bit overflow as indicated by 0xFFFF counter value would not happen as often. Colin: how many bits could be saved on the wire when moving from 32Bit to 16Bit? Qin: currently 32Bit are used but some people raised the size issue. Colin: how much smaller does the report block get with 16Bit? Qin: 8 metrics, so 16Bytes total per report saved. Colin: 6 Bytes per 5 seconds saved with media stream is for instance 4Mbps Dan (from the floor): having one value for all metrics would be easier to implement Colin: overflowing with 32Bit counters most likely not to happen during session Shida as chair stated that we have rough consensus to use 32Bit for every field. 1405 RTCP XR Report Block for Summary Statistics Metrics (Rachel, 10) http://tools.ietf.org/id/draft-ietf-xrblock-rtcp-xr-al-stat presenter: Rachel draft describes three new blocks: gap loss/discard + frame impairment statistics question before was: which discard types should be used to calculate gap discard rate? agreed before that duplication should not taken into account. Dan (from floor as contributor) asks to explain the document the decision why discard type 3 was selected for calculation in draft. The decision is capturing the mail discussion consensus, but more text is needed in the draft to explain the conclusion. 4-6 attendees read the draft Session concluded at 14:00