Subject: [BEHAVE] TURN: Proposal for the BANDWIDTH attribute

From: Philip Matthews <[email-masked]>
Date: Wed, 12 Mar 2008 15:01:23 -0400

As people may be aware, the text in TURN-07 regarding the BANDWIDTH  
attribute is just placeholder text, since I didn't know what a real  
solution might look like. I have now talked to a number of people  
here at the IETF meeting and I have a serious proposal. I plan to  
present the proposal below at the BEHAVE meeting tomorrow.

- Philip

The BANDWIDTH attribute would contain two fields that specify a Token  
Bucket (see http://en.wikipedia.org/wiki/Token_bucket)
* Token Bucket Rate
* Token Bucket Size

The client MAY include the BANDWIDTH attribute in an Allocate  
request. Including the attribute means that the client would like to  
see the server do admission control and provide a service guarantee,  
while not including the attribute means that the client would like to  
get best effort service. The client will generally include the  
attribute if it expects to be sending roughly constant rate data  
(e.g. voice or video), and will not include it if it expects to send  
at a variable rate or if it has no idea of the rate that it will be  
sending.

When the server receives this request, it responds as follows:
* If the BANDWIDTH attribute was not include, and the server is happy  
to provide best-effort service, then the server replies with a  
success response.
* If the BANDWIDTH attribute was not include, but the server is not  
happy to provide best-effort service, then the server rejects the  
request with an error response.
* If the BANDWIDTH attribute was included, and the server can provide  
that level of service, then the server replies with a success response.
* If the BANDWIDTH attribute was included, but the server cannot  
provide a service guarantee (e.g., it only provides best-effort  
service), then the server replies with an error response.
* If the BANDWIDTH attribute was included, and the server can  
normally provide a service guarantee, but the client asked for a  
level of service (e.g., a Token Bucket Rate) that the server cannot  
provide at the current time, then the server replies with a  
(different) error response. The server MAY include the BANDWIDTH  
attribute in its error response which specifies a level of service  
that it could currently provide.

One type of server implementation might provide just best-effort  
service, and thus reject any requests containing a BANDWIDTH  
attribute. Another type of server implementation might do admission  
control, and thus require requests to contain a BANDWIDTH attribute.  
Admission control can be done by simply adding up the Token Bucket  
Rate values for all current and requested allocations and making sure  
that is less than some maximum value. A server doing admission  
control may or may not also do policing; policing requires the server  
to actually monitor that the client is sending at or below the rate  
it specified, and requires the server to keep a token bucket for each  
allocation.

My expectation is that TURN servers used for voice or video  
applications would do admission control, while TURN servers used for  
general data relaying would do best-effort service. At present, I  
don't know how to mix these two types of traffic on the same server  
and still give service guarantees, but it might be possible and the  
text above allows this if the server can do it.

_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: "Kevin Johns" <[email-masked]>
Date: Wed, 12 Mar 2008 17:02:10 -0600

Philip,

Thanks for providing this proposal. I have been mulling this over for
awhile and had not proposed anything as I was still not sure of the
right solution. I am happy to see that what you propose partially lines
up with what I have been thinking which was to reuse some existing SDP
attributes - maxprate and a transport independent bandwidth modifier
(TIAS) both of which are defined in RFC 3890. While maxprate aligns with
token bucket rate, TIAS does not directly align with token bucket size,
however the token bucket size can be determined from the bandwidth and
rate. I was leaning toward this approach since it utilized existing SDP
parameters which might have broader client implementation then flow spec
parameters.

At the moment I am hard pressed to favor one approach over the other
although I am thinking the use of token bucket parameters may place
additional complexity on the client as it will need to know how to
properly represent its anticipated stream. If folks want to be able to
police then token bucket is probably the way to go. If people don't care
about policing then it may be a slight overkill.

I do have one concern with your proposed procedures - if the TURN server
does not support admission control and the client included the bandwidth
attribute, I am not sure flat out rejection is the right answer. The
server should be able to redirect to a TURN server which supports
bandwidth (ALTERNATE-SEVER maybe?) or accept with an indication that
admission control was not performed (maybe a different success code?).

If we stick with token bucket parameters, we will need to discuss
whether guidance on client calculation of these parameters is necessary
or not. Guidance on things like whether IP headers should be included in
the calculation or not (probably not especially if using TURN for IP
version interworking) as well as how to best represent variable bit rate
traffic may be required (do the parameters represent an expected average
or max or somewhere in-between?).

Regards,
Kevin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Philip Matthews
Sent: Wednesday, March 12, 2008 1:01 PM
To: Behave WG
Cc: Rohan Mahy
Subject: [BEHAVE] TURN: Proposal for the BANDWIDTH attribute

As people may be aware, the text in TURN-07 regarding the BANDWIDTH
attribute is just placeholder text, since I didn't know what a real
solution might look like. I have now talked to a number of people here
at the IETF meeting and I have a serious proposal. I plan to present the
proposal below at the BEHAVE meeting tomorrow.

- Philip

The client MAY include the BANDWIDTH attribute in an Allocate request.
Including the attribute means that the client would like to see the
server do admission control and provide a service guarantee, while not
including the attribute means that the client would like to get best
effort service. The client will generally include the attribute if it
expects to be sending roughly constant rate data (e.g. voice or video),
and will not include it if it expects to send at a variable rate or if
it has no idea of the rate that it will be sending.

When the server receives this request, it responds as follows:
* If the BANDWIDTH attribute was not include, and the server is happy to
provide best-effort service, then the server replies with a success
response.
* If the BANDWIDTH attribute was not include, but the server is not
happy to provide best-effort service, then the server rejects the
request with an error response.
* If the BANDWIDTH attribute was included, and the server can provide
that level of service, then the server replies with a success response.
* If the BANDWIDTH attribute was included, but the server cannot provide
a service guarantee (e.g., it only provides best-effort service), then
the server replies with an error response.
* If the BANDWIDTH attribute was included, and the server can normally
provide a service guarantee, but the client asked for a level of service
(e.g., a Token Bucket Rate) that the server cannot provide at the
current time, then the server replies with a
(different) error response. The server MAY include the BANDWIDTH
attribute in its error response which specifies a level of service that
it could currently provide.

One type of server implementation might provide just best-effort
service, and thus reject any requests containing a BANDWIDTH attribute.
Another type of server implementation might do admission control, and
thus require requests to contain a BANDWIDTH attribute.  
Admission control can be done by simply adding up the Token Bucket Rate
values for all current and requested allocations and making sure that is
less than some maximum value. A server doing admission control may or
may not also do policing; policing requires the server to actually
monitor that the client is sending at or below the rate it specified,
and requires the server to keep a token bucket for each allocation.

My expectation is that TURN servers used for voice or video applications
would do admission control, while TURN servers used for general data
relaying would do best-effort service. At present, I don't know how to
mix these two types of traffic on the same server and still give service
guarantees, but it might be possible and the text above allows this if
the server can do it.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 13 Mar 2008 09:45:18 -0400

On Wed, Mar 12, 2008 at 03:01:23PM -0400,
 Philip Matthews <[email-masked]> wrote 
 a message of 67 lines which said:

> The BANDWIDTH attribute would contain two fields that specify a
> Token Bucket

And why a token bucket and not a leaky bucket (or a way to negotiate
the algorithm)?
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Philip Matthews <[email-masked]>
Date: Thu, 13 Mar 2008 10:20:02 -0400

> And why a token bucket and not a leaky bucket (or a way to negotiate

I am a QoS newbie, so much of this proposal came from discussions  
with other people. In particular, a lot of this proposal came from a  
discussion with Francois Le Faucheur of Cisco, who is considered an  
expert on QoS in RSVP. It was his suggestion that we use a Token  
Bucket algorithm rather than a Leaky Bucket algorithm.

However, if people really care, we could either switch to a Leaky  
Bucket algorithm, or provide the option for doing either.

- Philip

PS. For those interested, Wikipedia has a brief description of the  
differences.

---

From: Philip Matthews <[email-masked]>
Date: Thu, 13 Mar 2008 10:34:08 -0400

Kevin:

Thanks for your input.
See inline.

> about policing then it may be a slight overkill.

Thanks for the pointer to RFC 3890. I was not previously aware of  
this document, and from a quick look it seems very relevant. As I see  
it, we could either stick with my proposal for the two BANDWIDTH  
parameters but use ideas from RFC 3890 to help fill in details, or we  
could switch to the parameters described in RFC 3890.

Right now, I have no option on this point.

> admission control was not performed (maybe a different success code?).

This is an interesting question.
Right now, I am proposing to remove ALTERNATE-SERVER, though this  
issue is still open.
However, there is a question of whether we want to optimize the case  
where a client plans to send voice or video (and thus includes  
BANDWIDTH) but the server supports only best-effort. Right now, the  
client would have to retry without the BANDWIDTH parameter. My  
implicit assumption is that the client would do this only the first  
time it used a server and would then remember this in the future, but  
perhaps it is worthwhile to have a flag that says "I am willing to  
accept best effort if you don't do admission control".

Anyone else have any opinions on this point?

Just as a note, I think that the reverse situation (a client prefers  
best-effort, but is willing to include a BANDWIDTH parameter if  
necessary) is not as important, since I feel that a client that  
prefers best-effort doesn't know what bandwidth to request.

> or max or somewhere in-between?).

Yes, I think we do need to give guidance. I have some ideas, and RFC  
3890 provides others. This proposal is still rough and needs more  
fleshing out.

- Philip

---

From: "Kevin Johns" <[email-masked]>
Date: Thu, 13 Mar 2008 09:33:15 -0600

The advantage of the token bucket is that it better accommodates bursty
traffic whereas a leaky bucket tries to make variable bit rate traffic
look like constant bit rate.

I think the token bucket is a better choice for this as it attempts to
preserve the original stream rate rather then try and make it look like
a constant stream.

Kevin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Philip Matthews
Sent: Thursday, March 13, 2008 8:20 AM
To: Stephane Bortzmeyer
Cc: Behave WG
Subject: Re: [BEHAVE] TURN: Proposal for the BANDWIDTH attribute

On Thu, 13-Mar-08, at 09:45 , Stephane Bortzmeyer wrote:

> On Wed, Mar 12, 2008 at 03:01:23PM -0400,  Philip Matthews 
> <[email-masked]> wrote  a message of 67 lines which said:
>

>> Bucket

I am a QoS newbie, so much of this proposal came from discussions with
other people. In particular, a lot of this proposal came from a
discussion with Francois Le Faucheur of Cisco, who is considered an
expert on QoS in RSVP. It was his suggestion that we use a Token Bucket
algorithm rather than a Leaky Bucket algorithm.

However, if people really care, we could either switch to a Leaky Bucket
algorithm, or provide the option for doing either.

- Philip

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 13 Mar 2008 14:43:52 -0400

On Wed, Mar 12, 2008 at 03:01:23PM -0400,
 Philip Matthews <[email-masked]> wrote 
 a message of 67 lines which said:

> attribute

BTW, this attribute should be renamed CAPACITY, for the reasons
explained in RFC 5136.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 14 Mar 2008 20:20:19 -0400

Does anyone have a serious need for either option that can't be satisfied 
with the other? I'm trying to push back on "we could provide the option for 
doing either" unless someone desperately needs each of the choices.

Thanks,

Spencer

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 21 Mar 2008 12:57:10 -0700

On the topic of the parameter that was formerly known as BANDWIDTH,  
I'm in favor of the moving it to a serrate document.

---

From: Philip Matthews <[email-masked]>
Date: Mon, 24 Mar 2008 11:06:13 -0400

Anyone else have any comments on this, either for or against?
- Philip

---

From: "Derek MacDonald" <[email-masked]>
Date: Mon, 24 Mar 2008 10:30:10 -0700

I would also like to see this moved out into a separate document.

-Derek

---

From: "Kevin Johns" <[email-masked]>
Date: Mon, 24 Mar 2008 16:14:47 -0600

While I don't see a big value gain in this (having optional
functionality in the spec accomplishes the same thing) I am not opposed
to this as it still gives people the choice of functionality and level
of complexity they want in their network.

However, by splitting this off into a separate document we add another
extension to TURN (there are already extensions for IP version
interworking and TCP) which begins to beg the question as to how best to
handle these extensions going forward. Primarily within the main TURN
document (e.g., how does a TURN server not supporting a given extension
handle requests which require a given extension?) we will need to
somehow acknowledge the extensibility of TURN and develop procedures for
how the server (or client) acts upon receipt of a request calling out
functionality which is not supported.

Kevin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Philip Matthews
Sent: Monday, March 24, 2008 9:06 AM
To: Behave WG
Subject: Re: [BEHAVE] TURN: Proposal for the BANDWIDTH attribute

---

From: Lars Eggert <[email-masked]>
Date: Tue, 25 Mar 2008 11:37:25 +0200

> I'm in favor of the moving it to a serrate document.

I'd still like to see it gone, but I can live with being on the rough  
side of the consensus, if that's where I'll end up.

*If* the parameter that was formerly known as BANDWIDTH stays around -  
either in a separate doc or as an OPTIONAL part of the spec - it does  
need an accurate definition. I'd encourage the proponents of keeping  
it around to post such a definition to the list.

Lars

---

From: Lars Eggert <[email-masked]>
Date: Tue, 25 Mar 2008 17:01:17 +0200

Lars

---

From: Philip Matthews <[email-masked]>
Date: Wed, 26 Mar 2008 15:49:35 -0400

Just to be clear: if we split this off, then I will remove it from  
the base TURN specification (except perhaps for a brief mention in  
the document), and it will not be me (at least in the short term) who  
writes the extension document.

So a vote to remove means that you think this is something that is  
not needed right now and could be added later.

- Philip

---

From: Philip Matthews <[email-masked]>
Date: Wed, 26 Mar 2008 15:56:27 -0400

So far, I have three votes to remove this feature, and one vote which  
I interpret as neutral. Please speak up if you have an opinion.

- Philip

---

From: Bruce Lowekamp <[email-masked]>
Date: Wed, 26 Mar 2008 18:11:55 -0400

I think it should be split off.

Regardless of whether it is in the base spec or an extension, I  
suspect the only place it would wind up being used is where a single  
provider deploys both the clients and servers.  Even if it was in the  
base spec, I can't see most implementors adding code for it (and the  
API to pass data to the layer requesting it) unless they have a very  
clear and specific plan for it.

If there are a group of different implementors who have a clear idea  
what to do with it, they should be the ones working on the draft.

Bruce

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 26 Mar 2008 15:38:46 -0700

At Wed, 26 Mar 2008 15:56:27 -0400,
> I interpret as neutral. Please speak up if you have an opinion.

Remove.

-Ekr

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 27 Mar 2008 15:59:52 -0700

> functionality which is not supported.

I completely support this.  I am for removing as much as possible in
TURN so we can finish it (but not mechanisms like ALTERNATE-SERVER that
cannot be added later).  We also need an extension mechanism, something
like SIP Require/Supported.

-- 
Marc Petit-Huguenin           [                                 ]
Home: [email-masked] [RFC1855-compliant space for rent ]
Work: [email-masked]            [                                 ]
[                                                               ]
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Bruce Lowekamp <[email-masked]>
Date: Fri, 28 Mar 2008 09:17:32 -0400

> like SIP Require/Supported.

This is an interesting issue.

I had been thinking that one way to implement this would be to define  
(in the extension doc) two numbers for bandwidth, one comprehension- 
required and another comprehension-optional.  If a client can provide  
a bandwidth estimate, but doesn't demand a reservation, it could  
include the optional attribute.  If a client wants to insist on a  
reservation, it could use the required attribute.  (I guess the other  
way is only to provide the required and let the client retry if it's  
rejected.)

However, I don't see any way in 3489bis for the STUN server to say  
"sorry, I require a bandwidth attribute"  in an error response.  For  
extensibility, should there be a standard error response that  
indicates required attributes?

Bruce

---

From: Philip Matthews <[email-masked]>
Date: Fri, 28 Mar 2008 09:46:07 -0400

>> like SIP Require/Supported.

Personally, I don't feel we need something as complex as Required/ 
Supported, but if you have a couple of simple suggestions that would  
make STUN more extensible, I would be interested in hearing them.

> way is only to provide the required and let the client retry if it's

These ideas sound reasonable to me.

> indicates required attributes?

Why not just define a new error code that means "bandwidth attribute  
required"? This would be in the 4xx class? Clients that don't  
understand this code would simply understand that their request had  
been rejected, while clients that did understand the code have the  
option to retry with the attribute.

- Philip

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 28 Mar 2008 09:35:37 -0700

Philip Matthews wrote:
> Personally, I don't feel we need something as complex as
> Required/Supported, but if you have a couple of simple suggestions that
> would make STUN more extensible, I would be interested in hearing them.
> 

After looking more closely in the SIP Required/Supported mechanism, I
think that most of it is already in STUN in a different form.  A
comprehension-required attribute in a request is equivalent to a Require
option-tag, a comprehension-optional attribute in a request is
equivalent to a Supported option-tag and the 420 STUN response is
equivalent to the 420 SIP response.  Also when a SIP server uses an
extension for a response, it signals it by adding a Require header.
This is equivalent of using a comprehension-required attribute in the
STUN response.

One potential limitation is that the number of extensions possible in
STUN/TURN is limited by the number of attributes possible, where it is
mostly unlimited in SIP.  Because the comprehension-required mechanism
is here from the beginning it will be possible in the future to define a
comprehension-required attribute that contains the equivalent of an
option tag to create an additional namespace for extensions and
establish a IANA registry for it.

There is two additional features that exist in SIP Require/Supported but
that do not have any equivalent in STUN/TURN:

In SIP a 2xx response contains the list of supported extensions.  There
is no equivalent for this (or for the OPTIONS method) in STUN/TURN.

The second feature that does not exist in STUN/TURN, the lack of
equivalent of the 421 SIP response, was explained by Bruce below.  Your
solution, i.e. defining a specific response for each required extension
has the same namespace limitation explained above, but the current
namespace is even more limited.

Now, what I propose:

1.  Do not define an additional namespace for extensions, as the
attribute namespace is big enough for the near future and as it can be
expanded in the future.
2.  Defines a SUPPORTED attribute similar to the UNKNOWN-ATTRIBUTES
attribute that can be added to a 200 response and that list the
attributes supported by the server.
3.  Defines a 421 response with a REQUIRE attribute similar to the
UNKNOWN-ATTRIBUTES that contains the list of mandatory attributes.

(or replace UNKNOWN-ATTRIBUTES, SUPPORTED and REQUIRE by a unique
ATTRIBUTES attribute).

> required"? This would be in the 4xx class? Clients that don't understand
> this code would simply understand that their request had been rejected,
> while clients that did understand the code have the option to retry with
> the attribute.
> 
> - Philip
>

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 28 Mar 2008 12:44:21 -0700

One idea:  for TURN, there is a long-term credential challange/response (see
"Long-term Credential Mechanism" from draft-ietf-behave-rfc3489bis-15).  It
might be useful to consider having TURN extend this so that the first STUN
exchange with the TURN server additionally provide a capabilities exchange:
client: "I have this list of capabilities", server: "I have these
capabilities".

For example, that first STUN request could contain an attribute indicating the
TURN client is only interested in best-effort relaying.  The TURN server could
respond (along with its nonce and what-not, as currently described in
draft-ietf-behave-rfc3489bis) indicating that it will only to know the
bandwidth the client intends on sending towards the TURN server.

-d

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Bruce Lowekamp
> Sent: Friday, March 28, 2008 6:18 AM
> To: Marc Petit-Huguenin
> Cc: Behave WG

---

From: Brian Korver <[email-masked]>
Date: Sat, 29 Mar 2008 16:01:33 -0700

remove it.

-brian
[email-masked]