Re: [AVT] AVT minutes at IETF 75 -- first draft

[Colin Perkins <[e-mail]>]

On 12 Aug 2009, at 19:28, Tom Taylor wrote:
> AVT met Monday morning, 09:00-11:30, and Friday, 14:15-15:15. Chairs  
> were Roni Even and Tom Taylor. Thanks to Bill ver Steeg, Colin  
> Perkins, and Brian Rosen for your meeting notes.
>
> 1. Agenda and Note Well
>   ====================
>
> See http://www.ietf.org/proceedings/75/agenda/avt.html. The agenda  
> was accepted as proposed, except for a note by Colin Perkins <[e-mail] 
> > that the authors of the ECN-related documents agreed on a single  
> common presentation on Friday afternoon.
>
> 2. Status
>   ======
>
> Roni Even reported. See http://www.ietf.org/proceedings/75/slides/avt-0.pdf 
> . It was noted that a queue of drafts is building up behind draft- 
> ietf-avt-rtcpssm, which awaits an editorial update. Colin Perkins  
> promised that the update would be provided shortly.

One minor correction: Jörg promised me that an update would be  
provided shortly; I'm not going to provide the update (indeed, some of  
my drafts are blocked waiting for it...)

> Tom Taylor explained that he had mistakenly failed to copy the list  
> when calling a halt to the debate over max-send-level in the 3984bis  
> draft for lack of consensus. Actually the debate had continued  
> behind the scenes, but Ye-Kui <[e-mail]> and Randell <[e-mail] 
> > finally came to an agreement and updated text should be available  
> shortly. We will have a second short WGLC on the revised text, then  
> 3984bis and the SVC draft can proceed to the IESG.
>
> The authors feel that draft-ietf-avt-rtp-gsm-hr will be ready for  
> WGLC after another iteration.
>
> 3. Rapid Acquisition for Multicast RTP Sessions
>   ============================================
>
> draft-ietf-avt-rapid-acquisition-for-rtp-01.
> Bill ver Steeg <[e-mail]> reported.
> See http://www.ietf.org/proceedings/75/slides/avt-1.pdf.
>
> The presentation listed a number of open issues. The one issue  
> discussed in the meeting was the question Ye-Kui Wang raised on the  
> list, about why the Min RAMS Buffer Fill Requirement AVP is needed  
> in the RAMS Request message. Bill's reply was that the sender needs  
> this information to know the minimum fill the receiver requires in  
> its jitter buffer. (Or the receiver may have other buffer  
> requirements.) Ye-Kui commented that this AVP might force the  
> Retransmission Server to select an earlier I-frame start point for  
> the beginning of the retransmitted burst, rather than the most  
> recent one. Ali Begen <[e-mail]> expanded on Bill's answer,  
> saying that there are lots of reasons why the receiver needs an  
> increased buffer fill.  The server will have to decide on the right  
> starting point depending on the requirements indicated by the  
> receiver.  The server might even decide it is faster to wait for the  
> next I-frame rather than go back.
>
> Roni Even commented that the draft should discuss the issues that  
> clients may have in setting the value of the Min RAMS Buffer Fill  
> Requirement AVP.
>
> The remaining open issues were referred to the list.
>
> 4. Port Mapping for Retransmission
>   ===============================
>
> No draft.
> Roni Even reported.
> See http://www.ietf.org/proceedings/75/slides/avt-2.pdf.
>
> This issue came up in the work on rapid acquisition of multicast  
> streams, but also applies to small-group multicast as described by  
> RFC 4588. The basic problem is that declarative SDP (as opposed to  
> offer-answer) does not allow the receiver of a unicast stream such  
> as a retransmission stream within a multicast session to specify the  
> transport address to which the stream should be sent.
>
> Comments on the Problem Summary slide:
>
> Dave Oran <[e-mail]> commented that the operation should be  
> atomic to avoid the need for correlation of exchanged messages.  
> Moreover, the mechanism has to finish before the retransmission  
> starts, but not too early or we have NAT bindings expire, or  
> maintain too much state at the sender (at worst, state for each  
> receiver in a large multicast group).
>
> Colin Perkins had an architectural concern with the transmission of  
> transport addresses in RTCP. The alternative is perhaps to use STUN.  
> Dave Oran pointed out that there is an atomicity issue with  
> synchronization of STUN with the RTCP/RTP exchange. Moreover STUN  
> has its own architectural issues, since it is designed for a  
> stateless server and the retransmission server is stateful. Finally,  
> whatever the solution, we must guard against reflection attacks.
>
> It was agreed that the IP address to which the flow should be  
> directed would always be that from which the RTCP FB or NACK message  
> originated. However, the port would be different in general.
>
> It was agreed that off-line discussion was needed. A meeting was  
> arranged over the lunch hour on Tuesday. The report of the outcome  
> of that meeting was presented on Friday afternoon (see below).
>
> 5. Synchronized Playback in RAMS
>   =============================
>
> draft-yang-avt-rtp-synced-playback-00.
> Peilin Yang <[e-mail]> presented.
> See http://www.ietf.org/proceedings/75/slides/avt-3.pdf.
>
> Bill ver Steeg reported that Cisco is filing IPR statements in this  
> area.
>
> Ali Begen wondered how the server could set N and V, given that  
> there are other sources of delay such as jitter that are specific to  
> the receiver. He also pointed out that frame skipping does not  
> account for the audio portion of the media transmission. Ashok  
> Narayanan <> noted that speeding up and slowing down video will  
> introduce artifacts.
>
> Dave Oran and Colin Perkins made the point that synchronized  
> playback to multiple receivers is a general problem, and a very  
> difficult one. Ye-Kui countered that at least one component of delay  
> could be removed by this technique. He cited work on delay reduction  
> ongoing in TISPAN, involving real-time measurement of delay. Dave  
> Oran asked on what scale: 2 receivers or 200,000? It would appear  
> the work is closer to 2. Dave suggested the problem could be larger  
> in some network situations.
>
> There was a comment that other methods were available for adjusting  
> timing, each with its own quality issues. One part of the difficulty  
> of the general problem is that delay across the Internet is variable.
>
> Roni's summation was that there have been lots of comments to  
> address, especially the factor of changing delay on the Internet.   
> The problem is interesting, but the solution presented may not be  
> appropriate.
>
> 6. Improved Rapid Acquisition of Multicast Sessions
>   ================================================
>
> draft-wang-avt-rtp-improved-rams-00.
> Ye-Kui Wang presented.
> See http://www.ietf.org/proceedings/75/slides/avt-4.pdf.
>
> Bill ver Steeg wondered if this was intended to be a new normative  
> specification or implementation guidelines for the existing draft.  
> Ali Begen suggested it was up to the receiver to choose the right  
> time to join the multicast session. Colin Perkins was concerned that  
> this might be over-specifying receiver behaviour. Ye-Kui responded  
> that we have to be sure to specify behaviour adequately.
>
> Further discussion focussed on the assumption that the bottleneck  
> link was adjacent to the receiver (hence the receiver knows the  
> bandwidth available). Ye-Kui suggested this was a reasonable  
> assumption in the the case of a home network, where devices know the  
> guaranteed bandwidth from the service provider and can be aware of  
> bandwidth consumption by other devices in the home. Colin Perkins  
> countered that devices must always be aware of congestion and loss  
> and be prepared to back off.
>
> 7. Multicast Acquisition Report Block Type for RTCP XR
>   ===================================================
>
> draft-begen-avt-rapid-sync-rtcp-xr-01.
> Ali Begen presented.
> See http://www.ietf.org/proceedings/75/slides/avt-5.pdf.
>
> Bill ver Steeg noted the need, here and elsewhere, to deal with  
> extended sequence numbers.
>
> 8. Audio Level Indicators in RTP Streams
>   =====================================
>
> Combined presentation of draft-ivov-avt-slic-00 and draft-lennox-avt- 
> rtp-audio-level-exthdr-00.
> Enrico Marocco <[e-mail]> presented.
> See http://www.ietf.org/proceedings/75/slides/avt-6.pdf.
>
> The problem statement, draft-ivov-avt-slic-00, was worked up on the  
> DISPATCH list. The problem was referred to AVT after a solution  
> approach was selected. There are actually two related problems.  
> draft-ivov-avt-slic-00 is concerned with getting audio levels from a  
> mixer to a receiver. draft-lennox-avt-rtp-audio-level-exthdr-00 is  
> concerned with getting audio levels from a sender to a mixer.
>
> Jeffrey Goldberg <> suggested additional metadata besides audio  
> volume (e.g. position, Dolby) might be interesting. Jonathan Lennox <[e-mail] 
> > replied that this could be the subject of another header extension  
> draft.
>
> Francois Audet <[e-mail]> could see the reasoning for in- 
> band transport of the indicators from the mixer to the receiver, but  
> was concerned that in-band transport from the senders would involve  
> a lot of code and drive up client cost. Enrico cited the need rapid  
> responsiveness to changing speaker conditions. Roni Even expressed a  
> concern about packet congestion, and Francois was concerned over  
> compatibility with existing terminals.
>
> Gunnar Hellstrom <[e-mail]> saw a possible use  
> case for text conferencing (e.g. using RFC 4103), where the  
> information presented would be the source of a particular text  
> message.
>
> Dave Oran had a thought: perhaps send comfort noise payload with the  
> same timestamp as the primary packets. [Not clear if this was  
> related to Gunnar's use case.] Jonathan Lennox suggested that RED  
> (RFC 2198) would be less heavyweight.
>
> 9. SRTP Store-and-Forward
>   ======================
>
> draft-mattsson-srtp-store-and-forward-03 and draft-naslund-srtp- 
> saf-02.
> John Mattsson <[e-mail]> presented.
> See http://www.ietf.org/proceedings/75/slides/avt-7.pdf.
>
> Cullen Jennings <[e-mail]> asked what has changed since the  
> last meeting. Were the objections raised in that meeting addressed?  
> The answer was that the usage of CCI and CID has changed. Richard  
> Barnes <[e-mail]> asked if CCI and CID are protected. John  
> said they were not -- they were like PKI in SRTP.
>
> Roni noted a list comment. Dan Wing could not be present because of  
> a collision with BEHAVE, but felt that the solution was complicated  
> both on the client and on the server. John said it wasn't really --  
> they had implemented it in two days.
>
> Randell Jesup commented offline that the RTCP part wasn't mentioned  
> in the draft. RTCP is needed in some cases to sort out data  
> misordering. John stated that the middlebox has to store the  
> relevant part of the RTCP. The RTCP does not need protection.
>
> Cullen asked how many had read the draft. A few had done so. Given  
> that most people who needed to comment were absent, further  
> discussion was deferred to the list.
>
> = 
> = 
> = 
> = 
> = 
> ======================================================================
> = 
> = 
> = 
> = 
> = 
> ======================================================================
>
> Friday presentations. Thanks to Dave Oran for the notes.
>
> 1. Agenda and Note Well
>   ====================
>
> Roni Even opened the meeting.
> See http://www.ietf.org/proceedings/75/slides/avt-8.pdf.
>
> A report from Tuesday's port mapping breakout session was added as  
> the last item on the agenda.
>
> 2. ECN for RTP over UDP/IP
>   =======================
>
> draft-westerlund-avt-ecn-for-rtp-00.txt draft-carlberg-avt-rtp- 
> ecn-02.txt draft-carlberg-avt-rtcp-xr-ecn-01.txt
> Piers O'Hanlon <[e-mail]> presented.
> See http://www.ietf.org/proceedings/75/slides/avt-11.pdf.
>
> Chart 2:
> ECN is actually quite useful to realtime flow - can adapt before  
> loss occurs. (TCP can retransmit.) Most RTP flows today do not adapt  
> to loss - using loss as a signal can be too late to recover before  
> playout deadline expires.
>
> Chart 3:
> Newer codecs can do rate adaptation.
> ECN allows really congestion response and better user experience  
> (but this draft does not specify the sender's reaction to feedback).
>
> Chart 4:
> ECN-for-TCP tutorial.
>
> Chart 5:
> Extension to UDP seems straightforward:
>    - Signal ECN using SDP offer/answer
>    - set ECT on RTP data packets
>    - send feedback on RTCP RRs (no portable way to monitor receiver  
> ECN marks on UDP).
>
> Chart 6:
> Actually not quite that simple
>    - need to tell if media path supports ECN - can't do this on  
> signaling path
>    - current AVPF is slow - many RTTs.
>    - frequent rate changes are not good for user experience.
> Unlikely it will be strictly TCP-friendly.
>
> Charts 7-8:
>    - RTP has mixers and translators - explicit middle-boxes
>    - mixers are the easy case since they are endpoints.
>    - multicast complicates picture.
> Basic message: ECN capability varies across receivers and along paths.
>
> Chart 9:
> Here is a proposal. Four components
>    - negotiate with SDP offer/answer
>    - verification of the media path capability to ECN
>    - feedback
>    - error control, fallback.
>    - broken middle boxes can drop/remark packets
>    - need to probe the path. Two ways.
> 1. use ICE & STUN (details to be sorted out)
> 2. treat ICE as optimization, but do RTP-native probe.
>
> Bob  Briscoe <[e-mail]>: may have an alternative for  
> how to do the data path operations. One can simplify by only doing  
> data plane probing - no need for negotiation.
> Colin Perkins: reason to have the negotiation is to avoid problems  
> with boxes not prepared to receive RTCP packets they don't understand.
>
> Chart 9 (cont'd)
>    - need to monitor in case path fails
>    - can do receiver-only adaptation, but much better to always send  
> feedback.
>
> Complications:
> - translators that don't change the media are easy
> - it's the ones that split/join you need to be careful about
> - media transcoders are harder - need to separate the legs.
>
> The authors suggested that this be joint work with TSVAREA, but  
> adopt it as an AVT work item. They were instructed to submit a joint  
> draft. The chairs will discuss how and if to add a WG charter item  
> for this work.
>
> 3. RTP Payload Format for MPEG2-TS Preamble
>   ========================================
>
> draft-begen-avt-rtp-mpeg2ts-preamble-01
> Ali Begen presented.
> See http://www.ietf.org/proceedings/75/slides/avt-9.pdf.
>
> The proposed payload format carries MPEG2-TS (transport stream)  
> stuff, but not what RFC2250 does.
> Question: are the parts in this payload scattered in the transport  
> stream? Answer: yes.
>
> The encoder locks onto the "TSRAP" (Transport stream random access  
> point).
> - extracts the needed pieces from the TS, and sends them in RTP.
> - encodes via TLVs like in RAMS: examples - PAT, PMT, PCR, SEQ, ECM,  
> EMM.
> Question: how does the canonical order for feeding to the decoder  
> interact with the encoding order in the payload packets?
> Question: do we really need vendor extensibility? Answer: yes.
>
> 4.Multicast/Unicast Port Mapping Proposal
>  =======================================
>
> No draft.
> Roni Even presented.
> See http://www.ietf.org/proceedings/75/slides/avt-10.pdf.
>
> Tuesday's breakout session discussed how to deal with the port  
> assignment problem. They came up with a strawman proposal which the  
> group believes solves the problem:
> - do a two-phase operation
> - first phase to get port information to the server, server turns  
> this into a cookie and replies to the client.
> This can be done in advance, doesn't store server state, and avoids  
> reflection attacks.
> - at the time you need to do the real transaction (e.g. NAK, RAMS),  
> send the cookie by which the server can figure out the ports to use  
> for the outbound packets (both RTP and RTCP).
>
> Next step is to prepare a draft based on this.
> Do we need a charter change? do we need a milestone?
> Does WG think it's suitable?
>
> Hum taken - no hums against, some hums in favor.
>
>
>
>
>
> _______________________________________________
> Audio/Video Transport Working Group
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt



-- 
Colin Perkins
http://csperkins.org/