Subject: RE: [AVT] CCM draft review -- should "bandwidth" include the headeroverhead

From: "Even, Roni" <[email-masked]>
Date: Sun, 11 Feb 2007 15:22:11 +0200

Magnus,
This is our view about why to use the codec bit rate and not any overhead. We have to remember that this is mostly for video who does not have a fixed frame size and that packets can be larger than MTU size and thus may be broken differently based on implementations.

For one thing, the amount of data in the headers depends on whether header compression is in use.  Since header compression can be applied (or removed) anywhere along the path, the amount of overhead seen by the receiver might be different than the overhead seen by the transmitter.

Another reason is that an intermediate device (gateways, proxies, or other RTP media engine) might be re-packetizing the data.  This would also create a mismatch between the source and the receiver.  All of this is avoided if we define the bit rate to be the media rate.

A third way a mismatch can be created is by encryption, where an encryption pad is added (or possibly removed) at the campus edge.  So I'd also want that RTP padding to be excluded from the definition (not just the headers). 

Of course, we'd also prefer to keep it as media because that is what both H.323 and H.320 do and part of the usage of this command is to adapt rates between different transport channels.

Thanks
Roni Even
> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Thursday, January 18, 2007 4:53 PM
> To: Stephan Wenger
> Cc: Randell Jesup; [email-masked]
> Subject: Re: [AVT] CCM draft review -- should "bandwidth" include the
> headeroverhead
> 
> 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
> 
> 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

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

---

From: Randell Jesup <[email-masked]>
Date: Sun, 11 Feb 2007 11:26:19 -0500

"Even, Roni" <[email-masked]> writes:
>This is our view about why to use the codec bit rate and not any
>overhead. We have to remember that this is mostly for video who does not
>have a fixed frame size and that packets can be larger than MTU size and
>thus may be broken differently based on implementations.

Which is why TIAS (especially with TMMBR) is fundamentally broken for
offer/answer.  TIAS allows setting the max packet rate - fine for a
declarative use, but for offer/answer, it means that the receiver knows the
actual bandwidth (typically configured - "I have a 1Mbps downstream",
perhaps measured/probed, but usually NOT probed end-to-end to the sender),
it must (to send TIAS) follow RFC 3890 #6.4 in reverse, using a (high)
guess at maxprate.  When done, you basically have 
TIAS = BW - (maxprate*hsize).  

So the sender limits their codec to TIAS, and probably uses a lot less than
maxprate packets, wasting that bandwidth.  If maxprate was chosen too low,
the sender might have to (for video) reduce frame rate, especially if (as
you mention) the sender wants to send more packets than the receiver
anticipates.  If the sender goes over maxprate, it might work, and might
not, and there's no way for the sender to estimate how much to reduce the
TIAS amount by other than guessing.

I think b=AS (etc) make more sense; the sender knows the actual prate, size
of any headers it sends, and so can make best use of of the available bits.
If we need to know any additional header/etc modifications inbetween the
sender and receiver, then we should find a mechanism to discover and/or
signal that directly.

>For one thing, the amount of data in the headers depends on whether header
>compression is in use.  Since header compression can be applied (or
>removed) anywhere along the path, the amount of overhead seen by the
>receiver might be different than the overhead seen by the transmitter.

And how does the receiver making an offer or answer determine this?  The
receiver typically only knows the last-link settings.

>Another reason is that an intermediate device (gateways, proxies, or other
>RTP media engine) might be re-packetizing the data.  This would also
>create a mismatch between the source and the receiver.  All of this is
>avoided if we define the bit rate to be the media rate.

Avoided: not really.  I'd say pushed off into some undefined mechanism.
Or, if not handled, you're not really solving the problem.

>A third way a mismatch can be created is by encryption, where an
>encryption pad is added (or possibly removed) at the campus edge.  So I'd
>also want that RTP padding to be excluded from the definition (not just
>the headers).

And again, how does the receiver know this to include it in the TIAS
calculation?  If this is an RTP/RTCP-aware midbox, it could adjust BW
values - if *everything* that can modify bandwidth is aware and handles
TIAS in offers and TMMBR, you could adjust TIAS by (maxprate *
packet_delta), but in reality I don't see this happening.  BTW, any
end-to-end signalling or media encryption will cause a major headache here
- the midbox can't see/modify these values.  At best it could in some cases
signal the modification separately or in a separate tag at call setup, but
that's not an option with current protocols.

>Of course, we'd also prefer to keep it as media because that is what both
>H.323 and H.320 do and part of the usage of this command is to adapt rates
>between different transport channels.

I'd say then push the burden of converting to bandwidth into media rate
onto the converter, not into every endpoint (especially since using these
conversions seems to require either a lot of assumptions or potentially
wastes bandwidth).

I think I'm pretty much in agreement with Magnus here.

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

This speaks to my comment above about finding a way to signal overhead
separate from link bandwidth.

-- 
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: "Even, Roni" <[email-masked]>
Date: Mon, 12 Feb 2007 11:32:53 +0200

Randell,
I think part of the discussion is because there is a lack of application
usage.
For example, on a gateway between H.320 and SIP you need to limit the
codec BW bellow the circuit switch rate. Same for a mixed conference
that has ISDN as well as SIP or H.323 parties.
This is why in H.323 and H.320 the rate is the codec rate
Roni Even

> From: Randell Jesup [mailto:[email-masked]]
> Sent: Sunday, February 11, 2007 6:26 PM
> To: Even, Roni
> Cc: Magnus Westerlund; Stephan Wenger; [email-masked]
> declarative use, but for offer/answer, it means that the receiver
knows
> the
> >> Guido's idea of including the average packet overhead might
actually
> not
> 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, 12 Feb 2007 15:07:27 +0200

Folks,

I have a proposal in the best tradition of ITU-T standardization :-):  
let's do it both.

Roni has compelling arguments, I believe, for the interpretation of  
the TMMBR bitrate as the codec bitrate only.  I agree with him that  
using the codec bitrate opens cross-protocol application spaces that  
would otherwise be closed.  And, the codec bitrate is not affected by  
ROHC, IPv4/v6 issues, and so on.

Magnus and others have suggested that including the header overhead  
makes sense as well, almost certainly for all-IP scenarios.  It's  
also what most folks assume in 3GPP SA4, which is going to be the  
first "customer" for TMMBR.

So let's do it both.  We can signal the interpretation by a bit in  
the header (sliced off from the bitrate---there are enough bits), or  
we can make this dependent on signaling.  I have a slight preference  
for the latter.

How does this sound?

Regards,
Stepha

On Feb 12, 2007, at 11:32 AM, Even, Roni wrote:

>> So the sender limits their codec to TIAS, and probably uses a lot  
>> less
>> than
>> I think b=AS (etc) make more sense; the sender knows the actual  
>> prate,
>> size
>>> encryption pad is added (or possibly removed) at the campus  
>>> edge.  So
> I'd
>> signal the modification separately or in a separate tag at call  
>> setup,
> but

---

From: "Even, Roni" <[email-masked]>
Date: Mon, 12 Feb 2007 19:51:28 +0200

Stephan,
I can agree with your suggestion in principal depending on the
mechanism. I just want to mention that the video conferencing products
are waiting for this and may implement it before 3GPP. Those are
shipping products that use today INFO based fast update and use b=TIAS
for bw.
Since I am not a participant in SA4 but comes from an industry that
ships video conferencing products for quiet some time I would like to
ask you to think about the input from this industry about using codec
rate for flow control in the RTCP feedback. I am not talking here about
the SDP parameter
Thanks

Roni Even

> From: Stephan Wenger [mailto:[email-masked]]
> Sent: Monday, February 12, 2007 3:07 PM
> To: Even, Roni
> Cc: Randell Jesup; Magnus Westerlund; [email-masked]
> >>> overhead. We have to remember that this is mostly for video who
does
> > not
> >>> have a fixed frame size and that packets can be larger than MTU
size
> > and
> >> maxprate packets, wasting that bandwidth.  If maxprate was chosen
too
> > low,
> >> the sender might have to (for video) reduce frame rate, especially
if
> > (as
> >> not, and there's no way for the sender to estimate how much to
reduce
> >> of any headers it sends, and so can make best use of of the
available
> >> bits.
> >> If we need to know any additional header/etc modifications
inbetween
> >>> For one thing, the amount of data in the headers depends on
whether
> >> header
> >>> Another reason is that an intermediate device (gateways, proxies,
or
> >> other
> >>> create a mismatch between the source and the receiver.  All of
this
> > is
> >> end-to-end signalling or media encryption will cause a major
headache
> > here
> >> - the midbox can't see/modify these values.  At best it could in
some
> >> cases
> >>> Of course, we'd also prefer to keep it as media because that is
what
> > both
> >>> H.323 and H.320 do and part of the usage of this command is to
adapt
> >> rates

---

From: "Desineni, Harikishan" <[email-masked]>
Date: Mon, 12 Feb 2007 12:26:18 -0800

That doesn't sound good to me. It complicates the definition and
confuses the implementers on what to use and when. 

Just one definition for TMMBR would be cleaner. Majority is towards
using it as pure media bitrate. 

I don't think 3GPP SA4 understand transport details that well as it is
not their core area. They depend on IETF to decide what is good in
general.

Thanks,
Hari

> Sent: Monday, February 12, 2007 5:07 AM
> To: Even, Roni
> Subject: Re: [AVT] CCM draft review -- should "bandwidth" include
> theheaderoverhead
> 
> Folks,
> 
does
size
too
if
reduce
available
inbetween
whether
or
this
headache
some
what
adapt

---

From: Randell Jesup <[email-masked]>
Date: Mon, 12 Feb 2007 15:46:06 -0500

>This is why in H.323 and H.320 the rate is the codec rate

Ok; H.320<->SIP gateway use has a reason for having TIAS for reception, but
not in place of (or used for) link bandwidth specifications.  In this case,
TIAS is specifying an aspect of the decoder or a link on the far side of
the device negotiating; it's not attempting to convey anything about the
link between the H320 gateway and the SIP device.  Normally (to my mind at
least), b=AS (etc) apply to telling the sender the configured or probed
link bandwidth available.  So I could see providing TIAS _and_ AS or CT.

This may be an aspect of the fact that I (and a lot of others) are focused
on pure SIP UA-to-UA unicast (i.e. phone call) scenarios, while you may
well be much more focused on H.323/etc interop and conferencing.

TMMBR (the original point of discusson here) is speaking to a link
restriction, and so I still feel that there should not be an assumption
that TMMBR should be applied to (implied) TIAS values, it should be applied
to link-bandwidth.  The argument being made is that TMMBR should be in
terms of TIAS, even if TIAS was not the original negotiation.

If there are multiple b=*'s of different types, which one takes precedence?
My assertion (assuming multiple b='s are valid) is that TMMBR should apply
to link bandwidth values if present (b=AS or b=CT), and to TIAS only if
b=TIAS is the only bandwidth value specified.  If no b= value is specified,
then I'm not sure and I'd have to review the spec.

---

From: Randell Jesup <[email-masked]>
Date: Mon, 12 Feb 2007 16:12:17 -0500

>using it as pure media bitrate. 

I don't consider it cleaner if I have to convert my b=AS/CT (somehow...)
into b=TIAS, apply TMMBR, and re-convert, and end up wasting bits because
of assumptions about maxprate/etc.  And I'd dispute the "majority"
assertion.  :-) But I'm a SIP "phone" guy, not a conferencing/H.* interop
guy.

>not their core area. They depend on IETF to decide what is good in

I'd be a little cautious - I'm not sure that if we define it in a way they
don't like (not useful to them, or too hard to use), they may decide to
ignore the IETF.  Perhaps not, I don't have any visibility beyond the
message's I've read here.  I wouldn't *assume* they'll happily implement
things if it doesn't fit into their needs - I certainly wouldn't; I'd say
screw it and implement what I need using APP or some such.  And that
fragmentation doesn't help anyone.

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 12 Feb 2007 22:38:17 +0100

Stephan Wenger skrev:
> Roni has compelling arguments, I believe, for the interpretation of the 
> TMMBR bitrate as the codec bitrate only.  I agree with him that using 
> the codec bitrate opens cross-protocol application spaces that would 
> otherwise be closed.  And, the codec bitrate is not affected by ROHC, 
> IPv4/v6 issues, and so on.
> 
> makes sense as well, almost certainly for all-IP scenarios.  It's also 
> what most folks assume in 3GPP SA4, which is going to be the first 
> "customer" for TMMBR.
> 
> So let's do it both.  We can signal the interpretation by a bit in the 
> header (sliced off from the bitrate---there are enough bits), or we can 
> make this dependent on signaling.  I have a slight preference for the 
> latter.
> 
> How does this sound?
> 

Not, good at all. This will only be confusing. Lets sort this discussion 
out and determine what we actually want to signal.

Roni, a media bit-rate without any indication of the amount of header 
overhead you be worse than a gross bit-rate value. The reason is that 
what you as a receiver know something about is the gross bit-rate. The 
receiver has no knowledge about how much overhead the sender will put on 
each packet. Thus a media bit-rate is hard to calculate for the receiver 
as it varies in two dimensions, packet rate and per packet overhead. 
Both can be changed by the sender.

Regarding the MTU reasoning. You really should avoid IP fragmentation. 
And therefore PMTUD should be run. As I see it one could run 
draft-ietf-pmtud-method over RTP simply by selecting to use the RTCP XR 
packet loss vector to inform the sender about which packets gets 
through. Also the NACK format would work. As RTP is designed to aim for 
the working point that doesn't fragment using fragmentation as an 
argument why media bit-rate is better is strange. If you have 
fragmentation problems, deal with that.

When it comes to repacketization or transcoding, then the TMMBR will 
need to be rewritten or absorbed by that entity. Due to the reason that 
it is that middelbox that determines the bit-rate forwarded to the 
receiver. We intend to include clearer guidance on this into the CCM 
draft, instead of what was present in the topologies.

I will try to write an analysis for the three proposals on the table.

TMMBR report:
a) Media Bit-rate
b) Gross bit-rate on IP-level
c) Gross bit-rate on IP-level and the amount of overhead seen in the 
received packets.

Cheers

Magnus Westerlund

---

From: "Even, Roni" <[email-masked]>
Date: Mon, 12 Feb 2007 23:49:16 +0200

Hi,
I think you have to know ow to convert from b= to the codec rate anyhow, otherwise how can you know how much to allow the encoder to use in term of bit rate.
On the receiver side, the way I see it is that once you establish the connection and want to use TMMBR you already know the codec rate you receive, if you decode so you can reduce the rate based on this information.
Roni

________________________________

מאת: Randell Jesup [mailto:[email-masked]]
נשלח: ב 12/02/2007 23:12
אל: Desineni, Harikishan
עותק לידיעה: Stephan Wenger; Even, Roni; Magnus Westerlund; [email-masked]
נושא: Re: [AVT] CCM draft review -- should "bandwidth" include theheaderoverhead

---

From: "Desineni, Harikishan" <[email-masked]>
Date: Mon, 12 Feb 2007 13:52:22 -0800

> Sent: Monday, February 12, 2007 12:46 PM
> To: Even, Roni
> Ok; H.320<->SIP gateway use has a reason for having TIAS for
reception,
> link bandwidth available.  So I could see providing TIAS _and_ AS or
CT.

Your point on "AS" is just your assumption and it is not defined that
way in RFC3550/3890. Following is the description of "AS" from 3890.

Sec 1.1.2, RFC 3890
"Application Specific Maximum: The Application Specific maximum
bandwidth is
indicated by the modifier "AS". The session bandwidth includes the
bandwidth that the RTP data traffic will consume, including the lower
layers, down to the IP layer. Therefore, the bandwidth is in most cases
calculated over RTP payload, RTP header, UDP, and IP, defined in RFC
2327 [1]."

It is bandwidth at IP level. IMO, "AS" inherently assumes some packet
rate. From the above text in RFC3890 AS is nothing but TIAS + BW for
packet overhead. BW for packet overhead should be assuming some packet
rate. Specifying bandwidth below IP (link bandwidth) may not be
architecturally pure. Usually SDP does not specify anything below IP.

> to link-bandwidth.

It is actually link restriction mapped to media restriction. As far as I
know, link bandwidth (below IP) does not fall in the scope of SDP or
RTCP.
One has to translate the link restriction (below IP) to media
restriction (above IP) and use it in RTCP/SDP. TIAS and maxprate gives
some estimation which is better than nothing. (TIAS,maxprate) is better
than AS. The reason being AS is hiding the max packet rate and actual
media rate.

[The following mostly applies to point to point topology]
(High value of) maxprate may result in bandwidth overallocation to some
extent but it is better than nothing. In fact, even if maxprate is
accurate it can still result in overallocation because the sender may
send at much lower media bit rate (than TIAS) while still using the
signaled maxprate. What the sender is actually planning to send at
(media send rate) is not captured in any SDP attribute. In a point to
point session, one has to note that link bandwidth limitation applies to
'send' direction as well and it is not limited to 'receive' direction.
Link bandwidth limitation in 'send' direction is possible for the same
reasons it is possible for link bandwidth limitation in 'receive'
direction (QoS changes forced by the cellular network in 'send'
direction of a stream)

Correct bandwidth needed for a stream:

(Actual max media bit rate + max header overhead bit rate)

Actual max media bit rate <= TIAS

Actual max media bit rate can be signaled in a new SDP attribute
('sendrate'). 

>  The argument being made is that TMMBR should be in
OS
the
from

---

From: "Even, Roni" <[email-masked]>
Date: Tue, 13 Feb 2007 00:06:48 +0200

Magnus,
We are talking about TMMBR which happens after the receiver has already received media and can know what is the payload bit rate.
 
As for fragmentation you should know that knowing the path MTU do not make each sender break a frame to the same sizes. Example MTU=500 frame = 800. can be broken to 400 and 400 or 300, 300 and 200 based on policy for breaking on macro block or GOB boundary or any other algorithm as long as smaller than MTU.

Repacketization in a middlebox can happen between two networks with different MTUs and the middle box cannot reduce the rate (it does not transcode). RTCP may flow end to end (this is a viable topology in the topolgy draft).

Roni

מאת: Magnus Westerlund [mailto:[email-masked]]
נשלח: ב 12/02/2007 23:38
אל: Stephan Wenger
עותק לידיעה: Even, Roni; Randell Jesup; [email-masked]
נושא: Re: [AVT] CCM draft review -- should "bandwidth" include the headeroverhead

TMMBR report:
a) Media Bit-rate

Cheers

Magnus Westerlund

---

From: Dave Singer <[email-masked]>
Date: Mon, 12 Feb 2007 15:07:32 -0800

On the question of what bitrate to send, it depends on who knows what:

"Please send me a stream that fits through a constriction of x kb/s. And
a) I know that ROHC is in use through that constriction;
b) I know it is not;
c) I don't know;  if you do, then you can do the partitioning;
d) I don't know, and if you don't either, assume the worst (i.e. that 
it is not)."

My suspicion is that we have to signal (c, d), and that (d) is the 
most likely outcome.  That is, we include headers unless the sender 
knows to the contrary.

On the question of "what is bitrate", I'd suggest that we say that 
the source was traffic-smoothed to not exceed x.  By that I mean, if 
I send a packet of Y kbits, then the next packet is sent no earlier 
than Y/x seconds later.  Alternatively, the bitrate is the max over 
all consecutive pairs of packets [i,i+1] of
(timestamp(i+1) - timestamp(i))/size(i)

which is harsh, but otherwise we'll have to define a leaky bucket 
model, or an averaging interval.  Both of these either require 
signalling the size of the ingest buffer to the constriction, or 
assuming it, neither of which are pleasant.
-- 
David Singer
Apple Computer/QuickTime

---

From: Randell Jesup <[email-masked]>
Date: Mon, 12 Feb 2007 18:44:35 -0500

"Even, Roni" <[email-masked]> writes:
>I think you have to know ow to convert from b= to the codec rate anyhow,
>otherwise how can you know how much to allow the encoder to use in term of
>bit rate.  On the receiver side, the way I see it is that once you
>establish the connection and want to use TMMBR you already know the codec
>rate you receive, if you decode so you can reduce the rate based on this
>information.  Roni

a) At the sender side, the codec and the RTP could interact on a
   packet-by-packet (second-by-second, etc) basis to adjust bitrate
   (i.e. the RTP layer knows what overhead exists (at the sending end), and
   RTP header extensions added (for example by ZRTP), etc).  The codec does
   not have to be given a fixed bitrate to encode at.  Most devices are set
   up that way currently, but they don't need to be.

b) The receiver does not know (and in many cases cannot know) the sender's
   bitrate.  At most you know the rate you suggested to the sender.  Many
   codec/rate-controller implementations use "bitrate" settings as a
   maximum, so a receiver can't monitor the incoming rate to get anything
   useful.  Similarly, the packet rate could vary by 2x or more easily.

c) Only the sender needs to convert link bandwidth to codec bandwidth.
   This makes sense, since only the sender knows if he'll be including (for
   example) header extensions, and if so how often.  You don't want to have
   the receiver have to assume worst-case use of header extensions, you
   want the sender to account for actual use by adjusting codec bandwidth.
   For example, if an extension in use could use 50 bytes per packet, the
   receiver may have to use "link - (normal_overhead+50)*maxprate", while
   the sender can use (if it wants to)
   "link - ((actual_overhead)*actual_prate + actual_hdrext_use)" 

   The sender needs to know how to calculate codec BW anyways, if the
   sender accepts b=AS or b=CT.

I'm not saying b=AS/etc is perfect.  I am saying that for link bandwidth
signalling and adaption it's better than codec bandwidth (TIAS), and much
better than having TMMBR *always* use TIAS values (even if not signaled).

Perhaps in addition to being conference/interop focused, your usages also
leave a lot of headroom, and so a little wasted bandwidth isn't a big deal.
For lower-bandwidth devices trying to squeeze every bit out of a tight link
(home users, 3GPP, etc), link efficiency is much more important than ease
of codec control or ease of calculations for codec BW.

IMHO.

---

From: "Even, Roni" <[email-masked]>
Date: Tue, 13 Feb 2007 09:00:39 +0200

Hi,
I think that looking at it from the perspective of the link is not the right direction.
The first question to ask is why does the receiver wants to send a TMMBR which is a temporary change. I gave a couple of examples in previous emails. (speed between IP and circuit switch, dividing the bit rate between two video streams, processing issues on codec)
Once you know why the receiver wants to do it than you can try to analyze what the receiver knows at that stage in order to ask the correct speed.
My point that in most cases when the receiver wants to reduce the speed it has to do with the coder on the receiver side which knows the media bit rate and not the link overhead.
Congestion is a case but it does not require an exact number but rather takes some percentage bellow the current speed.
 
Roni

מאת: Dave Singer [mailto:[email-masked]]
נשלח: ג 13/02/2007 01:07
אל: [email-masked]
נושא: RE: [AVT] CCM draft review -- should "bandwidth" include theheaderoverhead

---

From: Randell Jesup <[email-masked]>
Date: Tue, 13 Feb 2007 07:18:59 -0500

"Even, Roni" <[email-masked]> writes:
>I think that looking at it from the perspective of the link is not the
>right direction.  The first question to ask is why does the receiver wants
>to send a TMMBR which is a temporary change. I gave a couple of examples
>in previous emails. (speed between IP and circuit switch, dividing the bit
>rate between two video streams, processing issues on codec) Once you know
>why the receiver wants to do it than you can try to analyze what the
>receiver knows at that stage in order to ask the correct speed.  My point
>that in most cases when the receiver wants to reduce the speed it has to
>do with the coder on the receiver side which knows the media bit rate and
>not the link overhead.

Aha.  This explains some of the disconnect occuring here.  Those are uses
that haven't even crossed my mind for TMMBR.

I (and I assume the 3G people, and David Singer and Magnus I think) are
looking to TMMBR for link status changes, while you are looking to it for a
very different (more codec-oriented) purpose.

>Congestion is a case but it does not require an
>exact number but rather takes some percentage bellow the current speed.

Yes, probably, though you can easily do that with TMMBR.

---

From: "Desineni, Harikishan" <[email-masked]>
Date: Tue, 13 Feb 2007 09:37:49 -0800

> >in previous emails. (speed between IP and circuit switch, dividing
the
> bit
> looking to TMMBR for link status changes, while you are looking to it
for
> a

If TMMBR is not codec oriented then it should not be treated as a codec
control message and it has to be taken out from "codec control messages"
draft.

---

From: "Desineni, Harikishan" <[email-masked]>
Date: Tue, 13 Feb 2007 10:19:59 -0800

> From: Dave Singer [mailto:[email-masked]]
> Sent: Monday, February 12, 2007 3:08 PM
> To: [email-masked]
> Subject: RE: [AVT] CCM draft review -- should "bandwidth" include
> theheaderoverhead
> 

With option d), it is possible for the sender to signal what its worst
assumption is. I.e., Sender can tell details like what (max/avg) bitrate
it will send at. In theory, packet overhead is out of sender's control
as RTP header extensions can be added by RTP nodes in the middle.
Whatever the sender/receiver does w.r.to packet overhead is just a worst
case guess over end to end path. One thing that will at least remain
valid (assumption free) end to end is the (max/avg) media bit-rate of
the sender.

I have a draft which captures the SDP bandwidth attribute that can be
used to signal a sender's max media bitrate in offer/answer model. Until
it appears on the IETF server, it can be accessed from
http://people.qualcomm.com/hdesinen/draft-hdesinen-mmusic-oa-send-bw-att
r-00.txt

---

From: "Desineni, Harikishan" <[email-masked]>
Date: Tue, 13 Feb 2007 12:22:00 -0800

Codec control message should be independent of transport. Roni's view
makes it a true codec control message. (Re)Using it for signaling
transport/link status/bandwidth changes will make it less obvious for
codec control usage.

A message that captures transport/link status/bitrate changes alone does
not well qualify for being a true codec control message. If there is a
use case for such a message, it is better to define it as a separate
RTCP report message (not call it a codec control message) and solve the
header overhead problem with the help of the new message (and any
additional signaling). Let's keep things simple by not introducing
transport specific issues in TMMBR.

> From: Desineni, Harikishan [mailto:[email-masked]]
> Sent: Tuesday, February 13, 2007 9:38 AM
> To: Randell Jesup; Even, Roni
> Cc: Dave Singer; [email-masked]
> Subject: RE: [AVT] CCM draft review -- should
> "bandwidth"includetheheaderoverhead
> 
> 
> 
> > >right direction.  The first question to ask is why does the
receiver
> > wants
> > >rate between two video streams, processing issues on codec) Once
you
> know
> > >that in most cases when the receiver wants to reduce the speed it
has
> to
> > >do with the coder on the receiver side which knows the media bit
rate

---

From: "Desineni, Harikishan" <[email-masked]>
Date: Tue, 13 Feb 2007 12:42:01 -0800

Few more points after carefully reading the draft version-03

* Section 4.3 captures "Payload Specific Feedback Messages". IMHO, these
are the true codec control messages which are independent of transport
and can be directly signaled to a codec.

Payload specific feedback messages from Sec 4.3:
     0:     unassigned
     1:     Picture Loss Indication (PLI)
     2:     Slice Lost Indication (SLI)
     3:     Reference Picture Selection Indication (RPSI)
     4:     Full Intra Request Command (FIR)
     5:     Temporal-Spatial Trade-off Request (TSTR)
     6:     Temporal-Spatial Trade-off Announcement (TSTA)
     7:     Video Back Channel Message (VBCM)
     8-14:  unassigned

* Section 4.2 captures "Transport Layer Feedback Messages". TMMBR and
TMMBN are listed here along with Generic NACK. These are transport
specific feedback messages and do not purely fall in codec control
category. Ideally, transport specific messages do not qualify for being
codec control messages and hence TMMBR/TMMBN should be taken out from
this ("codec control messages") draft. If TMMBR is needed for pure codec
media control then it has to be in "payload specific" section (4.3).

Transport layer feedback messages from Sec 4.2:
      0:    unassigned
      1:    Generic NACK (as per AVPF)
      2:    Temporary Maximum Media Bit-rate Request
      3:    Temporary Maximum Media Bit-rate Notification

Thanks,
Hari

> From: Desineni, Harikishan
> Sent: Tuesday, February 13, 2007 12:22 PM
> To: Desineni, Harikishan; Randell Jesup; Even, Roni
use
> case for such a message, it is better to define it as a separate RTCP
> report message (not call it a codec control message) and solve the
header
> overhead problem with the help of the new message (and any additional
> signaling). Let's keep things simple by not introducing transport
specific
> issues in TMMBR.
> > > >I think that looking at it from the perspective of the link is
not
receiver
you
> > > >receiver knows at that stage in order to ask the correct speed.
My
> > point
has
rate
> > and
> > > >not the link overhead.
> > >
> > > Aha.  This explains some of the disconnect occuring here.  Those
are
> > uses
> > > I (and I assume the 3G people, and David Singer and Magnus I
think)
> > are

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 13 Feb 2007 22:42:50 +0100

Even, Roni skrev:
> 
> Magnus,
> We are talking about TMMBR which happens after the receiver has already 
> received media and can know what is the payload bit rate.

I see this as being problematic for several reasons. The first one is 
that the sender may not at all send at rates close to the TMMBR rate you 
request. For example due to congestion. Remember that TMMBR is not for 
real congestion control. Thus the receiver has no data on which 
combination of packet rates and packetization it will use for any 
maximum packet rate. Thus the actual bit-rate consumed may be 
significantly different from what the receiver requested. Also this 
implies that the sender are restricted in there of change packet rate 
and packetization parameters. To me this seems to yield much larger 
discrepancies than your actual gross rate and seen overhead.

>  
> As for fragmentation you should know that knowing the path MTU do not 
> make each sender break a frame to the same sizes. Example MTU=500 frame 
> = 800. can be broken to 400 and 400 or 300, 300 and 200 based on policy 
> for breaking on macro block or GOB boundary or any other algorithm as 
> long as smaller than MTU.

No, this is another argument why the sender should know gross bit-rate 
and can take into account what changing the packetization will result 
in. Using a media bit-rate will not provide any restrictions at all on 
the fragmentation, while gross-bitrate will have impact on how you break 
up packets.

>  
>  
> Repacketization in a middlebox can happen between two networks with 
> different MTUs and the middle box cannot reduce the rate (it does not 
> transcode). RTCP may flow end to end (this is a viable topology in the 
> topolgy draft).
>  
>  

And as the new version of topologies and CCM drafts will be clearer on 
is that a mixer or translator doing this will need to rewrite the RTCP 
messages to provide the correct image over the box. Thus this is not an 
argument against using a gross bit-rate and that media bit-rate is better.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 13 Feb 2007 23:02:41 +0100

Hi,

Dave Singer skrev:
> d) I don't know, and if you don't either, assume the worst (i.e. that it 
> is not)."
> 
> My suspicion is that we have to signal (c, d), and that (d) is the most 
> likely outcome.  That is, we include headers unless the sender knows to 
> the contrary.

Yes, I also think so. Do also notice that there is a requirement to 
combine TMMBR with congestion control. That way the sender will be 
anyway react in the cases where the real overhead in a bottleneck is 
larger than the overhead seen by a receiver.

> 
> 
> On the question of "what is bitrate", I'd suggest that we say that the 
> source was traffic-smoothed to not exceed x.  By that I mean, if I send 
> a packet of Y kbits, then the next packet is sent no earlier than Y/x 
> seconds later.  Alternatively, the bitrate is the max over all 
> consecutive pairs of packets [i,i+1] of
> which is harsh, but otherwise we'll have to define a leaky bucket model, 
> or an averaging interval.  Both of these either require signalling the 
> size of the ingest buffer to the constriction, or assuming it, neither 
> of which are pleasant.

As I see it the traffic smoothing case is the correct one. There are 
some buffering in the network that will help with this. The issue is 
that one don't know how much, thus one has to be careful. If one defines 
a token bucket then one needs to find a level of buffering that is 
available. I don't see how that will be possible.

Cheers

Magnus Westerlund

---

From: "Franceschini Guido" <[email-masked]>
Date: Fri, 16 Feb 2007 18:34:24 +0100

I think that the semantic we are looking for is best represented by Randell's mail, i.e. a transport/link status/bitrate change. Hari is thus right in stating that this is not exactly a Codec Control Message.

But apart from the nomenclature, I have seen so far discussion looping around a couple of concepts:
- at what level should we measure the bandwidth?
- do we have to indicate something in addition to the bandwidth (packet rate, average overhead)?

None of the existing bandwidth metrics (CT, AS, TIAS) fits well with the problem of describing how to saturate (or avoid congesting) the path capacity.
IMHO this problem, raised in the context of TMMBR, i.e. in the context of providing updates, applies equally well in the SETUP phase. Again, none of the existing tools has been designed to describe how to saturate (or avoid congesting) the path capacity.

I have just written a draft that addresses the above requirement (available at: http://www.ietf.org/internet-drafts/draft-franceschini-avt-bwmetrics-00.txt), and I already mentioned in a past mail the essential conclusion of my analysis, i.e.:
- signaling from RX to TX a tuple made of
-- a bandwidth parameter (TIDC), that represents the bandwidth available in the downlink at a certain protocol stack layer X;
-- an overhead parameter (MPO), that measures the average overhead of a packet in the downlink at that same layer X.

In the draft I show that the maximum accuracy in the downlink characterization is obtained when the layer X is selected as the point where the packet oriented protocol stack portion (e.g. RTP, UDP, IP, PPP, ETH...) interfaces the byte-oriented protocol stack portion (e.g. LAPM or various other link layers).
For such a choice, the packet rate is irrilevant.
If instead a different 'layer X' is considered, the packet rate impacts on the accuracy of characterization. 

In the discussion seen on this thread, the two major candidates considered as layer X have been IP and Application (codec bitrate). The model I propose could accomodate both, but as I said, the packetrate shall also be known to provide an accurate characterization when we select a reference layer other than the ideal one.

I think the packetrate is not a precise parameter, and in general cannot be known by the receiver -just approximatively guessed-, and anyway, if the receiver assumes a specific packetrate, it should better signal this as well.

I am in favor of defining a mechanism that allows for accurate characterization of a link capacity, and to depart from the maximum accuracy not by design, but because of reasonable implementation impediments. Therefore, my proposal for a layer X at which to measure bandwidth and overhead, that does not necessarily corresponds to Application (codec bitrate) or IP layers, and that could avoid the uncertainty due to a badly guessed packetrate.

Also, I have read in this e-mail thread that it is not practical to determine whether ROHC is applied or not on the local link. Maybe this is true, today, but I disagree with what has been derived from this statement. The availability of this information to the application is indeed a terminal implementation issue: the terminal _has_ this info, it's just a matter for the application to gather this info from the O.S.
I would therefore disagree with the principle that we should not consider the presence of ROHC _by design_, simply because it is felt that today's devices do not expose this information to applications.
Of course, as far as presence of ROHC cannot be granted, a terminal should assume that no header compression is achieved. But if it knows more, why not exploiting this knowledge to more accurately characterize the link capacity?

Furthermore, an issue that has had no attention in this thread but that I feel relevant for this context, is that of cross-media relations. By this I mean:
- the jitter induced in the audio stream by the presence of big video packets on the same physical link (in case an entire packet is serialized without interleaving of audio data)
- the bandwidth eroded to the video stream by the packetization overhead of the audio stream

Apparently, no mechanism has been defined so far to allow a transmitter terminal to determine how to organize the audio and video traffic and partition the available bandwidth between the two. When the goal is to saturate a path capacity, these problems shall be addressed.
My draft describes a possible approach to this problem, with a detailed real-life example and figures.
The cons of my approach is that the bandwidth parameter (TIDC) in this context has session-level meaning, thus updates (through TMMBR or whatever RTCP feedback message) should convey session-level, and not just media-level parameters. This is certainly not a big hurdle from a syntax point of view, but maybe there are architectural CONS that I haven't seen.

Best regards
Guido Franceschini 
Telecom Italia - Technology 
Innovation & Engineering Services - Service Creation & Application 
Multimedia Technology Innovation 
Via G. Reiss Romoli, 274 
10148 Torino - ITALY 
Phone +39 011 2286137 
Fax     +39 011 2287185 
[email-masked] <mailto:[email-masked]>  

> Sent: martedì 13 febbraio 2007 21.22
> Subject: RE: [AVT] CCM draft review --
> should"bandwidth"includetheheaderoverhead
> 
> 
> 
> > > >I think that looking at it from the perspective of the 
> link is not
> > the
> > > >receiver knows at that stage in order to ask the correct 
> speed.  My
> > point
> > > Aha.  This explains some of the disconnect occuring here. 
>  Those are
> > uses
> > > I (and I assume the 3G people, and David Singer and 
> Magnus I think)
> > are
--------------------------------------------------------------------

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: Magnus Westerlund <[email-masked]>
Date: Mon, 19 Feb 2007 17:45:04 +0100

Hi,

Guido, I think your draft is very interesting when it comes to work on 
updating RFC 3890 and the TIAS concept to something that works. However 
for the moment I would like to focus on solving the issue around CCM. 
Thus I will below remind you all of the purpose of TMMBR, the topologies 
and their impact and then discuss the alternatives that has been raised. 
  Looking at the advantages and disadvantages.

TMMBR as currently written in CCM has the following usages:

1. A mixer requests a media sender to reduce its bit-rate to have the 
mixer avoid doing transcoding for some or all session participants.

2. Put an upper limit for the congestion control to probe when known 
path limitations exist. Such signals that a receiver could know is 
changes in the link layer, for example a wireless that effect the 
maximum bit-rate the link will be able to transfer.

For the first case the topology one discuss to use TMMBR in is the 
following:

    +---+      +------------+      +---+
    | A |<---->|            |<---->| B |
    +---+      |            |      +---+
               |   Mixer    |
    +---+      |            |      +---+
    | C |<---->|            |<---->| D |
    +---+      +------------+      +---+

A. Mixer sending TMMBR

In this case the mixer may request that A reduces it transmission 
bit-rate, due to a limitation on any of the paths to B-D. The bit-rate 
has been learned by the mixer as a result of congestion control between 
a itself and the receiver, or from a TMMBR message from receiver.

For the second usage this occurs in the following topologies.

    +---+         +---+
    | A |<------->| B |
    +---+         +---+

B. Point to Point where receiver send TMMBR directly

               +-----+
    +---+     /       \    +---+
    | A |----/         \---| B |
    +---+   /   Multi-  \  +---+
           +    Cast     +
    +---+   \  Network  /  +---+
    | C |----\         /---| D |
    +---+     \       /    +---+
               +-----+
C. Point to Multipoint using Multicast where any receiver may send TMMBR 
to any sender.

In these case the receiver sending the TMMBR knows a limitation on the 
path between the sender and itself.

So what method of reporting the known bit-rate is the best. Lets start 
looking at the comparison when all links have homogeneous overhead, i.e. 
there are no transparent translators, like NATs present within the 
topologies.

The two main ways of reporting the available bit-rate restriction that 
has been proposed are:

X. IP layer Gross Bit-rate, i.e. all bit-rate consumed by all the 
packets from the IP header and above.

Y. Media layer bit-rate, i.e. the bit-rate that may be consumed by the 
media encoding only. Thus excluding any bit-rate consumed by the headers 
used to packetize the media, e.g. IP, UDP, RTP, RTP Payload headers.

Considering these two proposals in regards to the usages above.

For usage A the mixer can easily provide a IP-gross bit-rate from its 
congestion control. If the mixer would have to provide a media bit-rate 
  to the sender then the following uncertainties creep in.

R1. The IP layer congestion control does not equal the media bit-rate, 
thus requiring the mixer to continuously measure the media bit-rate vs 
IP layer bit-rate to determine how much the media bit-rate should be 
reduced.

R2. In cases a reduced media bit-rate results in a change of the 
packetization scheme from the sender the resulting IP bit-rate will not 
change. Thus reducing the possibility to maximize the utilization as a 
certain marginal would be needed.

R3. Any changes in the packetization scheme as a result of other reasons 
than available bit-rate may result in the need to send a new TMMBR 
message to have the sender adjust its total bit-rate due to the changed 
overhead. Thus increasing the signalling churn needed.

Looking at usage B, it is highly dependent on the type of bit-rate 
restriction. For cases when the restriction is easy to measure in IP 
layer bit-rate then that is advantageous. In cases when a packet rate 
would be need to derive either the IP layer or media bit-rate available 
then they are from complexity point of view similar. Assuming that one 
has measured the packet rate prior to needing to send the TMMBR request 
one can use that rate to estimate the amount of overhead also introduced 
in the future. Thus resulting in the same error situations raised in R2 
and R3. This error is dependent on two factors, the error in the packet 
rate estimation and the amount of per packet overhead need to reach a 
value for the reported layer. So in case one knows the link layer 
bit-rate available, the IP layer error is only the overhead of the 
link-layer headers, while a media bit-rate may be link-layer, IP, UDP 
and RTP overhead multiplied by the error in estimating the packet rate.

Usage C, is no different from B.

One advantage of the media bit-rate is when it interfaces through 
gateways to other technologies that are based on circuit switched 
technologies and uses media bit-rate, such as H.323.

So far the sender has used the assumption that the overhead per packet 
the receiver sees equals what the sender see, i.e. the protocol stacks 
are identical for both sender and receiver. This is the reasonable 
assumption unless information is provide on the contrary.

Lets introduce a transparent translator, for example NAPT that changes 
the IP version from 4 to 6 and vice versa when packets flow through it. 
This change of per packet overhead results only in a different value for 
the overhead to be used in calculation to estimate what media rate can 
be supported. Thus the size of error can be effected by this. For a IP 
layer bit-rate value this results in bit-rate flowing through the 
restriction may be larger than the requested maximum value in cases the 
overhead at the restriction is larger than at the sender. In these case 
the restricting entity would end up being the congestion control and 
TMMBR looses its meaning. In cases where the overhead is reduced this 
results in a under-utilization. Similar cases occurs in the media 
bit-rate solution when the packet-rate estimate is off and the resulting 
transmission bit-rate results in congestion or under-utilization. 
Independent of what the value represents the receiver can updated its 
TMMBR value, however it would be to late and simply be a correction 
after the issue has arisen.

If one would be to refine the IP layer bit-rate value with an overhead 
measurement. I would propose the simple filtration of keeping 15/16 of 
the old value and add 1/16 of the last packets value for each packet 
received. That way a sender can compare the overhead seen by the 
receiver with what it is sending. By the filtering on both sides this 
should provide a rather stable number to determining any differences in 
overhead. By doing this the sender can take the per packet overhead 
directly into account when transmitting media avoiding overshooting the 
TMMBR bit-rate value. It even lets a receiver take header compression 
into account if the restriction and header compression is happening over 
the same link.

As I see it a IP layer bit-rate value with a filtered value for the per 
packet overhead, IP up to and including the RTP packet header has the 
least downsides. It reports the actual restriction bit-rate value for 
the common networking layer. It allows the sender to directly take the 
effect on packetization on the total bit-rate into account. It also 
avoids running the bit-rate value as a relative value that are adjusted 
based on measurements on the arriving packets.

Comments

Magnus Westerlund

---

From: "Franceschini Guido" <[email-masked]>
Date: Tue, 20 Feb 2007 12:04:16 +0100

Dear Magnus, all,

IMHO all the issues being described so far can be reduced to the problem of making the sender aware of the bottlenecks it shall respect. Thus, if we identify a suitable characterization of the bottleneck(s), then we are done (in terms of signalling).
Depending on the different cases, as you show, bottlenecks can be more effectively characterized by the media bitrate, or by the IP gross bitrate. Plus possibly additional params such as average overhead and/or packet rate.

Then the problem I see you are debating is: which choice is better? or, which choice has the least downsides? This derives from the assumption (which has become a constraint) that either one or the other metric should be used. I think this can be relaxed.

If we define metrics that are generic and neutral, and that can represent either the media bitrate or the IP gross rate or even the bandwidth as measured at some other layer, than what would be the cons?

To be more practical, I try to review your Mixer scenario, and to show how my proposal would adapt to it.
My proposal, in essence, consists in always providing a tuple made of <available bandwidth measured at layer X, average per packet overhead measured at the same layer X>, and having the sender collect all the information about bottlenecks so as to determine how to generate traffic that fits all constraints.

Scenario A, the mixer

Suppose the mixer received information about the bottleneck towards receiver D (BottD = <TIDC_D, MPO_D>): it could simply propagate that same bottleneck info to the A, B and C senders. Then the traffic generated by each of them would comply with the constraints in the path to D, although A, B and C might have chosen different encoding and transmission parameters.

With numbers:
BottD = <21000, 40>
A chooses to generate AMR at 4750, with 20 ms per packet (50 pkt/sec)
==> with respect to D metrics A generates 50*40*8=16000 bit/s of overhead + 4750 of payload (total of 20750 < 21000)

B chooses to generate AMR at 12200, with 40 ms per packet (25 pkt/sec)
==> with respect to D metrics B generates 25*40*8=8000 bit/s of overhead + 12200 of payload (total of 20200 < 21000)

C chooses ....

Suppose than that receiver C as well has a bottleneck, but has a different stack (e.g. a VPN that duplicates the IP layer)

Then C could notify such bottleneck BottC to the Mixer, and this could be again propagated to the A, B and D senders.

With numbers:
BottD = <21000, 40>
BottC = <25000, 60>
If the same choices as before were kept:
A would generate AMR at 4750, with 20 ms per packet (50 pkt/sec)
==> with respect to D metrics A generates 50*40*8=16000 bit/s of overhead + 4750 of payload (total of 20750 < 21000)
==> with respect to C metrics A generates 50*60*8=24000 bit/s of overhead + 4750 of payload (total of 28750 > 25000) NOT OK

B would generate AMR at 12200, with 40 ms per packet (25 pkt/sec)
==> with respect to D metrics B generates 25*40*8=8000 bit/s of overhead + 12200 of payload (total of 20200 < 21000)
==> with respect to C metrics B generates 25*60*8=12000 bit/s of overhead + 12200 of payload (total of 24200 < 25000) STILL OK

By means of collecting the bottleneck info, in such a case the sender A will decide to change its encoding/transmitter parameters, while sender B would take no action.

Now suppose receiver A has a bottleneck too, but its stack is of a yet different nature, since it resides in a H323 branch. Here the media bitrate is more meaningful than any other measurement, thus it would communicate its bottleneck characterization providing the media codec layer measurements:
BottA = <8000,0>

I.e., it tells the Mixer that it can receive up to 8000 bit/sec of audio, irrespective of the packetization scheme in use (the overhead is 0 at this layer).
The Mixer would once again propagate this information to the B, C and D sender which in turn will determine their encoding and transmission parameters matching all bottleneck constraints. Etc, etc etc.

Now also receiver B communicates a bottleneck. B is behind a NAPT that maps IPV4 to IPV6, i.e. B runs an IPV6 stack.
Once again, B will communicate its BottB tuple, which will contain yet another overhead figure. And the Mixer will propagate the BottB information to senders A, C and D, which in turn will determine their encoding and transmission parameters matching all bottleneck constraints. Etc, etc etc.

Comments?

Guido

-----Messaggio originale-----
Da: Magnus Westerlund [mailto:[email-masked]] 
Inviato: lunedì 19 febbraio 2007 17.45
A: Franceschini Guido
Cc: Desineni, Harikishan; Randell Jesup; Even, Roni; [email-masked]
Oggetto: Re: [AVT] CCM draft review -- should"bandwidth"includetheheaderoverhead

Hi,

A. Mixer sending TMMBR

    +---+         +---+
    | A |<------->| B |
    +---+         +---+

               +-----+
    +---+     /       \    +---+
    | A |----/         \---| B |
    +---+   /   Multi-  \  +---+
           +    Cast     +
    +---+   \  Network  /  +---+
    | C |----\         /---| D |
    +---+     \       /    +---+
               +-----+

Comments

Magnus Westerlund

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 20 Feb 2007 16:53:16 +0100

> Then the problem I see you are debating is: which choice is better? or, which choice has the least downsides? This derives from the assumption (which has become a constraint) that either one or the…

Yes, I would like us (the WG) to determine which choice is the best, or 
at least has the least downsides. And yes, I would like to have one 
defined format to avoid combinatorial explosion within the 
implementations if one would allow to measure things at various layers 
and then have the receiver of the request work things out.

I would also like to come to a conclusion on this prior to the IETF 
meeting, preferably before the draft cut-off date in two weeks time.

> My proposal, in essence, consists in always providing a tuple made of <available bandwidth measured at layer X, average per packet overhead measured at the same layer X>, and having the sender coll…

I think you are unclear about how one define overhead in your proposal. 
 From what layer to what layer are considered overhead. Looking at the 
below example your overhead seem to be from the lowest IP layer up to 
the RTP payload.

> Once again, B will communicate its BottB tuple, which will contain yet another overhead figure. And the Mixer will propagate the BottB information to senders A, C and D, which in turn will determin…

Assuming I interpret this correct, you would support a TMMBR proposal 
that encodes the following information:

1. The maximum bit-rate as seen on lowest common networking layer. In 
the case of IP, the maximum bit-rate available at the lowest visible IP 
layer, i.e. excluding link layer headers.

2. The average measurement of the number of bytes present in each packet 
from the start of the first IP header until the start of the RTP 
payload. Which represents the header overhead in bytes for each packet 
from the lowest visible IP header to the RTP payload. This value is 
measured for each received packet and the value reported is filtered by 
for each packet doing the following calculation:
avg_packet_overhead = 15/16*avg_packet_overhead + 1/16 * packet_overhead

As Guido present above there is an issue with using a tuple. Only 
allowing a mixer to forward a single tuple for TMMBR can result in that 
some combinations will not be okay depending on the packet rate 
selected. Thus there may be need to include multiple tuple to correctly 
restrict the space of possible combinations. I need to think more about 
what the relations are between selecting a packet rate and provided 
values of bit-rate and overhead.

Cheers

Magnus Westerlund

---

From: "Franceschini Guido" <[email-masked]>
Date: Tue, 20 Feb 2007 18:39:22 +0100

Dear Magnus, all,

some more comment inline.

Best regards
Guido

<snip>
 
> > To be more practical, I try to review your Mixer scenario, 
> and to show how my proposal would adapt to it.
> > My proposal, in essence, consists in always providing a 
> tuple made of <available bandwidth measured at layer X, 
> average per packet overhead measured at the same layer X>, 
> and having the sender collect all the information about 
> bottlenecks so as to determine how to generate traffic that 
> fits all constraints.
> 

You are correct in saying that in my analysis of the Mixer scenario I was not fully precise.
Indeed, I computed the overhead exactly as you described (from the lowest IP up to RTP included): I did so to avoid adding too many details in the analisys. My calculation was therefore non perfectly accurate, depending on the stack protocol below the IP layer. Actually, my intention was mostly to show the concept that a sender should collect all bottlenecks information, and that the metrics I propose are compatible with a variety of different stacks. Which is the key advantage over picking up the media-bitrate or the IP-gross rate. I tried to provide a convincing example that 4 different protocol stacks can be managed uniformely by means of tuples that -although each potentially referring to a different layer X- are neutral in practice, something that cannot be achieved if either the media-bitrate or the IP-gross rate is signaled.

> 
> > 
> > 
> > Scenario A, the mixer
> > 
> > Suppose the mixer received information about the bottleneck 
> towards receiver D (BottD = <TIDC_D, MPO_D>): it could simply 
> propagate that same bottleneck info to the A, B and C 
> senders. Then the traffic generated by each of them would 
> comply with the constraints in the path to D, although A, B 
> and C might have chosen different encoding and transmission 
> parameters.
> > 
> > With numbers:
> > BottD = <21000, 40>
> > ==> with respect to D metrics A generates 50*40*8=16000 
> bit/s of overhead + 4750 of payload (total of 20750 < 21000)
> > 
> > ==> with respect to D metrics B generates 25*40*8=8000 
> bit/s of overhead + 12200 of payload (total of 20200 < 21000)
> > 
> > C chooses ....
> > 
> > Suppose than that receiver C as well has a bottleneck, but 
> has a different stack (e.g. a VPN that duplicates the IP layer)
> > 
> > Then C could notify such bottleneck BottC to the Mixer, and 
> this could be again propagated to the A, B and D senders.
> > 
> > With numbers:
> > BottD = <21000, 40>
> > BottC = <25000, 60>
> > ==> with respect to D metrics A generates 50*40*8=16000 
> bit/s of overhead + 4750 of payload (total of 20750 < 21000)
> > ==> with respect to C metrics A generates 50*60*8=24000 
> bit/s of overhead + 4750 of payload (total of 28750 > 25000) NOT OK
> > 
> > ==> with respect to D metrics B generates 25*40*8=8000 
> bit/s of overhead + 12200 of payload (total of 20200 < 21000)
> > ==> with respect to C metrics B generates 25*60*8=12000 
> bit/s of overhead + 12200 of payload (total of 24200 < 25000) STILL OK
> > 
> > By means of collecting the bottleneck info, in such a case 
> the sender A will decide to change its encoding/transmitter 
> parameters, while sender B would take no action.
> > 
> > Now suppose receiver A has a bottleneck too, but its stack 
> is of a yet different nature, since it resides in a H323 
> branch. Here the media bitrate is more meaningful than any 
> other measurement, thus it would communicate its bottleneck 
> characterization providing the media codec layer measurements:
> > BottA = <8000,0>
> > 
> > I.e., it tells the Mixer that it can receive up to 8000 
> bit/sec of audio, irrespective of the packetization scheme in 
> use (the overhead is 0 at this layer).
> > The Mixer would once again propagate this information to 
> the B, C and D sender which in turn will determine their 
> encoding and transmission parameters matching all bottleneck 
> constraints. Etc, etc etc.
> > 
> > Now also receiver B communicates a bottleneck. B is behind 
> a NAPT that maps IPV4 to IPV6, i.e. B runs an IPV6 stack.
> > Once again, B will communicate its BottB tuple, which will 
> contain yet another overhead figure. And the Mixer will 
> propagate the BottB information to senders A, C and D, which 
> in turn will determine their encoding and transmission 
> parameters matching all bottleneck constraints. Etc, etc etc.
> > 
> > Comments?
> > 
> 

Mmmm, your definition does not really matches my intention.

I try to explain: suppose we have a stack (at a receiver) including RTP/UDP/IP/PPP/LAPM. Suppose the physical gross bandwidth is 40 Kbit/s (in downlink).
The RTP, UDP, IP and PPP layers are packet-oriented, and add a per-packet overhead (12, 8, 20, 8 bytes respectively), whereas the LAPM layer is byte-oriented and adds a per-byte overhead (say a 10% overhead).
If we measure bandwidth and overhead at the point at which the protocol stack portion providing per-packet overhead interfaces with the protocol stack portion providing per-byte overhead, we have a precise characterization.

   TIDC(PPP) = 36 (= 40 - 10%)
   MPOD(PPP) = 48 (= 12(RTP)+8(UDP)+20(IP)+8(PPP))
    
If we measure bandwidth and overhead in other points of the stack, we also need to make a guess about the packet rate. Here are various other possible tuples, for other layers and under the hypothesys of 50 and 25 packets/sec: 
    
   TIDC(IP,50) = 33  (= 36 Kbit/s - 8*8*50 bit/sec)
   MPOD(IP) = 40     (= 12+8+20)
    
   TIDC(UDP,50) = 25 (= 36 Kbit/s - 28*8*50 bit/sec)
   MPOD(UDP) = 20    (= 12+8)
    
   TIDC(RTP,50) = 22 (= 36 Kbit/s - 36*8*50 bit/sec)
   MPOD(RTP) = 12    (= 12)
    
   TIDC(APP,50) = 17 (= 36 Kbit/s - 48*8*50 bit/sec)
   MPOD(APP) = 0 
    
   TIDC(IP,25) = 34  (= 36 Kbit/s - 8*8*25 bit/sec)
   MPOD(IP) = 40 
    
   TIDC(UDP,25) = 30 (= 36 Kbit/s - 28*8*25 bit/sec)
   MPOD(UDP) = 20 
    
   TIDC(RTP,25) = 29 (= 36 Kbit/s - 36*8*25 bit/sec)
   MPOD(RTP) = 12 
    
   TIDC(APP,25) = 26 (= 36 Kbit/s - 48*8*25 bit/sec)
   MPOD(APP) = 0 

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.
Nevertheless, if the receiver communicates the tuple computed at the PPP layer, it does the best job.

Thus, my definition would better be:

1. The maximum bit-rate as seen on lowest packet-oriented layer (said layer X).

2. The average measurement of the number of bytes present in each packet from the start of the first layer X header until the start of the RTP payload, plus the number of bytes present in each packet from the end of the RTP payload to the end of the layer X trailer (if any). Etc etc etc. I am fine with your overhead measurement criteria, that -I understand- is meant to determine the average performance of a possible compression scheme.

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

---

From: "Desineni, Harikishan" <[email-masked]>
Date: Wed, 21 Feb 2007 00:50:01 -0800

> I try to explain: suppose we have a stack (at a receiver) including
> RTP/UDP/IP/PPP/LAPM. Suppose the physical gross bandwidth is 40 Kbit/s
(in
> downlink).
> The RTP, UDP, IP and PPP layers are packet-oriented, and add a
per-packet
> overhead (12, 8, 20, 8 bytes respectively), whereas the LAPM layer is
> byte-oriented and adds a per-byte overhead (say a 10% overhead).
> If we measure bandwidth and overhead at the point at which the
protocol
> stack portion providing per-packet overhead interfaces with the
protocol
> stack portion providing per-byte overhead, we have a precise
> characterization.
> 
> If we measure bandwidth and overhead in other points of the stack, we
also
> need to make a guess about the packet rate. Here are various other
> possible tuples, for other layers and under the hypothesys of 50 and
25
> packets/sec:
> 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.

In my opinion this discussion on "bandwidth" control/usage is nothing
but signaling for RTP stream control (which is more than just codec
control). I would name such messages as SCMs (Stream Control Messages in
RTCP) and clear the confusion that resulted by incorrectly naming them
as "codec" control messages. IMO, SCMs should be captured in a new draft
(like Guido's) and described in a better way. RTCP TMMBR (or a flavor of
it) which includes header overhead should be called a "stream" control
message.

> Nevertheless, if the receiver communicates the tuple computed at the
PPP
> layer, it does the best job.
> 
> from the start of the first layer X header until the start of the RTP
> payload, plus the number of bytes present in each packet from the end
of
> the RTP payload to the end of the layer X trailer (if any). Etc etc
etc. I
> am fine with your overhead measurement criteria, that -I understand-
is
> meant to determine the average performance of a possible compression
> scheme.
>

---

From: Randell Jesup <[email-masked]>
Date: Wed, 21 Feb 2007 12:35:17 -0500

"Desineni, Harikishan" <[email-masked]> writes:
>> TIDC values, and that this effect is huge at the APP level, but reduced
>> at the IP level, for such a stack example.
>

Note that video links might vary wildly in packets per second, due to
a) motion, b) packetization, c) jitter (for example, using codec bitrates
of circa 384K/30FPS on a 1500-byte MTU link - a frame could easily be one
or two packets, causing big swings in rate), d) iframe pacing and/or error
recovery (iframes use a bunch of packets compared to pframes typically), 
etc, etc.  The sender may vary framerate in response to
bitrate/congestion as well.

This is part of why I argue for letting the sender apportion the available
bits (as best as possible), including as much of the packet overhead as
possible.

Averages for header overhead may or may not help, depending on the type of
header overhead.  For example, if a header extension uses 500 bytes once
every 3 seconds (say for security/ZRTP/etc), on a link with nominal 50 pps
of 50 bytes, the "15/16 plus 1/16" will show serious spikes, and make TMMBR
very sensitive to exactly where in the decay of the spike it's sent.  On
the other hand, the sender should know about any header extensions it is
and has sent.

---

From: "Franceschini Guido" <[email-masked]>
Date: Thu, 22 Feb 2007 09:48:35 +0100

Hari, Magnus,

> 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

        Thank you

                                        www.telecomitalia.it

---

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

> bits (as best as possible), including as much of the packet overhead as

Harikishan, are your point that it is hard for the media sender to 
correctly take the overhead into account when transmitting video? In 
most cases it shouldn't be. The rate-control simply need to be told the 
TMMBR tuple, thus taking the overhead applicable per packet and the 
bit-rate and use that in its control loop. For any non-real-time streams 
sent in a session using TMMBR, would still need to be available in 
multiple rates and then the sender can use a look ahead in the stream to 
determine what actual rate the different versions would use. So I don't 
think there is a problem here.

I would also like to point out that TMMBR needs to work for all media, 
from T.140 chat text at less than 1kbps and beyond uncompressed HDTV 
conferencing at gigabit speed.

I finally understood what Guido was going with his proposal. Allowing 
the TMMBR sender to select which layer it reports on does work in the 
common case. The TMMBR tuple definition for his proposal would then be:

Bit-rate: The maximum available bit-rate at the layer reported on.

Overhead: A measured value between the start of the layer reported on 
and up to the RTP payload's start within the packet.

> the other hand, the sender should know about any header extensions it is

The idea with the filtered measurement was that the media sender can 
compare its local version of this filtering with what it receives in the 
TMMBR request. In a packet loss free environment that would provide a 
perfect measurement in the differences in overhead between what the 
media sender uses and what the TMMBR reporting node sees. When you 
include packet loss you get some noise in the measurement. How much is 
highly dependent on the overhead variations. If you have a distribution 
for the used overhead with a few extreme outlyers then you will get into 
problems if these are dropped. However to my knowledge these type of 
variations of overhead will not be that common and usually not be that 
extreme. Looking at possible reasons in the normal IP and RTP context:

- CSRC list changes
- Header extensions for intermittent sent data
- Header compression (requiring one to measure on layer 2).
- IP extension headers / options

As I see it as long as the overhead measurement is done over a 
reasonable number of packets and for reasonable amounts of packet loss 
this shouldn't be a major problem. If any would like to verify this by 
simulation that would be appreciated.

Cheers

Magnus Westerlund

---

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

> and up to the RTP payload's start within the packet.

OK, but don't forget trailer bytes too

Guido

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

---

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

Bo and me has spent some time thinking about what we see as one of the 
major real problems with using tuples in TMMBR. As one changed TMMBR 
from a one-dimensional problem to a two dimensional problem, the concept 
of a single owner of the restriction took a hike. Thus we end up with a 
need to indicate multiple tuples that are the active restrictions. This 
will create extra complexities. There will also be more data to transmit.

We are working on this, and haven't yet verified and simulated it to 
understand the full implications. However we do like to share this with 
you to provide you the opportunity to think about the same problem and 
possibly find any issues we have forgotten about. Our current proposal 
for how this would work is the following:

Lets start assuming that there is a session with a number of 
participants. They can all have restriction tuples (bit-rate, overhead). 
So if a media receiver has some change he first checks if the new values 
are an actually restriction compared to the current set of restrictions 
in the session. If that is the case it sends a TMMBR message to the 
media sender. The media sender checks the restriction compared to its 
current set and see if that is an actual restriction given its sets 
(remember the asynchronous behavior in a multi-party session) and if 
that allows it to drop some of the previous restriction as being less 
restrictive then the new one. Then it sends out the TMMBN with the 
current set.

So how does on determine which is the current set of restrictions. Me 
and Bo have been kicking around an algorithm that might result in this. 
However we need to spend some time on verification.

1. First sort the set X of restriction tuples according to bit-rate 
creating a vector of tuples, X1 to Xn with the X1 carrying the lowest 
bit-rate and Xn the highest value.

2. Eleminate all tuples in X with a overhead value smaller than the 
value in X1.

3. Repeat step 2 for all elements in X from the lowest to the next highest.

4. A reduced set X has been created.

The above algorithm eliminates all the tuples that doesn't provide a 
restriction because they allow a higher bit-rate and their bit-rate 
grows slower than the previous one when packet-rate increases.

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.

However looking at the above there is evident that one could do more 
here with some additional information. The comparison using packet rates 
that means no useful data is transported is easy to do but doesn't 
restrict as well as is possible. There exist two parameters that could 
be introduced into this to provide restrictions that exist in real 
usage. However these values needs to be the same and known to all 
session participants to be possible to utilize.

The first one would to explicit declare the maximum packet rate the 
application has any usage of at all for this media. For example this 
could be restricted by codec, or by the codec in combination with the 
session maximum bit-rate. This maximum packet rate value would allow one 
to eliminate from the set of restriction all tuples whose bit-rate 
divided by overhead is larger than the session maximum packet-rate.

A second possible restriction would to declare a minimum of useful 
rtp-payload bit-rate. In many cases the media codec or application has 
knowledge about what the smallest bit-rate that would provide any 
utility from the media at all. For example for an audio session using 
the AMR speech codec packetized in RTP (RFC 3267), that bit-rate would 
be 4.75kbps. I ignore the per frame and RTP payload overhead in this 
case, but those could be considered to be included also. This minimal 
overhead could then be subtracted from all the tuples bit-rate values 
prior to running the above presented algorithm. Note that this second 
restriction needs to be applied prior to the first one if both where to 
be present.

What these restrictions provides are some application sanity 
restrictions on what possible combination of useful bit-rate and maximum 
packet rate it can produce and still do some good. However these would 
need to be signaled and could also result in some dispute during session 
establishment if the applications aren't agreeing on a value.

So the big question to you is: Is solving the inaccuracy problem that 
introducing a tuple solves worth the extra complexities and overhead?

Cheers

Magnus Westerlund

---

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

On 23 Feb 2007, at 10:33, Franceschini Guido wrote:
> 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
>

A reminder that the IETF IPR policy [RFC 3978 section 3.2] states:

    No information or document that is subject to any requirement of
    confidentiality or any restriction on its dissemination may be
    submitted as a Contribution or otherwise considered in any part of
    the IETF Standards Process, and there must be no assumption of any
    confidentiality obligation with respect to any Contribution.  Each
    Contributor agrees that any statement in a Contribution, whether
    generated automatically or otherwise, that states or implies that  
the
    Contribution is confidential or subject to any privilege, can be
    disregarded for all purposes, and will be of no force or effect.

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

---

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

Magnus,

let me first check if I have understood your scenario. Then I'll give my view on your mail: just disregard it if I missed to understand the scenario in the first place.

Scanario: a sender S and multiple receivers R1, R2 ... RN

The sender is notified of a number of bottlneck tuples B1, B2 ... BN, each expressed for a potentially different stack.
Based on some internal logic, the sender decides how to encode and packetize its traffic, and also acknowledges with TMMBN to let each receiver aware of the currently valid limits.

If the above is correct, then let's go on.

There is a set of challenges in this scenario:

1) identification of the most restrictive bottleneck among the B1 ... BN 
2) generation of the TMMBN to let receiver know about the current restriction
3) reduction of useless TMMBR traffic
4) accuracy of the Bx data

Concerning 1) identification of the most restrictive bottleneck among the B1 ... BN

The usage of a tuple instead of a single value allows for a more accurate description, but it is easy to derive from an accurate description a less accurate one ;-)
More specifically, if you indicated in the TMMBR the IP gross bitrate, or the media bitrate, you were actually impling some packetrate (actually, the generator of the TMMBR implied a maxpacketrate). You can now apply as well a maxpacketrate, with the advantage that you are now the sender, and can therefore apply a more close-to-reality maxpacketrate.
Suppose you apply a maxpacketrate of 50; you would obtain from:
(35 kbps, 40 bytes) ==> 35000-(40*50*8)=19000
(45 kbps, 50 bytes) ==> 45000-(50*50*8)=25000

Thus, you go back to the same complexity that you have to deal with anyway, with just a better accuracy (the sender applied a uniform and credible maxpacketrate, instead of having each receiver applying his own guess). Also, the sender knows that it must not exceed 50 pkt/sec.

Concerning 2) generation of the TMMBN to let receiver know about the current restriction

Here the goal is to let each receiver aware of the current limits, so that it will generate new TMMBR only if they have an impact on the sender.
It is definitely undesirable that the sender generates a TMMBN listing all tuples that it is currently taking into account.
But if the TMMBN contains a different tuple, made of:
<media bitrate, maxpacketrate>
then each receiver is again able to determine whether it should send a TMMBR or not.
Let's use the figures above:

at time t0:
- receiver R1 sends TMMBR(35 kbps, 40 bytes)
- receiver R2 sends TMMBR(35 kbps, 40 bytes)
==> sender sends TMMBN(19000, 50 pkt/sec, R1)

at time t1:
- R2 changes from (45 kbps, 50 bytes) to (40 kbps, 50 bytes)
==> R2 computes that 19000 + (50*50*8) = 39000, thus does not send TMMBR

at time t2:
- R2 changes to (38 kbps, 50 bytes)
==> R2 sends TMMBR
- Sender computes (38 kbps, 50 bytes) ==> 38000-(50*50*8)=18000
==> sender sends TMMBN(18000, 50 pkt/sec, R2)

