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

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.

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

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

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

Lars (as an individual)

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