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

I forgot to add my thanks to Dave Oran and Jonathan Lennox for taking the notes of the second session.

Could I also ask that any comments or corrections to the notes arrive by this coming weekend, i.e. so I can complete the notes for the proceedings on Monday 9th August.

regards

Keith

> -----Original Message-----
> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On
> Behalf Of DRAGE, Keith (Keith)
> Sent: Tuesday, August 03, 2010 12: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
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt
>