[AVT] AVT minutes

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

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt