Subject: RE: [MMUSIC] B=AS in SDP

From: [email-masked]
Date: Tue, 1 Oct 2002 11:43:06 +0300

Hi Lior,
The same discussion took place in November 2001, and I attached the e-mails sent to MMUSIC reflector related to this issue.
I also think that this value should include the <data + packetization + network header overheads>, by making a reasonable guess on the possible overhead if no other information is available. 
Currently, 3GPP PSS streaming Spec. (TS 26.234) also follows the same definition.

For RTCP bandwidth, currently in IETF AVT group there is an internet draft to include new SDP attributes to signal RTCP bandwidth. 
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcp-bw-05.txt

BR
Emre

Emre Baris Aksu

Nokia Mobile Phones
Tampere / Finland
e-mail : [email-masked]
Mobile : +358 40 743 1972
Fax    : +358 7180 70504

> -----Original Message-----
> From: ext Lior Sion [mailto:[email-masked]]
> Sent: 01. October 2002 11:22
> To: Mmusic (E-mail)
> Subject: [MMUSIC] B=AS in SDP
> 
> 
> Hello,
> 
> We have a long argument about the concept of the bandwidth in 
> the SDP (b=as line), and i would like to raise it before 
> closure of the new SDP draft.
> The question is what part of the session's bandwidth is 
> included in this parameter - data only (no headers), data + 
> rtp headers, or data + rtp + ip headers, rtp + rtcp, etc. 
> 
> Although I've seen all arguments in favor of adding the 
> headers and the RTCP to this value, i can't see how this can 
> be done. Since the client chooses the block size (using 
> blocksize parameter in RTSP SETUP request), only then i can 
> calculate the number of packets to be sent, and even this 
> it's only an assumption (in mpeg4 for example, i can't be 
> sure how many packets the server would create for each frame, 
> due to headers boundaries). Since protocol headers (i.e., 
> UDP) are added to each packets, total bw can not be guessed 
> beforehand.
> 
> Moreover, at SDP stage, streaming server still doesn't know 
> the underlying protocol. It can be TCP, UDP, etc. and this 
> has major influence on packet sizes and header sizes per packet.
> 
> What do you think?
> 
> Lior
> 
> **************************************************************
> ************************************
> The contents of this email and any attachments are confidential.
> It is intended for the named recipient(s) only.
> If you have received this email in error please notify the 
> system manager or  the 
> sender immediately and do not disclose the contents to any 
> one or make copies.
> 
> ** eSafe scanned this email for viruses, vandals and 
> malicious content **
> **************************************************************
> ************************************
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mmusic
> 

Subject: Re: AS parameter in SDP
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Date: Tue, 20 Nov 2001 20:13:35 +0300

Colin Perkins wrote:

> I always assumed this was the RTP session bandwidth (section 6.2 of the RTP
> specification), and hence included RTP/UDP/IP header overheads.

While this is simple for well-known fixed size overhead as e.g. 20+8 bytes for
IP+UDP, it's not clear to me that an application would have access to other types of
overhead. For example, consider the use of IPSec or IPv6. Do we really want the app
to be concerned about such things ?

-- Flemming

>
>
> Colin
>
> --> Flemming Andreasen writes:
> >I have asked this question myself before, but never gotten an official answer. I
> >have had discussions with a few people in private, and the opinion there has
> >been that it should include RTP header overhead. The reason for at least
> >including RTP header overhead is, that if it doesn't somehow account for the
> >varying header overhead that different packetization periods will lead to, then
> >it's unclear what benefit the parameter provides. Letting it apply to any lower
> >layers could be considered a layer violation.
> >
> >Colin:    Assuming nobody disagrees with the above, can we get this clarified in
> >the SDP-new draft ?
> >
> >Thanks
> >
> >        Flemming
> >
> >David Lide wrote:
> >
> >> There seems to be some confusion on the exact definition of the AS parameter
> >> in SDP.  Should this
> >> value reflect just the RTP payload requirements (e.g. 64 kbps for PCM voice)
> >> or include the RTP header, IP, UDP header, security overhead, etc.
> >>
> >> thanks,
> >> dave
> >
> >--
> >Flemming Andreasen
> >Cisco Systems
> >
> >

--
Flemming Andreasen
Cisco Systems

Subject: Re: AS parameter in SDP
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Date: Wed, 21 Nov 2001 21:44:02 +0300

Colin Perkins wrote:

> --> Flemming Andreasen writes:
> >Colin Perkins wrote:
> >> I always assumed this was the RTP session bandwidth (section 6.2 of the RTP
> >> specification), and hence included RTP/UDP/IP header overheads.
> >
> >While this is simple for well-known fixed size overhead as e.g. 20+8 bytes
> >for IP+UDP, it's not clear to me that an application would have access to
> >other types of overhead. For example, consider the use of IPSec or IPv6.
> >Do we really want the app to be concerned about such things ?
>
> If you're using the bandwidth information for resource reservation or
> capacity planning, you pretty much need to include the header sizes.

Sure (however lower layer compression may actually make this inaccurate as well).

>
> If not, then it's advisory and the application can make a reasonable
> guess and hope (nothing should break too badly if the values are not
> quite right...).
>

All right - network layer and up it is then. As long as we get this clarified in
the SDP-new spec I'm happy.

-- Flemming

> Colin

--
Flemming Andreasen
Cisco Systems

Subject: Re: AS parameter in SDP
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Date: Wed, 21 Nov 2001 06:48:07 +0300

--> Flemming Andreasen writes:
>Colin Perkins wrote:
>> I always assumed this was the RTP session bandwidth (section 6.2 of the RTP
>> specification), and hence included RTP/UDP/IP header overheads.
>
>While this is simple for well-known fixed size overhead as e.g. 20+8 bytes
>for IP+UDP, it's not clear to me that an application would have access to
>other types of overhead. For example, consider the use of IPSec or IPv6.
>Do we really want the app to be concerned about such things ?

If you're using the bandwidth information for resource reservation or
capacity planning, you pretty much need to include the header sizes. 
If not, then it's advisory and the application can make a reasonable
guess and hope (nothing should break too badly if the values are not
quite right...).

Colin

Subject: Re: AS parameter in SDP
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Date: Tue, 20 Nov 2001 19:49:05 +0300

I always assumed this was the RTP session bandwidth (section 6.2 of the RTP
specification), and hence included RTP/UDP/IP header overheads. 

Colin

--> Flemming Andreasen writes:
>I have asked this question myself before, but never gotten an official answer. I
>have had discussions with a few people in private, and the opinion there has
>been that it should include RTP header overhead. The reason for at least
>including RTP header overhead is, that if it doesn't somehow account for the
>varying header overhead that different packetization periods will lead to, then
>it's unclear what benefit the parameter provides. Letting it apply to any lower
>layers could be considered a layer violation.
>
>Colin:    Assuming nobody disagrees with the above, can we get this clarified in
>the SDP-new draft ?
>
>Thanks
>
>        Flemming
>
>David Lide wrote:
>
>> There seems to be some confusion on the exact definition of the AS parameter
>> in SDP.  Should this
>> value reflect just the RTP payload requirements (e.g. 64 kbps for PCM voice)
>> or include the RTP header, IP, UDP header, security overhead, etc.
>>
>> thanks,
>> dave
>
>--
>Flemming Andreasen
>Cisco Systems
>
>