Subject: [AVT] CCM draft review -- should "bandwidth" include the header overhead

From: Stephan Wenger <[email-masked]>
Date: Sat, 6 Jan 2007 16:51:23 +0200

Folks,

this message relates to the thread "CCM draft, Randell's comments,  
part 2", and is raised here with a new subject line to a) attract  
your attention (successfully so! :-) and b) because it appears to be  
a fundamental issue that may go well beyond the CCM draft.  Feel free  
to read the "CCM comments part 2" thread for context, but don't get  
confused with the terminology discussion that is interleaved therein  
-- the terminology stuff can be fixed quite easily without much more  
input.

To set the stage: the CCM draft contains a mechanism where an RTP  
receiver can inform an RTP sender about his wishes for a temporary  
bandwidth reduction to a bandwidth of n*128 bit/s.  The current draft  
does not explain how this bandwidth is calculated.  Two proposals are  
on the table:

Randell suggests to calculate this bandwidth to include all overhead  
except the link layer overhead (i.e. IP, UDP, RTP, payload headers,  
and the media payload itself).  Doing so is desirable as offer-answer  
RFC 3264 (and perhaps other RFCs in the signaling world) apparently  
define bandwidth that way.  Note that the CCM draft includes an  
algorithm that uses the "negotiated session maximum" (which may well  
stem from offer-answer exchanges) as a starting point, so there is a  
value in an aligned definition.

I'm a bit reluctant to accept that suggestion.  The above arguments  
are compelling.  However, I think it's equally true that, at least  
when RoHC is in place, one simply doesn't know the size of the IP/UDP/ 
RTP headers.  Beyond that, while an application can be made aware  
whether it is running on IPv4 or IPv6, that appears to me not as a  
good implementation practice either.  However, I do believe an  
application should be aware of the size of the RTP header and payload  
headers, and those should be accounted for.

So here's your choice:
a) bandwidth includes IP and UDP header overhead
b) bandwidth includes IP and UDP header overhead, and those are  
inferred to 20+8 bytes (IPv4)
c) bandwidth excludes IP and UDP header overhead, but includes RTP  
and RTP payload overheads
d) codec bandwidth only, excluding any protocol headers
e) say nothing, leave it open (as the current draft unintentionally  
does)

Please comment.

Another question:
Do we need to define how exactly the bandwidth is calculated, i.e.  
window size, buffer model, etc. etc.?  Coming from the video coding  
world, I can tell you that this is a rather scary endeavor.  Or is it  
sufficient to argue with an "average bandwidth over a reasonably  
chosen interval in the order of magnitude of one second"?

Thanks for your input,
Stephan

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

---

From: David R Oran <[email-masked]>
Date: Sat, 6 Jan 2007 10:37:50 -0500

On Jan 6, 2007, at 9:51 AM, Stephan Wenger wrote:

> your attention (successfully so! :-) and b) because it appears to  
> be a fundamental issue that may go well beyond the CCM draft.  Feel  
> free to read the "CCM comments part 2" thread for context, but  
> don't get confused with the terminology discussion that is  
> interleaved therein -- the terminology stuff can be fixed quite  
> easily without much more input.
>
> bandwidth reduction to a bandwidth of n*128 bit/s.  The current  
> draft does not explain how this bandwidth is calculated.  Two  
> proposals are on the table:
>
> Randell suggests to calculate this bandwidth to include all  
> overhead except the link layer overhead (i.e. IP, UDP, RTP, payload  
> headers, and the media payload itself).  Doing so is desirable as  
> offer-answer RFC 3264 (and perhaps other RFCs in the signaling  
> world) apparently define bandwidth that way.  Note that the CCM  
> draft includes an algorithm that uses the "negotiated session  
> maximum" (which may well stem from offer-answer exchanges) as a  
> starting point, so there is a value in an aligned definition.
>
> when RoHC is in place, one simply doesn't know the size of the IP/ 
> UDP/RTP headers.  Beyond that, while an application can be made  
> aware whether it is running on IPv4 or IPv6, that appears to me not  
> as a good implementation practice either.  However, I do believe an  
> application should be aware of the size of the RTP header and  
> payload headers, and those should be accounted for.
>
> So here's your choice:
RSVP uses IP+<everything inside> for its bandwidth numbers, and has  
hint options to communicate compression hints so that intermediaries  
and the receiver can adjust for any supposed compression gain. I'm  
not sure this is the right model for RTP media bandwidth, but I  
thought I should at least mention it.

> world, I can tell you that this is a rather scary endeavor.  Or is  
> it sufficient to argue with an "average bandwidth over a reasonably

---

From: "Even, Roni" <[email-masked]>
Date: Sun, 7 Jan 2007 17:04:34 +0200

Hi,
The bandwidth modifier in SDP RFC 4566 has a bwtype parameter. RFC4566
specifies CT and AS type which include overhead. There is also RFC3890
who specifies the TIAS (transport independent BW).
The recommendations in RFC3890 about usage of CT, AS and TIAS are viable
also here.
 
My view is that in this layer we should use the transport independent
approach (option D) and reference RFC 3890.

I think otherwise we need to explain similar logic to RFC3890.

Roni

> -----Original Message-----
> From: Stephan Wenger [mailto:[email-masked]]
> Sent: Saturday, January 06, 2007 4:51 PM
> To: [email-masked]
> Cc: Randell Jesup
> Subject: [AVT] CCM draft review -- should "bandwidth" include the
> headeroverhead
> 
> Folks,
>

---

From: "Chandra Umesh.1 (Nokia-NRC/MtView)" <[email-masked]>
Date: Mon, 08 Jan 2007 00:11:33 -0800

> chosen interval in the order of magnitude of one second"?

I think choosing a reasonable time interval would be a good option. RTCP
receiver report interval duration would be right time to calculate the
bandwidth seen by the receiver.

Umesh

---

From: Stephan Wenger <[email-masked]>
Date: Mon, 8 Jan 2007 13:08:35 +0200

Sounds very reasonable to me.  Anyone else?
Stephan

On Jan 7, 2007, at 5:04 PM, Even, Roni wrote:

>> UDP/

---

From: Randell Jesup <[email-masked]>
Date: Mon, 08 Jan 2007 09:56:41 -0500

Stephan Wenger <[email-masked]> writes:
>To set the stage: the CCM draft contains a mechanism where an RTP  receiver
>can inform an RTP sender about his wishes for a temporary  bandwidth
>reduction to a bandwidth of n*128 bit/s.  The current draft  does not
>explain how this bandwidth is calculated.  Two proposals are  on the table:
>
>except the link layer overhead (i.e. IP, UDP, RTP, payload headers,  and
>the media payload itself).  Doing so is desirable as offer-answer  RFC 3264
>(and perhaps other RFCs in the signaling world) apparently  define
>bandwidth that way.  Note that the CCM draft includes an  algorithm that
>uses the "negotiated session maximum" (which may well  stem from
>offer-answer exchanges) as a starting point, so there is a  value in an
>aligned definition.

Right - if we're referencing the bandwidth from signalling, we need to
align that bandwidth with what signalling uses, or specify something like
"RTP payload reception bandwidth negotiated by signalling".  Long and
awkward, but at least clear and absolves you of dealing with the multiple
different ways signalling can deal with bandwidth - I hope.

>I'm a bit reluctant to accept that suggestion.  The above arguments  are
>compelling.  However, I think it's equally true that, at least  when RoHC
>is in place, one simply doesn't know the size of the IP/UDP/ RTP headers.
>Beyond that, while an application can be made aware  whether it is running
>on IPv4 or IPv6, that appears to me not as a  good implementation practice
>either.  However, I do believe an  application should be aware of the size
>of the RTP header and payload  headers, and those should be accounted for.

And there's the rub - in most use-cases for CCM, the application is
primarily interested in total bandwidth (IP/UDP/RTP/codec (and RTCP, though
that's implied), NOT in codec bandwidth.  A temporary restriction of
reception bandwidth is generally due to an access or transit link
restriction.  (In theory it could be due to processing constraints, but I
would submit that's an odd case rarely if ever to be used in practice, and
if it is they can add the IP/UDP/RTP/RTCP overhead to their calculations.)
One additional bit to add to the fire - header extension bandwidth.

>b) bandwidth includes IP and UDP header overhead, and those are  inferred
>to 20+8 bytes (IPv4)
>c) bandwidth excludes IP and UDP header overhead, but includes RTP  and RTP
>payload overheads
>e) say nothing, leave it open (as the current draft unintentionally  does)

I think the option that is not acceptable at all is 'e', because that will
cause non-interoperable implementations.  Any of the others could be used,
though some may make life easier than others, or align better with other
RFCs and so avoid confusion and mistakes.  'a' is the option that matches
RFC 3264/4566.

>From an application framework point-of-view, if the application (or network
stack) signals the RTP stack the bandwidth has changed, the RTP stack can
calculate the appropriate bandwidth to indicate (both via TMMBR and up to
the application); one assumes that the RTP stack knows the details of
IP/UDP/RTP in use.

>From the point of view of reception of TMMBR, again the RTP stack can take
the TMMBR(s) and indicate up to the application what payload bandwidth
that works out to, since the RTP stack should know all the details.

>Another question:
>Do we need to define how exactly the bandwidth is calculated, i.e.  window
>size, buffer model, etc. etc.?  Coming from the video coding  world, I can
>tell you that this is a rather scary endeavor.  Or is it  sufficient to
>argue with an "average bandwidth over a reasonably  chosen interval in the
>order of magnitude of one second"?

Since this is a modification to a previously-agreed-to bandwidth, it should
inherit the characteristics of that bandwidth.  That's RFC 4566's and
associated RFC's problem. 

-- 
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: Randell Jesup <[email-masked]>
Date: Mon, 08 Jan 2007 10:08:10 -0500

>approach (option D) and reference RFC 3890.

Then (assuming the UA negotiated using CT or AS) senders and receivers of
TMMBR need to do a conversion from CT/AS to TIAS or vice-versa, and we'd
need to spell that out.

Perhaps we need option 'f' - do not specify if the bandwidth is CT, AS or
TIAS.  That's specified by signaling.  Make it clear that TMMBR is a
modification of whatever bandwidth was signaled - if they negotiated AS,
then it's IP/UDP/RTP/codec.  If they used TIAS, then the TMMBR bandwidth is
just the codec, and it's up to the UA sending TMMBR to figure out what the
codec bandwidth would be for a given link bandwidth.  After all, TMMBR is a
modification of the signaled bandwidth, so this makes some sense.

My preference is 'a' with 'f' close behind it (and I can see an argument
for 'f' being better than 'a').  All the others I dislike but will work,
other than 'e' which is disasterous.

BTW, if they have to calculate codec bandwidths from a raw link bandwidth
we should make sure to remind them to include RTCP.

---

From: "Even, Roni" <[email-masked]>
Date: Mon, 8 Jan 2007 17:34:46 +0200

Randell,
RFC 4890 recommends sending both TIAS and AS for backward compatibility
with systems that do not support TIAS. This RFC gives a good explanation
why to use TIAS. This is what we do in our implementation. In this case
how should the requester behave and how does the receiver of TMMBR know
which model was used, this will lead us to option A or your option f
without the TIAS.

Note that the BW in RFC 4566 is not specific for RTP but may use for
general application while here we are talking only about RTP.

We also need to consider that the request for TMMBR may come from a
layer that does not see the signaling, this is why I prefer option D.

To summarize even though I prefer option "d" which is transport
independent, I would not mind if it will be option "a" or "f" (on f
taking into account that both AS and TIAS may be specified for the
stream)

Roni 

> From: Randell Jesup [mailto:[email-masked]]
> Sent: Monday, January 08, 2007 5:08 PM
> To: Even, Roni
> Cc: Stephan Wenger; [email-masked]
> Subject: Re: [AVT] CCM draft review -- should "bandwidth" include the
> headeroverhead
> 
> then it's IP/UDP/RTP/codec.  If they used TIAS, then the TMMBR
bandwidth
> is
> codec bandwidth would be for a given link bandwidth.  After all, TMMBR
is
> a
> 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: Stephan Wenger <[email-masked]>
Date: Mon, 8 Jan 2007 17:50:44 +0200

Gut reaction: I don't like a), for reasons already explained.  f) I  
could live with.  d) would be my current favorite.  e) was listed for  
completeness only, and is out.
Stephan

On Jan 8, 2007, at 5:34 PM, Even, Roni wrote:

>> Then (assuming the UA negotiated using CT or AS) senders and  
>> receivers
> of
>> Perhaps we need option 'f' - do not specify if the bandwidth is  
>> CT, AS
> or
>> just the codec, and it's up to the UA sending TMMBR to figure out  
>> what
> the

---

From: Randell Jesup <[email-masked]>
Date: Mon, 08 Jan 2007 11:33:09 -0500

Stephan Wenger <[email-masked]> writes:
>Gut reaction: I don't like a), for reasons already explained.  f) I  could
>live with.  d) would be my current favorite.  e) was listed for

In all cases, *something* has to take an (assumed) link bandwidth and
adjust it according to the IP/UDP/RTP/hdrext/RTCP/etc used (eventually into
a payload (not really codec) bandwidth).  Options are:

a:   media sender
b,c: media sender and media receiver (since assumption may not match reality)
d:   media receiver (TMMBR sender)
e:   everyone and no one :-)
f:   CT/AS: media sender; TIAS: media receiver

As for the case of signaling BOTH AS and TIAS for f), I'd be tempted to
use the AS bandwidth (see below).

My main reason for preferring a media sender do the calculation is that
only they really know how much they're sending, and only they know what
tradeoffs are available.  For example: a sender might be sending a header
extension using an appreciable amount of bandwidth.  When there's a
reception restriction, the sender could (at it's option) reduce or
eliminate the header-extension data in preference to payload data.  If the
receiver does the calculation, it has to assume the header extension will
continue.  This is *especially* problematic if the receiver doesn't
understand the extension, since then it can't really calculate the
bandwidth of the extension except by looking at past packets and guessing.
Also, the receiver would have to (except in the TIAS case) infer the packet
rate, which may be variable.  Even in the f) only-TIAS case, it has to
assume that the packet rate signaled in TIAS won't (can't) change, which
may not be the case.

I think there is a fatal flaw in any system that has the receiver
calculating the sender's bandwidth.  In f), if the negotiated mechanism was
(onlY) TIAS, you still have the receiver calculating bandwidth for TMMBR,
which is why I'd prefer a) - but at least in this case it's no worse than
using (only) TIAS in the first place.

---

From: "Chandra Umesh.1 (Nokia-NRC/MtView)" <[email-masked]>
Date: Mon, 08 Jan 2007 08:54:46 -0800

I also agree that at the application layer we should use a transport
independent approach - option D.

Umesh

---

From: Lloyd Wood <[email-masked]>
Date: Mon, 08 Jan 2007 17:39:29 +0000

>different ways signalling can deal with bandwidth - I hope.

Bandwidth is measured in Hz. This isn't that, and accounting for all layers and overheads (FEC/coding, etc) is impossible.

"RTP payload receiver link capacity" would be more like it.

Don't use "bandwidth".

L.

---

From: Stephan Wenger <[email-masked]>
Date: Mon, 8 Jan 2007 19:57:43 +0200

On Jan 8, 2007, at 7:39 PM, Lloyd Wood wrote:

> ]...]
>
> Bandwidth is measured in Hz. This isn't that, and accounting for  
> all layers and overheads (FEC/coding, etc) is impossible.
>

I disagree with the last statement.  Bandwidth is commonly used  
nowadays for as a synonym for bitrate or whatever.  9 out of 10 of  
the first hits for the term bandwidth refer to something that has to  
do with the number of bits to go from a to b.  Wikipedia also  
mentions bandwidth in the context of web hosting connectivity.

Link capacity is something very different.  It refers to the "link",  
which sounds like "link layer", which disregards the shared nature of  
IP link access.

Let's fix the issue at hand (namely whether to account for header  
overhead, and how) instead of this type of terminology discussions.

Regards,
Stephan

---

From: Lloyd Wood <[email-masked]>
Date: Mon, 08 Jan 2007 18:42:45 +0000

>mentions bandwidth in the context of web hosting connectivity.

Wikipedia is hardly authoritative.

If you want to say bitrate, say bitrate.

>which sounds like "link layer", which disregards the shared nature of  

"bandwidth" suggests total bandwidth for the shared medium, ignoring medium allocation issues and how much of that shared channel an interface gets.

Talking about what capacity the link provides to the interface seems to be what is needed here, regardless of IP multiplexing issues (which are distinct from channel sharing issues).

L.

---

From: Wesley Eddy <[email-masked]>
Date: Mon, 8 Jan 2007 13:09:21 -0500

> which sounds like "link layer", which disregards the shared nature of  

IPPM has tried to put some precise definitions in place for other WGs
to use (maybe they'd be helpful here):
http://www.ietf.org/internet-drafts/draft-ietf-ippm-bw-capacity-04.txt

-- 
Wesley M. Eddy
Verizon Federal Network Systems

---

From: Wesley Eddy <[email-masked]>
Date: Mon, 8 Jan 2007 13:09:21 -0500

---

From: "Even, Roni" <[email-masked]>
Date: Wed, 10 Jan 2007 08:58:47 +0200

Randell,
My view is that since the media encoder does not know how the media will
be sent than it must be known to the encoder what "raw" rate it can use.

Roni Even

> Subject: Re: [AVT] CCM draft review -- should "bandwidth" include
> theheaderoverhead
> 
bandwidth
is
OS
the
from

---

From: Randell Jesup <[email-masked]>
Date: Wed, 10 Jan 2007 09:48:46 -0500

>be sent than it must be known to the encoder what "raw" rate it can use.

I'm confused by that statement.  If any part of the system *could* (should)
know how the media will be sent, overhead, etc, it's the media encoder.

Now, perhaps there are systems where the media encoder is somehow divorced
from the lower-level transport mechanisms - but in order to respond to a
TMMBR, the lower-level transport must process the TMMBR and pass a request
to the media encoder.  Certainly that request could either have the
overhead subtracted already so the media encoder part of the sender
effectively gets a codec bitrate (though there are problems, see below),
or it can pass up the TMMBR request along with "here's the overhead you
have to account for" and let the media encoder figure out what to send.

I see that as immensely more likely to produce the correct result in
*all* cases than a solution where the receiver has to try to guesstimate
the overheads and pre-subtract them.  Doubly so if they didn't use TIAS
to begin with (and to be honest, I'd never even heard of TIAS until this
discussion started).

Again, since only the media encoder/sender (UA) knows how many packets it
will send, and any variable-bandwidth additions to that (like hdrexts), no
receiver can calculate codec bandwidth.  Even the transport layer of the
sender, acting alone, can't calculate it, since it doesn't know how many
packets the media encoder will generate.  RTP is not TCP; it's not a
byte-stream.  If we have 20000 Bps (160000bps), and the overhead is a fixed
40 bytes per packet, and we're sending 50 packets per second, we have
exactly 360 bytes for codec data (18000 Bps).  Ok.  But if the media
encoder is video, and we tell it 18000Bps, it may generate 25 720-byte
packets (and we're ok), or 100 180-byte packets (and we're screwed).  Video
codecs are often not fixed-packet-rate codecs due to iframes and variations
in compression efficiency, even more so when the target rate is around a
payload-size boundary (such as ~384Kbps@30fps).  And this leaves out
hdrexts, header compression (which might require constant feedback from the
transport layer to the media encoder, which is possible there (inside the
sender) but not possible from the receiver to the sender without
congestion/etc).

How exactly the media encoder and transport layers work together in the
sender to decide how much bandwidth to use for the codec is up to them.
They certainly *can* do it, and they should *already* be doing it.  The
receiver certainly CANNOT.

Probably the reason it is glossed over now is a) most people don't use
variable-bandwidth overhead (hdrext, header compression, etc) and so get
away with fixed subtractions; b) almost all traffic is IPv4 (again,
allowing fixed subtrations; c) bandwidth is only signaled, and adjustments
(if any, and they're not common) are done due to loss (ala TFRC), not a
specific bandwidth renegotiation or signal, and d) people fudge the
bandwidth by specifying values lower than the actual link in order to get
things to work semi-reliably.

---

From: "Even, Roni" <[email-masked]>
Date: Wed, 10 Jan 2007 17:17:05 +0200

Randell,
This is showing we are coming from different applications. For me the media encoders create for example an H.264 bit stream. The packetization afterwards can be RTP for SIP or H.323 or can be different (H.221) for H.320 systems.
When we try to match rates on a GW or multipoint conference the common starting point for us is the H.264 payload. 
Roni Even
 
________________________________

מאת: Randell Jesup [mailto:[email-masked]]
נשלח: ד 10/01/2007 16:48
אל: Even, Roni
עותק לידיעה: Stephan Wenger; [email-masked]
נושא: Re: [AVT] CCM draft review -- should "bandwidth" include theheaderoverhead

---

From: "Desineni, Harikishan" <[email-masked]>
Date: Wed, 10 Jan 2007 08:13:29 -0800

Stephan and others,

I haven’t followed all the e-mails on this thread and apologies if I am repeating the same information. Few points from my side

1) It is not clear how a video receiver could come up with max media bit rate value, is there an algorithm for this? Such an algorithm might be too complex based on the discussions on this thread. The draft is only addressing on how to signal this value. I do not see much value in signaling it without really knowing how to compute it.

2) Somewhere in this thread it was written that the bit rate reported in TMMBR is just the value of bit rate measured at the receiver over a duration of X seconds (X could be 1 sec or RTCP interval and not sure how to figure out this value of X). In this case I would think that the value reported by the receiver is an average bit rate measured at the receiver. For cellular links this value can vary rapidly under congestion conditions hence the value of X plays a major role in the computation of the bit rate that needs to be reported back to sender (s).

3) If it is indeed measured over a period of time (Say X sec), then the message here should really be called TARR (Temporary Average Receive Rate) or some other name which makes more sense. Calling it the maximum bit rate does not look correct.

4) I prefer to have the pure codec bit rate specified (option d) for the message under discussion. 

--Hari
________________________________________
From: Even, Roni [mailto:[email-masked]] 
Sent: Wednesday, January 10, 2007 7:17 AM
To: Randell Jesup
Cc: Stephan Wenger; [email-masked]
Subject: RE: [AVT] CCM draft review -- should "bandwidth" includetheheaderoverhead

Randell,
 
________________________________________
מאת: Randell Jesup [mailto:[email-masked]]
נשלח: ד 10/01/2007 16:48
אל: Even, Roni
עותק לידיעה: Stephan Wenger; [email-masked]
נושא: Re: [AVT] CCM draft review -- should "bandwidth" include theheaderoverhead

---

From: Randell Jesup <[email-masked]>
Date: Wed, 10 Jan 2007 11:53:40 -0500

"Even, Roni" <[email-masked]> writes:
>This is showing we are coming from different applications. For me the
>media encoders create for example an H.264 bit stream. The packetization
>afterwards can be RTP for SIP or H.323 or can be different (H.221) for
>H.320 systems.

Sure, but that's why I said "transport layer", not specifically RTP
(though it's RTP for TMMBR).  The RTP transport layer has to communicate
the bandwidth request somehow to the media encoder, and the media encoder
has to decide what to do.

Only the media encoder knows/can control the number of packets it will
send.  That means that only the media encoder (or a coupling of the encoder
with feedback about actual bandwidth usage from the transport layer) can
obey a bandwidth request.  

The details are up to the encoder and transport layer.  If the encoder is
dumb and you're unwilling to touch the API for it, the RTP transport layer
could receive a TMMBR, make an initial adjustment of the media encoder
bitrate, and then periodically adjust the bitrate according to what the
media encoder does (bandwidth actually used) in order to hit the target.
That would be ugly but work.

Regardless of the transport layer (and SIP and H.323 don't have different
packetizations; both use RTP - H.324M may be somewhat different) the
transport layer and the media encoder need to communicate (obviously),
even if indirectly, about things like bandwidth.  (Which is what TMMBR is
part of.)

To be serious - if you really want to follow an AS bitrate, the transport
and encoder already should be doing this.  As mentioned before, you can
slide by with wasted bandwidth and/or occasional overuse in "average"
cases, but that doesn't make it the correct way to handle it.  And TIAS
is fundamentally flawed IF it's being used to account for downstream
link bandwidth.

>When we try to match rates on a GW or multipoint
>conference the common starting point for us is the H.264 payload.  Roni

Sure, but that doesn't change the issues here.  While we don't do
conferencing/multicase, we do face the same general issues about bandwidth
and codec/transport interaction.  It gets a little more complicated in
multipoint/multicast, obviously, but the fundamentals are the same.

---

From: Randell Jesup <[email-masked]>
Date: Wed, 10 Jan 2007 12:12:36 -0500

"Desineni, Harikishan" <[email-masked]> writes:
>1) It is not clear how a video receiver could come up with max media bit
>   rate value, is there an algorithm for this? Such an algorithm might be
>   too complex based on the discussions on this thread. The draft is only
>   addressing on how to signal this value. I do not see much value in
>   signaling it without really knowing how to compute it.

Which is why I feel the receiver should indicate their link (stream)
bandwidth, and let the sender (who has the information and is actually
sending the data) figure out how to derive codec bandwidth (which might
vary depending on how many packets the codec sends).

