Re: [AVT] Notes from session 2 of AVT working group

[Roni Even <[e-mail]>]

Keith,
Thanks, look OK I have no comments
Roni

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> DRAGE, Keith (Keith)
> Sent: Tuesday, August 03, 2010 2:38 AM
> To: IETF AVT WG
> Subject: [AVT] Notes from session 2 of AVT working group
> 
> The following is the combined notes from Session 2 of the AVT working
> group. Please mail any comments or corrections.
> 
> 
> regards
> 
> Keith
> 
> -----------------------------------------------
> 
> AVT working group Friday 09:00 - 11:30
> ======================================
> 
> Keith Drage & Roni Even in the chair.
> 
> Introduction and Status Update
> ------------------------------
> 
> [Slide pack avt-0.pdf]
> 
> Slide 4 and slide 6 onwards presented.
> 
> Chairs
> 
> - Cullen will not be presenting the application-id work
> 
> - Ali wants to swap around his presentations to do cnames first, and
> RTCP port for multicast before port mapping.
> 
> - 2 RFC's published: 5764 and 5761
> 
> - 4 docs in RFC editor queue
> 
> - 5 docs in IESG processing (some blocked on revised IDs)
> 
> - 1 document dropped
> 
> - 3 documents for proto writeup (one completed last night)- new Cisco
> IPR statement received on SVC
> 
> - 1 completed WGLC
> 
> - several new and existing payload drafts -- need volunteers to review
> them. Currently only one active reviewer -- Magnus  will be be back,
> but not yet. Colin will review MIDI draft.
> 
> Ingmar: Regarding payload drafts, mainly interesting for authors -
> difficult to get others to really work on them; would it  be okay to
> just have the template?
> 
> Roni: basically right - but some people doing their first don't get the
> structure right, but you also have to look at the  content to be sure
> the content is adequate (though it's very simple in many cases).
> 
> Colin: might be useful to have a review template, a least for last call
> review.
> 
> Roni: We'll look at this. Referred to draft-ietf-avt-rtp-howto.
> 
> - 3 candidate drafts not yet adopted for WG milestones. 1 draft
> admitted as a WG item but WG draft not submitted yet.
> 
> - a selective transmission scheme as individual draft has been
> submitted; please look at it.
> 
> - RAMS base document has been submitted for publication. Still need the
> CNAME port mapping, and RTCP port for SSM since they  are companion
> drafts.
> 
> - list of other topics (see chair slides) that need prioritization so
> WG can allocate resources appropriately. Please let  chairs know what
> your preferences are.
> 
> Ali: Asked for status on multicast acquisition (draft-ietf-avt-
> multicast-acq-rtcp-xr) has it completed WGLC - is it still ok?
> 
> Answer: yes
> 
> Stefan W.: Are we going to revisit preamble? Will be leaving early.
> Keith: At end of meeting and only if time. Will be  indicative and will
> incorporate positions already expressed.
> 
> Guidelines for Choosing RTCP CNAMEs
> -----------------------------------
> 
> Ali Begen presenting.
> 
> [Slide pack avt-4.pdf]
> 
> draft-ietf-avt-rtp-cnames-00
> 
> - see Ali's slides for background and problem statement. CNAMEs should
> be unique within an RTP session; RFC 3550  recommendation for forming
> them doesn't necessariy accomplish this.
> - draft updates the guidelines for CNAMES from RFC3550
> - distinguishes persistent CNAMES from per-session CNAMES
> 
> Jonathan Lennox: What is actual per-session CNAME scope? What about
> correlating audio/video. Persistent might mean you have  the same CNAME
> over time.
>  Does per-Session apply for multiple simultaneous sessions?
> 
> Colin Perkins: I believe the draft says per "multimedia session"; you
> obviously need to use the same CNAME for lipsync. Per- session should
> say "per multimedia session" so the reader does not get confused about
> audio/video correlation.
> 
> Colin Perkins: For each RTP endpoint you didn't necessarily mean that -
> you mean "everything you want to synchronize with
> 
> Roni: Still keeping ASCII, we're not changing the RFC3550 structure,
> right?
> 
> Ali: Yes
> 
> - ready for WGLC?
> 
> Keith: The important question is whether are there open issues.
> 
> Ingmar: What about if two hosts use the same CNAME? Shared names that
> come up on satellite, etc. (e.g. cloned mac addresses)
> 
> Colin: It breaks in the same way as 3550; don't do that.
> 
> Roni: Draft won't solve all the problems but will be better than
> RFC3550, just improves probability that it won't go wrong.
> 
> Peter Musgrave: Any security concerns on persistent CNAMES?
> 
> Ali: If you want privacy, use per-session CNAMEs. There is some
> coverage in the draft.
> 
> Dave: If you want privacy, use SRTP and encrypt the RTCP.
> 
> Colin: That does not solve the problem.
> 
> Stephan: Does this document have to update 3550?
> 
> Roni: Yes, but it keeps the same structure.
> 
> Roni: So, ready for WGLC?
> 
> Stefan Wengler: The correlation with RFC 3550 needs to be dealt with.
> 
> Roni: Yes, th draft updates RFC 3550.
> 
> Keith: send email if you don't think it's ready for WGLC, otherwise
> it's going to happen.
> 
> RTCP Port for Multicast Sessions
> --------------------------------
> 
> Ali Begen presenting.
> 
> [Slide pack avt-5.pdf]
> 
> draft-ietf-avt-rtcp-port-for-ssm-00
> 
> - see Ali's slides for problem statement and description of solution.
> 
> - two possible issues - soliciting advice
> 
> Should we mandate the use of the new attribute or keep it optional? If
> it does not exist, the +1 rule will apply.
> 
> Jonathan Lennox: what about mandatory vs. optional.
> 
> Colin: Need to say what happens if it's absent in any case
> 
> Jonathan Lennox: Updating SSM (RFC 5760)?
> 
> Ali: Yes
> 
> Lennox: Then it can be mandatory, otherwise has to be optional
> 
> Ali: Consensus on this issue to cover optional.
> 
> Should we allow optional address in the attribute? Any reason why RTCP
> should be multicast in a different group? a=multicast -rtcp:42000 IN
> IP4 233.252.0.3
> 
> Colin: Nobody has come up with a need in the last 15 years
> 
> Jonathan Lennox: Probably don't want to do this for ASM.
> 
> Colin: Should update rtcpssm so people will find it.
> 
> Ali: Consensus on 2nd question not to include optional address.
> 
> Roni: Do a small update, then do WGLC. Any other issues?
> 
> Colin: This is an SDP draft, needs music review.
> 
> Keith: We'll ask MMUSIC to review it as part of WGLC
> 
> Keith: Once we get the update we'll do the WGLC and check with MMUSIC
> about their review. Again if there are other open  issues, send email.
> 
> Port Mapping Between Unicast and Multicast RTP Sessions
> -------------------------------------------------------
> 
> Ali Begen presenting.
> 
> [Slide pack avt-10.pdf]
> 
> draft-ietf-avt-ports-for-ucast-mcast-rtp-02
> 
> - This was split out of RAMS, it's a normative reference for it, needs
> to go forward quickly
> 
> - there are multiple approaches. Had a breakout in Anaheim and some
> issues came up.
> 
> - now there is the WG current draft, an alternative approach, and a
> third draft as well to consider.
> 
> - see Ali's slides for problem description and solution based on
> cookies
> 
> Open issues discussion:
> 
> - Which keep-alive method should we choose?
> 
> Answer: Guidelines for keepalive usage are already with IESG, use them
> (draft-ietf-avt-app-rtp-keepalive).
> 
> - Should we stick with 4585 packet format for cookie request and
> response? (Yes) How do we set the media sender SSRC? Use  client's SSRC
> in both packet sender and media sender SSRC fields.
> 
> Ali: Currently documented in draft and same as already specified in
> RAMS.
> 
> - Should the client use the same SSRC/CNAME in both sessions so the
> reports received in two sessions can be linked? (Yes)
> 
> Colin: If you use the same SSRC, then they become one RTP session and
> you have no issue. Need to be careful with the  terminology. If a
> single RTP session be sure to say that.
> 
> - Should the server respond if a cookie request is rejected? (Yes, with
> an empty Cookie).
> 
> No comment from working group.
> 
> - Should the server indicate the expiration date for the Cookie
> explicitly in the response message? (Yes)
> 
> Jonathan Lennox: How is time specified for expiration? Are you assuming
> it uses some notion of current time.
> 
> Ali: No. Relative time from now. You should refresh your cookie well
> before the timeout.
> 
> 
> Token-based Port Mapping (Ali Begen):
> 
> [Slide pack avt-11.pdf]
> 
> draft-begen-avt-token-for-portmapping-00
> 
> - alternative to cookie approach. Prior solution was to get cookie in
> advance, but still some people are unhappy; there is  overhead.
> 
> - see Ali's slides for problem description and solution.
> 
> Bill ver Steeg: Even though I'm a co-author on the cookie draft, likes
> the token approach better.
> 
> Token retrieval is done once, based on your IP; valid until the server
> decides it's invalid. Need only one token no matter  how many unicast
> sessions you want.
> 
> Colin Perkins: The token validates your public IP address?  What
> happens if your NAT gives you multiple IP addresses (i.e.  what about
> Carrier grade NATs?)
> 
> Bill Ver Steeg: Carrier Grade NAT is typically between the service-
> provider's network and the public Internet, whereas this  device is
> typically in the
> 
> service-provider's network.  If that's not true we should fall back to
> cookies
> .
> 
> 
> Colin: if you document those restrictions/assumption then you're ok
> 
> Roni: if token is invalid you might send back a different one.
> 
> Dave: I'm going to argue both sides of the issue.  One the one side,
> it's ugly to have solutions that make topological  assumptiions.  On
> the other hand, anything that breaks carrier-grade NATs I'm in favor
> of.
> 
> Ali: we need to decide whether token has better tradeoffs than cookie,
> who needs lots of cookies, trimers, refreshes, etc.
> 
> Jonathan Lennox: if you're the service provider and deploying servers,
> you have good topological notion but is it really true  that you're
> behind the Carrier Grade NAT?
> 
> Colin: It might be possible to unify the solutions; i.e. make the port
> optional in the cookies, if it's not present it  applies to all ports.
> Combining them is probably not more complicated than either one
> individually.
> 
> Ali: Consensus seems to be do the union.
> 
> Colin: Tastier cookies!
> 
> Roni: Do we mean that the response has either token or cookie
> 
> Colin: token+port=cookie
> 
> Jonathan Lennox: In SDP do you have some notion.
> Jonathan Lennox: What is the grouping/correlation?
> 
> Ali: All that share token.
> 
> Jonathan Lennox: As a client how do I know if an existing token will
> work with a different server? Do we need an "issuer id"?  Is there some
> way to identify whether two sessions are using the same token?
> 
> Bill (Eventually): We could add that, we need to think about it
> 
> Colin: There's nothing RAMS-specific about this; you can write the
> draft in a simpler way if you don't talk in those terms.
> 
> Ports on client and server: server ports must be different (to prevent
> RTCP ambiguity).
> 
> Roni: Tradeoff with token is that it can be rejected if you send token
> to the same place.
> 
> Colin: In SDP put something in - by the way: nothing in here is RAMS-
> specific
> .
> 
> 
> Roni: General to multicast/unicast.
> 
> Colin: The solution is actually completely general - request a cookie/
> then use a cookie. Can write the draft in a simpler  way if you don't'
> tie it to RAMS, or even multicast/unicast use cases.
> 
> Jonathan Lennox: On SDP need to be careful about per m= version
> session-wide. Portmapping-req attitribute: must be at media  level, not
> session.
> 
> Colin: Why not?
> 
> Jonathan: It would have to apply to every m= line.  It clearly doesn't
> make sense in this case (because you can't have a  feedback target for
> the multicast group) but you can imagine cases where multiple m= lines
> all have the same token server.
> 
> Chairs: Hearing that WG support for a combination approach. See on list
> if this should replace the current WG draft, then  write it up if
> people agree.
> 
> Jonathan Lennox: Some discomfort on the topological restriction issue.
> 
> Chairs: Proposed procedure - update the individual draft (and achieve
> consensus on that) then consensus call to whether to  replaced the WG
> draft with the combined proposal in the individual draft. This approach
> got WG support.
> 
> Multipath RTP (MPRTP)
> ---------------------
> 
> Jorg Ott presenting.
> 
> [Slide pack avt-9.pdf]
> 
> draft-singh-avt-mprtp-00.txt
> 
> - see J?rg's slides for problem statement and solution
> 
> - Non-goal: solve the rate adaptation problem
> 
> Jonathan: But shouldn't we make it possible to use existing rate
> adaptation solutions.
> 
> Joerg: Yes; we're looking at TFRC.
> 
> Colin: Where you have delays and multiple streams, doesn't this
> complicate the sender scheduling enormously
> 
> J?rg: Yes.
> 
> Roni: Are you seeing this as a new RTP profile?
> 
> Joerg: We're thinking about a new profile, or extension headers; we'd
> like to avoid the problem of combinatorial explosion of  profiles.
> 
> Roni: Part of it will have to address this specific signaling, how it
> will work if I don't understand MPRTP signaling.
> 
> Joerg: Part of it is you need to have an in-band indication if you
> support MPRTP.  You can start off with a single path and  add more as
> needed.
> 
> Bill: Have you given any thought to the multicast case?
> 
> Joerg: We didn't want to do everything at once, it should be added in a
> future revision; the same things should be applicable  to SSM, for
> instance, except you need to figure out how to handle receivers with
> incompatible capabilities.
> 
> In-path discovery of support for MPRTP. Prospective spec: interaction
> with SDP, SIP, RTSP; ICE; in-band
> mechanisms.
> 
> Ingamar: Brian Ford was active several years ago with multiple-stream
> support. On structured stream transport.
> 
> Joerg: I'm familiar with the work; I didn't think he was doing
> multiple-path support. I need to go back and look at his work
> 
> We've been carrying out some experiments, stress-testing multiple
> receivers.  They behave badly.
> 
> We wil need RTP/RTCP extensions for subflows, packet allocation,
> receiver aggregation. Probably best to define this as a  receiver-side
> spec. Leave the algorithms open.
> 
> Open questions: does it make sense to think about this in AVT?
> 
> Colin: in Multipath TCP, you don't care what order things arrive in, as
> long as it's quickly; for media, you do
> 
> Joerg: we need to figure out algorithms, scheduling is tricky; canned
> media can do some scheduling games.
> 
> Colin: we have things like layered and multiple-description codecs,
> which can do smart things if they know the multiple  paths, to what
> extent do we want to expose that?
> 
> Joerg: we're not defining APIs, your implementation can exploit that if
> it wants, but we don't want to require it.
> 
> Colin: tries to do some of the things using multiple sessions doe with
> layered coders etc. should this be exposed to the  application
> .
> 
> 
> Conclusion: There was interest in the working group in this work but
> for the moment would progress as an author draft.
> 
> RTCP XR Report for Real-time Video Quality Monitoring
> -----------------------------------------------------
> 
> Qin Wu presenting.
> 
> [Slide pack avt-6.pdf]
> 
> draft-wu-avt-rtcp-xr-quality-monitoring-00
> 
> - see slides for problem description and solution
> 
> Want measures for video quality for operator; RFC 3611 doesn't define
> any such metrics.  Nework-dependent factors that affect  RTP streams
> uniformly aren't enough to measure video quality.
> 
> Drive for this comes from operators: diagnose problems, root cause
> analysis, validate SLA compliance.
> 
> Network-dependent metrics (packet loss, delay, jitter) don't completely
> capture video QoE.
> 
> Proposal: six new report blocks: RTP flow sync, A/V sync, summary
> metrics
> 
> Request for WG item.
> 
> Keith: Need to discus where this goes in the priority queue.
> 
> Colin: Metrics are good. At some point someone in the IETF should do
> video metrics; these seem like a plausible set of  metrics (though I'm
> not an expert), we can quibble about details I'm sure.  Specifc points
> - to perceptual quality there are  lots of candidates and be clear
> which one you are really using. you have to be careful how you name
> them and be specific  about what you measure.  Also need to decide if
> this goes in the old architecture or if we do this like the monarch
> draft.  This seems to follow RFC 3611, not monarch. But this seems like
> a plausible starting point for video metrics.
> 
> Qin: Yes perceptual metrics need more definition and input from SG 12
> in ITU-T. For monitoring architecture scope is not  clear. Believes
> this draft follows.
> 
> Roland Schott: Good idea to do this but some concerns on scalability
> for multicast. We need to do multicast monitoring.  Metric should be in
> line with standards for  monitoring systems.
> 
> Roni: Supports what Colin said. Prior work focused on MPEG2. Need
> something general Values should be based on standards from  other
> standards bodies.
> 
> Bill Ver Steeg: A lot of this looks good; we may be looking too deeply
> into the protocol, and we need to separate stuff  that's normally in
> the clear from stuff that's normally encrypted
> 
> Some of this might be looking really deeply into the media  - what
> about crypto.
> 
> Dave Oran: This is endpoint monitoring - can be done after decryption
> in cases that it needs to look at media.
> 
> Bill: In a set-top box, it's hard to get at the encrypted stuff.
> 
> Dave: It's hard in general.
> 
> Ali: What happened to similar draft by Alan Clark from before. Why was
> it killed?
> 
> Roni: it wasn't killed, but it was told to be less MPEG-2 specific.
> 
> Colin: Prior work was all jumbled. We've been around this area in the
> past; these drafts mix metrics, e.g. I-frames, jitter  buffers, packet
> loss.  Monitoring
> 
> architecture gives guidance on how things can be combined.  I think
> that's why the previous  work didn't go forward, we were trying to work
> out how to do that. Needed to be done better.
> 
> Keith: Before we do this, we need to work out the monitoring
> architecture.
> 
> 
> Roni: And the prioritizing of the work.
> 
> 
> Keith: No new milestones at the moment.
> 
> RTCP Receiver Report for Feedback Storm Suppression
> ---------------------------------------------------
> 
> Qin Wu presenting.
> 
> 
> [Slide pack avt-7.pdf]
> 
> draft-wu-avt-retransmission-supression-rtp-02
> 
> 
> 
> 
> - see slides - first time to present in AVT - second version of draft.
> 
> Want to provide RTCP receiver report to prevent massive NACK/FIR
> implosion.  No NACK suppression in the SSM scenario.
> 
> Problem: packet loss in upstream link of distribution source.
> 
> Proposal: define new RTCP messages to handle this behavior.
> 
> Request to accept draft as WG item; encourage more review of draft and
> feedback
> 
> Dave Oran: Seems reasonable work has my support. I think this is pretty
> good stuff; there's some stuff in the draft about  scenarios and use
> cases that are less persuasive, but others are more persuasive.  I've
> already built the hack version that
> the draft thinks is a bad idea.  In the draft as currently written,
> 
> there is nothing that trips over my IPR, but I'll work  with the
> authors to avoid my IPR, or if we want those functions we'll file an
> appropriate IPR disclosure.
> 
> Colin: I've read this draft, Seems reasonable.
> 
> Bill: I read the draft, it's going down the right path, there are nits
> we can pick at but we can discuss this on the list.
> 
> Roni: We should do another revision of this draft, and then decide
> whether to take it as a WG item based on priority of other  items.
> 
> Keith: The fundamental question is if we want to do this work.
> 
> (Show of hands: some interest in the work, none opposed. Judged as
> working consensus for support but significant portion of
> don't-cares.
> 
> Chairs: Need to work to get a milestone. Seems there is WG support for
> this. Will not adopt the draft yet.
> 
> Dave: I said on the list, I'm willing to help on getting this draft
> through.
> 
> Extended Rapid Acquisition of Multicast RTP Sessions
> ----------------------------------------------------
> 
> Ingemar Johansson presenting.
> 
> 
> [Slide pack avt-7.pdf]
> draft-johansson-avt-mcast-based-rams-03
> 
> - see slides for problem description and mechanism.
> 
> Proposal based on 3 weeks of measurement from (non-RAMS-enabled)
> Swedish IPTV network. Number of zappings per minute: 350  users, in
> some cases you get 70 zappings per minute to the same channel.
> 
> Ali: We need to know whether they're changing within the same several
> hundred milliseconds.
> 
> Ingemar: Some of my colleagues have that data.
> 
> Many users change channels at the smae time (add breaks, end of
> programs), peak between 7 PM - 11 PM, change channel many  times in
> short periods.
> 
> Dave: When you do this, you need to know how many are DVRs -- DVRs
> don't need rapid channel change.
> 
> Ingemar: This data is only set top boxes.
> 
> Proposed extension to RAMS: 3xx redirect extension, two new TLV fields
> for RAMS-R and RAMS-I, carrying information for  multicast group to
> tune in to. Fast channel-change server uses RAMS unicast when request
> rate is low, switch to ERAMS when  request rate is high.  Peak load
> goes down in proportion to number of users that share the same ERAMS
> group. Provides  graceful degradation under load.
> 
> Request for this to be a WG item.
> 
> Ali: Need finer grained distributions
> .
> 
> 
> Bill ver Steeg: We discussed this this morning; I found the analysis
> fascinating and spot-on from a technical and theoretical  standpoint,
> we need to analyze existing systems, I've rarely found more than 7-8
> users that hit the same channel within the  same few hundred
> milliseconds.  I'm not sure this applicable to today's deployments.
> 
> Colin: There was a paper in IMC a few years back analyzing channel-
> change behavior for a quarter-million households, I  believe the data
> set is available (Telefonica).
> 
> Bill: I'll put that link to the list.
> 
> Keith: would this be informational or proposed standard?
> 
> Ingemar: It would need to be standards track. Defines protocol.
> 
> Roni: I think we need more analysis of user behavior from the
> references we got, to see if it makes sense and the uses cases.  It
> sounds like people think the technical topic is interesting, but they
> need more input about usefulness.
> 
> Keith: We need to figure out where this fits in our priorities --
> suggest carrying on with it as an author draft, taking this  input.
> 
> MPEG2-TS preamble discussion
> ----------------------------
> 
> draft-begen-avt-rtp-mpeg2ts-preamble-05
> draft-xia-avt-mpeg2ts-preamble-02
> 
> Keith returned to the subject of the MPEG2-TS preamble to get some
> feedback from the working group. MPEG2-TS breakout didn't  form any
> conclusions.
> 
> Appeared only about 50% of those present had read the two drafts.
> 
> Ingemar: I've read the draft, but have no experience of the actual
> hardware limitations.
> 
> Have people seen enough technical information to make a decision, or do
> they want more technical information?
> 
> Roni: There's a difference between what's written on the draft, and the
> discussion on the list.
> 
> Hands: Very few either in terms of seen enough for a decision or want
> more technical discussion.
> 
> Keith: no consensus; it's your responsibility as members of the IETF to
> decide what's the best forward for the Internet, and  you must all form
> an opinion on the best way forward. (Note discussions on list are
> raising comments that would appear to  justify a revision of both
> drafts.)
> 
> Close of meeting, unless there's anything else anyone wants to raise.
> _______________________________________________
> Audio/Video Transport Working Group
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt