Audio/Video Transport Core Maintenance (AVTCore) Working Group Minutes IETF 80

 

Chairs: Magnus Westerlund

 Roni Even

 

Note Takers:    Stephen Botzko

                        Bill VerSteeg

 

AVTCore Introduction and Status Update

 

The Chairs started up the meeting to remind everyone of the recent split of AVT WG into four WGs. Please join the mailing list for the WGs that you are interested in. Please don’t cross post to the mailing list. This are the minutes for the AVTCore WG. The WG has published 2 RFCs, has 3 documents in AUTH48, and an additional 4 in the RFC-editors queue, and 3 documents with the AD or IESG. There are three WG documents that are not going to be discussed here today. draft-ietf-avtcore-srtp-vbr-audio has just finished WG last call and is ready for publication, but have received some minor comments that should be addressed before publication request. draft-ietf-avt-srtp-ekt-02 and draft-ietf-avt-srtp-aes-gcm-01 both needs review.

 

Then the chairs reviewed the WG’s milestones. We are already late on the RTP monitoring architecture and the guidelines for VBR with SRTP. The later is mostly done, but the monitoring architecture requires more work and needs to be rescheduled. We also have two milestone with due dates in April that needs work. Also the Retransmission suppression for May will require a push to be met.

 

Explicit Congestion Notification for RTP over UDP

draft-ietf-avtcore-ecn-for-rtp-01

 

Colin Perkins briefly indicated the major changes since the AVT -03 version. Then discussion of the first of the open issue started. This issue was the saturation of the packet loss counter. The proposal is to define one unsigned counter for duplication and one for packet loss. There was no comments on this from the WG.

 

The next issue was the Initiation of multi-SSRC per host sessions. The proposal is to ignore this as it is an optimization. Jonathan Lennox asked if ECN and fan-out actually work together. And the answer is yes as long as it only does fan-out and is ECN capable. Jonathan commented in regards to the proposal to have success for one SSRC imply for other SSRCs for the same CNAME, that the same CNAME is sometime shared between multiple hosts in addition to across multiple RTP session. Magnus Westerlund commented that we want the same optimization to work for both single session and multiple sessions. Harald Alvestrand requested clarification what was meant with host here. Colin clarified that host equals a particular 5-tuple. Bill VerSteeg commented that in cases multiple hosts acts like a single entity they are likely to behave in similar fashion with regards to ECN, thus simplifying is reasonable.

 

Colin continued describing the remaining issues. Then asked for general feedback. Sohel Kahn asked if the draft could include multi-bitrate examples, especially with source and destination behavior. Colin, answered that the draft intentionally does not specify the response to congestion indication that ECN provide. Sohel, then asked that a clarification is added to the draft. And additional request to clarify the byte/packet counters. Colin responded that the draft count congestion in packet in the report formats, what the client does is up to the implementation. Charles Eckel asked if it deterministic the ability to set ECN, which it is based on setsockopt. Charles followed up asking if it is path dependent. Colin answered that offer/answer is used to negotiate which method is to be used. Magnus added that all the current methods needs support for the mechanism at both ends, thus don’t see the benefit of initiating different methods based on direction. Jonathan Lennox asked if ICE interacts correctly with middleboxes. Colin responded that a translator would need to terminate ICE, thus allowing at least ECN on the client to translator leg, possibly further if supported by the next leg.

 

RTCP Extension for Feedback Suppression Indication

draft-ietf-avtcore-feedback-supression-rtp-00

 

Qin Wu presented the outline and the introduction and then went forward with the issues. Colin Perkins commented on the report merging that it is difficult to do merging with secure data, thus not worth doing the slight optimization for something that in general is not possible.

 

Roni asked the room who had read the draft? Small show of hands.  Magnus Westerlund (as individual) requested that write up some deployment scenarios with topologies. Colin Perkins responded that he slightly disagree with usage scenarios. The WG should not tie it down to specific scenario. Magnus agrees with the intent, but still think there is room for clarification. Bill VerSteeg commented that an IPTV use case with millions of receivers might be a good acid test for this mechanism. But do want to ensure the general applicability of the mechanism. Jonathan Lennox commented that the WG needs to get the language correct for when to send feedback and when to not send feedback.

 

RTCP Feedbak Suppression and Retransmission

