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

["Franceschini Guido" <[e-mail]>]

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 [phone] 
Fax     [phone] 
[e-mail] <mailto:[e-mail]>  


> -----Original Message-----
> From: Randell Jesup [mailto:[e-mail]]
> Sent: mercoledì 10 gennaio 2007 0.34
> To: Stephan Wenger
> Cc: [e-mail]; [e-mail]; [e-mail];
> Carsten Waitzmann
> Subject: Re: [AVT] CCM draft review -- should "bandwidth" include the
> headeroverhead
> 
> 
> Stephan Wenger <[e-mail]> writes:
> >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
> [e-mail]
> "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)
> 
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/avt
> 
--------------------------------------------------------------------

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 [e-mail].

        Thank you

                                        www.telecomitalia.it

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

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