>2) Somewhere in this thread it was written that the bit rate reported in
>   TMMBR is just the value of bit rate measured at the receiver over a
>   duration of X seconds (X could be 1 sec or RTCP interval and not sure
>   how to figure out this value of X). In this case I would think that the
>   value reported by the receiver is an average bit rate measured at the
>   receiver. For cellular links this value can vary rapidly under
>   congestion conditions hence the value of X plays a major role in the
>   computation of the bit rate that needs to be reported back to sender
>   (s).

TMMBR is not a report of actual reception rate, it's *desired* reception
rate request.  Typically a change in TMMBR would be due to something like a
3G data rate change - instead of waiting for congestion, lost packets, etc,
the receiver would immediately send TMMBR telling the sender that it's
maximum receive bandwidth just got cut in half.

>3) If it is indeed measured over a period of time (Say X sec), then the
>   message here should really be called TARR (Temporary Average Receive
>   Rate) or some other name which makes more sense. Calling it the maximum
>   bit rate does not look correct. 

The whole "calculation over period X" came into the discussion two ways:
a) if the receiver is calculating the codec bitrate and needs to account
   for things like ROHC, hdrexts, etc, then it needs to average them across
   some period of time.  This is a Bad Idea (IMHO).
b) Discussion was occuring about "what does bandwidth mean", and what
   complying with it means in a discrete packet environment.  My opinion is
   that TMMBR/etc (this draft) is not the place to define what the
   bandwidth specified means; that's defined by the signaling protocols
   (SDP/etc).  TMMBR modifies the value (which in SDP could be b=CT, b=AS,
   or b=TIAS, and who knows what in other signaling protocols), but it
   should not modify the definition.

>   message under discussion.  

Please take a look again at the above and the earlier messages in this
thread.  d) *seems* simplest (and is simple for an all-fixed-overhead case,
like all-IPV4, no ROHC, no hdrext, fixed packet rate), but it doesn't solve
the problem and just shifts it around.

---

From: "Desineni, Harikishan" <[email-masked]>
Date: Wed, 10 Jan 2007 10:11:34 -0800

> vary depending on how many packets the codec sends).

Accurate link bandwidth may not be trivial to derive. On packet based
cellular links, it can vary rapidly depending on factors like geometry
of the device, speed at which the device is traveling and the loading
condition inside a cell. Whatever the device comes up can just be an
estimate unless it is connected to a link which offers guaranteed
throughput
> >   how to figure out this value of X). In this case I would think
that
> rate request.  Typically a change in TMMBR would be due to something
like
> maximum receive bandwidth just got cut in half.

How would the receiver know that its bw got cut in half? Either its n/w
will tell it or it has to self detect (via underlying congestion control
scheme or packet loss info in RTCP RR).

3G data rate changes due to the reasons I noted above (new users getting
into the system, geometry of the cell and other factors specific to the
n/w) including the congestion in the 3G network. A node (base station)
in the cellular n/w can detect congestion/packet loss and change the
allocated data rates for several mobiles in its neighborhood. A receiver
could also inform this to the other end (sender) using an updated SDP
with updated AS or TIAS value. And such an update won't be significantly
slower than TMMBR.

>    complying with it means in a discrete packet environment.  My
opinion
>    should not modify the definition.

Agreed! Hence, the TMMBR value should be like the modified value of the
attribute (AS/TIAS/CT) value that was used in SDP. TIAS is a useful
attribute in at least point to point multimedia services. It lets the
device unambiguously identify bit rate in one direction. AS would remain
for some more time for backward compatibility reasons

> >4) I prefer to have the pure codec bit rate specified (option d) for
the
> >   message under discussion.
> 

Pure codec bit rate (like TIAS) would keep things simple and I think it
is needed to unambiguously identify at least what value should be
communicated to the encoder. The remaining part of the problem would
probably need to be solved with additional attributes like pure code
bitrate in send direction (max and avg) and max/avg packet rate (based
on frame rate and other encoder settings like I-frame size/interval) in
send direction and let the answerer respond with what it would like to
receive.

---

From: Randell Jesup <[email-masked]>
Date: Wed, 10 Jan 2007 15:23:00 -0500

>estimate unless it is connected to a link which offers guaranteed

Sure - but the whole concept of TMMBR is based around the receiver
"somehow" knowing that its downstream link has changed bandwidth - even if
it isn't exact.  There are many cases where it can know that (a modem
re-negotiated, an 802.11 wireless link switched from 11mbps (raw) to 1mbps
(raw), etc).

>> like a 3G data rate change - instead of waiting for congestion, lost
>> packets, etc, the receiver would immediately send TMMBR telling the
>> sender that it's maximum receive bandwidth just got cut in half.
>

That's up to the receiver - as per above, some do know.  I've assumed that
at least some cell network stacks at least have an idea about when they
change bandwidth; that's a driving force (I'm told) behind TMMBR.

>with updated AS or TIAS value. And such an update won't be significantly

The argument here (and I agree with it) is that reINVITE via SDP is MUCH
slower and higher overhead than TMMBR.  The SIP server may be no where near
either endpoint; it may be loaded, there may be delays induced by SBCs
and/or ICE/TURN/etc.  Plus, on reINVITE, there's a LOT of extra processing
for each UA, and UAs may well require switching ports (which means
ICE/STUN/etc), re-initializing streams and codecs (perhaps glitching
audio/video in the transition), etc.  Read the justifications in the draft;
if you disagree then let's open the more general discussion.

>> >   Rate) or some other name which makes more sense. Calling it the
>> >   maximum bit rate does not look correct.
>> 
>>    for things like ROHC, hdrexts, etc, then it needs to average them
>>    across some period of time.  This is a Bad Idea (IMHO).
>>    complying with it means in a discrete packet environment.  My opinion
>>    is that TMMBR/etc (this draft) is not the place to define what the
>>    (SDP/etc).  TMMBR modifies the value (which in SDP could be b=CT,
>>    b=AS, or b=TIAS, and who knows what in other signaling protocols),
>>    but it should not modify the definition.
>

That would be option "f" - modify whatever was negotiated, and the details
of what that means and how to calculate it are up to the sender and
receiver (and are the same issues that exist during signaling to turn
b=whatever into a media encoder rate - TIAS for the general case still
has issues, if it's being used to control link bandwidth use.  TIAS may
make sense when it's not being used for bandwidth control, but to control
quality or internal processing overhead by the decoder).

>> >   the message under discussion.
>> 
>> thread.  d) *seems* simplest (and is simple for an all-fixed-overhead
>> case, like all-IPV4, no ROHC, no hdrext, fixed packet rate), but it
>> doesn't solve the problem and just shifts it around.
>
>communicated to the encoder.

It keeps things simple for the encoder - but makes life very, very painful
for the RTP layers, especially at the receiver.

>The remaining part of the problem would

That's one hell of a lot of signaling complexity just to avoid having the
sender's transport (RTP) layer and the media encoder layer handle it.  Even
if you don't modify the encoder to understand anything more than just
"bitrate", the RTP layer could track the actual bandwidth usage (including
IP/UDP/RTP/hdrext/etc) (or just track the overhead and whether it's larger
than was "expected" when it set the media encoder rate) and if needed
adjust the request to the encoder.

For example, if the sender's RTP layer assumed 24Kbps of overhead at call
setup or TMMBR time, and it sees the actual overhead is running 36Kbps
(because the encoder is sending more, smaller, packets), then it could
reduce the media encoder bitrate by 12K.  A receiver could only do this
with multiple TMMBRs, and even so might not have enough info about _why_
the rate was different than it anticipated.  A sender could do this easily
and as often as it wishes, even with a relatively "dumb" encoder.

---

From: "Desineni, Harikishan" <[email-masked]>
Date: Thu, 11 Jan 2007 09:59:58 -0800

> if you disagree then let's open the more general discussion.

Firewall traversal/codec init can take place at call setup (SIP invite)
time.
reINVITE or UPDATE for bandwidth changes can result in an updated SDP
which does not significantly differ from the existing one. It will have
different/updated values for b=AS or b=TIAS lines with no change in port
numbers or codec types. This should not result in any additional
firewall traversal, port switching or codec re-initialization. The SIP
message would just travel a longer path and I am not sure how
significant can that delay be given that there isn't any need for
additional stuff (port switch,firewall traversal,codec re-init) that you
pointed out.

> 
> >> >3) If it is indeed measured over a period of time (Say X sec),
then
OS
the
from

---

From: Randell Jesup <[email-masked]>
Date: Thu, 11 Jan 2007 14:06:03 -0500

"Desineni, Harikishan" <[email-masked]> writes:
>> slower and higher overhead than TMMBR.  The SIP server may be no where
>> near either endpoint; it may be loaded, there may be delays induced by
>> SBCs and/or ICE/TURN/etc.  Plus, on reINVITE, there's a LOT of extra
>> processing for each UA, and UAs may well require switching ports (which
>> means ICE/STUN/etc), re-initializing streams and codecs (perhaps
>> glitching audio/video in the transition), etc.  Read the justifications
>> in the draft; if you disagree then let's open the more general
>> discussion.
>
>

A reINVITE *might* not result in extra firewall traversal, port switching
or codec re-initialization - but in many cases it will anyways.  Some cases
may be hard to avoid, since midboxes that don't remember the entire earlier
SDP exchange may be involved, and they may do things in order to make the
general case easier.  (To know nothing needs to change other than
bandwidth, you have to compare pretty much everything in the SDP, including
items you don't understand (or at least that a midbox may not understand).

Even if ports, codecs, etc don't change, many UAs may (to make life
simpler) force a re-initialization of jitter buffers, codecs (iframes), etc
on a re-INVITE.  Otherwise the UA has to decide exactly which possible set
of changes requires a codec reset - and test every possible combination of
parameter changes via reINVITE..  It's a lot simpler to just reset on
reINVITE and live with the glitch - especially since most current UAs don't
reINVITE at all, or only near the start or on adding/removing streams.
The worst case would be if something decides (again to simplify things)
to use different ports on a reINVITE (yes, UAs do, and for at least
somewhat valid reasons).  That would cause a new ICE/TURN/STUN/etc to be
needed.

As for SIP, SIP servers are at times loaded and slightly delayed (perhaps
only a few tenths, perhaps longer, but that's a long time for this sort of
feedback).  Sometimes a SIP proxy might be 1/2 the world away from either
end of the call, adding several tenths more in transit delay.  Also - this
is an AVT RFC; while SIP is a primary user, other signaling layers may be
used like H.323.

For others: Am I out in left field, or is this a reasonable explanation for
the why TMMBR can't be handled with reINVITE?

---

From: "Franceschini Guido" <[email-masked]>
Date: Thu, 11 Jan 2007 21:40:57 +0100

I support Randell's arguments against reINVITE for two reasons:
1) in my experience on the field in deploying a videocommunication system, reINVITE was sort of banned. A solution based on reINVITE would require additional tests on too many devices along the path to make it practical. By contrast, a solution based on RTCP would affect only the end points.
2) reINVITE would only apply to p2p (although this is the use case I care more)
 
Guido

Da: Randell Jesup [mailto:[email-masked]]
Inviato: gio 1/11/2007 8:06
A: Desineni, Harikishan
Cc: Stephan Wenger; Even, Roni; [email-masked]
Oggetto: Re: [AVT] CCM draft review -- should "bandwidth"includetheheaderoverhead

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

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: "Even, Roni" <[email-masked]>
Date: Thu, 11 Jan 2007 23:15:00 +0200

The issue of signaling path vs end to end was heavly discussed in the
past also for video fast update. The concern was with overloading
proxies with communications. The idea was that if you want a temporary
change in the rate, use RTCP feedback. If you want a permanent change
both up and down use SDP in re-invite. Using re-invite for permanent
change may enable middle boxes to handle BW management if they want to
do it based on SDP b= parameter. 
Roni

> Sent: Thursday, January 11, 2007 9:06 PM
> To: Desineni, Harikishan
> Cc: Even, Roni; Stephan Wenger; [email-masked]
> Subject: Re: [AVT] CCM draft review -- should "bandwidth"
> includetheheaderoverhead
> 
> simpler) force a re-initialization of jitter buffers, codecs
(iframes),
> etc
> For others: Am I out in left field, or is this a reasonable
explanation
> for
OS
the
from

---

From: "Desineni, Harikishan" <[email-masked]>
Date: Thu, 11 Jan 2007 18:35:25 -0800

OK. There are two types of changes here. Let's classify the
mentioned/known changes into permanent (A) and temporary (B) lists.

(A) Permanent changes

a)
>From Randell - " Sure - but the whole concept of TMMBR is based around
the receiver "somehow" knowing that its downstream link has changed
bandwidth - even if it isn't exact.  There are many cases where it can
know that (a modem re-negotiated, an 802.11 wireless link switched from
11mbps (raw) to 1mbps (raw), etc)."

[Hari] re-negotiated ones are permanent changes. reINVITE is the right
choice.

b) 
>From Randell -
"

>will tell it or it has to self detect (via underlying congestion 
>control scheme or packet loss info in RTCP RR).

That's up to the receiver - as per above, some do know.  I've assumed
that at least some cell network stacks at least have an idea about when
they change bandwidth; that's a driving force (I'm told) behind TMMBR."

[Hari] This is a permanent change. Cellular network QoS changes
(bandwidth downgrades) are permanent in the sense that they last for
significant duration. They are not definitely momentary changes and
hence cannot be treated as temporary.

c) This is almost same as the above, a permanent QoS change. [Basso]
reference seems to be expired and I don't think it helps the reader in
any case.

CCM draft, Sec 3.1, use case 7

"That cellular link
      also commonly has some type of QoS negotiation enabling the
      cellular device to learn the maximal bit-rate available over this
      last hop. Thus indicating the maximum available bit-rate to the
      transmitting part can be beneficial to prevent it from even trying
      to exceed the known hard limit that exists. For cellular or other
      mobile devices the available known bit-rate can also quickly
      change due to handover to another transmission technology, QoS
      renegotiation due to congestion, etc. To enable minimal disruption
      of service a possibility for quick convergence, especially in
      cases of reduced bandwidth, a media path signalling method is
      desired."

(B) Temporary

> Sent: Thursday, January 11, 2007 1:15 PM
> To: Randell Jesup; Desineni, Harikishan
> > >> The argument here (and I agree with it) is that reINVITE via SDP
is
> > MUCH
> > >> near either endpoint; it may be loaded, there may be delays
induced
> by
> > >additional stuff (port switch,firewall traversal,codec re-init)
that
> you
> > or codec re-initialization - but in many cases it will anyways.
Some
> > cases
> > SDP exchange may be involved, and they may do things in order to
make
> > on a re-INVITE.  Otherwise the UA has to decide exactly which
possible
> set
> > reINVITE and live with the glitch - especially since most current
UAs
> > don't
> > somewhat valid reasons).  That would cause a new ICE/TURN/STUN/etc
to
> be
> > end of the call, adding several tenths more in transit delay.  Also
-
> this
> > is an AVT RFC; while SIP is a primary user, other signaling layers
may
> be

---

From: Randell Jesup <[email-masked]>
Date: Thu, 11 Jan 2007 22:43:53 -0500

>[Hari] re-negotiated ones are permanent changes. reINVITE is the right

That was a random contrived example.  There are cases where the delay to
signal via reINVITE would cause congestion, not to mention the other
reINVITE issues (ports, ICE, codec/jitter reset, proxy load, etc) as
discussed in the other thread and seconded by Roni.  Link bandwidth could
flip on a second by second basis or more often, or so I assume.

>hence cannot be treated as temporary.

Comments from the authors?  Part of the reason for TMMBR is to avoid
congestion on (temporary or anticipated) bandwidth changes, as opposed to
reacting to congestion (i.e. TFRC).

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 18 Jan 2007 11:15:39 +0100

> reacting to congestion (i.e. TFRC).

In my view even if you suffer from a permanent change in your receiver 
bandwidth you may still want to react to this quickly. Thus send your 
TMMBR, then do the SIP renegotiation to avoid causing unnecessary 
congestion due to slow reaction.

I would also caution against mapping things to hard against how a 
particular link layer works today. Because these things has a tendency 
to change. There are also other technologies that works different.

I would also like to point out the Translator/Mixer use case which has 
nothing at all to do with link layers between the TMMBR sending entity 
and the media sender. This is case where congestion control information 
on another part of the topology needs to be forwarded upstream.

 From my read through of the comments related to this, there is no one 
questioning the usefulness of TMMBR in general, only in which cases it 
makes sense to apply. Are there anything in this context in the draft 
that someone should be changed? In that case be explicit and propose 
changes.

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: Magnus Westerlund <[email-masked]>
Date: Thu, 18 Jan 2007 15:52:48 +0100

Hi,

I have just read through the whole debate around what the TMMBR bitrate 
value should contain. I below attempt to summarize this and provide my 
view in relation to the arguments that has been made.

1. Bandwidth vs Bitrate
Yes, we should change to bitrate as this is clearer. We should also 
document the assumption that the value indicated is a smoothed value. 
The only way of only indicating a single bit-rate value is to assume 
that these bits are sent in constant rate instead of bursty fashion. If 
we where trying to capture the bursty reality of most links then we 
would need to indicate a token bucket. Due to token buckets having two 
parameters then the owner comparison would be difficult. In addition it 
is not easy to determine the token bucket parameters. Thus I propose we 
don't go there, instead the receiver will face the jitter he will 
subjected to by the path.

2. What header overhead should be included.

To me it seemed that most people was in favor of using a media rate, 
like RTP payload, or even media codec rate to be signaled. I disagree 
due to the following reasons:

The receiver can only indicate a gross bit-rate which is available to 
receive with. He can not guess what packet rate or packetization the 
media sender will use. Thus the media sender must be the one responsible 
for making the sum of media rate and packetization overhead fit the 
indicated TMMBR. If not the receiver has no idea how much of his 
available bit-rate that actually will be consumed.

When talking about gross bit-rate and packetization overhead it should 
include all headers down to and including the common layer. In the 
context of Internet applications we would then be talking about IP.

I also would like to say that I agree with Guido Franceschini that TIAS 
is flawed in this regard. TIAS only works for declarative usages of SDP. 
TIAS is a media sender property. It doesn't work with SDP offer/answer 
as that requires one to describe the bitrate available to receive with. 
Thus RFC 3890 should be updated to address these issues.

This leads to the main issue with using a bitrate value that include all 
overhead down to IP level. Which is the one that TIAS tried to address, 
the variable overhead for different parts of the transport topology. 
Lets try to understand when this becomes an issue. If one uses a total 
bitrate in the signalling the receiver may receive larger than TMMBR 
value in the case that the headers get expanded. This may occur in a NAT 
doing IPv4 to IPv6 translation on the path. I actually have a hard time 
thinking of another device doing changes without being an RTP 
translator. I think this is important as an RTP translator could be made 
responsible to translate the TMMBR request also. However that would not 
be possible to do perfect without the packet rate. Thus the question 
arise how well this should work.

