Minutes IETF101: avtcore
minutes-101-avtcore-00

Audio/Video Transport Core Maintenance (avtcore) Working Group

======================================================
CHAIRS:  Jonathan Lennox       <jonathan@vidyo.com>
          Rachel Huang         <rachel.huang@huawei.com>

AGENDA

Thursday, 22 March 2018 at 13:30-14:15 (Park Suite)
-------------------------------------------------

1. Note Well, Note Takers, Agenda Bashing - (Chairs, 13:30, 5 min)

Note takers: Bo Burman, Bernard Aboba
Jabber: Magnus Westerlund

   Status of working group drafts:

      draft-ietf-avtcore-multi-media-rtp-session-13
      draft-ietf-avtcore-rtp-multi-stream-optimisation-12
      draft-ietf-avtext-rid-09
      draft-ietf-avtext-lrr-07
            [RFC Editor Queue: MISSREF: Bundle]

      draft-ietf-avtcore-mprtp (expired)
        Jonathan: Suggest taking it off the milestones
        Bernard: Don't think that we have an option. Part of the issue is that
        this is not only multi-path RTP, it is multi-path ICE. Colin: These are
        presumably separable parts, but you need both. Jonathan: As individual
        I think it would make sense to take multi-path ICE to either ice or
        dispatch WG Ben (as AD): IETF is contribution-driven. Bernard: If you
        don't charter it to be successful, it will not be. Ben (as AD): Would
        not object to any multi-path contribution. Colin: Think the suggestion
        is to drop it unless someone brings more work. Jonathan: Will bring
        this decision to the list. Encourage to do appropriate work.

      draft-ietf-avtcore-multiplex-guidelines
        Colin: That work stalled. Roni decided it was important, but then it
        stalled again. Not sure there is real value. Roni: Volunteered to do it
        and will continue with that. Magnus: There was an update before last
        meeting, but more editing is needed.

      draft-ietf-avtext-framemarking-06
        Mo: There were some comments, mostly editorial. Didn't see a hard need
        to do something differently or specify in a certain way. Jonathan: I
        think as receiver you need to know. Mo: We can add some clarification
        text. For the I bit, do you want to prohibit I bit on layers when base
        layers have it. The conclusion was that it is per layer. Will add
        clarifying text why things can be one way or the other. There is also a
        new IPR declaration with FRAND terms. Ben: Please see to that the IPR
        disclosure gets to the list.

2. RMCAT Feedback Message Work Status (Colin Perkins, 13:35, 20 min)

   draft-ietf-avtcore-cc-feedback-message-01

   Colin: Any concerns with using 1/1024 of a second for Arrival Time?
   Jonathan (as individual): Could you get rounding errors, e.g. when comparing
   to send times that could typically be in microsecoonds? Colin: Probably, but
   may not be significant. Jonathan (as individual): What if you have
   reordering on the wire, could you derive "later" from RTCP? Colin: Tend to
   think it is not worth it because it would be too late for congestion control
   to work with it. Jonathan (as individual): What if something has been off
   for a long time, what to do when it comes back? Colin: Suspect that is
   ambiguous and would have to be clarified. Jonathan (as individual): You
   should send feedback for every source that supports congestion control; how
   do you know? Colin: Suspect that there would be parameters in SDP, but that
   is probably all we need. We will need to specify some signaling, but the
   rest would be congestion control algorithms. Jonathan: Can anyone volunteer?
   Harald, Bernard and Magnus volunteers. Zahed: We have a github if anyone
   wants to provide editorials. Can send link to the list. Jonathan: Bring any
   technical issues to the list. Harald: Hope we can have WGLC before IETF 102.

3. Frame Priority Marking RTP Header Extension  (Roni Even, 13:55, 15 min)

  draft-even-avtcore-priority-markings-01

  Roni: Have tested it in WiFi routers and it provides good results for
  non-scalable streams. Colin: No objection to opt in the work. The issue has
  been how you do the marking. Have not seen anything in the draft how you
  consider doing that. Roni: It marks within a single stream. Colin: Don't
  think that works. Which marking is which priority, if you have equipment from
  different vendors. Roni: Marking is done by the encoder. Jonathan: What would
  be the typical ratios of how much is marked and how much is not? Magnus
  proxying for Tom Petersen from Jabber: Should the spec consider streams that
  may have FEC or is it out of scope? Roni: You can probably use it to mark the
  FEC stream too. Bernard: FEC is typically hop-by-hop, so a middlebox would
  not forward it but re-create it. Probably not so frequently implemented by
  the video people I know. Jonathan: Streaming ecosystem is different. Mo: This
  can applied to video, audio or FEC if it is inband FEC. Jonathan: Is there
  interest? Mo: Have no objection, but there is coupling between components and
  it could be hard to standardize the understanding needed to set good
  percentages for marking. Not clear to an arbitrary vendor or receiver what to
  mark. Jonathan: If a receiver could specify the expected marking ratios,
  would that help? Mo: If there is no coupling between sender and receiver,
  don't see how it could work.

4. Next steps and open mic - (Chairs, 14:10, 5 min)

No topics.