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

   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-cc-feedback-message-02                                            

      draft-ietf-avtcore-multiplex-guidelines-06

         The authors should talk and report back to the WG.      

      draft-ietf-avtext-framemarking-08

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

   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)

   draft-aboba-avtcore-quic-multiplexing-02 

   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)