Subject: Re: [MMUSIC] RTSPv2 bandwidth indication

From: Magnus Westerlund <[email-masked]>
Date: Fri, 24 Sep 2010 16:43:44 +0200

Hi,

I am of the opinion we shouldn't change anything here. The Bandwidth
header in RTSP 1.0 is in bps, and there is no confusion in it self that
there are different units.

To be clear there are several SDP bandwidht modifiers that are in BPS
and some that are in KBPS. Thus independntly of a change there will not
be perfect match between the two protocols.

Based on that I see minimal change to RTSP the right way to go.

Cheers

Magnus

Martin Stiemerling skrev 2010-06-29 14:42:
> Hi, 
> 
>> -----Original Message-----
>> From: Jan Lindquist [mailto:[email-masked]]
>> Sent: Friday, June 11, 2010 10:22 AM
>> To: Martin Stiemerling; mmusic (E-mail)
>> Subject: RTSPv2 bandwidth indication
>>
>> Hello,
>>
>> The response to the RTSP DESCRIBE includes an SDP which is according to
>> RFC4566. The bandwidth information is populated as follows (section
>> 5.8):
>>
>>    The <bandwidth> is interpreted as kilobits per second by default.
>>
>> Additionally the bandwidth is the maximum bandwidth of the stream to be
>> setup.
>>
>>
>> The bandwidth header in the RTSP SETUP is populated as follows (section
>> 16.8):
>>
>>    The Bandwidth request-header field describes the estimated bandwidth
>>    available to the client, expressed as a positive integer and
>> measured
>>    in bits per second.  The bandwidth available to the client may
>> change
>>    during an RTSP session, e.g., due to mobility, congestion, etc.
>>
>> The two text have a mismatch and should be clarified.
>>
>> 1. The values used are different which is an unfortunate oversight.
>> Possibly could use the same format as the SDP bandwidth format with
>> bandwidth type.
> 
> This sounds reasonable to me. 
> 
>>
>> 2. Not clear what is meant by estimated bandwidth available to the
>> client. How can a client estimate it the bandwidth. If the client has a
>> gigabit ethernet connection does it estimate based on interface. The
>> client can't either be sure what type of access line is in the home if
>> fiber or DSL. I would instead thought it is the maximum bandwidth that
>> the client expects to use for the session which is retrieved from the
>> DESCRIBE or other means.
> 
> The Bandwidth header is originally defined in RTSP 1.0 (RFC 2326), Section 12.6. I'm probably not long enough in business with RTSP to tell the actual reasons for this. 
> 
> Anybody else who help out here?
> 
>   Martin
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
> 

-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 28 Sep 2010 13:22:23 +0200

>> The Bandwidth header is originally defined in RTSP 1.0 (RFC 2326), Section 12.6. I'm probably not long enough in business with RTSP to tell the actual reasons for this. 

I did ignore the second issue in Jan's email. From my perspective the
Bandwidth header should only be used by clients that has actual
knowledge about their available bandwidth. That knowledge would come
from the access link itself when directly available to the client, like
in a cellular device.

The current text says:

16.8.  Bandwidth

   The Bandwidth request-header field describes the estimated bandwidth
   available to the client, expressed as a positive integer and measured
   in kilobits per second.  The bandwidth available to the client may
   change during an RTSP session, e.g., due to mobility, congestion,
   etc.

   Example:
     Bandwidth: 62360

I would suggest that we change the text to:

   The Bandwidth request-header field describes the estimated bandwidth
   available to the client, expressed as a positive integer and measured
   in kilobits per second.  The bandwidth available to the client may
   change during an RTSP session, e.g., due to mobility, congestion,
   etc. Clients may not be able to accurately determine the available
   bandwidth, for example due to that first hope is not a known
   bottleneck. It is RECOMMENDED that only clients that has accurate
   and explicit information about bandwidth bottlenecks uses this
   header.

Comments?

Magnus Westerlund

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Tue, 28 Sep 2010 19:26:42 +0800

I feel the Bandwidth header should be populated by the server after determining the actual bandwidth available to the client. If client would populate this value, then it would put the total available bandwidth, which may not be actually available.

Regards
Ranjit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus Westerlund
Sent: Tuesday, September 28, 2010 4:52 PM
To: Magnus Westerlund
Cc: mmusic (E-mail); Martin Stiemerling
Subject: Re: [MMUSIC] RTSPv2 bandwidth indication

>>> client. How can a client estimate it the bandwidth. If the client 
>>> has a gigabit ethernet connection does it estimate based on 
>>> interface. The client can't either be sure what type of access line 
>>> is in the home if fiber or DSL. I would instead thought it is the 
>>> maximum bandwidth that the client expects to use for the session 
>>> which is retrieved from the DESCRIBE or other means.
>>

I did ignore the second issue in Jan's email. From my perspective the Bandwidth header should only be used by clients that has actual knowledge about their available bandwidth. That knowledge would come from the access link itself when directly available to the client, like in a cellular device.

The current text says:

16.8.  Bandwidth

   Example:
     Bandwidth: 62360

Comments?

Magnus Westerlund

---

From: Jan Lindquist <[email-masked]>
Date: Tue, 28 Sep 2010 13:28:50 +0200

Hello Magnus,

Thank you for considering my comment. The proposed text makes it very clear the intention as to the usage of the header. Having different values in the SDP and the bandwidth header is acceptable since the purpose is different.

Thank you,
JanL 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Magnus Westerlund
> Sent: Tuesday, September 28, 2010 1:22 PM
> To: Magnus Westerlund
> >> The Bandwidth header is originally defined in RTSP 1.0 
> (RFC 2326), Section 12.6. I'm probably not long enough in 
> business with RTSP to tell the actual reasons for this. 
> >>
> 
> 
> I did ignore the second issue in Jan's email. From my 
> perspective the Bandwidth header should only be used by 
> clients that has actual knowledge about their available 
> bandwidth. That knowledge would come from the access link 
> itself when directly available to the client, like in a 
> cellular device.
> 
> The current text says:
> 
> 16.8.  Bandwidth
>

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 28 Sep 2010 16:15:15 +0200

> I feel the Bandwidth header should be populated by the server after determining the actual bandwidth available to the client. If client would populate this value, then it would put the total availa…

Can you please clarify why the server would populate it? If it knows it
can utilize the information locally.

But I agree that the only reasonable interpretation from server
perspective is that this is a known upper limit at the point of starting
up the session. Should we clarify that?

Cheers

Magnus Westerlund

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Wed, 29 Sep 2010 00:01:43 +0800

Hi Magnus

Usually clients would not know how much bandwidth is actually available for them, though they may be aware of the theoritical value. So in case of multiple clients connected to the server, the bandwidth would be shared and the whole bandwidth may not be availabel to a single client. So in such cases, the server should be filling in the value rather than client doing it. 

Regards
Ranjit

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]] 
Sent: Tuesday, September 28, 2010 7:45 PM
To: Avasarala Ranjit-A20990
Cc: mmusic (E-mail); Martin Stiemerling
Subject: Re: [MMUSIC] RTSPv2 bandwidth indication

> I feel the Bandwidth header should be populated by the server after determining the actual bandwidth available to the client. If client would populate this value, then it would put the total availa…

Can you please clarify why the server would populate it? If it knows it can utilize the information locally.

But I agree that the only reasonable interpretation from server perspective is that this is a known upper limit at the point of starting up the session. Should we clarify that?

Cheers

Magnus Westerlund

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 28 Sep 2010 13:35:42 -0500

At 06:22 AM 9/28/2010, Magnus Westerlund wrote:
> >> The Bandwidth header is originally defined 
> in RTSP 1.0 (RFC 2326), Section 12.6. I'm 
> probably not long enough in business with RTSP 
> to tell the actual reasons for this.
> >>
>
>
>knowledge about their available bandwidth.

Magnus

How is the following scenario accounted for then:

         10or100Mbps                <1Mbps
