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

From: <[email-masked]>
Date: Tue, 9 Jan 2007 09:12:56 -0000

Hi,

I support this proposal to use option D, codec bandwidth only, and
reference RFC3890 TIAS. Besides the reasons below, it aligns with the
statistics "octets sent" (nt/os) and "octets received" (nt/or) in the
network package of ITU-T H.248.1, which are defined as "media flow
excluding all transport overhead".

Geoff

> Message: 1
> Date: Mon, 08 Jan 2007 08:54:46 -0800
> From: "Chandra Umesh.1 (Nokia-NRC/MtView)" <[email-masked]>
> Subject: Re: [AVT] CCM draft review -- should "bandwidth" include the
> 	headeroverhead
> To: ext Stephan Wenger <[email-masked]>,	"Even, Roni"
> 	<[email-masked]>
> Cc: Randell Jesup <[email-masked]>, [email-masked]
> Message-ID: <[email-masked]>
> Content-Type: text/plain;	charset="US-ASCII"
> 
> I also agree that at the application layer we should use a 
> transport independent approach - option D.
> 
> 
> Umesh
> 
> 
> On 1/8/07 3:08 AM, "ext Stephan Wenger" <[email-masked]> wrote:
> 
> > Sounds very reasonable to me.  Anyone else?
> > Stephan
> > 
> > On Jan 7, 2007, at 5:04 PM, Even, Roni wrote:
> > 
> >> Hi,
> >> The bandwidth modifier in SDP RFC 4566 has a bwtype parameter. 
> >> RFC4566 specifies CT and AS type which include overhead. There is 
> >> also RFC3890 who specifies the TIAS (transport independent BW).
> >> The recommendations in RFC3890 about usage of CT, AS and TIAS are 
> >> viable also here.
> >> 
> >> My view is that in this layer we should use the transport 
> independent 
> >> approach (option D) and reference RFC 3890.
> >> 
> >> I think otherwise we need to explain similar logic to RFC3890.
> >> 
> >> Roni
> >> 
> >>> -----Original Message-----
> >>> From: Stephan Wenger [mailto:[email-masked]]
> >>> Sent: Saturday, January 06, 2007 4:51 PM
> >>> To: [email-masked]
> >>> Cc: Randell Jesup
> >>> Subject: [AVT] CCM draft review -- should "bandwidth" include the 
> >>> headeroverhead
> >>> 
> >>> Folks,
> >>> 
> >>> this message relates to the thread "CCM draft, Randell's 
> comments, 
> >>> part 2", and is raised here with a new subject line to a) attract 
> >>> your attention (successfully so! :-) and b) because it 
> appears to be 
> >>> a fundamental issue that may go well beyond the CCM draft.  Feel 
> >>> free to read the "CCM comments part 2" thread for 
> context, but don't 
> >>> get confused with the terminology discussion that is interleaved 
> >>> therein
> >>> -- the terminology stuff can be fixed quite easily 
> without much more 
> >>> input.
> >>> 
> >>> To set the stage: the CCM draft contains a mechanism where an RTP 
> >>> receiver can inform an RTP sender about his wishes for a 
> temporary 
> >>> bandwidth reduction to a bandwidth of n*128 bit/s.  The current 
> >>> draft does not explain how this bandwidth is calculated.  Two 
> >>> proposals are on the table:
> >>> 
> >>> Randell suggests to calculate this bandwidth to include 
> all overhead 
> >>> except the link layer overhead (i.e. IP, UDP, RTP, 
> payload headers, 
> >>> and the media payload itself).  Doing so is desirable as 
> >>> offer-answer RFC 3264 (and perhaps other RFCs in the signaling 
> >>> world) apparently define bandwidth that way.  Note that the CCM 
> >>> draft includes an algorithm that uses the "negotiated session 
> >>> maximum" (which may well stem from offer-answer exchanges) as a 
> >>> starting point, so there is a value in an aligned definition.
> >>> 
> >>> I'm a bit reluctant to accept that suggestion.  The above 
> arguments 
> >>> are compelling.  However, I think it's equally true that, 
> at least 
> >>> when RoHC is in place, one simply doesn't know the size 
> of the IP/ 
> >>> UDP/ RTP headers.  Beyond that, while an application can be made 
> >>> aware whether it is running on IPv4 or IPv6, that appears 
> to me not 
> >>> as a good implementation practice either.  However, I do 
> believe an 
> >>> application should be aware of the size of the RTP header and 
> >>> payload headers, and those should be accounted for.
> >>> 
> >>> So here's your choice:
> >>> a) bandwidth includes IP and UDP header overhead
> >>> b) bandwidth includes IP and UDP header overhead, and those are 
> >>> inferred to 20+8 bytes (IPv4)
> >>> c) bandwidth excludes IP and UDP header overhead, but 
> includes RTP 
> >>> and RTP payload overheads
> >>> d) codec bandwidth only, excluding any protocol headers
> >>> e) say nothing, leave it open (as the current draft 
> unintentionally
> >>> does)
> >>> 
> >>> Please comment.
> >>> 
> >>> Another question:
> >>> Do we need to define how exactly the bandwidth is calculated, i.e.
> >>> window size, buffer model, etc. etc.?  Coming from the 
> video coding 
> >>> world, I can tell you that this is a rather scary 
> endeavor.  Or is 
> >>> it sufficient to argue with an "average bandwidth over a 
> reasonably 
> >>> chosen interval in the order of magnitude of one second"?
> >>> 
> >>> Thanks for your input,
> >>> Stephan
> 

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

---

From: Carsten Waitzmann <[email-masked]>
Date: Tue, 09 Jan 2007 12:00:31 +0100

Hello,

during the last ITU-T meeting (Nov06) Q3/16 there was a discussion on the H.248 
network level statistics. The following agreement had been achieved (and the 
H.248 sub-series Implementors’ Guide is updated accordingly):

"When calculating the os and or statistics, the transport overhead is to be 
excluded. This means that the network transport overhead is not included, but 
overhead for the transport protocol and application layer is included in the 
count. For example, in an IP network using UDP for the transport protocol, to 
calculate the os statistic, the overhead associated with layers 1-3 (IP and 
below) is excluded, but overhead for layers 4-7 (UDP and above) is included in 
the count."

Therefore network package stats are not aligned to option D.

Potentially, new H.248 statistics will be defined covering option D.

best regards
Carsten

---

From: Stephan Wenger <[email-masked]>
Date: Tue, 9 Jan 2007 14:49:29 +0200

Hi Carsten,

This looks like an excellent design choice for the environment in  
question (h.248 network level statistics).  It covers IPv4/IPv6  
transparency, and accounts correctly for RTP headers and other  
optimizations.  It would even work with Ericsson's SHIM stuff :-).   
It cannot cover ROHC, but that's perhaps a non-issue in MEGACO.

I'm not so sure that it's all that a great idea for end-to-end  
bandwidth control.

More and more I tend towards option D.

Stephan

On Jan 9, 2007, at 1:00 PM, Carsten Waitzmann wrote:

> Hello,
>
> during the last ITU-T meeting (Nov06) Q3/16 there was a discussion  
> on the H.248 network level statistics. The following agreement had  
> been achieved (and the H.248 sub-series Implementors’ Guide is  
> updated accordingly):
>
> "When calculating the os and or statistics, the transport overhead  
> is to be excluded. This means that the network transport overhead  
> is not included, but overhead for the transport protocol and  
> application layer is included in the count. For example, in an IP  
> network using UDP for the transport protocol, to calculate the os  
> statistic, the overhead associated with layers 1-3 (IP and below)  
> is excluded, but overhead for layers 4-7 (UDP and above) is  
> included in the count."
>
>>>>> RFC4566 specifies CT and AS type which include overhead. There  
>>>>> is also RFC3890 who specifies the TIAS (transport independent BW).
>>>>> The recommendations in RFC3890 about usage of CT, AS and TIAS  
>>>>> are viable also here.
>>>>>
>>>>>> Subject: [AVT] CCM draft review -- should "bandwidth" include  
>>>>>> the headeroverhead
>>>>>>
>>>>>> Folks,
>>>>>>
>>>>>> part 2", and is raised here with a new subject line to a)  
>>>>>> attract your attention (successfully so! :-) and b) because it
>>>
>>> appears to be
>>>>>> a fundamental issue that may go well beyond the CCM draft.   
>>>>>> Feel free to read the "CCM comments part 2" thread for
>>>
>>> context, but don't
>>>>>> get confused with the terminology discussion that is  
>>>>>> interleaved therein
>>>>>> To set the stage: the CCM draft contains a mechanism where an  
>>>>>> RTP receiver can inform an RTP sender about his wishes for a
>>>
>>> temporary
>>>>>> bandwidth reduction to a bandwidth of n*128 bit/s.  The  
>>>>>> current draft does not explain how this bandwidth is  
>>>>>> calculated.  Two proposals are on the table:
>>>>>>
>>>>>> and the media payload itself).  Doing so is desirable as offer- 
>>>>>> answer RFC 3264 (and perhaps other RFCs in the signaling  
>>>>>> world) apparently define bandwidth that way.  Note that the  
>>>>>> CCM draft includes an algorithm that uses the "negotiated  
>>>>>> session maximum" (which may well stem from offer-answer  
>>>>>> exchanges) as a starting point, so there is a value in an  
>>>>>> aligned definition.
>>>>>>
>>>>>> UDP/ RTP headers.  Beyond that, while an application can be  
>>>>>> made aware whether it is running on IPv4 or IPv6, that appears
>>>
>>> to me not
>>>>>> b) bandwidth includes IP and UDP header overhead, and those  
>>>>>> are inferred to 20+8 bytes (IPv4)

---

From: Lloyd Wood <[email-masked]>
Date: Tue, 09 Jan 2007 13:44:46 +0000

At Tuesday 09/01/2007 12:00 +0100, Carsten Waitzmann wrote:
>Hello,
>
>during the last ITU-T meeting (Nov06) Q3/16 there was a discussion on the H.248 network level statistics. The following agreement had been achieved (and the H.248 sub-series Implementors’ Guide is updated accordingly):
>
>"When calculating the os and or statistics, the transport overhead is to be excluded. This means that the network transport overhead is not included, but overhead for the transport protocol and application layer is included in the count. For example, in an IP network using UDP for the transport protocol, to calculate the os statistic, the overhead associated with layers 1-3 (IP and below) is excluded, but overhead for layers 4-7 (UDP and above) is included in the count."

I'd call that "path capacity".

L.

>>>I also agree that at the application layer we should use a transport independent approach - option D.
>>>
>>>
>>>Umesh
>>>
>>>
>>>>>The bandwidth modifier in SDP RFC 4566 has a bwtype parameter. RFC4566 specifies CT and AS type which include overhead. There is also RFC3890 who specifies the TIAS (transport independent BW).
>>>>>The recommendations in RFC3890 about usage of CT, AS and TIAS are viable also here.
>>>>>
>>>>>>Subject: [AVT] CCM draft review -- should "bandwidth" include the headeroverhead
>>>>>>
>>>>>>Folks,
>>>>>>
>>>>>>part 2", and is raised here with a new subject line to a) attract your attention (successfully so! :-) and b) because it 
>>>
>>>appears to be 
>>>>>>a fundamental issue that may go well beyond the CCM draft.  Feel free to read the "CCM comments part 2" thread for 
>>>
>>>context, but don't 
>>>>>>get confused with the terminology discussion that is interleaved therein
>>>>>>To set the stage: the CCM draft contains a mechanism where an RTP receiver can inform an RTP sender about his wishes for a 
>>>
>>>temporary 
>>>>>>bandwidth reduction to a bandwidth of n*128 bit/s.  The current draft does not explain how this bandwidth is calculated.  Two proposals are on the table:
>>>>>>
>>>>>>and the media payload itself).  Doing so is desirable as offer-answer RFC 3264 (and perhaps other RFCs in the signaling world) apparently define bandwidth that way.  Note that the CCM draft includes an algorithm that uses the "negotiated session maximum" (which may well stem from offer-answer exchanges) as a starting point, so there is a value in an aligned definition.
>>>>>>
>>>>>>UDP/ RTP headers.  Beyond that, while an application can be made aware whether it is running on IPv4 or IPv6, that appears 
>>>
>>>to me not 
>>>>>>application should be aware of the size of the RTP header and payload headers, and those should be accounted for.
>>>>>>
>>>>>>So here's your choice:
>>>>>>b) bandwidth includes IP and UDP header overhead, and those are inferred to 20+8 bytes (IPv4)

---

From: Randell Jesup <[email-masked]>
Date: Tue, 09 Jan 2007 18:34:15 -0500

>More and more I tend towards option D.

I would ask you think deeply on what's implied by the receiver telling the
sender what the codec bandwidth should be before choosing d)

The "normal" reason for TMMBR is a reduction in link bandwidth.  If (for
example) the call was negotiated using b=AS, the receiver will have to
a) figure out what the current TIAS bandwidth is (by looking at IP/UDP/RTP
headers (including header extensions) over long enough (including iframes
for video) to estimate the current bandwidth, or 
b) guess at TIAS based on AS and assumptions about overhead (which may not
be true), and based on assumptions about how the sender took AS and turned
it into codec bandwith.
Then it could use its guess at TIAS and adjust it down by the amount that
AS would have dropped.

If it had been negotiated as TIAS (and we can't assume that!!), then you
know TIAS and could send a new TIAS that's the same amount lower as the
link bandwidth dropped.  But how did you send TIAS in the first place?  You
had to guess at what IP/UDP/RTP (header extensions) overhead the sender
would end up sending you, AND guess at the frame rate they'd send you (and
put it in the TIAS request).  And remember the receiver may well not know
how to estimate the bandwidth of any header extensions (which are not
guaranteed to be fixed bytes/packet or to be in every packet).

It's far better to tell the sender "here's the link bandwidth (AS) for this
stream; you figure out how much that leaves you for codecs".  If you
negotiated TIAS I'm ok with sticking to it - but my current thinking is
that TIAS is resting on the same sort of bad assumptions it supposedly
was supposed to solve - it just moved them from the sender to the receiver.

-- 
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: "Franceschini Guido" <[email-masked]>
Date: Wed, 10 Jan 2007 11:39:00 +0100

Dear all,

it's a long time I have been absent from this and other goups, but now it seems I can finally contribute.

In my recent work (implementation and deployment of a SIP based p2p videocommunication system) I have found that the currently defined bw parameters CT, AS, TIAS were not satisfactory, either because their semantics were insufficient (CT, AS), or because (TIAS) the parameter describes the characteristics of the media being sent, whereas I had the need to describe the capacity of the receiver. In my work I have thus defined yet another parameter.

I briefly present the idea here below: if I get some positive feedback, then I'll work on a more comprehensive I-D.

I can anticipate that -for the immediate- I will be in favor of signalling in the TMMBR message the pure codec payload. But I also hope you'll find interesting the arguments I am going to present, and that some more people would share the desire to make this whole bw stuff more satisfactory and consistent, in the end.

The focus of this thread is on the packet overhead. I have perceived that the main concern in this thread is about the per-packet overhead due to the (unknown) protocol stack at the receiving peer. Delivering video RTP packets on top of different stacks leads of course to different overheads, but also delivering the same video payload within video RTP packets of 100 bytes or 1000 bytes means consuming a very different bandwidth. So far, sorry for the triviality. There is another aspect related to the video RTP packet size however, that I haven't seen mentioned so far: the jitter induced on the audio stream. Indeed, when audio and video share the same link, audio and video packets are serialized. A 1000 bytes packets over a 64 Kbit/s link takes about 125ms... As a matter of fact, video RTP packet sizes should be selected to be small enough to avoid too much jitter on the audio stream, and big enough to avoid too much overhead. The best compromise depends on the link rate and on how much is the per-packet overhead, and this depends on IPV4/6, Header compression, IP tunneling, etc. Plus of course Link characteristics, that might be optimized for certain packet dimensions.

In my work, I ended up defining a new pair of parameters, based on the following requirements:
- Transport independence (each peer is not aware of the protocol stack and overheads present at the other end)
- Description of the downlink capacity of the receiver side (so as to enable the transmitter to optimally fit that capacity)

The parameters I defined are:
- TIDC = Transport Independent Downlink Capacity
- MPO  = Mean per-Packet Overhead
They describe the Downlink characteristics, thus they typically apply to the (SDP) session level, not the media level.

The idea works like this (I try to adhere as much as possible to the terminlogy of http://www.ietf.org/internet-drafts/draft-ietf-ippm-bw-capacity-04.txt):
Suppose Peer A is attached to a physical Link La, with a nominal downlink capacity NomDCap(La) of 100 Kbit/s, and with a protocol stack that includes RTP/UDP/IP/XXX/YYY, where the XXX is a layer that adds 8 bytes of overhead per packet, and YYY is a layer that adds 20% overhead. The downlink capacity at the XXX layer is 100 Kbit/s decremented by 20%, thus 80 Kbit/s. At this layer each packet will have an overhead of 12 (RTP) + 8 (UDP) + 20 (IP) + 8 (XXX) bytes = 48 bytes.
Thus TIDC=80 and MPO=48.
Note that the MPO figure does not account for overheads due to the RTP Header Extensions and RTP Payload Formats; it includes up to the RTP layer, so that in case RTP Header compression schemes are used at Link La, the MPO value can be calculated accordingly.
These parameters are communicated from Peer A to Peer B, somehow (e.g. SIP/SDP).
Peer B, being informed of this <TIDC=80, MPO=48>, and being aware of its own corresponding uplink characteristics, can determine how to optimally packetize audio and video and how much audio and video bandwidth it can use. Note that Peer B need not to know anything about the layers XXX and YYY, nor about presence of ROHC, IP Tunneling or whatever at Link La: it simply knows that each packet that it will generate will consume 48 bytes of overhead at Link La, and that such overhead is measured at the same level as the 80 Kbit/s figure. Thus, if Peer B decides to generate AMR audio at 12.2 Kbit/s with 50 packets/sec, it knows that it is consuming 48*8*50=19.2 Kbit/s of audio overhead at Link La, which leaves 80-12.2-19.2 = 48.6 Kbit/s for video payload + video overhead + RTCP and anything else (at Link La).

If Peer B is also concerned about the audio jitter induced by the video RTP packets, by means of this <TIDC=80, MPO=48> Peer B can compute the serialization delay of a video RTP packet at Link La (and similarly at its local Link Lb), that directly correspond to additional terms for the jitter on the audio stream, and thus Peer B can determine the maximum acceptable length for a video RTP packet.
It can also identify the best compromise in the audio packet length between delay and overhead.
And it can finally determine the residual amount of bandwidth available for the pure video payload.

For a perfect job, a third parameter (at SDP media level) could be added as well, to indicate the maximum codec bandwidth the receiver is willing to accept. This because even if the downlink capacity at Peer A is 1 MBit/s, maybe Peer A only wants to dedicate just a fraction of it to the video. This third parameter should preferably consist of a single value (MAXPAYLOADBR, representing the pure media payload bitrate), or alternatively be represented by the pair <TIAS, maxprate>, from which the pure media payload bitrate could be derived.
In the absence of such third parameter, the transmitter would assume that all the available downlink capacity can be saturated.

Now back to the essence of this thread.

Assuming that the transmitter is made aware somehow, for each receiver, of the downlink characteristics (TIDC and MPO) and of the maximum acceptable codec bandwidth of each media (MAXPAYLOADBR), it would be wise to either:
- update the pure codec bandwidth (if for some reason the receiver decided to change its preferences)
- update the link characteristics (if these changed, e.g. because the receiver uses a PSTN modem that renegotiated the physical bandwidth or because the receiver is on a mobile network and the mobile link has changed)
By doing so, the transmitter would be aware, for each receiver, of the downlink characteristics and of the maximum acceptable codec bandwidth, and could generate media stream(s) so as to fit the constraints of each receiver.
This is, IMHO, the target, fully satisfactory solution.
For the immediate, I therefore believe that it would be safe to just use the pure codec bandwidth (option D) in the TMMBR messages. And I understand that there is no time to place more changes/additions to accomodate my proposed params (TIDC,MPO).
For the future instead, I'd like to work towards the fully satisfactory solution, and I am quite convinced of the merits of the TIDC,MPO params.
In this context, the (new) problem is how to make the transmitter aware of the <TIDC, MPO> of each receiver, or of their changes. As I said, these are session-level params, not media-level params. For P2P SIP based sessions, SDP is an obvious solution to communicate the initial values. In case the downlink characteristics change during the session, RE-INVITE can be considered. But for Multicast scenarios, SDP (from receivers to transmitter) is not applicable. In this case RTCP would be the preferable medium, but as of today there is no explicit support in RTCP for communicating session-wide parameters, only media related parameters. It seems easy to define a new RTCP packet, or SDES component, to carry such session-wide information, unless there are implications I have not considered.

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

> From: Randell Jesup [mailto:[email-masked]]
> Sent: mercoledì 10 gennaio 2007 0.34
> To: Stephan Wenger
> Cc: [email-masked]; [email-masked]; [email-masked];
> Carsten Waitzmann
--------------------------------------------------------------------

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

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