* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Avtcore Status Pages

Audio/Video Transport Core Maintenance (Active WG)
Art Area: Adam Roach, Alexey Melnikov, Ben Campbell | 2011-Jan-26 —  

IETF-100 avtcore minutes

Session 2017-11-16 0930-1200: Orchard - Audio stream - avtcore chatroom


minutes-100-avtcore-01 minutes

          AVTCORE Audio/Video Transport Core Maintenance WG Meeting
          Date and Time: Thursday, November 16, 2017 - Morning Session I, 09:30 -
          10:30+, UTC+08
          Room: Orchard
          Chairs: Jonathan Lennox / Rachel Huang
          1. Note Well, Note Takers, Agenda Bashing - (Chairs, 09:30, 5 min)
          Jabber Scribe: Brian Rosen
          Note taker: Magnus Westerlund
          2. WG Status - (Chairs, 09:35, 10 min)
          Status of working group documents:
                Published RFCs:
                     RFC 8269 (was draft-ietf-avtcore-aria-srtp)
                     RFC 8285 (was draft-ietf-avtcore-rfc5285-bis)
                     RFC 8286 (was draft-ietf-avtext-splicing-notification)
                      [RFC Editor Queue: MISSREF: Bundle]
                      [RFC Editor Queue: MISSREF: Frame marking]
                WG chairs going through agenda.
                Roni Even, noted that in Payload WG, the Flexible FEC draft will
                start WG last call in the near future.
                Adam noted that Flex FEC is part of Cluster 238.
                   Joerg Ott was planning to do something, but not clear when. The
                   milestone is a long time past. Discussion if it is time to
                   kill the milestone. Ben Campbell (AD) wanted to know why the
                   milestone should not be killed?
                draft-ietf-avtcore-multiplex-guidelines resurrected. Major
                editorial changes. Next step is to update the document to address
                open editorial issues. Mo Zanaty volunteered to review.
          3. RTCP Feedback for Congestion Control (Colin Perkins, 10:05, 10 min)
                Magnus Westerlund commented that there is a need for more text
                regarding when to send the feedback message. For example if no
                RTP packets are received, do you send any Feedback? Discussion
                of relation with congestion control documents. Mo Zanaty agreed
                that more practical information is needed,. considering intervals
                for feedback interval. Colin thinks regular RTCP configuration is
                sufficient. Jonathan (as individual) commented that This document
                plus the RTP specification should be sufficient for an receiver
                implementor. The sender side will need also the RMCAT guidance for
                a specific algorithm. Will a receiver be expected to send always
                early feedback, to send as often as you can.
                Roni Even asked about ECN. Zahed answered that it depends on the
                congestion control algorithm if they have response. Harald commented
                that RMCAT is about delayed based CC, all other information is
                Jonathan asked if there are overlapp in information. Colin maybe
                note that what has overlap. But in the end a implementation needs
                to do what is signalled.
                Jonathan noted that there may be important semantic differences
                that need to be noted.
                Jonathan (as chair) noted that we like to have some implementation
                experience with the feedback messages before requesting
                publication. Colin (as RMCAT WG chair) agreed that we like to have
                experience with at least one CC candidate.
          4. Frame Marking RTP Header Extension (Mo Zanaty, 09:45, 20 min)
                Bernard Aboba asked that there was an issue when one had two or
                more layers. In that context the I/B bit didn't really work. Mo,
                going through change to see if that has resolved the issue.
                Jonathan (as individual) in the context of LRR, while this
                constrain all layers. Mo, no one could have higher layer that is
                not independent due to high encoding cost, where base layer is
                Intra coded.
                Bernard, jonathan you had case in your document of a temporal
                nested case. Does these work with these changes. Yes, for the
                particular case with 2 or more spatial layers, the switching up
                points would be marked. Mo, there should be no restriction for
                practical useful layer combinations.
                All issues should be resolved. Authors thinks it is ready for WG
                last call. Bernard agreed that issues are resolved.
                Jonathan (as chair) lets see what the WG says about Roni's
                proposal. But otherwise we continue to a WG last call. Roni, noted
                that the Frame Priority do not block progress. The Frame priority
                is an extension to this document.
          5. Frame Priority Marking RTP Header Extension (Roni Even, 10:15, 10 min)
                Jonathan (as individual) asked what is the difference between
                temporal scalability and frame priority. Not the same use case.
                Mo noted that this priority frame marking is not really targeting
                artifact free decoding, only minimizing artifacts. Frame marking,
                has a Discard bit, that is only for packet that will not effect
                the future dimensioning. Roni stated that they attempted to use
                this in their residential gateways. Targeting WIFI limitations
                and more streaming use cases than conference.
                Roni thinks there are no need to signal this as it is has backwards
                compability. Mo: may violate MUST in frame marking draft. Jonathan
                noted that frame marking should say MUST set to 00, receiver
                MUST ignore.  Jonathan would prefer signalling to indicate this.
                Stephan Wenger noted that this is an old idea. There was an argument
                in H.264 standardization that assigning specific meaning to the
                priority levels. It is an encoder choice on how much impact a
                particular priority level results in.
                Jonathan (as chair) asking if this is something is interested
                in? Stephan Wenger noted no real interest, but also not
                disinterest. The cost appears to be the loss of the two bits. Mo,
                he resisted this in frame marking draft, in the expectation that
                it would take to define how the sender is setting the priority. If
                one is not defining setting the priority then the usability of this
                is less. The middlebox will not be able to determine the impact
                of dropping of a given priority.  Colin, we should define how the
                sender will priority, so that the middlebox knows what to do.
                Delay decision of adopting until frame marking is done.
          6. Quic Multiplexing with RTP (Colin Perkins, 10:25, 15 min)
                Colin Perkins presenting the goals of ensuring that QUIC can be
                multiplexed with STUN to enable Peer-To-Peer usage. Also interest
                be run as part of WebRTC as replacment for the data channel.
                Presenting the Option 5 that is the result of off-line
                discussion. Magnus noted that there is an assumption of not
                needing connection in Peer-to-peer use case. Mo noted that this
                is precluding us ever defining RTP v3.
                Mo wondered if we are not creating a lot of different variants that
                will exist in parallel. Colin, yes, this change of QUIC is short
                term to ensure that STUN works. Long term we may have RTP in QUIC.
                Harald noted that we likely need to update 7983, to ensure that
                the next people that would like to fit are given the correct
                information. Colin thinks this is a more complex matter. Especially
                as QUIC are likely to want to use the full byte for QUIC.
                Xavier Marjou do you have use case. Colin, noted that QUIC is a
                general purpose transport protocol, so all possible applications
                are possible.
                Adam Roach (as individual) it is reasonable to engineer so that
                it work for STUN. Doing it for all is nuts. Colin protests that is
                one additional change between. Adam noted that there are additional
                restrictions. Yes, single connection. Colin noted that when there
                are enough packet types defined, we are likely moved RTP inside
                of QUIC. Thus, alternatives exist.
                Roni Even, I care about RTP co-existance with QUIC.
                Nils Ohlm a second question will we get new protocols. Harald
                noted that they have QUIC as data channel for WebRTC as running
                code. They don't want wait until QUIC v2. So we need this.
                Magnus noted that to actually preserve QUIC short packets from
                colliding with STUN also that packet type filed should count
                down. The reason might be middleboxes that run STUN to not have
                to bind all incoming flows to remote IP + port after connection
                establishment, assuming not having multiple QUIC connection with
                the same peer.
                Discussion if and where RFC 7983 bis would be done. Not urgent.
          7. RTCP XR Block for Effective Loss Index Reporting (Hui Zheng (Marvin),
          10:40, 10 min)
                (On behalf of XRBlock)
                Qin Wu presenting. Chairs noted this is for XRBLOCK WG so no
                consensus can be determined.
                Magnus Westerlund asked if this was a new metric or an established
                one. It is a new one.
                Colin commented that this fits the architecture and there is plenty
                of space.
          8. Next steps and any other issues - (Chairs, 10:50, 5 min)

Generated from PyHt script /wg/avtcore/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -