Subject: Re: Issues with using tuples in TMMBR was:Re: R: [AVT] CCM draft review -- should"bandwidth"includetheheaderoverhead

From: Magnus Westerlund <[email-masked]>
Date: Thu, 01 Mar 2007 14:32:34 +0100

Magnus Westerlund skrev:
> 
> A second step would be to eliminate all tuples where they although have 
> higher bit-rate, the overhead value is only slightly larger so that the 
> first restriction does not allow a packet rate that is large enough, 
> even when all the allowed bit-rate is spent on headers. An example to 
> illustrate this:
> 
> Lets say that you have a tuple of (35kbps, 40 bytes) and a second one 
> that is (45 kbps, 50 bytes).  The maximum packet rate the first one 
> allows are 35000 /(40*8) = 109.375 packets / s. Performing the same 
> calculation for the second tuple yields 45000/(50*8) = 112.5 packets/s. 
> Thus the second tuple does not provide a restriction that is applicable 
> given that the first one is included in the set.
> 
> 5. For each tuple in X calculate the largest possible packet-rate 
> yielding no useful work, i.e. bit-rate / overhead and store in vector Y.
> 
> 6. For each element in X, index by i, in case Yi+1 is larger than Yi 
> remove Yi+1 and Xi+1 from the sets and repeat comparison for i.
> 

The above outlined algorithm is wrong. What needs to be compared is if 
the RTP payload bit-rate for i+1 becomes smaller than for i for any 
packet rate in the range achievable by i. In case the below becomes true 
then i+1 is a restriction.

(X_i+1_BR - X_i+1_OH*(X_i_BR/X_i_OH)) < 0

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

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

---

From: "Franceschini Guido" <[email-masked]>
Date: Thu, 1 Mar 2007 18:48:59 +0100

Dear Magnus,

your algorithm is far too complex, IMO. I described earlier a different and simpler one, but maybe it's worth explaining it again.
I know you already had observation about changing the packetrate during transmission, but ... some more feedback on that at the end of the mail

My proposal is as follows:
TMMBR provides: TIDC, MPO (measured at a receiver specific reference layer)
TMMBN provides: TIAS, maxprate, ID of most constraining receiver

Each Receiver measures and communicates its <TIDC, MPO>: the receiver can be accurate in doing this.
The Sender knows what it is going to send, therefore knows the maxprate. Maybe the Sender has a choice among a set of possible maxprate.
Whenever the sender receives a TMMBR, it maps the <TIDC, MPO> values, by means of the maxprate, into a codec bitrate maximum (maxTIAS).
E.g.:
 <35000, 40> with maxprate=50 leads to maxTIAS=(35000-40*8*50)=19000
 <35000, 40> with maxprate=25 leads to maxTIAS=(35000-40*8*25)=27000

The sender collects all TMMBR, and for each maxprate it can support, mantains an ordered list of the Receiver constraints.
Then decides the maxprate (and thus the TIAS) it will use, and notifies this by means of TMMBN.
Again, the Sender has control on these TIAS and maxprate parameters, thus it can be accurate.

Finally, each receiver, by getting the TMMBN, can estimate the bandwidth (at its own specific reference layer) that the sender will consume, and will therefore be able to decide whether to generate or not further TMMBR messages when its link capacity changes.

Now a detailed example, with figures.

At time T0:
- receiver R1 sends TMMBR(35000, 20)
- receiver R2 sends TMMBR(50000, 60)
- receiver R3 sends TMMBR(30000,  0)
- receiver R4 sends TMMBR(45000, 50)

Sender can use either maxprate=25 or maxprate=50, and computes:
@maxprate=25
	maxTIAS(R1) = (35000-20*8*25)=35000- 4000=31000
	maxTIAS(R2) = (50000-60*8*25)=50000-12000=38000
	maxTIAS(R3) = (30000- 0*8*25)=30000-    0=30000
	maxTIAS(R4) = (45000-50*8*25)=45000-10000=35000
@maxprate=50
	maxTIAS(R1) = (35000-20*8*50)=35000- 8000=27000
	maxTIAS(R2) = (50000-60*8*50)=50000-24000=26000
	maxTIAS(R3) = (30000- 0*8*50)=30000-    0=30000
	maxTIAS(R4) = (45000-50*8*50)=45000-20000=25000

Thus, the sender creates these ordered lists:
@maxprate=25
	maxTIAS(R3)=30000
	maxTIAS(R1)=31000
	maxTIAS(R4)=35000
	maxTIAS(R2)=38000

@maxprate=50
	maxTIAS(R4)=25000
	maxTIAS(R2)=26000
	maxTIAS(R1)=27000
	maxTIAS(R3)=30000

Sender decides to work at maxprate=25:
==> sender sends TMMBN(30000, 25, R3)

Each receiver estimates how much of its link capacity (at its own reference layer) is consumed:
R1: (30000+20*8*25)=30000+ 4000=34000 (available is 35000, ok)
R2: (30000+60*8*25)=30000+12000=42000 (available is 50000, ok)
R3: (30000+ 0*8*25)=30000+    6=30000 (available is 30000, saturated)
R4: (30000+50*8*25)=30000+10000=40000 (available is 45000, ok)

At time T1:
In R2 the bandwidth available at its reference layer changes from 50000 to 45000.
Since R2 knows that the sender is currently consuming 42000 of its reference layer bandwidth, it does not generate any TMMBR

At time T2:
In R2 the bandwidth available at its reference layer changes from 45000 to 40000.
Since R2 knows that the sender is currently consuming 42000 of its reference layer bandwidth, it generates a TMMBR:
- receiver R2 sends TMMBR(40000, 60)

The sender updates its computations:
@maxprate=25
	maxTIAS(R2) = (40000-60*8*25)=40000-12000=28000
@maxprate=50
	maxTIAS(R2) = (40000-60*8*50)=40000-24000=16000

And updates its ordered lists:
@maxprate=25
	maxTIAS(R2)=28000
	maxTIAS(R3)=30000
	maxTIAS(R1)=31000
	maxTIAS(R4)=35000
@maxprate=50
	maxTIAS(R2)=16000
	maxTIAS(R4)=25000
	maxTIAS(R1)=27000
	maxTIAS(R3)=30000

Sender decides to work at maxprate=25:
==> sender sends TMMBN(28000, 25, R2)

All receivers update as well their estimate on their link capacity consumption

At time T3:
In R2 the bandwidth available at its reference layer changes from 40000 back to 50000.
Since R2 knows that it is the most constraining receiver, it generates again a TMMBR:
- receiver R2 sends TMMBR(50000, 60)

The sender updates its computations: (back to T0 figures)
And updates its ordered lists: (back to T0 figures)
Sender decides to work at maxprate=25:
==> sender sends TMMBN(30000, 25, R3)
All receivers update as well their estimate on their link capacity consumption (back to T0 figures)

Now some more feedback about your obseravation concerning the change in packet rate.

What the sender communicates is the maxpacketrate: as far as it complies with that, fine. Of course, if the sender said "maxprate=50", and then only generates 25 packets/sec, it is sub-optimally using the available resources, true.
Suppose however that the sender recognizes this fact, and decides to better exploit the available resources.
As per my example above, suppose it has sent at time T0:
TMMBN(25000, 50, R4)
But then recognizes that it is actualy working at no more than 25 packets/sec
Then it must announce this change, to give receivers a chance to send back a TMMBR updating their <TIDC,MPO>, in case these values changed in the meantime and the receiver decided not to generate a TMMBR (as at time T1 in my example).
If instead we accept that the sender can autonomously change its transmission 'style', we should require all receivers to always generate TMMBR whenever their link capacity diminishes, indipendently of whether they estimate that this change would affect the sender behaviour.

Thus, in my view, we should either:
- allow the sender to vary its <TIAS, maxprate> at its own discrection, but request receivers to always generate TMMBR when their link capacity diminishes
- or request the sender to announce any change in <TIAS, maxprate>, and allow receivers to generate TMMBR only when their link capacity change would affect the sender behaviour.

Best regards
Guido

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: giovedì 1 marzo 2007 14.33
> To: Magnus Westerlund
> Cc: Franceschini Guido; [email-masked]
> Subject: Re: Issues with using tuples in TMMBR was:Re: R: [AVT] CCM
> draft review -- should"bandwidth"includetheheaderoverhead
> 
> 
> Magnus Westerlund skrev:
> > 
--------------------------------------------------------------------

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: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 01 Mar 2007 14:37:50 -0500

This is actually a linear programming problem. You are trying to
determine minimum bit rate subject to N linear constraints, where N is
the number of reporting receivers.

Franceschini Guido wrote:
> Dear Magnus,
> 
> your algorithm is far too complex, IMO. I described earlier a
> different and simpler one, but maybe it's worth explaining it again. 
> I know you already had observation about changing the packetrate
> during transmission, but ... some more feedback on that at the end of
> the mail
> 
> 
> My proposal is as follows: TMMBR provides: TIDC, MPO (measured at a
> receiver specific reference layer) TMMBN provides: TIAS, maxprate, ID
> of most constraining receiver
> 
> Each Receiver measures and communicates its <TIDC, MPO>: the receiver
> can be accurate in doing this. The Sender knows what it is going to
> send, therefore knows the maxprate. Maybe the Sender has a choice
> among a set of possible maxprate. Whenever the sender receives a
> TMMBR, it maps the <TIDC, MPO> values, by means of the maxprate, into
> a codec bitrate maximum (maxTIAS). E.g.: <35000, 40> with maxprate=50
> leads to maxTIAS=(35000-40*8*50)=19000 <35000, 40> with maxprate=25
> leads to maxTIAS=(35000-40*8*25)=27000
> 
> The sender collects all TMMBR, and for each maxprate it can support,
> mantains an ordered list of the Receiver constraints. Then decides
> the maxprate (and thus the TIAS) it will use, and notifies this by
> means of TMMBN. Again, the Sender has control on these TIAS and
> maxprate parameters, thus it can be accurate.
> 
> Finally, each receiver, by getting the TMMBN, can estimate the
> bandwidth (at its own specific reference layer) that the sender will
> consume, and will therefore be able to decide whether to generate or
> not further TMMBR messages when its link capacity changes.
> 
> 
> At time T0: - receiver R1 sends TMMBR(35000, 20) - receiver R2 sends
> TMMBR(50000, 60) - receiver R3 sends TMMBR(30000,  0) - receiver R4
> sends TMMBR(45000, 50)
> 
> @maxprate=25 maxTIAS(R1) = (35000-20*8*25)=35000- 4000=31000 
> maxTIAS(R2) = (50000-60*8*25)=50000-12000=38000 maxTIAS(R3) = (30000-
> 0*8*25)=30000-    0=30000 maxTIAS(R4) =
> (45000-50*8*25)=45000-10000=35000 @maxprate=50 maxTIAS(R1) =
> (35000-20*8*50)=35000- 8000=27000 maxTIAS(R2) =
> (50000-60*8*50)=50000-24000=26000 maxTIAS(R3) = (30000-
> 0*8*50)=30000-    0=30000 maxTIAS(R4) =
> (45000-50*8*50)=45000-20000=25000
> 
> Thus, the sender creates these ordered lists: @maxprate=25 
> maxTIAS(R3)=30000 maxTIAS(R1)=31000 maxTIAS(R4)=35000 
> maxTIAS(R2)=38000
> 
> @maxprate=50 maxTIAS(R4)=25000 maxTIAS(R2)=26000 maxTIAS(R1)=27000 
> maxTIAS(R3)=30000
> 
> Sender decides to work at maxprate=25: ==> sender sends TMMBN(30000,
> 25, R3)
> 
> Each receiver estimates how much of its link capacity (at its own
> reference layer) is consumed: R1: (30000+20*8*25)=30000+ 4000=34000
> (available is 35000, ok) R2: (30000+60*8*25)=30000+12000=42000
> (available is 50000, ok) R3: (30000+ 0*8*25)=30000+    6=30000
> (available is 30000, saturated) R4: (30000+50*8*25)=30000+10000=40000
> (available is 45000, ok)
> 
> 
> At time T1: In R2 the bandwidth available at its reference layer
> changes from 50000 to 45000. Since R2 knows that the sender is
> currently consuming 42000 of its reference layer bandwidth, it does
> not generate any TMMBR
> 
> 
> At time T2: In R2 the bandwidth available at its reference layer
> changes from 45000 to 40000. Since R2 knows that the sender is
> currently consuming 42000 of its reference layer bandwidth, it
> generates a TMMBR: - receiver R2 sends TMMBR(40000, 60)
> 
> The sender updates its computations: @maxprate=25 maxTIAS(R2) =
> (40000-60*8*25)=40000-12000=28000 @maxprate=50 maxTIAS(R2) =
> (40000-60*8*50)=40000-24000=16000
> 
> And updates its ordered lists: @maxprate=25 maxTIAS(R2)=28000 
> maxTIAS(R3)=30000 maxTIAS(R1)=31000 maxTIAS(R4)=35000 @maxprate=50 
> maxTIAS(R2)=16000 maxTIAS(R4)=25000 maxTIAS(R1)=27000 
> maxTIAS(R3)=30000
> 
> Sender decides to work at maxprate=25: ==> sender sends TMMBN(28000,
> 25, R2)
> 
> At time T3: In R2 the bandwidth available at its reference layer
> changes from 40000 back to 50000. Since R2 knows that it is the most
> constraining receiver, it generates again a TMMBR: - receiver R2
> sends TMMBR(50000, 60)
> 
> The sender updates its computations: (back to T0 figures) And updates
> its ordered lists: (back to T0 figures) Sender decides to work at
> maxprate=25: ==> sender sends TMMBN(30000, 25, R3) All receivers
> update as well their estimate on their link capacity consumption
> (back to T0 figures)
> 
> 
> 
> What the sender communicates is the maxpacketrate: as far as it
> complies with that, fine. Of course, if the sender said
> "maxprate=50", and then only generates 25 packets/sec, it is
> sub-optimally using the available resources, true. Suppose however
> that the sender recognizes this fact, and decides to better exploit
> the available resources. As per my example above, suppose it has sent
> at time T0: TMMBN(25000, 50, R4) But then recognizes that it is
> actualy working at no more than 25 packets/sec Then it must announce
> this change, to give receivers a chance to send back a TMMBR updating
> their <TIDC,MPO>, in case these values changed in the meantime and
> the receiver decided not to generate a TMMBR (as at time T1 in my
> example). If instead we accept that the sender can autonomously
> change its transmission 'style', we should require all receivers to
> always generate TMMBR whenever their link capacity diminishes,
> indipendently of whether they estimate that this change would affect
> the sender behaviour.
> 
> Thus, in my view, we should either: - allow the sender to vary its
> <TIAS, maxprate> at its own discrection, but request receivers to
> always generate TMMBR when their link capacity diminishes - or
> request the sender to announce any change in <TIAS, maxprate>, and
> allow receivers to generate TMMBR only when their link capacity
> change would affect the sender behaviour.
> 
> Best regards Guido
> 
> 
>> -----Original Message----- From: Magnus Westerlund
>> [mailto:[email-masked]] Sent: giovedì 1 marzo 2007
>> 14.33 To: Magnus Westerlund Cc: Franceschini Guido; [email-masked] 
>>> that is (45 kbps, 50 bytes).  The maximum packet rate the first
>>> one allows are 35000 /(40*8) = 109.375 packets / s. Performing
>>> the same calculation for the second tuple yields 45000/(50*8) =
>> 112.5 packets/s.
>> The above outlined algorithm is wrong. What needs to be compared is
>> if the RTP payload bit-rate for i+1 becomes smaller than for i for
>> any packet rate in the range achievable by i. In case the below 
>> becomes true then i+1 is a restriction.
>> 
>>  Ericsson AB                | Phone +46 8 4048287 Torshamsgatan 23
>> | Fax   +46 8 7575550 S-164 80 Stockholm, Sweden | mailto:
>> [email-masked] 
> 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
> 
>

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 02 Mar 2007 10:59:50 +0100

Guido,

First of all, my proposal may look complex in the way I describe it. I 
think this is primarily because I like you to understand how it works 
and why. However, in the end I do hope the implementation of this 
proposal is not that difficult.

In regards to your proposal. I think you are making one serious error in 
the proposal in regards to packet rate. With a single tuple, you can't 
move from the maxpacket rate you have proposed without risking that some 
other tuple is the more constraining one. Lets exemplify this with the 
attached graph. The graph plots RTP payload bit-rate as a function of 
packet rate for two different tuples, <35kbps, 40 bytes> and <40kbps,60 
bytes>. As can be seen the 35kbps one is the more constraining one up to 
slightly above 30 packets per second. Over that rate the overhead has 
eaten up the larger availble bit-rate from the second tuple.

Assume in this case that you would be running with a maxpacket rate of 
50 which would mean that according to your proposal the media sender 
would announce the second tuple as the limiting one. When the sender 
then likes to change his packetization to 25 pps then the only 
constraint the media sender is aware of is the second tuple. Thus 
resulting in it overrunning the path to receiver one.

If I understand you correctly, here you argue that one should simply 
send a new TMMBN to tell the media senders that they have a new packet 
rate. However that I think have some serious issues.

First it doesn't work for variable packet rate codecs, like video. In a 
video rate control you could actually take the dependencies of packet 
rate into account to create streams that work in situation, 
independently if it is better to send many packets or fewer. However 
then you have understand the limitations over the spectrum of possible 
packet rates.

Secondly, even for codecs that has rather stable packetization like most 
voice codecs your proposal results in extra delay as you first need to 
announce your new packet rate and then wait for TMMBR messages that 
might appear to update the current constrain, or choose to potentially 
overload some path.

Bo, Ingemar and me are working on providing better description of our 
proposal in the form of an update draft. I do expect us to be able to 
provide some type of pseudo code for an algorithm that can be used to 
determine if a tuple is more restrictive than the current established set.

cheers

Magnus Westerlund

---

From: "Franceschini Guido" <[email-masked]>
Date: Fri, 2 Mar 2007 14:18:30 +0100

Magnus,

my impression is that in you are going deep into the details before assessing the global picture first.
I understand your algorithm to reduce the initial set X of tuples into a smaller set, by eliminating all tuples that do not provide any additional information.
However, you have not clarified yet what you would insert in the TMMBN message, nor the logic by which a receiver would decide whether to generate a TMMBR message or not.

I think we should first assess 'how do we want the system to work' and then enter the details of 'how to obtain this behavior'.
In other words: we are dealing with a _shared_ logic, that runs partly in the sender, and partly in the receivers: we should first assess how the involved parties co-operate, and only then dig into the specific work of the sender (actually, my opinion is that in the specification we do not need to enter such details at all: maybe we can provide an informative section showing a possible algorithm, but this should have no normative value).

Forget for a while my algorithm or your algorith, and just focus on the messages on the wire (i.e. on the normative part)

According to my proposal:
TMMBR provides: TIDC, MPO (measured at a receiver specific reference layer)
TMMBN provides: TIAS, maxprate, ID of most constraining receiver

Note that TMMBN states a sort of contract: "I, the sender, guarantee to not exceed neither this media bitrate, nor this packet rate".

Furthermore, I describe two possible choices:
1) allow the sender to vary its <TIAS, maxprate> at its own discrection, but request receivers to always generate TMMBR when their link capacity diminishes
2) or request the sender to announce any change in <TIAS, maxprate>, and allow receivers to generate TMMBR only when their link capacity change would affect the sender behaviour.

Solution 1) basically means that the TMMBN contract is void.

Solution 2) instead means that if the Sender changes the contract, it must announce it.

PROS of solution 1 is that it allows changing the packet rate at the sender side at any time
CONS of solution 1 is that it forces receivers to generate TMMBR whenever their link capacity diminishes. Furthermore (depending of how much information is carried by TMMBN), receiver might be required to generate TMMBR also when their link capacity grows, since a receiver might not be aware of wheter it is acting as the most constraining bottleneck in some packetrate case.
In one word, the CONS of solution 1 is that a lot of TMMBR traffic is required, thus it does not scale.

PROS of solution 2 is that receivers have a "contract" they can look at in order to determine whether they have to generate a TMMBR or not. This drastically reduces the number of TMMBR messages they generate, and thus scales better to large groups.
CONS of solution 2 is that in case the Sender decides to alter the maxpacketrate, a procedure shall be initiated by the sender itself to change the "contract". Such procedure might probably re-use the same TMMBN/TMMBR messages.

I am in favor of solution 1, since I believe that reducing the TMMBR traffic and scaling to large groups is more important than allowing for maxpacketrate changes, nevertheless this is just my opinion.

I believe however that we should assess _this_ first, i.e. the contours of the (shared!) algorithm, and only after having clarified this it might make sense to go deep into the details of the sender algorithm itself.

Cheers
Guido

> Sent: venerdì 2 marzo 2007 11.00
> To: Franceschini Guido
> Cc: [email-masked]

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

---