Concerning 3) reduction of useless TMMBR traffic

The above algorithm shows how the usage of tuples instead of single values can be managed with the same efficiency

Concerning 4) accuracy of the Bx data

The usage of tuples instead of single values allows, even in such p2mp scenario, to compute more accurate limits.

To conclude: IMHO the usage of tuples have no CONS with respect to picking up a single value, while providing benefits instead.

Cheers
Guido

> Sent: venerdì 23 febbraio 2007 11.38
> To: Magnus Westerlund
> Cc: Franceschini Guido; [email-masked]
> Subject: Issues with using tuples in TMMBR was:Re: R: [AVT] CCM draft
> review -- should"bandwidth"includetheheaderoverhead
> 
> 

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

---

From: "Desineni, Harikishan" <[email-masked]>
Date: Sun, 25 Feb 2007 20:30:17 -0800

Guido, I think you meant

At time t0:
"-receiver R2 sends TMMBR(45 kbps, 50 bytes)" instead of "-receiver R2 sends TMMBR(35 kbps, 40 bytes)" 

Your explanation looks straight forward to me. 

A sender need not maintain a list of tmmbr tuples all the time. Only the active limitation needs to be stored. Whenever a new TMMBR tuple is received, it needs to do just one comparison to determine whether a TMMBN with new limitation is necessary. No complexity involved there.

I see one difference when I compared your example with the example from Magnus. Magnus interpreted the first element in the tuple as pure header overhead. Your example interpreted it as total bit-rate up to particular protocol layer including codec media bit-rate.

If I map your example to a simple p2p session:
SDP offer includes the TMMBR tuple (Max 'receive' rate, 'recv' per packet overhead) and SDP answer includes TMMBN tuple (Max 'send' codec media bit-rate, max 'send' packet rate). Max receive rate in TMMBR tuple includes both codec media rate and header overhead due to protocol layers. 

--Hari

> From: Franceschini Guido [mailto:[email-masked]]
> Sent: Friday, February 23, 2007 5:31 AM
> To: Magnus Westerlund
> Cc: [email-masked]
> Subject: RE: Issues with using tuples in TMMBR was:Re: R: [AVT] CCM
> draftreview -- should"bandwidth"includetheheaderoverhead
> 
> Magnus,
> 
> let me first check if I have understood your scenario. Then I'll give my
> view on your mail: just disregard it if I missed to understand the
> scenario in the first place.
> 
> 
> The sender is notified of a number of bottlneck tuples B1, B2 ... BN, each
> expressed for a potentially different stack.
> Based on some internal logic, the sender decides how to encode and
> packetize its traffic, and also acknowledges with TMMBN to let each
> receiver aware of the currently valid limits.
> 
> The usage of a tuple instead of a single value allows for a more accurate
> description, but it is easy to derive from an accurate description a less
> accurate one ;-)
> More specifically, if you indicated in the TMMBR the IP gross bitrate, or
> the media bitrate, you were actually impling some packetrate (actually,
> the generator of the TMMBR implied a maxpacketrate). You can now apply as
> well a maxpacketrate, with the advantage that you are now the sender, and
> can therefore apply a more close-to-reality maxpacketrate.
> Thus, you go back to the same complexity that you have to deal with anyway,
> with just a better accuracy (the sender applied a uniform and credible
> maxpacketrate, instead of having each receiver applying his own guess).
> Also, the sender knows that it must not exceed 50 pkt/sec.
> 
> 
> Here the goal is to let each receiver aware of the current limits, so that
> it will generate new TMMBR only if they have an impact on the sender.
> It is definitely undesirable that the sender generates a TMMBN listing all
> tuples that it is currently taking into account.
> The usage of tuples instead of single values allows, even in such p2mp
> scenario, to compute more accurate limits.
> 
> 
> To conclude: IMHO the usage of tuples have no CONS with respect to picking
> up a single value, while providing benefits instead.
> 
> Cheers
> Guido
> 
> 
> 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: "Franceschini Guido" <[email-masked]>
Date: Mon, 26 Feb 2007 09:06:59 +0100

> Guido, I think you meant
> 
> At time t0:
> "-receiver R2 sends TMMBR(45 kbps, 50 bytes)" instead of 
> "-receiver R2 sends TMMBR(35 kbps, 40 bytes)" 

Yes, thanks!
> A sender need not maintain a list of tmmbr tuples all the 
> time. Only the active limitation needs to be stored. Whenever 
> a new TMMBR tuple is received, it needs to do just one 
> comparison to determine whether a TMMBN with new limitation 
> is necessary. No complexity involved there.

A downside of your algorithm is that if the current limitation (and only stored limitation in the server) is due to Rn, and Rn now communicates an higher limit, your server does not know to what higher limit to move.
IMO we should not over-specify here: the complex algorithm from Magnus and Bo is one, mine is another, your yet another one ==> it's an implementation matter, that balances complexity and effectiveness.
 
> I see one difference when I compared your example with the 
> example from Magnus. Magnus interpreted the first element in 
> the tuple as pure header overhead. Your example interpreted 
> it as total bit-rate up to particular protocol layer 
> including codec media bit-rate.

The key aspect of my suggestion here, is that each peer communicates accurate data, no guesses.
The accurate data that a receiver can communicate relates to the <TIDC, MPO> tuple (hopefully measured at the most precise layer of its stack); it has no control on the packet rate, thus it should better not imply any.
The accurate data that a sender can communicate relates to <media bitrate, maxpacketrate>, which are both under its control.
This works nicely in p2p as well as in p2mp.
Note that the metrics generated by the sender correspond to the <TIAS, maxprate> tuple already defined in RFC3890 !
 
> SDP offer includes the TMMBR tuple (Max 'receive' rate, 
> 'recv' per packet overhead) and SDP answer includes TMMBN 
> tuple (Max 'send' codec media bit-rate, max 'send' packet 
> rate). Max receive rate in TMMBR tuple includes both codec 
> media rate and header overhead due to protocol layers. 

Exactly (we only need to find good definitions for such semantics, so that we get uniform on this)
Guido

PS: the computation of the RTP Header extension is somehow disputable. Should it be part of the media bitrate figure (TIAS) provided by the sender (it should not, per RFC3890)? Should it be part of the mean packet overhead (MPO) figure provided by the receiver (it should, since it is overhead, but it should not, since it is not under the control of the receiver)?
IMO this is a detail that we could disregard for the time being: maybe the solution could be to identify a bw portion that can be assigned to RTP Header Extension, similarly to RTCP.

> > From: Franceschini Guido 
> [mailto:[email-masked]]
> > Concerning 1) identification of the most restrictive 
> bottleneck among the
> > B1 ... BN
> > 
> > then each receiver is again able to determine whether it 
> should send a
> > TMMBR or not.
> > The above algorithm shows how the usage of tuples instead 
> of single values
> > can be managed with the same efficiency
> > 
> > 

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

---

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

> If the above is correct, then let's go on.

Yes.

> Thus, you go back to the same complexity that you have to deal with anyway, with just a better accuracy (the sender applied a uniform and credible maxpacketrate, instead of having each receiver app…

For a sender to determine which tuple is the currently most restrictive 
one is not a problem. The issue arise if the sender likes to change for 
example the packetization and the packet rate. Without any differences 
in how the receiver would be affected by this, there was no need update 
your TMMBR value as result of a sender change. However with a change of 
packet rate you can actually end up with different tuples being the 
restriction. The maximum packet rate only helps reduce the number of 
possible tuples as it cuts of the outer extremes.

> ==> sender sends TMMBN(18000, 50 pkt/sec, R2)

I think there might be benefits from including a maximum packet rate 
also in the TMMBN. But I need to think a bit more about this. However 
including the max_prate in SDP does to me still seem to be a good 
solution. Otherwise in highly dynamic multi-party session the new 
participants may end up creating unnecessary request traffic due to it 
not knowing any restriction on the maximum packet rate.

> The above algorithm shows how the usage of tuples instead of single values can be managed with the same efficiency

I am not agreeing that one always can restrict oneself to a single 
value. As stated before, if one does that any change in the actual 
packet rate would result in that one moves from one tuple to another if 
they are giving certain values. The only way the TMMBR mechanism could 
work in this case is for a TMMBN to be sent with a new max packet rate 
every time one makes changes to the packetization and how often it 
produces packet. This also ends up being complicated when one has 
content that changes its packet rate continuously. Allowing for multiple 
restriction tuples to be valid at the same time do ensure that senders 
can take those effects into account also.

> The usage of tuples instead of single values allows, even in such p2mp scenario, to compute more accurate limits.

Agreed. I do think that the usage of tuples will help solve an real 
problem. However I do need to raise a discussion if the added complexity 
is worth it to solve the problem. I think it is.

> To conclude: IMHO the usage of tuples have no CONS with respect to picking up a single value, while providing benefits instead.

Well, here I do disagree. There are CONS.

Cheers

Magnus Westerlund

---

From: "Franceschini Guido" <[email-masked]>
Date: Wed, 28 Feb 2007 10:14:13 +0100

Colin, all,

The automatically inserted notice only states that if you received my mail by mistake you should not make any use of it.
But if you are an intended recipient, no problem.
I got confirmation about this from the legal dept.

Guido

> From: Colin Perkins [mailto:[email-masked]]
> Sent: venerdì 23 febbraio 2007 11.47
> To: Franceschini Guido
> Cc: IETF AVT WG
> Subject: IETF IPR policy (was Re: R: [AVT] CCM draft review--
> should"bandwidth"includetheheaderoverhead)
> 
> 

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

---

From: Colin Perkins <[email-masked]>
Date: Wed, 28 Feb 2007 10:15:35 +0000

Guido,

My point was to remind you, and the working group, that the IETF IPR  
policy disallows such confidentiality notices [RFC 3978 section 3.2].

Colin

On 28 Feb 2007, at 09:14, Franceschini Guido wrote:
> Colin, all,
>
> The automatically inserted notice only states that if you received  
> my mail by mistake you should not make any use of it.