AVT meeting notes - Prague - note takers Alan Clark, Stephan Wenger Monday, 19 March 2007 at 13:00-15:00 (Roma/Vienna/Madrid) -------------------------------------------------------- 13:00 Introduction and Status Update (Chairs, 15) 1:15 tape Tom Taylor (TT): Notes (Alan Clark, Stephan Wenger), scribe (no one on jabber) TT: Agenda (no comments) TT; IPR policy review TT: Document status, 4733, 3734, 4855, 4856, 4788, 4629, 4628, 4695, 4696 all published TT; with RFC editor: hc-over-mpls, amr-bis payload TT; IESG: savpf, hdrext, toffset, ulp, smpte very soon as well TT; WGLC: rfc3047bis, rtp-and-rtcp-mux, rfc2833biscas (three weeks on those) 1:20 tape Ingemar Johanssom (IJ) non-compound RTCP IJ presentation of slides (pretty verbatim) arguments for - shorter serialization time (long RTCP packets leads to more jitter) - can send more frequent feedback - more robust on links with mtu size limits 3gpp example - header compression PDCP layer, fragmentation in RLC layer - under bad channel conditions block sizes smaller and hence more risk of segmentation Gave simulation example - showed that compound RTCP degrades faster than RTP Using non-compound RTCP - middle boxes may discard - old RTCP receivers may discard - PT of RTCP may vary from 200/201 Leads to new requirements - compound RTCP should be maintained - non-compound should be allowed in early/intermediate AVPF framework - need verification that non-compound RTCP is received (otherwise would not know if network and far end accepts) Joerg Ott (Jo): We had this before during AVPF design. This is link layer optimization stuff, why should the rest of the Internet care? Benefit for congestion control profile (TFRC) to be checked, cross-check in conjunction with Ladan's draft on Wednesday suggested. IJ: lower layer optimization main target, 3GPP issue voip Stephan Wenger (SW): if you fix a 3GPP problem, fix it in 3GPP Roni Even: its more than 3GPP issue, JO: if there's a bigger picture, then we should discuss a bigger picture not this locatliced solution RE: This does not only address 3GPP, do we want to have it in AVPF only, or also in other profiles? Draft says AVPF only. Agree with Jo. Magnus Westerlund (MW): applicable to a number of use cases. AVPF is the key profile Jo: Remind AVPF has been forced to remove any form of positive ACK, as it is Congestion Control, which was 3 years ago non P.C. SW: bring just one use case and I'm more comfortable with it MW: TFRC is this one use case SW: let's take this up again in TFRC context Carsten Bormann (cabo): RTCP compression draft-bormann-something Jo: even over 3GPP links, you send some stuff that is not compressed by said draft Colin Perkins (CP)as chair: general interest, probably useful, extended requirement discussion needed, details over next couple of meeting, if there's a general use case, we continue with this. 1:40 tape Thomas Schierl (TS), sdp mmusic layer codec TS presentation of slides, removal of SSRC mux CP: use cases (1) and (2) (on SSRC mux) are not useful use cases, decision to remove SSRC mux OK 1:45 Stephan Wenger (SW): svc payload SW: presentation of slides Reviewed changes from ID to WG-00 draft - aligned with JVT joint draft 8 - removed SSRC mux, now doing session mux - IPR declaration related to PACSI header SSRC discussion - happy to remove SSRC multiplexing Open issues - continue on packetization/ de-packetization rules - alignment with SVC spec - think about usage of layer codec in SDP offer/answer - same story for declarative session description - capability - two choices, 1- try do in this draft , 2- leave to a revision SW: capability negotiation in this draft? RE: good idea to work with media capability negotiation group, they look for more complex applications. SW: concern re timing RE: regular offer answer in draft only, capability negation support in second draft SW: yes, let's do that RE: timing? SW: WGLC in Chicago Thomas Wiegand: media spec frozen 95% in April, 100% in July RE: RFC number out quickly for non-IETF citations CSP: WGLC to RFC: at least 3 months 1:57 tape Tom Kristensen (TK) H.264 extensions 13:50 H.264 Payload extensions for RDCO and Static Macroblocks(Kristensen , 15) draft-kristensen-avt-rtp-h264-extension-00.txt Static macroblocks - some macroblocks don't change (static), frees processing time for non-static blocks - parameter related to number of static macroblocks Reduced complexity decoding operation (H.241 Annex B for H.264 Baseline) - can reduce decoder complexity by 30% and encoder by 15% - propose new MIME (Tom - Media) type - as RCDO is distinct from H.264 profiles and not compatible with H.264 baselines TT: media sub-type instead of MIME subtype CP: too many subtypes is not a good thing, as it hinders interop SW: Background: contention in ITU-T, non-compatible change to H.264, specified in a spec where it should not belong. New subtype is not only useful but required, support both proposals, two different drafts suggested, as MB processing is useful outside H.264 RE: two separate topics, re static MBs, H.241 low complexity codec. Static MBs:how to define a mechanism that allows us to extend parameter space without re-issuing RFCs. SW: WRT. H.241 extension, idea to include codepoints in a container; RE: not what I want to do SW: ok with me then TK:Max MBs also useful for SVC draft Thomas Wiegand: clarification of low complexity: RCDO bitstreams can be decoding, it just looks horrible. Practically, different subtype is needed. SVC people are looking at static MBs; likely we will see similar vision of decoding processing power as in H.241 SW: should be done codec independently, perhaps there's even more stuff that could go into that draft CP: there is no such thing as a generalized parameter mechanism SW: Informational RFC how to write a payload format for video codecs CP: feel free to write it MW: send it to me for the "how to write a payload draft" draft TK: So to summarie: one draft? No, two draft Thomas Wiegand: making things too generic is dangerous, no need to promote 10 year old codecs CP: if there's a need for a mechanism applying to more than one codec, then more than one codec payload spec needs to be updated: have not sensed any enthusiasm in doing that RE: in fact, we try to freeze H.261/H.263 payloads by moving up standard's track TK: split the drafts RE: RCDO: separate draft, as no interop of the two profiles. Static MB: have a new draft, these are new parameters added to H.264 payload, to be folded in later TT: media type registrations have to be referred to media-types list in time RE: draft is not formally OK yet. 2:13 tape 14:05 Issues with TMMBR (Westerlund, 20) draft-ietf-avt-avpf-ccm-04.txt Issues - session maximum bit rate is not well defined - what is bit rate - media encoding, payload, stream..... sender/ receiver - is a single value sufficient? use a token bucket? - easier to keep a single value - proposal to calculate a smoothed reception rate (over a second or more) - sender should not be too bursty RE: Do you want to discuss traffic shaping? MW: no. Perhaps one paragraph only; assumption: sender is well-behaved. RE: bandwidth definition broken not only in CCM, but also everywhere else (i.e. SDP) - varying overhead due to protocol stack - may be different for sender and receiver - discussed on mailing list RE: 3890 is about MtU size - proposed to use average bits/sec plus average overhead - showed chart comparing three different link speed/ overhead scenarios - need to consider range of scenarios/ topologies but think these are covered - described method of selecting lowest bandwidth and highest but rate, compute highest packet rate possible TT: Is this basically a linear programming problem? Known solutions. But this is not quite such a problem MW: there are also other factors that do not permit straightforward linear optimization, i.e. congestion control RE: don't always know beforehand the packet rate, need to make assumptions MW: yes, but that shouldn't be a problem in practice (example: video). MW: it's the media sender's implementation problem to find the right packet rate, overhead, packet size - may be cases where there is a hard time but many decoders have some form of bit bucket or rate limiting - TMMBN contains info on limitations produced by media sender's usage of algorithm Guido Franciscini (GF): minimized state-keeping is an implementation issue, media server may have a database of info MW: algorithm has properties beyond resource saving... RE: Confused remark re several session GF: no, that's not his thing. Suggest media server keeps data base on all received TMMBR requests, MW: this may be an option, but it has impacts on how you update things, larger RTCP traffic GF: when media sender raises value, you may congest receivers. MW: yes, but you need to use congestion control anyway. MW: no database, MW: if there's something really broken, speak up now. Otherwise we'll go to new last call CP: Having seen presentation, this makes sense. But cannot derive this from the draft. Clean up language SW: Within a week 14:25 Bandwidth Metrics for bottleneck characterization(Franceschini, 15) draft-franceschini-avt-bwmetrics-00.txt 2:40 tape Verbally declared IPR related to draft, draft at present informational, no direct relation and no IPR on Magnus idea CP: need to submit formal IPR disclosure - TIDC - transport independent downlink capacity - method for calculating mean packet overhead - jointly consider multiple media streams (RTP session) - advocates use of RTCP to manage the link capacity allocation - recommends session level TIDC CP: seem to assume that there is only audio and video; this is the IETF, you have to consider all traffic types (including TCP traffic) GF: trying to manage what can be controlled, other traffic types may not be controllable SW: don't think link optimization should be discussed in AVT CP: should take work to WG that works on QoS GF: this is the same concept as TMMBR? CP: No it's not, this is link partitioning, which is against congestion control principles GF: Example of partitioning again CP: you can't do this GF: TMMBR is used to partition link CP No GF: instead of having one TMMBR for audio and one TMMBR for video, let's have one for both TT: choose payload type to combine them Crowd: NO CP: TMMBR is link capacity. MW: TMMBR specific to one source, one media. does not say whether it is used for audio and video separately or together, context of RTP session RE: use case of TMMBR for media codec type changes SW: Is in RTCP RR, and pertains to one media sender in one RTP session, not to the link. SW: If you wish to fine-tune operation points between multiple codecs, send TMMBR on all sessions you have, SW: in multicast or layered codec scenario this draft would not work SW: is this an algo description how to generate multiple TMMBR messages on optimizing link: write it up as informational RE: over time, list GF: OK CP: interested people should meet offline, hash out meaning of TMMBR. MW: after TSV Area tomorrow afternoon CP: send it to the list 14:40 Source-specific SDP attribute (Lennox, 20) draft-lennox-mmusic-sdp-source-attributes-00 3:00 tape Source specific attributes - SDP can't signal things related to multiple sources in an RTP session - describe/ differentiate between multiple SSRCs from the same participant in the same RTP session - e.g. multiple cameras, FEC, based vs enhanced, layered codecs... Issue CP: isn't this done by CNAME? Jonathan Lennox (JL): No CP: you want to say what the sessions per SSRC are about? JL: Yes - SDP Media Stream describes RTP Session - suggest using Media Source term Implications for RTP - SSRC changes - must not reuse signalled SSRC - but still could have problem due to race conditions Proposed approach - give signaled SSRC precedence - signaled SSRC's should not collide but if they do then use normal algorithm to resolve - signal updated SSRC Backward compatibility problems - many endpoints can't hand RTP sessions with multiple sources or may not have decoding resources - could cause anarchic behavior in badly designed endpoints Dave Oran: can this ever happen on a non-broken endpoints, and if an endpoint is broken this won't fix it JL: Yes, can happen (some discussion, no conclusion) Henning Schulzrinne (HS): complexity issue. Also seems fairly close to XCON - suggests discussion should be broader and potentially relate to multiple parameters JL: talk is fine, but we don't want to map everything into XCON Henning Schulzrinne (HS): have architecture discussion, decide where things belong beyond this one single parameter Ken Toney: talking about the same SSRC with different source/ destination? JL: semantics are as in RTP session, SSRC generated by single endpoint, one entity CP: relationship to SDES items? Could also signal language etc in SDES JL: probably went overboard with the details of his SDP-based descriptions CP: need to decide and create guideline: do we convey it in SDP or in SDES - reviewed architectural issues - AVT review - any architectural issues overlooked? SDES issue Close of session 3:18 on tape =================== Wednesday, 21 March 2007 at 15:10-16:10 (Grand Ballroom) -------------------------------------------------------- 15:10 RTCP HR (Clark, 15) draft-ietf-avt-rtcphr-00.txt 3:32:30 on tape ietf68-ch5-wed-noon Issues and concerns - removal of topology-related material - general cleanup following comments - suggestion to negotiate sub-blocks in SDP Aligning w/ SG 16 reqts for use in H.248 - aiming to finish mid-2007 Topology stuff: not so easy to remove everything. Have to provide guidance on how to calculate metrics and what to propagate when there are devices like bridges in the path. Colin: describe how to calculate metrics when the device does and when it does not terminate the RTP session. Alan: agreed. - Colin suggestion: refer to topology draft as much as possible. Too late to move anything else into it. No comments received on the actual metrics. Some people have already implemented the current draft. Hence just have to address the sub-block negotiation – whether to use the SDP to allow end points to negotiate which parts of the report to receive. Authors willing to do it if it is desirable. Roni Even: what is the requirement for the application to negotiate which parts to receive? Alan: not sure. A major service provider requested the capability. Alan can probe to find out what the issue is. ** Use case requested. 15:25 RTCP XR video Metrics (Clark, 15) draft-ietf-avt-rtcpxr-video-00.txt Tape: 3:42:00 Metrics for video over IP is an active area of study. Rather than compete with other work in progress, authors want to take advantage of it. Draft concentrates on RTP transport. Also covers Forward Error Correction (FEC) related statistics. Also bear in mind the requirement in mobile to keep packet sizes small. Roni: the draft seems to show audio and video in same block. This is correct only for MPEG transport streams. There are no guidelines for other cases. Should Al Morton –- reduced vs no reference -- should wait until that question is resolved, to see if there is any value in carrying references at all. Dave Oran: this is a matter of whether you have an elementary or transport stream – mark each block with the type of content measured rather than using an arbitrary metric to combine them. Alan: the intention is to match an MPEG programme stream when that is involved. Colin – try keep structures as general and transport-independent as possible. Preserve the commonality of the statistics captured while using different block types to report on different content types. Alan: currently these are metrics relating to MPEG using RTP transport. Could try to create common framework. Colin: No shortage of RTCP report types -- have used only 6 of 256. Suggests using that level rather than one report type with a bunch of sub-blocks = yet another layer of multiplexing. Suggests a set of drafts each defining a report type. All get bundled into a common RTCP report. Alan: Could end up with 6-8 drafts. Colin: so? Each draft should address one problem. Accommodating FEC: pre- and post loss rates, burst density/length, loss periods. Dave Oran: people want to derive from the metric how close to the edge they are. Can these metrics give that? Alan: yes. Burst metrics very useful for this purpose. Mark Watson: number of lost packets within an FEC block is the item of interest. Saw in graph that the burst legth is time based, but something based on FEC block size (=time) would be most useful. The metrics in the draft are an improvement, but metrics based on the time scale of FEC block would be most useful. Alan: instrument FEC coder? Mark: metrics are used to decide whether to use FEC and which FEC coder to use. Dave: may be sending FEC streams separately from the main media stream. Can't just use the source stream to tell what is going on -- have to consider in some cases the losses in the FEC streams (though this is a second-order effect). QoE metrics – being defined elsewhere. They tend to involve IPR. Cullen Jennings: are we defining metrics? As AD he would not expect we have expertise to do so. Alan: not defining them, just implementing what others have been defined. Kaynam Hedayat: Problem – draft refers to metrics for which a standard does not exist. Concentrate on metrics that are standards. Otherwise we will run into the problem that audio shows, where it is hard to correlate results from different networks. Also avoid metrics that are relevant to audio but not to video. Dave – report inputs to metrics, then receiver can apply – much better architecture. Kaynam: agreed. Dave reiterates, Colin agrees. Alan: disagrees w/ Keynam's point re RFC 3611 -- millions of end points reporting successfully. Endpoint can do real-time correlation, other entities cannot – lose info when averaging. Some metrics are place holders for work in progress, are being replaced as MOS metrics become available ifrom other bodies. 15:40 RTCP XR IPTV Metrics (Hedayat, 15) draft-venna-avt-rtcpxr-iptv-00.txt Tape 4:10:00 Purpose is to define raw metrics that serve as basis for others to calculate derived values. Also aiming usage at operations rather than algorithm refinement. - take advantage of IPPM metrics - "yard-stick" measurements for the industry - based on experience from tier 1 & 2 ntwks - TS-level main block: packet-level program sub-block – per program elementary stream sub-block Looking for feedback. Especially interested in IPTV application. Mark Watson – have to support everyday operation – constantly changing network characteristics and FEC algorithms have to change with them. Alan – draft deals with MPEG transport streams and not RTP. Is this in scope for AVT? Kaynam -- there is RTP-related- define raw metrics Colin – focus of this group is RTP-based media. Kaynam assures that MPEG transport over RTP is involved here Alan – look into tunneling protocol over RTCP transport Colin – be very careful to keep in step with IPPM -- Transport AD concern. Alan – IPPM found some stuff out of scope – suggestion that we may need a BOF to consider application performance in general Colin – ADs aware of issue -- something may happen in the near future. 15:55 RTP with TCP Friendly Rate Control (Gharai, 15) draft-ietf-avt-tfrc-profile-07.txt Tape 4:18:00 How to support required transfer of control information between a TRFC sender and receiver in RTP/RTCP. Would like feedback on whether the protocol and language of the draft are correct. Draft modified, now uses two new header extensions rather than a profile. One is for the round-trip time, the other for the send timestamp. It is not necessary to send the round-trip time every time, so making it a separate header extension saves a few bytes on the average. Some concern whether the send timesatmp field is long enough. Colin: suggests making the send timestamp relative to the RTP timestamp, to save bits. Alternative breakout would be to use one extension for send timestamps only, the other for combined send timestamp plus round-trip time. Plus RTCP feedback to send back the receiver feedback. [Some discussion of what feedback message type number to use.] Some concern over data volume. RTCP packet comes to 100 bytes, but TRFC wants feedback once per round-trip time. Jonathan Lennox: assumes that RR always has a report block – not sure that this is required. Magnus says RFC doesn't say anything about it. Jonathan: leave them out of early RTCP, include only in the regular RTCP reports. Colin: can overflow if too many. Jonathan: what if one is too many? Another point: Feedback is on an SSRC basis, which seems right, but TRFC would presumably span the whole session. If there is more than one RTP source with the same IP, have to report on all of them. Example: multiple cameras. Unicast at the transport layer, but multiple SSRCs. Magnus: Really have to look below the RTP/RTCP layer. Colin: may have to say this works only for two participants (i.e. one SSRC per end point. Some nasty interactions possible, have to be considered. May need more than 5% for RTCP feedback in some cases, will have to be signalled. JonL: need to know RTT before signalling! Need specific AVPF settings for transmission intervals. Magnus: the settings affect only the regular RTCP reports, not the early feedback. Connclusion: don't have to discuss this point. Moreover, do not toggle allow_early. Magnus: the toggling guards against excessive bandwidth consumption by early feedback packets. Colin: implies you have to set your RTCP bandwidth high enough that this wasn't a problem. Stephan Wenger: hasn't read the draft, expects he would have one - discuss on list in the coming week. For SDP signalling (rtcp_fb attribute): need a payload type value. What would that be? Magnus: use "*". TMMBR report (draft-ietf-avt-avpf-ccm-04.txt reprise) Tape 4:35:10 Stephan Wenger reported. Plan to clean up and then have a language pass over the next week. Key point is to make clear that TMMBR pertains to a single media stream, not a link. Also will give example of usage that is different from link capacity restriction. Will make clear that algorithm is not mandated provided that the algorithm used gets the same results. Further point: in the congestion control section, must bring out the point that congestion control may require a rate lower than that called for in TMMBR. When the media sender concludes that bandwidth can increase, it must wait two round-trips to see if another participant has a tighter restriction. Overhead is defined more clearly. Roni had a couple of additional points, since he was unable to find the meeting, but these have been addressed. Comment: Jonathan L: might have to wait more than two round-trip time. Have also to wait until the receiver can send another feedback message -- may just have sent one. Magnus: sender may have difficulty knowing receiver's timings, but point is valid. Colin also agrees. Stephan: make informed guess based on the size of the multicast group. Will float ideas on list. 16:10 End