Re: [BEHAVE] TURN Issue #1: Bandwidth Param

Lars Eggert wrote:
> On 2007-12-7, at 21:15, ext Jonathan Rosenberg wrote:
>> Client MAY include bandwidth in a request.
> 
> What exactly is bandwidth defined as? This is not trivial; see 
> draft-ietf-ippm-bw-capacity. We do need a crisp definition if this is to 
> work.

Right - the plan was to take a leaky bucket definition from RSVP.

> 
>> If present, it is a request from the client that the server forward 
>> traffic to and from the client such that the total in each direction 
>> will not be excess of this value.
> 
> Do I read this correctly as a "please rate-limit me to X" option? What 
> incentive does a client have to send this?

The presumption is that the server has a relationship with the client 
and is there to support a particular application (say, voip). And so, if 
the client includes the value the server is likely to honor it and not 
drop data below that rate. If the client includes nothing the server 
might choose to rate limit at a value that is below what the client 
actually needs. So the client is incented to include it.

> 
>> Server MAY include a value in a response, even if there was not one in 
>> a request. The meaning of the value in the response, is that the 
>> server agrees to forward traffic to/from the client so long as it is 
>> below the bandwidth value. Any traffic above that value may be dropped 
>> by the server.
> 
> But this doesn't tell the client all that much. Yes, if it stays below 
> the limit, it can be sure that the server doesn't rate-limit it, but 
> congestion on the path can happen before that rate is reached, i.e., the 
> client can't depend on it. And because the server may forward traffic 
> that exceeds this rate, the client has every incentive to see if it can 
> send more than the signaled rate.

This parameter is really only primarily useful for fixed rate 
applications for voip. For variable rate I agree its largely useless.

> 
>> If there is no value in the response, the server will relay traffic at 
>> best effort. Furthermore, there is never an absolute guarantee that 
>> the server will be able to relay data even if the usage is below the 
>> bandwidth parameter, and clients MUST be prepared for packet loss. Of 
>> course, there could be packet loss outside of the TURN server anyway.
> 
> Right, this pretty much sums up my concerns.
> 
> TURN isn't a QoS-signaling solution, so I'm all for removing this option.

No, but TURN servers do provide a service (media relay of traffic) and 
it seems sensible for clients to ask for a particular level of service 
and be told if they get it or not.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
jdrosen@cisco.com
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com

_______________________________________________
Behave mailing list
Behave@ietf.org
https://www1.ietf.org/mailman/listinfo/behave