Subject: RE: R: [AVT] CCMdraftreview-- should"bandwidth"includetheheaderoverhead

From: "Allison, Art" <[email-masked]>
Date: Fri, 23 Feb 2007 09:25:06 -0500

Guido,
Thanks for the response, especially the equates_of_termonology (AhHa!).

It seems to me that signaling the individual codec bit-rates is less desirable than signaling the IP gross bitrate in "TMMBR"  with respect to the goal of managing lip sync . 

If codec level signaling were chosen, then a means to /somehow/ determine that the components have gotten out of synch would seem to be needed in order to avoid the unintended result of unpredictable and uncontrolled lip-sync variance. 

A IP gross bitrate approach would also seem to better accommodate adding new time sensitive elements without having to go back to the fundamentals because the added element interfered with the main stream flow through a constriction. Examples: Teletext, Closed Captions, web references to overlay (vs pop up) during advertisements, etc.

<acknowledge this is only a factor to consider, not a trade-off of all system needs>
::{)
Art

_____________
Art Allison
Director, Advanced Engineering
Science & Technology
National Association of Broadcasters
1771 N Street, NW
Washington, D.C. 20036
Phone: 202.429.5418
Fax: 202.777.4981
[email-masked]

The National Association of Broadcasters is a trade association that advocates on behalf of more than 8,300 free, local radio and television stations and also broadcast networks before Congress, the Federal Communications Commission and the Courts.

-----Original Message-----
From: Franceschini Guido [mailto:[email-masked]] 
Sent: Friday, February 23, 2007 4:50 AM
To: Allison, Art; [email-masked]
Subject: RE: R: [AVT] CCMdraftreview-- should"bandwidth"includetheheaderoverhead

Allison,

I somehow addressed this type of issue in my draft.
In my view, this is part of what I called "cross-media relations". I specifically addressed:
   o  the impact of video packet sizes on audio jitter, in case audio 
      and video RTP packets get serialized on the physical link; 
   o  the impact of audio packet rate (and thus overhead) on the 
      bandwidth that remains available for the video. 

The key aspect of this "cross-media relations", at least in my view, is that they require the bottleneck characterization to be expressed at session level and not at media level.

Let me make a bit of history:

The main discussion in this thread is around the TMMBR feedback message (or whatever it will be re-named).

Initially, two proposals were made for TMMBR: to signal the codec bitrate, or the IP gross bitrate.
IMO, both solutions are more or less inaccurate, depending on the protocol stack running in the bottleneck.

I made than the proposal of using a tuple (TIDC, MPO), measuring the bottleneck capacity at a layer X, where such layer X need not be know at the recipient of the signalling message, and may be choosen by the generator of the bottleneck description.
My proposal (in my opinion of course), is no worse than previous ones, since the generator of the bottleneck description can still measure the capacity at the media level, or at the IP level. However, the generator of the bottleneck description has also the opportunity to provide a more accurate description by carefully selecting the layer X: this makes my proposed metrics preferable with respect to the other solutions.

So far, we are still talking about media level parameters.

The usage of media level parameters avoids jeopardizing the specification efforts, since it is just a matter of specifying the metrics to be used, and adopting them in both SDP and an RTCP feedback message. No architectural impact.

The kind of problem you raise, is however NOT addressed by this kind of solution, since the entity that generates the bottleneck info somehow decides how to subdivide the total bottleneck capacity into a portion dedicated to the audio and a portion dedicated to the video. 
This reduces the ability of the sender to make the best decision about how to encode and deliver audio and video: indeed, the sender will not receive the genuine information, but pieces of information filtered by outside logics. Hence its decisions will be less then optimal.

In my draft I showed how, in a real-life use case, the signalling of the bottleneck capacity (actually: the TIDC parameter) at session level instead of media level, allows the sender to keep control of the audio jitter induced by the video packetization, to accurately calculate the portion of bottleneck capacity consumed by the audio flow, and assign the remaining to the video flow, thus optimizing the video quality.

Unfortunately, signaling session-level parameters through RTCP feedback is, as far as I know, new.

More feedback inline.
Guido

