Minutes IETF100: avtcore
minutes-100-avtcore-02

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)

      draft-ietf-avtcore-multi-media-rtp-session

      draft-ietf-avtcore-rtp-multi-stream-optimisation

      draft-ietf-avtext-rid

            [RFC Editor Queue: MISSREF: Bundle]

      draft-ietf-avtext-lrr-07

            [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.

      draft-ietf-avtcore-mprtp

         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

      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 fallback.

      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)