AVTCore notes, Thursday 15:20, IETF88 ===================================== WG Chairs: Magnus Westerlund, Roni Even Note Taker: Robert Hansen Jabber Relay: Jonathan Lennox AVTCORE WG Status ================= Presentation: http://www.ietf.org/proceedings/88/slides/slides-88-avtcore-1.pdf The chairs gave an update on document status progressions (RFCs 7022 and 7007 published, draft ietf-avtcore-idms-13 in the editorial queue, and others up for AD Evaluation). draft-ietf-avtcore-srtp-ekt and draft-ietf-avtcore-clksrc are in working group last call - reviews are requested for these and for other documents. draft-wu-avtcore-dynamic-pt-usage-02 was summarised by Roni, with proposals to update the IANA registry and a question on whether a new document was required or whether RFC 5761 was sufficient to accomplish this. Colin Perkins commented that all the information is available in the RFCs. There was an oversight to not update the IANA registry in RFC 5761. But there are no need to write a document for this, only talk to IANA to have the update the registry based on RFC 5761. Keith Drage concurred that if the only goal is to have the IANA registry be update that can be done by reference to the RFC. Colin remarked that in the propsal in the draft, there are two aspects that aren't in RFC 5761. The first is that one can use payload types 64 and 65, they are reserved due to conflict with RTCP Packet types. If the WG wish to allow these to be used, then someone needs to write a document and have it go through the WG. The second thing which isn't part of the RFC is the order in which one uses the payload type values with static assignments. Colin believe this is not a useful thing, but if the WG think so, then that needs to be written. Mo Zanaty commented that he think it would be a bad idea to reclaim PT 64 and 65 as they are in actual use, including by WebRTC.org open source code. Magnus Westerlund comments that the use of RFC 5761 is after all a choice and thus, the conflict avoidance is not allways valid. Colin Perkins responded that he thinks the appropriate thing is to have the IANA registry simply point to the RFC 5761. The conclusion was the chairs agreed to review the RFC and potentially contact IANA to update the registry to match the document. The chairs presented the milestones. Simulation results for Multi-Stream =================================== Presentation: http://www.ietf.org/proceedings/88/slides/slides-88-avtcore-0.pptx Magnus Westerlund presented results of simulation work done related to draft- ietf-avtcore-rtp-multi-stream and draft-ietf-avtcore-rtp-multi-stream- optimisation. He presented the algorithm used for SSRC RTCP report aggregation, the simulation values used and the results, comparing aggregation of packets against the unaggregated results. The bitrate consumed with aggregation is significantly reduced, but with the transmission interval increased by a factor of three or four. His conclusion was that the RTCP transmission interval is signficiantly increased, and that a better scheduling algorithm is required. He then showed the results of implementing report grouping from optimisation draft (without using aggregation). The results of the simulation of the same point-to-point scenario as before was to reduce the reporting period and halving the average RTCP packet size. He then showed the results of a simulation of a flow between selectively forwarding middle boxes. Here report grouping offers a significant benefit on the transmission interval (with the non-group versions having worst-case reporting intervals of >20s). Packets were on average 1/8th the size when using grouping reports. As part of this there was acknowledgement of an issue with RFC 3550 that RTCP timeouts might be occuring due to time interval for sending packets approaching five times the packet receiver's time interval. There was a conclusion that when calculating timeout intervals the larger of the sender and receiver intervals should be taken into account, and that this should be expressed in a document. The conclusion was that report groups are effective and offer significant improvements that increase with the number of streams. Addition work required is the need for improvals for the aggregation algorith that are simple and manitain the bandwidth target. Packet bursts of a joining endpoint are not currently taken into account. RTP Circuit Breaker over LTE network ==================================== Presentation: http://www.ietf.org/proceedings/88/slides/slides-88-avtcore-4.pdf Zaheduzzaman Sakker gave a presentation of the testing of the circuit breaker defined in draft-ietf-avtcore-rtp-circuit-breakers-03 in very congested simulated conditions. Clarification was made that this the radio traffic is running in unacknowledged mode. The circuit breaker did fire with increasing probability as load worsened. With the circuit breaker enabled there was some improvement of the traffic properties. However, even for some heavily congested users (up to 50% loss in the worst case) the congestion circuit breaker did not trigger. The culprit for this was that the low round trip time, leading to a high TCP throughput estimation. There was some discussion about whether in a real system the effective RTT would be increased by delays within the system; Zaheduzzaman did not believe this was an error in the simulation, but reflected a real issue. To attempt an improvement, the complex TCP throughput equation from RFC 5348 was tried instead - this showed a significantly higher level of triggering. However, this was now triggering the circuit breaker in some cases for users with as low as 8% loss. There was discussion if this was a problem, or was a valid triggering if this loss occurred in a long burst. This is not yet known. Colin later clarified that the complex TCP throughput equation was tried during their simulations and also increased the sensitivity; in their case making it too sensitive. The conclusions from the presentation were that the congestion trigger needs further work; the complex TCP throughput equation did help but makes the system more complex. Zaheduzzaman undertook to look at the low loss rate losers for which the circuit-breaker was triggering to see if this was triggering validly due to the loss rate being temporarily higher. There was a suggestion to use the burst definition in RFC 3611 to see if the loss was bursty or not. He also plans to modify the proposed circuit breaker triggers, and to consider additional circuit breakers, such as high loss or high round trip time. There was debate about the level of loss or high RTT that would constitute an unusable stream. There was general agreement that high loss should trigger the breaker; for high RTT there was some debate about what the values or measurement periods to trigger on should be, though there was general agreement that it would be useful. RTT also raises the issue that for streaming high RTTs should tolerate much higher delays - Colin clarified that originally this work was designed for interactive streams, but could potentially be used for streaming. Payload WG topics: ==================== The rest of the session was alloacted to Payload WG documents and status. draft-ietf-payload-rt-howto has a publication request, VP8 RTP payload =================== draft-ietf-payload-vp8 is waiting to progress at the IESG. Cullen brought up the issue of negotiating resolution with the vp8 payload document, which he believes are lacking, and suggested the addition of the imageattr attribute. There was debate over the use of levels, and what resolution ratios are allowed within a level. There was agreement that in practise most decoders cannot actually cope with all of the potential resolutions based on limits, but there was debate about why this was an issue for VP8 while other codecs have the same issue. here was a suggestion that the maximum limit of 1:8 and 8:1 used in H.264 be adopted (and there was a clarification that firefox already uses this limit). However, there was still a concern that real implementations, particularly hardware ones, still need to be able to negotiate more constraints that this, and that this could be solved by referencing the imageattr document (which in practise is already in use by various groups). There was debate about whether this should be mandatory to send or receive - there was agreement that this should be an optional SDP attribute or element, but if present should be mandatory to honour by the far end. H.265 RTP Payload ==================== For draft-wenger-payload-h265-payload-header-extension there was a proposal for support for temporal scalability There was been a single review (preferring option 2). Note that there is IPR on this not yet registered (Stephan will register the IPR in the next week or so). It was agreed to add the support for temporal resolution to the document and the editor (Ye-Kui) will do it. Opus RTP payload ================== Jean-Marc Valin gave a presentation on the OPUS RTP payload format. There was a question on why this was not yet an RFC. Jean-Marc clarified that it has not yet had many reviews, so the purpose of the presentation was to make sure there were no unraised issues. There was a summary of the RTP payload and of the SDP syntax. All FMTP parameters are informative rather than being mandatory and can be ignored by the sender if desired. For instance, even if the receiver declares they want to receive CBR the sender is not actually required to send it. This is because the OPUS decoder must be able to decode any valid OPUS packet sent. There was considerable debate about whether this ability of the sender to ignore any of these parameters was a good design or even a valid thing to do in SDP offer/answer. This debate went on for some time, and was not resolved by the end of the session. The discussion will have to continue on the list.