From: Magnus Westerlund <[email-masked]>
Date: Sun, 04 Mar 2007 15:36:43 +0100

Okay,

I will explain what the behavior I was thinking of. I thought it was 
obvious as it is exactly like the one documented in last version of the 
draft except with the difference that there are multiple limitations 
rather than a single bit-rate value.

A session starts with a single limitation equal to the session maximum 
bit-rate and a overhead value equal to 0.

A receiver when learning about a limitation on its side take its tuple 
and compare it with the currently minimal set of limitation tuples 
provided by the latest TMMBN message. This comparision will yield if the 
receivers limiation is stricter than the current set. In that case it 
send a TMMBR message.

The TMMBR message contains, SSRC of requestor, SSRC for media sender to 
which the limitation applies, bitrate value meassured at the layer the 
overhead value is messaured and a overhead value measured as an average 
between start of header for layer bit-rate is measured and the RTP 
payload's start.

The media sender upon receiving a TMMBR message will perform the same 
comparison and construct the set of tuples that provide the most strict 
limitations. Then sending that set out using a TMMBN which contains the 
set of SSRC owning the limit, the bit-rate value and the per packet 
overhead.

You will find more details in the draft we will submit tomorrow.

Cheers

Magnus Westerlund

---

From: Randell Jesup <[email-masked]>
Date: Mon, 05 Mar 2007 10:43:17 -0500

>bit-rate and a overhead value equal to 0.

I hate to beat a dead horse, but exactly what does "session maximum
bit-rate" mean in this context?  And do the sender and the receiver have
the same idea about what the maximum is to start with in all scenarios?
Is it the requested bitrate the receiver sent?  What if the sender decided
to use a higher (or lower) rate?

What if the receiver is joining an existing session?

Other than that, I'm ok with it.

>A receiver when learning about a limitation on its side take its tuple and
>compare it with the currently minimal set of limitation tuples provided by
>the latest TMMBN message. This comparision will yield if the receivers
>limiation is stricter than the current set. In that case it send a TMMBR
>message.

The only question (perhaps answered in the upcoming draft) is what
"stricter" exactly means, and how that relates to packet rate.  Note that
worst-case, an over-conservative assumption by the receiver here will
merely mean an extra TMMBR/TMMBN, especially if the receiver includes most
or all overhead in the TMMBR.  The sender still decides which TMMBR is
really the most strict.

Progress!  :-)

-- 
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: Magnus Westerlund <[email-masked]>
Date: Mon, 05 Mar 2007 17:09:07 +0100

Hi,

The draft was submitted in time, hopefully it will pop out in a few days.

> to use a higher (or lower) rate?

The session maximum bit-rate is negotiated by the session setup 
protocol. For example the AS values in SDP when using SIP.

> What if the receiver is joining an existing session?

Also in this case there is some type of session establishment that can 
provide a upper limit. And when joining a session with already existing 
restrictions the receiver may send a TMMBR message to establish its 
limitation prior to seeing a TMMBN. In that case it will learn the set 
of restrictions from the TMMBN sent as reaction to the TMMBR.

> or all overhead in the TMMBR.  The sender still decides which TMMBR is

There is a way of finding the set of most strict limitations sent in the 
draft.

Cheers

Magnus Westerlund

---

From: Randell Jesup <[email-masked]>
Date: Mon, 05 Mar 2007 13:14:52 -0500

>protocol. For example the AS values in SDP when using SIP.

b=AS says "I, the receiver, would like you to (or suggest that you) send no
faster than this".  This is not negotiated per se, and it's not a hard
limit.  And note that whether it's meant to or not, the term "session
maximum bitrate" implies several things that are misleading - it implies
that it's a session-level (as opposed to media-stream-level) item.  (It may
be, but b=AS may be at the stream level, and I'm assuming that a TMMBR over
RTCP applies to the stream for that RTCP port.  Does it apply to the entire
session if a b=AS only existed at the session level?)  It also implies (to
the new reader) that there is a two-way maximum negotiated.  This isn't the
case, but the terminology will tend to confuse people (and has in these
discussions here).

>limitation prior to seeing a TMMBN. In that case it will learn the set of
>restrictions from the TMMBN sent as reaction to the TMMBR.

We should consider (if not already done) talking to this case in the draft,
if for no other reason than to guide implementors.