Guido's idea of including the average packet overhead might actually not 
be a bad one. As that would allow the sender to take into consideration 
the per packet overhead seen by the TMMBR sending receiver. I would 
define that overhead as the number of bytes in addition to RTP payload. 
The reason to include the RTP header itself is that if there are some 
translator or mixer doing something to expand the RTP header.

Comments on this?

Cheers

Magnus Westerlund

---

From: "Desineni, Harikishan" <[email-masked]>
Date: Mon, 22 Jan 2007 15:25:24 -0800

> Thus RFC 3890 should be updated to address these issues.

I am somewhat confused here. Per 3890, TIAS is a receive parameter and
TIAS semantics for offer/answer are the same as those used for AS. 

>From Sec 5.8, RFC4566 
"AS The bandwidth is interpreted to be application specific (it will
      be the application's concept of maximum bandwidth)."

>From Sec 5.1, RFC3264
"If the bandwidth attribute is present for a stream, it indicates the
   desired bandwidth that the offerer would like to receive."

> translator or mixer doing something to expand the RTP header.

It seems like a useful parameter and I think Guido's proposal is in a
good direction addressing the complete capacity/bandwidth signaling
problem. However, it should be made clear how mean packet overhead (MPO)
can be used to derive packet rate. I think that few more parameters
might be necessary to negotiate appropriate packet rate in each
direction of a p2p session.

For P2P scenario described by Guido, packet rate for the stream in
answerer-->offer direction should be MIN(packet rate on Offerer's
downlink, packet rate on Answerer's uplink).

[
TIASr - same as TIAS from RFC3890
TIASs (TIAS/send) - RTP payload bit rate of the sender (offerer or
answerer)

TIDCo - transport independent downlink capacity of the offerer
TIDCa - transport independent downlink capacity of the answerer

TIUCo - transport independent uplink capacity of the offerer
TIUCa - transport independent uplink capacity of the answerer

Po_d - max packet rate on offerer's downlink
Pa_u - max packet rate on answerer's uplink
Po_u - max packet rate on offerer's uplink
Pa_d - max packet rate on answerer's downlink

]

Packet rate in answerer->offerer direction = MIN(Po_d, Pa_u)
Po_d = (TIDCo - TIASr)/(MPO offerer's downlink)
Pa_u= (TIUCa - TIASs)/(MPO answerer's uplink)

Packet rate in offerer-> answerer direction = MIN(Po_u, Pa_d)
Po_u = (TIUCo - TIASs)/ (MPO offerer's uplink)
Pa_d = (TIDCa - TIASr)/(MPO answerer's downlink)

If only offer and answerer need to compute the max packet rate,
parameters that need to be signaled in SDP are TIDC, TIAS, MPO.
TIUC,TIASs and MPO over local uplink will anyways be know to the stream
sender and hence no need to signal them in SDP.

If a middle box needs to know the max packet rate then the maxprate
needs to be signaled/negotiated in each direction in SDP.

Offer
----
m = video 59200 RTP/AVP 97
a=tidc:128000  (TIDCo)
a=tiuc:90000   (TIUCo)
a=mpo:320      (MPO offerer's downlink)
a=tias:100000  (TIASr)
a=tias/send:85000 (TIASs)
a=maxpraterecv:87  (Po_d)
a=maxpratesend:16    (Po_u)

Answer
-----
m = video 34620 RTP/AVP 97
a=tidc:64000   (TIDCa)
a=tiuc:90000   (TIUCa)
a=mpo:320      (MPO of answerer's downlink)
a=tias:55000   (TIASr)
a=tias/send:85000 (TIASs)
a=maxpratesend:16  (Pa_u)
a=maxpraterecv:28  (Pa_d)

After the session establishment, 
Maxpacket rate in offer->answerer is 16
Maxpacket rate in answerer->offerer is 16

Answerer can be made to return the final values in each direction 
I.e., maxpratesend:16, maxpraterecv:16

Another benefit of TIUC is the capacity optimization. Without TIUC,
uplink or downlink of may get over allocated. Here is an example which
explains the use and need for TIUC.

All bandwidth values are in bps

Offer
=========
m = video 59200 RTP/AVP 97
a=tidc:128000
a=mpo:320
a=tias:100000

Answer
========
m = video 34620 RTP/AVP 97
a=tidc:128000
a=mpo:320
a=tias:100000

(Attribute values for Bidirectional video stream as signaled in SDP
Offer/answer)
                  _____________
        (???)    |             |  (128Kbps)  
Offerer ---------|             |-------------> answerer
        <--------|             |-------------
      (128Kbps)  |_____________|  (???)

In the above signaling, uplink capacity of offerer and answerer are
unknown.

Let's say both offerer and answerer are limited to use downlink capacity
128Kbps and uplink capacity 64Kbps. As the answerer does not know about
offers's uplink capacity, answerer would overallocate its downlink
capacity to 128K. There is no way for the offerer to inform the answerer
that the answerer can reduce its downlink to 64Kbps and save some
capacity.
The same applies in the reverse direction.

(Resultant capacity allocation for video after session establishment)

                  _____________
      (64Kbps)   |             |  (128Kbps)  
Offerer ---------|             |-------------> answerer
        <--------|             |-------------
      (128Kbps)  |_____________|  (64Kbps)

Overallocated downlink capacity of the answerer : 64Kbps
Overallocated uplink capacity of the offerer: 64Kbps
Total capacity wasted = 128Kbps

With the help of TIUC, answerer can make sure that its
*uplink capacity allocation does not exceed offerer's downlink capacity
*downlink capacity allocation does not exceed offerer's uplink capacity.

Offer
=========

m = video 59200 RTP/AVP 97
a=tidc:128000
a=tiuc:64000
a=mpo:320
a=tias:100000

Answer
========

m = video 34620 RTP/AVP 97
a=tidc:128000
a=tiuc:64000 
a=mpo:320
a=tias:100000

(video stream capacity per SDP offer/answer signaling)

                  _____________
      (64Kbps)   |             |  (64Kbps)  
Offerer ---------|             |-------------> answerer
        <--------|             |-------------
      (128Kbps)  |_____________|   (64Kbps)

(Resultant capacity allocation for video after session establishment)

                  _____________
      (64Kbps)   |             |  (64Kbps)  
Offerer ---------|             |-------------> answerer
        <--------|             |-------------
       (64Kbps)  |_____________|   (64Kbps)

Overallocated downlink capacity of the answerer : 0
Overallocated uplink capacity of the offerer: 0
Total capacity wasted = 0

Comments ?  (May be we should branch this out into a different thread)

--Hari