client <----------> home gateway <---------> Internet

It seems to me without an active probe function - 
which is outside of MMUSIC's charter and not 
accounted for in the quoted text you provided 
below - that this Bandwidth header would always 
return a false and potentially quite misleading value.

Admittedly there are scenarios in which the 
Bandwidth header would be valid (e.g., connected 
directly to GPRS or dot11 enterprise network), 
this is virtually never the case in the 
residential environments we have today (e.g., the 
client is almost never connected directly to the 
Internet without some router or GW in between).

If this is true, is it wise to retain the 
Bandwidth header (especially with this definition)?

James

>That knowledge would come

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 29 Sep 2010 11:07:41 +0200

> Bandwidth header (especially with this definition)?

James, I would classify the above examples as one case where the client,
doesn't know the value. In general if you only have ethernet or wifi
connectivity you don't know about the available bandwidth.

Secondly, we do have users of this header. For example 3GPP PSS TS
26.234 uses bandwidth. And a client in a cellphone actually know what
upper limit their is to the capacity as long as the bottleneck is the
wireless hop. In the case of PSS they certainly not trust that value,
only use it as input on what a reasonable start point should be.

So, I don't want to remove it because their are users. I want to clarify
that it has only limited applicability.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 29 Sep 2010 11:12:18 +0200

> Usually clients would not know how much bandwidth is actually available for them, though they may be aware of the theoritical value. So in case of multiple clients connected to the server, the band…

Well, I fully agree with that in many cases the client doesn't know what
the bottleneck bandwidth is or if it is shared. And that is why I want
to make clear that only clients that truly know that it indicates a
bottleneck bandwidth should do it.

However, I don't see what use a client has of the bandwidth value. It is
the server that has usage of a bandwidth estimate. Thus no need to
return it. Also, I don't expect the bottleneck to be close to the server
in most cases. Certain back to your home deployments might have this
issue, but then I think it is primarily a question of configuring your
server with a bandwidth cap so it doesn't cause issues for itself.

Cheers

Magnus Westerlund

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Wed, 29 Sep 2010 17:16:35 +0800

Sure agree with you. 

Regards
Ranjit

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]] 
Sent: Wednesday, September 29, 2010 2:42 PM
To: Avasarala Ranjit-A20990
Cc: mmusic (E-mail); Martin Stiemerling
Subject: Re: [MMUSIC] RTSPv2 bandwidth indication

> Usually clients would not know how much bandwidth is actually available for them, though they may be aware of the theoritical value. So in case of multiple clients connected to the server, the band…

Well, I fully agree with that in many cases the client doesn't know what the bottleneck bandwidth is or if it is shared. And that is why I want to make clear that only clients that truly know that it indicates a bottleneck bandwidth should do it.

However, I don't see what use a client has of the bandwidth value. It is the server that has usage of a bandwidth estimate. Thus no need to return it. Also, I don't expect the bottleneck to be close to the server in most cases. Certain back to your home deployments might have this issue, but then I think it is primarily a question of configuring your server with a bandwidth cap so it doesn't cause issues for itself.

Cheers

Magnus Westerlund

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 29 Sep 2010 14:48:10 -0500

>connectivity you don't know about the available bandwidth.

Magnus - saying the client doesn't know its 
bandwidth because it is connected to Ethernet is 
interesting, as most of us consider Ethernet to 
be one of the root connections by most 
endsystems, but maybe that's just me... wouldn't 
you know it if you were only in almost any LAN 
environment? It seems to me that detectability of 
the WAN link speeds, if present between client 
and server, is when the Bandwidth header might not be reliable.

As I mentioned above, and as you mention below, 
if the client is directly connected (i.e., using) 
a lower speed interface/connection (such as 
3G/4G), then this reliability of the lowest link 
is probably the client's access - which is known to the client.

>that it has only limited applicability.

If you want to clarify the text, you might need 
to say why Ethernet is not a reliable connection 
for this purpose, and perhaps why others aren't either.

James