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

From: "Allison, Art" <[email-masked]>
Date: Thu, 22 Feb 2007 09:25:15 -0500

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.
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.

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

---

From: "Desineni, Harikishan" <[email-masked]>
Date: Thu, 22 Feb 2007 19:23:20 -0800

> From: Allison, Art [mailto:[email-masked]]
> Sent: Thursday, February 22, 2007 6:25 AM
> To: [email-masked]
> Subject: RE: R: [AVT] CCMdraftreview--

This is an important point which usually gets ignored while
concentrating on rate control for just one type of media.

> the allowed amount, but whatever the amount, it can be exceeded in
this

I agree with this. This problem can easily show up if a sender is
attempting to adjust only one type of media rate without considering the
overall impact on other streams. Adjusting the rate does not guarantee
that packet arrive on time for proper synchronized play-out at the
receiver. I believed this is partly addressed in Guido's draft(Guido,
can you comment?) and totally ignored by codec control messages and
TMMBR.

When one of the media streams to be synchronized is arriving late and
some of it is not rendered due to lip-sync constraints, it can have a
huge impact on user experience. A sender will not know this unless the
receiver can inform it back to the sender in some way.

*This cannot be reported as packet loss. Also, packet loss does not mean
that packets of a given stream are not arriving on time for proper
synchronization. There can be occasional packet loss even when all
others packets arrive before the target time and get synchronized
properly.

*Existing RTCP messages like Inter-arrival jitter do not capture such
problems. Inter-arrival jitter takes time to converge and it is not
reliable to quickly detect late arrival of media packets. Packets can be
late and still result in *not to worry* values of inter-arrival jitter.
This is fundamentally due to the fact the inter-arrival jitter is just
relative spacing between consecutive packets and not the overall delay
experienced by the media packets. The inter-arrival formula in RFC3550
runs over the life time of the session and values of it are sampled just
at the time of reporting. Assuming that media packets are delayed based
on inter-arrival jitter (IJ) can be too wild a guess. From IJ, it is not
possible to estimate the extent to which the packets are getting delayed
at the receiver. A receiver would want to report this late arrival
problem to a sender as and when the experienced delay is approaching
unacceptable boundaries. This can let a sender take quick action get the
overall user experience at the receiver under control.

*Another point is some implementations use elastic buffers which will
dynamically change their depth in order to adapt to changing packet
arrival patterns. This could in-turn have impact on synchronization
target that a receiver is attempting to maintain

* Many details (changing depth, synchronization target) in media
de-jitter buffers are implementation specific. It is not practical to
expect a sender to know all these details about a receiver's de-jitter
buffer.

> receiver.
> If each element is controlled the receiver would seem to need

This is another important point. Making a receiver report how close the
program elements are seems like a good approach to let a sender know
about the overall experience at the receiver's media buffers. Receiver
can even operate at finer level and report how delayed or early a
particular program element has arrived into its buffers. As an
optimization, receiver can tell the sender only when particular program
elements over a period of time are slowly approaching unacceptable
delay. A sender can take some actions until receiver starts complaining
or until the receiver says it is receiving everything on time.

> are expert in such consider the need for lip-synch for consumer

I think you have an important here which is not captured by TMMBR and I
believe it is addressed to some extent in Guido's draft (Guido, can you
comment?). I'll try to capture the above discussion into a draft and
make sure that your point gets discussed.

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 23 Feb 2007 10:11:50 +0100

Hi,

I don't think this topic is really relevant for the TMMBR discussion. 
The issue you talk about arise independently of the existance of TMMBR 
or not. Beyond how a media sender packetize data it can't make much to 
affect the lip-synch (assuming a good implementation). RTP was designed 
with a model that it is the receiver that needs to buffer and delay its 
playout to ensure best possible synchronization and smooth playout. And 
as I see it there are good reasons for this model. First any sender 
adjusting model breaks down in multi-party sessions. Also the feedback 
loop issues are eliminated by having the receiver deal with it.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Franceschini Guido" <[email-masked]>
Date: Fri, 23 Feb 2007 10:49:58 +0100

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

> Sent: giovedì 22 febbraio 2007 15.25
> To: [email-masked]

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

> the allowed amount, but whatever the amount, it can be 

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.

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

---

From: "SOLLAUD Aurelien RD-TECH-LAN" <[email-masked]>
Date: Fri, 23 Feb 2007 11:24:15 +0100

> The main discussion in this thread is around the TMMBR 
> feedback message (or whatever it will be re-named).
> 
> IMO, both solutions are more or less inaccurate, depending on 
> the protocol stack running in the bottleneck.
> 

Anyway, I would find useful to have a standard feedback message to
signal a desired codec bitrate back to the media sender. It would avoid
a per codec definition like the codec mode requests embedded in the RTP
payload header we have in RFC 3267 (AMR), RFC 3558 (SMV, EVRC), RFC 4348
(VMR-WB), RFC 4749 (G.729.1), ...

I initially thought it was the goal of TMMBR. But the current discussion
shows that it is likely to be something else.

Most modern audio codecs will be multi-bitrate, it is desirable to have
a standard RTCP message to signal codec bitrate change requests, instead
of incorrectly using the RTP media path to perform this. And it would be
interesting no to reduce it to AVPF profile.

Regards,
Aurelien

---

From: Colin Perkins <[email-masked]>
Date: Fri, 23 Feb 2007 10:40:42 +0000

On 23 Feb 2007, at 09:49, Franceschini Guido wrote:
...
> 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.

What about cross traffic, RTP or non-RTP? You can't assume the two  
RTP flows are the only ones sharing the bottleneck link. Indeed, this  
discussion seems to be focussing on congestion control, for which  
something like DCCP is likely better suited, than on coarse  
application-layer rate limiting, which was the intent of TMMBR.

-- 
Colin Perkins
http://csperkins.org/

---

From: "Franceschini Guido" <[email-masked]>
Date: Fri, 23 Feb 2007 14:55:44 +0100

> From: Colin Perkins [mailto:[email-masked]]
> Sent: venerdì 23 febbraio 2007 11.41
> To: Franceschini Guido
> Cc: Allison, Art; [email-masked]
> Subject: Re: R: [AVT] CCMdraftreview--
> RTP flows are the only ones sharing the bottleneck link. 

True. And indeed this should be better taken into account when describing the bottleneck. But this applies to any of the proposals on the table, not just mine.
Also, I definitely acknowledge that there are many elements that make the bottleneck description inaccurate:
- competing traffic
- error rate
- inappropriate metrics
...

Each vagueness in the information leads to a decision that in order to almost guarantee to prevent congestion, under-utilizes the available resources.
My proposal addresses of course just the metrics, and by doing so aims at reducing the vagueness of the information, and thus improving the resource utilization.
By no means my proposal affects any of the other factors of uncertainty.

> Indeed, this  

Guido

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

---

From: Randell Jesup <[email-masked]>
Date: Fri, 23 Feb 2007 09:52:23 -0500

>shows that it is likely to be something else.

Correct; TMMBR was not designed as a codec-bitrate-switch-request tool
(witness the name).  It could result in a sender deciding to switch
bitrates in a multi-bitrate codec, but counting on specific values to mean
specific things (like "switch from 16Kbps mode to 8Kbps mode" by indicating
8000 bps) is dangerous with TMMBR.  For example, a midbox might modify a
TMMBR request by subtracting some amount for overhead it knows about,
causing your 8000 to become 7500.

>interesting no to reduce it to AVPF profile.

I'm not sure I understand "interesting no to reduce it to AVPF profile".
I think it may make sense to consider a draft for something other than
TMMBR to provide the ability to request/suggest (pure) codec rate shifts,
for reasons other than restriction.  The two items don't work well together
in one model (as evidenced by the discussions/disagreements here over TIAS
vs AS vs tuples), but may work well when separated into two mechanisms with
different goals and uses.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)

---

From: "SOLLAUD Aurelien RD-TECH-LAN" <[email-masked]>
Date: Fri, 23 Feb 2007 16:45:28 +0100

> >payload header we have in RFC 3267 (AMR), RFC 3558 (SMV, EVRC), RFC 
> >4348 (VMR-WB), RFC 4749 (G.729.1), ...
> >
> >I initially thought it was the goal of TMMBR. But the current 
> >discussion shows that it is likely to be something else.
> 
> Correct; TMMBR was not designed as a 
> codec-bitrate-switch-request tool (witness the name).  It 
> could result in a sender deciding to switch bitrates in a 
> multi-bitrate codec, but counting on specific values to mean 
> specific things (like "switch from 16Kbps mode to 8Kbps mode" 
> by indicating 8000 bps) is dangerous with TMMBR.  For 
> example, a midbox might modify a TMMBR request by subtracting 
> some amount for overhead it knows about, causing your 8000 to 
> become 7500.

OK
 
> >a standard RTCP message to signal codec bitrate change requests, 
> >instead of incorrectly using the RTP media path to perform 
> this. And it 
> >would be interesting no to reduce it to AVPF profile.
> 

I mean that a codec bitrate change request mechanism would be useful
with the usual AVP profile too. (and SAVP etc...)
Most endpoints are now using AVP.

> I think it may make sense to consider a draft for something 
> other than TMMBR to provide the ability to request/suggest 
> (pure) codec rate shifts, for reasons other than restriction. 
>  The two items don't work well together in one model (as 
> evidenced by the discussions/disagreements here over TIAS vs 
> AS vs tuples), but may work well when separated into two 
> mechanisms with different goals and uses.
> 

Yes, for me, a pure codec bit rate CCM is useful and would help VoIP
developpers to take advantage of the modern codecs features (multi-rate,
scalable encodings...).

---

From: "Desineni, Harikishan" <[email-masked]>
Date: Fri, 23 Feb 2007 13:34:38 -0800

> From: Randell Jesup [mailto:[email-masked]]
> Sent: Friday, February 23, 2007 6:52 AM
> To: SOLLAUD Aurelien RD-TECH-LAN
> Cc: [email-masked]
> Subject: Re: R: [AVT]CCMdraftreview--
4348
> >I initially thought it was the goal of TMMBR. But the current
discussion
> >shows that it is likely to be something else.

The discussion exists because some people think it is something else
than what you understood. The authors did not specify which definition
was meant out of the two options and the discussion is to clarify that.

> (witness the name).

The name is misleading if it is not meant for just codec control.
If TMMBR was not designed as codec-bitrate-switch-request then the name
of the draft is misleading ""Codec Control Messages in the RTP
Audio-Visual Profile with Feedback (AVPF)"

If TMMBR is not pure codec-bitrate-switch-request tool, why is it
present in a draft with title "Codec Control Messages in the RTP
Audio-Visual Profile with Feedback (AVPF)"? This is what really puzzles
me. I've posted this question many times and it never got answered.

>  It could result in a sender deciding to switch

Middle box in the media path can be either RTP mixer or RTP translator
RTP mixer is an RTP end point and RTP translator is not.

If it is a pure codec control RTCP message then the RTP middle box
(mixer/translator) must not modify it unless there is codec media
transcoding or thinning taking place in the RTP media path.

> >a standard RTCP message to signal codec bitrate change requests,
instead
> for reasons other than restriction. 

RTCP message related to codec rate shifts should be in CCM and the
message which is not purely codec rate should NOT be in CCM. If TMMBR is
pure codec bitrate then it should stay (with an appropriate name - MCBR
MaxCodecBitRate) in CCM draft. If TMMBR includes header overhead then it
is not a pure codec command and has to go into a new draft.

SOLLAUD's point was that a true/generic codec rate switch message is
useful for all RTP profiles and not just AVPF (based on the codecs
listed by him that currently use codec commands in RTP payload field). 

> The two items don't work well
> together
> Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga
OS
> team
> [email-masked]
> "The fetters imposed on liberty at home have ever been forged out of
the
> weapons
> provided for defence against real, pretended, or imaginary dangers
from
> abroad."

---

From: "SOLLAUD Aurelien RD-TECH-LAN" <[email-masked]>
Date: Mon, 26 Feb 2007 10:17:27 +0100

Hi 

> -----Message d'origine-----
> De : Desineni, Harikishan [mailto:[email-masked]] 
> Envoyé : vendredi 23 février 2007 22:35
> À : Randell Jesup; SOLLAUD Aurelien RD-TECH-LAN
> Cc : [email-masked]
> Objet : RE: R: 
> [AVT]CCMdraftreview--should"bandwidth"includetheheaderoverhead
> > >> 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.
> > >
> The discussion exists because some people think it is 
> something else than what you understood. The authors did not 
> specify which definition was meant out of the two options and 
> the discussion is to clarify that.
> 
> codec-bitrate-switch-request tool 
> > (witness the name).
> 
> If TMMBR was not designed as codec-bitrate-switch-request 
> then the name of the draft is misleading ""Codec Control 
> Messages in the RTP Audio-Visual Profile with Feedback (AVPF)"
> 
> If TMMBR is not pure codec-bitrate-switch-request tool, why 
> is it present in a draft with title "Codec Control Messages 
> in the RTP Audio-Visual Profile with Feedback (AVPF)"? This 
> is what really puzzles me. I've posted this question many 
> times and it never got answered.

Yes, I have the same question.
If TMMBR deals with network layers, it is network congestion control, not Codec Control Message. And this kind of TMMBR does not address the "Codec Mode Request" thing we (unfortunately) find in the RTP payload formats I listed above.

> >  It could result in a sender deciding to switch bitrates in a 
> > specific things (like "switch from 16Kbps mode to 8Kbps mode" by 
> > indicating 8000 bps) is dangerous with TMMBR.  For example, 
> a midbox 
> > might modify
> a
> Middle box in the media path can be either RTP mixer or RTP 
> translator RTP mixer is an RTP end point and RTP translator is not.
> 
> (mixer/translator) must not modify it unless there is codec 
> media transcoding or thinning taking place in the RTP media path.
> 
> > 
> > >of incorrectly using the RTP media path to perform this. 
> And it would
> be
> other than 
> RTCP message related to codec rate shifts should be in CCM 
> and the message which is not purely codec rate should NOT be 
> in CCM. If TMMBR is pure codec bitrate then it should stay 
> (with an appropriate name - MCBR
> MaxCodecBitRate) in CCM draft. If TMMBR includes header 
> overhead then it is not a pure codec command and has to go 
> into a new draft.
> 
> SOLLAUD's point was that a true/generic codec rate switch 
> message is useful for all RTP profiles and not just AVPF 
> (based on the codecs listed by him that currently use codec 
> commands in RTP payload field). 

Exactly.
 
> > in one model (as evidenced by the discussions/disagreements 
> here over
> TIAS
> > vs AS vs tuples), but may work well when separated into two 
> mechanisms

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 26 Feb 2007 11:31:00 +0100

> If TMMBR deals with network layers, it is network congestion control, not Codec Control Message. And this kind of TMMBR does not address the "Codec Mode Request" thing we (unfortunately) find in th…

I agree that TMMBR is not directly a "CODEC" control message. However it 
is also not a purely transport related thing dealing with congestion 
control. The main motivation for TMMBR is to deal with RTP layer 
transport issues related RTP topologies including mixers and 
translators. If you don't understand this from the motivation text for 
TMMBR present in the CMM draft. Can you please explain what is lacking.

If you look at AVPF you can see that it does make the distinction 
between Transport Layer feedback and Payload Specific Feedback messages. 
The FIR and TSTR are clearly payload specific in the way that they only 
apply to certain codecs. TMMBR is transport related because it isn't 
restricted to any specific codec.

It was not split out into a separate draft because the issue TMMBR deals 
with are closely related to the one dealing with video. It has been part 
of the discussion. It is true that splitting it out to a separate draft 
would make this separation of different types of feedback messages 
clearer. However I don't the gain in clarity from this is worth the 
effort it will place on us authors.

Cheers

Magnus Westerlund

---

From: "SOLLAUD Aurelien RD-TECH-LAN" <[email-masked]>
Date: Mon, 26 Feb 2007 11:50:59 +0100

> De : Magnus Westerlund [mailto:[email-masked]] 
> >>
> >> Audio-Visual Profile with Feedback (AVPF)"? This is what really 
> >> puzzles me. I've posted this question many times and it never got 
> >> answered.
> > 
> > If TMMBR deals with network layers, it is network 
> congestion control, not Codec Control Message. And this kind 
> of TMMBR does not address the "Codec Mode Request" thing we 
> (unfortunately) find in the RTP payload formats I listed above.
> > 
> 
> I agree that TMMBR is not directly a "CODEC" control message. 
> However it is also not a purely transport related thing 
> dealing with congestion control. The main motivation for 
> TMMBR is to deal with RTP layer transport issues related RTP 
> topologies including mixers and translators. If you don't 
> understand this from the motivation text for TMMBR present in 
> the CMM draft. Can you please explain what is lacking.
> 
> If you look at AVPF you can see that it does make the 
> distinction between Transport Layer feedback and Payload 
> Specific Feedback messages. 
> The FIR and TSTR are clearly payload specific in the way that 
> they only apply to certain codecs. TMMBR is transport related 
> because it isn't restricted to any specific codec.
> 
> It was not split out into a separate draft because the issue 
> TMMBR deals with are closely related to the one dealing with 
> video. It has been part of the discussion. It is true that 
> splitting it out to a separate draft would make this 
> separation of different types of feedback messages clearer. 
> However I don't the gain in clarity from this is worth the 

I'm OK with that. The motivations for TMMBR are clear.

The conclusion could be that there is a need for another kind of CCM, to
perform codec bitrate requests in RTCP, in a profile-independant, and
codec-independant way. It means a new draft for this, not for the
current TMMBR.

Regards,
Aurelien

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 26 Feb 2007 12:00:42 +0100

> codec-independant way. It means a new draft for this, not for the

Yes, if one thinks that there are cases where AMR Codec-mode-request 
like behavior is needed in a more generic fashion then that is a 
separate type of message. It is a different problem than from TMMBR and 
for different reasons. I currently don't have any real opinion how good 
or bad such a thing would be.

Cheers

Magnus Westerlund

---

From: "Desineni, Harikishan" <[email-masked]>
Date: Mon, 26 Feb 2007 14:34:41 -0800

> > dealing with congestion control. 

It is a pure transport layer feedback message as stated in Section 4.2
of the draft.

>>The main motivation for

The justification for making the reader think that it is a "codec"
control message is lacking. It is a codec control if it does not include
header overhead and can be directly signaled to a codec
> > because it isn't restricted to any specific codec.

It is not restricted to certain (video/audio/text) codec and that's why
I think TMMBR (with header overhead) should not be called a codec
control message and just be called a transport layer feedback message.

> > separation of different types of feedback messages clearer.

Many folks assumed that TMMBR carries just codec media bit-rate only and
the question was "should header overhead bandwidth be included" (as
written in the subject of e-mail thread)? IMO, The source of confusion
is the fact that it is attempting far more beyond than just codec
control. It resulted in 2 months+ discussion which is still going and
that itself speaks that such a definition (TMMBR includes header
overhead) in CCM draft is highly confusing to many.

> > effort it will place on us authors.

I don't think it is a huge task to define it (TMMBR with header
overhead) and clearly describe it in a generic (codec independent)
manner a new draft. The text from CCM draft can be easily reused.  If
done in a new draft, it can be easily referred in video related use
cases in CCM draft as well any other non-video (scalable speech) related
or more video related codec control use cases in future drafts. Also, a
new draft gives the freedom to explain it in detail and clarify why it
is far beyond codec control.

> codec-independant way.
> It means a new draft for this, not for the
> current TMMBR.
> 
Given that it (TMMBR with header overhead) is independent of codec, one
can even play with this message without even interacting with codecs. I
mean one can just use it to control overhead above codec layers without
interacting with codecs.