> -----Original Message-----
> From: Allison, Art [mailto:[email-masked]]
> Sent: giovedì 22 febbraio 2007 15.25
> To: [email-masked]
> Subject: RE: R: [AVT] CCMdraftreview-- 
> should"bandwidth"includetheheaderoverhead
> 
> 
> 
> When considering content flow rate control, it seems to me that the 
> additional complexity of adjusting the audio flow rate needs to be 
> considered and has not been brought up on list.

Actually I tried, but with no feedback so far. Maybe your message is more clear.

> In order to enable retention of lip-synch within acceptable tolerances 
> the content packets (that are inside  the IP packets) need to arrive 
> within the buffer model design constraints.  The buffers can deal with 
> temporary variations, but a systemic differential change in the rate 
> for video and not audio could lead to, for example, audio frames 
> arriving early compared to video and being forced to be rendered (or
> dropped) due
> to the need to empty the buffer. One would expect  jumps in the amount 
> of audio offset with respect to the video when the flow was 
> differentially adjusted. Experts in the tolerance allowable differ in 
> the allowed amount, but whatever the amount, it can be exceeded in 
> this scenario.

I am not sure whether a differential-delay problem really exists, as far as congestion is succesfully prevented. But there is a somehow similar issue (and maybe we are stating the same): an RTP packet requires time to go through a bottleneck, and this time changes when the bottleneck capacity changes. Suppose you have audio+video, with video packets of, say, up to 1500 bytes (12000 bits). If you started with a bandwidth of 40000 bit/s, your video packet would take 300ms to go through the bottleneck. If RTP packets flow serialized through that bottleneck, this means that if an audio packet arrives just before that video packet, it would enter immediately the bottleneck; if instead it arrives just after, it will wait 300 ms before entering immediately the bottleneck. This is jitter!
And when the bottleneck capacity changes, also that jitter figure changes: this in turn would impact on the receiver.
The sender should try to keep that jitter figure constant across variations in the bottleneck capacity, but this work would be more precise if the bottleneck description it gets relates to the link in general, and not to the portion of the link capacity that some other entity decided to assign to the video.

> This need to keep the program elements 'close enough' in time is a 
> total content requirement that seems to me to indicate the signaling 
> of one element may introduce an additional complexity requirement in 
> the end receiver. If each element is controlled the receiver would 
> seem to need to compute how close to its buffer limits it is operating 
> and then signal changes in rate of the program elements differentially 
> to retain lip-synch.
> 
> Sorry, but I do not know how to translate this meta-issue into the 
> flow control means being discussed here; and merely suggest that those 
> that are expert in such consider the need for lip-synch for consumer 
> acceptance.
> 
> Art
> _____________
> Art Allison
> Director, Advanced Engineering
> Science & Technology
> National Association of Broadcasters
> 1771 N Street, NW
> Washington, D.C. 20036
> Phone: 202.429.5418
> Fax: 202.777.4981
> [email-masked]
> 
> The National Association of Broadcasters is a trade association that 
> advocates on behalf of more than 8,300 free, local radio and 
> television stations and also broadcast networks before Congress, the 
> Federal Communications Commission and the Courts.
> 
> -----Original Message-----
> From: Franceschini Guido [mailto:[email-masked]]
> Sent: Thursday, February 22, 2007 3:49 AM
> To: Desineni, Harikishan; Magnus Westerlund
> Cc: [email-masked]
> Subject: RE: R: [AVT] CCM draftreview-- 
> should"bandwidth"includetheheaderoverhead
> 
> Hari, Magnus,
> 
> > > It is clear that inaccurate packet-rate guesses determine
> inaccurate
> > TIDC
> > > values, and that this effect is huge at the APP level, but
> > reduced at
> > the
> > > IP level, for such a stack example.
> > 
> > If we have to work at a common layer (IP) (which results in not so 
> > inaccurate TIDC values), estimating (max) packet rate is anyways 
> > necessary for other media types like video. In your example, the 
> > header overhead looks huge due to the fact that it is
> applied over a
> > speech stream. The header overhead bit-rate of a video
> stream may not
> > be significant when compared to actual video (RTP Payload) bit-rate 
> > alone.
> > I.e., header overhead due to inaccurate video packet rate
> may not be
> > significant. In some topologies like point 2 point, it
> might even be
> > possible for the sender to signal its actual packet rate. Average 
> > measurement of header overhead can be used to correct/signal/detect 
> > header overhead inaccuracies.
> 
> It is true that in my example, as well as in most practical cases 
> related to video, the inaccuracy due to the selection of the IP layer 
> combined with a badly-guessed packetrate is negligible.
> In my draft I outlined another real-life example, with a much more 
> complex (and unefficient) stack, where below the IP layer there was 
> still plenty of stuff, making that inaccuracy more significant. 
> However, in that case the bandwidth was higher, thus a conservative 
> approach would not be too much of a penalty.
> Indeed, in order to prevent congestion, the terminal providing the 
> bottleneck characterization is required to provide a conservative 
> description, thus to assume the highest packetrate that is potentially 
> possible.
> 
> The message I am trying to convey is anyway the following: when 
> characterizing a bottleneck, there could be many causes that lead to 
> an inaccurate description. By means of the metrics I am proposing, at 
> least one of such reason (the metrics used) can be controlled.
> This would apply to a large variety of protocol stacks (I am hesitant 
> to say 'all' protocol stacks, but certainly many more examples that 
> would be reasonably covered by picking either the media-bitrate or the 
> IP-gross bitrate).
> Since, in order to prevent congestion, every bottlenck description 
> should stay on the safe side, the consequence of an inaccurate 
> measurement is that the measurement data that is signaled would 
> potentially lead to a sub-utilization of the available resources at 
> the bottleneck.
> 
> If a receiver makes the perfect choice for the measurement point 
> (e.g.:
> the PPP layer in the PSTN example) the accuracy is optimal, and the 
> tuple provided allows the sender to maximally exploit the bottleneck 
> resources; if the receiver makes a different choice (e.g. the IP 
> layer) the accuracy is less than optimal, but the tuple it would 
> provide is still neutral, i.e. transport stack protocol independent.
> The sender will probably exploit a bit less of the bottleneck 
> resources.
> The practical impact could be negligible in many cases. Thus, 
> referring again to the PSTN stack example, if I have an implementation 
> that knows well about its protocol stack, and provides the perfect 
> tuple:
> TIDC(PPP)=36
> MPO(PPP)=48
> very good.
> If instead I have a more generic software that only accounts for the 
> IP impact and provides the tuple <33, 40> (with an implied packetrate 
> of 50), then this is a bit less accurate; if my implementation finally 
> provides a tuple measured at the codec level such as <17, 0> (again 
> with an implied packetrate of 50), then this is quite less accurate.
> The recipient of this tuple will manage the information contained in 
> the tuple in a neutral manner, i.e. it does not need to know the exact 
> stack at the bottleneck: its computation will be more or less 
> optimized depending on the accuracy of the tuple provided, i.e. 
> optimal if the tuple referred to the PPP layer, a bit less perfect if 
> the tuple referred to the IP layer, potentially bad if the tuple 
> referred to the media layer.
> 
> To conclude: I do not see a need for specifying the measurement point 
> to be used, just an explanation showing how to obtain the maximum 
> precision, how much inaccuracy would be introduced otherwise and how 
> this would lead to a sub-utilization of the available resources at the 
> bottleneck.
> 
> Cheers
> Guido
> --------------------------------------------------------------------
> 
> CONFIDENTIALITY NOTICE
> 
> This message and its attachments are addressed solely to the persons 
> above and may contain confidential information. If you have received 
> the message in error, be informed that any use of the content hereof 
> is prohibited. Please return it immediately to the sender and delete 
> the message. Should you have any questions, please contact us by 
> replying to [email-masked].
> 
>         Thank you
> 
>                                         www.telecomitalia.it
> 
> --------------------------------------------------------------------
>                         
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/avt
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/avt
> 
--------------------------------------------------------------------

CONFIDENTIALITY NOTICE

This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to [email-masked].

        Thank you

                                        www.telecomitalia.it

--------------------------------------------------------------------

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt