Minutes IETF103: avtcore

Meeting Minutes Audio/Video Transport Core Maintenance (avtcore) WG
Title Minutes IETF103: avtcore
State Active
Other versions plain text
Last updated 2018-11-11

Meeting Minutes

   AVTCORE Audio/Video Transport Core Maintenance WG Meeting


Date and Time: Tuesday, November 6, 2018 - Morning Session I, 11:20 - 12:20

Chairs: Jonathan Lennox / Rachel Huang

1. Note Well, Note Takers, Agenda Bashing - (Chairs)

   Note takers : Roni and Bo

   There were a few last-minute agenda changes in adding the RMCAT feedback

   Status of working group drafts:





            [RFC Editor Queue: MISSREF: Bundle]



         The authors should talk and report back to the WG.


         Mo: updtaed all feedback on 08 - should include all comments. Ready
         for next step. Tl0picidix =0 omit if unknown, clarified open issue on
         LRR temporal layer refresh. Jonathan: plase explain on the list since
         not clear. It is not clear whether this solves all needed problems to
         be useful. Mo: will send to the list.

2. draft-ietf-avtcore-cc-feedback-message-02   - Colin

   Jonathan implemented in the Hackathon. sent comments

   no space for reoprt count
   Jonathan - put it in the last octet Nils Ohlmeier agrees.

   Timing - need to specify which clock to use.
   Jonathan : requires a stable clock, more stable than the typical Posix wall
   clock that is subject to adjustments. Magnus: recommend to use a stable
   clock and provide suggestions. Jonathan: is there a need to corralate this
   clock withe the RTCP clock? Colin: Not that I know of right now. Colin: what
   is the point of having the report timestamp have highre precision than the
   arrival time offset> action: no action, leave as is

   Colin: What value should be used for arrival timestamp offset for packets
   that arrived after report timestamp. need to calrify that they are not
   received. Colin: it's not claer what precise semantics "the time instance
   when report packet was generated" has. Jonathan: "This is the state of the
   world at this time". When the reporting interval is really long, more than 8
   seconds, largest time offset doesn't fit and you must create multiple
   reports. Colin: We have to do the right thing with all report packets.

   Overlapping reoprts: need to clarify this case, for example when there wsa

   Reporting on duplicates: Report on last copy, even if creating overlap in
   sequence number. Mo: Are any of these decisions imacting the congestion
   control algorithms? These numbers are used to estimate the bandwidth. Colin:
   We should probably bring this to RMCAT, e.g. handling of duplicates. Mo: For
   duplicates, it is probably the earliest one that makes most sense.

   signaling: limiting on specific subset of payload type.
   Colin: maybe on audio payload no need to reoprt
   Nils: This should apply to the entire RTP transport, not only a specific
   codec. Jonathan: You should not exclude a number of bits that are actually
   sent. Harald: Excluding certain payload types would severely complicate the
   congestion control and strongly recommend to report on everything. The
   receiver should not have any other option than to report on everything. The
   use case we should definitely support is to report on the whole transport.
   Nils: It should be rtcp-fb:*, i.e., all payload types. Mo: So all FEC and
   retransmission repair formats also have to report? Jonathan: Yes, you want
   to have feedback.

3. QUIC multiplexing discussion (Bernard Aboba)


   QUIC is potentially atractive as a transpot for peer to peer data tranfer
   for webrtc applications.

   non requirements : TURN and ZRTP

   Mo: Wouldn't the QUIC version field overlap with RTP TS = 0, which is a
   valid TS? Bernard: Yes. Mo: The discussion to squeeze the TURN range never
   resulted in anything. Jonathan: TURN must be demultiplexed from STUN, but
   otherwise you know that this comes from your TURN server. Mo: There may be
   several entities that have to demultiplex this and those then need to know
   what the TURN server is. It is better to have this unambiguous. I thought
   that the TURN range was squezzed down. Jonathan: What is the QUIC wire image
   , should we talk with Martin Thompson Bernard: undewrstands that there is no
   garantuee. There might also be changes to the TLS content registry that we
   might have to account for.

  call for action: document quic multiplexing in RFC7983bis.  Bernard will do.
  Colin may support.

4. RTP and Quic - (Jorg Ott)

  no i-d. conference paper document sent to the QUIC mailing list.

5. Next steps and open mic - (Chairs)