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

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 3 Aug 2010 01:38:01 +0200

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.

---

From: Roni Even <[email-masked]>
Date: Tue, 03 Aug 2010 08:53:59 +0300

Keith,
Thanks, look OK I have no comments
Roni

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 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
> 
> - Ali wants to swap around his presentations to do cnames first, and
> RTCP port for multicast before port mapping.
> 
> - 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).
> 
> - 3 candidate drafts not yet adopted for WG milestones. 1 draft
> admitted as a WG item but WG draft not submitted yet.
> 
> - 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.
> 
> - 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.
> Jonathan Lennox: What is actual per-session CNAME scope? What about
> correlating audio/video. Persistent might mean you have  the same CNAME
> over time.
> 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
> 
> Ingmar: What about if two hosts use the same CNAME? Shared names that
> come up on satellite, etc. (e.g. cloned mac addresses)
> 
> Roni: Draft won't solve all the problems but will be better than
> RFC3550, just improves probability that it won't go wrong.
> 
> Should we mandate the use of the new attribute or keep it optional? If
> it does not exist, the +1 rule will apply.
> 
> 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
> 
> 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.
> 
> - 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.
> 
> - 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 indicate the expiration date for the Cookie
> explicitly in the response message? (Yes)
> 
> - alternative to cookie approach. Prior solution was to get cookie in
> advance, but still some people are unhappy; there is  overhead.
> 
> 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
> 
> 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.
> 
> 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?
> 
> 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.
> 
> 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]
> 
> Colin: Where you have delays and multiple streams, doesn't this
> complicate the sender scheduling enormously
> 
> J?rg: Yes.
> 
> 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.
> 
> 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.
> 
> 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 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.
> 
> 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.
> 
> 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.
> 
> 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
> 
> 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.
> 
> 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
> 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.
> 
> 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.
> 
> (Show of hands: some interest in the work, none opposed. Judged as
> working consensus for support but significant portion of
> don't-cares.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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).
> 
> 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.
> 
> 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.
> 
> 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.)
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 3 Aug 2010 12:50:49 +0200

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

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of DRAGE, Keith (Keith)
> Sent: Tuesday, August 03, 2010 12:38 AM
> To: IETF AVT WG
> The following is the combined notes from Session 2 of the AVT
> working group. Please mail any comments or corrections.
>
>
> regards
>
> Keith
>
> - Ali wants to swap around his presentations to do cnames
> first, and RTCP port for multicast before port mapping.
>
> - 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).
>
> - 3 candidate drafts not yet adopted for WG milestones. 1
> draft admitted as a WG item but WG draft not submitted yet.
>
> - 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.
>
> - 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.
> Jonathan Lennox: What is actual per-session CNAME scope? What
> about correlating audio/video. Persistent might mean you have
>  the same CNAME over time.
> 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
>
> Ingmar: What about if two hosts use the same CNAME? Shared
> names that come up on satellite, etc. (e.g. cloned mac addresses)
>
> Roni: Draft won't solve all the problems but will be better
> than RFC3550, just improves probability that it won't go wrong.
>
> Should we mandate the use of the new attribute or keep it
> optional? If it does not exist, the +1 rule will apply.
>
> 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
>
> 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.
>
> 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.
>
> - 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 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.
>
> - alternative to cookie approach. Prior solution was to get
> cookie in advance, but still some people are unhappy; there
> is  overhead.
>
> 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 .
>
>
> 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.
>
> 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?
>
> 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.
>
> Colin: In SDP put something in - by the way: nothing in here
> is RAMS-specific .
>
>
> 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.
>
> 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]
>
> Colin: Where you have delays and multiple streams, doesn't
> this complicate the sender scheduling enormously
>
> J?rg: Yes.
>
> 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.
>
> 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 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.
>
> 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.
>
> 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.
>
> 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
>
> Dave Oran: This is endpoint monitoring - can be done after
> decryption in cases that it needs to look at media.
>
> 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.
>
> Want to provide RTCP receiver report to prevent massive
> NACK/FIR implosion.  No NACK suppression in the SSM scenario.
>
> 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.
>
> 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.
>
> (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.
>
> 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.
>
> 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.
>
> 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
> 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).
>
> 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.
>
> 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.
>
> Have people seen enough technical information to make a
> decision, or do they want more technical information?
>
> 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.)
>