draft-vancaenegem-avtcore-fb-supp-and-retransm-00

 

Tom VanCaenegem presented his comments on the area of feedback suppression. Colin Perkins commented that some topologies do not allow one client to receive another client’s feedback. This helps answer the intro slide question why a third party message is needed. Tom responded that SSM allows for message transfer, translators must forward all messages. Magnus Westerlund commented that retransmission with unicast delivery is not currently well defined, no guidelines in existing documents about suppression of the RTCP NACK messages. Tom agrees that it is not well defined currently.

 

Tom continued his overview on the usage in different topologies. Magnus Westerlund commented that NACK vs dedicated message needs to be examined. Tom responded that RFC4585 may “just work”, but needs investigation. Roni Even (as individual) in regards to RFC 4585, we do need clarification on the forwarding/reflection behavior. Tom answered that SSM in reflection mode would reflect all messages, and if operating in feedback summary mode the feedback target either terminates, forwards, or does summary information. Colin Perkins asked what are we trying to optimize? Tom responded that we need to balance feedback quantity and user experience.

Tom continued to with slide for SSM with multiple RS/FT devices. Magnus Westerlund suggested that we move forward by dividing up the problem. We have no current specification for retransmission with unicast delivery in SSM contexts and suppression in the feedback target. We also should look at various topologies. Jorg Ott commented that when RFC4585 they did not specify aggregation methods because there is a wide diversity of solutions. Assumed that multiple feedback targets were run by a common organization, and subject to local optimizations.

Bill VerSteeg commented that many of the use cases can be handled by local, vendor-specific optimizations, but RAMS deployments are designed to be multi vendor, and may require standardized and scalable solutions.

 

RTCP for inter-destination media synchronization

draft-brandenburg-avtcore-rtcp-for-idms-00

 

Ray van Brandenburg presented his slides with major changes and some issues. Roni Even (as individual) asked that the use cases for the messages are divided. Delay could be quantified from the client and sent to server. RTCP message could be used to provide this information. Ray answered that the approach assumes delay of client use a particular time source, not aware of the network delay. Roni followed up that the sender may be aware of the delay variance. Magnus Westerlund did a call for hands on adoption. 5 hands in favor for adoption. The chairs will take the call to the list.

 

Monitoring Architectures for RTP

draft-hunt-avtcore-monarch-01

 

Qin Wu presented the issues regarding the monitoring architecture. The first issue discussed was block namespace restrictions. Colin Perkins commented that we eventually will run out of space, 160 years of usage to fill the space. There appear to be more pressing work. When it comes to the question of reserving a subset for private use? Maybe. Magnus Westerlund commented that if we want private space, let’s use a single block identifier and include an enterprise number. Roni concluded that there are no support for work on namespace extension.

 

Qin continued with the next issue: identity info repetition vs blocks association.

Colin Perkins comments that it has been a long time since he looked at this. However, explicit is usually better than implicit. Thus explicit tagging probably makes more sense. Magnus (as individual) SSRC listing can also be verbose. Maybe need new packet type with new structure. Colin responded that that it may not be worth the trouble. Roni Even, commented that the last time this was discussed the consensus was to use a tag. Magnus concluded that we take this to the list for decision.

 

Qin went on with the Monitor Declaration issue. Roni commented that this is trying to close an editor’s notes. One can take the note out and work on translators during working sessions. Colin commented that signaling presence of Monitors is beneficial. Not sure if this is particular to the translator or a more general use. Roni responded that we need to clearly define the monitor function. Colin followed up that do not want to present data from a monitor as from a receiver in any user interface, thus one need to know it is a monitor.

 

Magnus asked about adopting this document as a WG item? There are no other candidate. 10-12 hands indicated positive, no against. The chairs will take the question to list with a provisional OK.

 

Multipath RTP

draft-singh-avtcore-mprtp-01

 

Varun Singh presented the slides all the way through to question if the next version should be a WG item. Thomas Scheirl asked if multi-path is accomplished using multiple interfaces? Varun responded that it could be different interfaces or just different paths to the same interface.

Magnus Westerlund asked if the intention is to specify the congestion control part also. Comparing with Multi-path TCP the congestion control is an important part of the work.

Varun responded that the scheduler is not in the draft, but the sender could use the information in the report to optimize scheduling.