Subject: [BEHAVE] TURN: Removing Preserving Allocations from the Base Specification

From: Philip Matthews <[email-masked]>
Date: Tue, 29 Jul 2008 13:41:36 -0400

At the BEHAVE session today, the WG voted to move the text on  
preserving allocations to a separate extension draft. This e-mail is  
an attempt to come to agreement on exactly what is meant by that  
decision.

The text in TURN-09 around preserving allocations is divided into  
three parts:

a) Text around the P bit, which is used to request a preserving  
allocation. This text describes where the P bit is located, how a  
client can set the bit, and what a server does when it receives an  
Allocate request with this bit set. Most of this text is general,  
defining how REQUESTED-PROPS is a set of one-bit flags that are used  
to request special properties of the allocation.

b) Tezt about how various fields in the IP header are handled. These  
fields are DSCP, ECN, TTL, Flow Label, the fragmentation fields, IPv4  
options, and IPv6 extensions. For each of these fields, the text  
describes a preferred behavior and an alternate behavior. A preserving  
allocation MUST implement the preferred behavior. A non-preserving  
allocation SHOULD implement the preferred behavior, but if that is not  
possible, then it SHOULD implement the alternate behavior. The text  
was structured in this way because investigation showed that what can  
be done in userland without special privileges varies from OS to OS.  
For example, the preferred behavior for the DSCP field is to preserve  
it, but if that is not possible because there is no way to read the  
DSCP field on an incoming packet, then the alternate behavior is to  
set it to Best Effort.

c) Text on how to do relaying of ICMP messages. For example, this text  
describes how to send a special Data indication to the client that  
contains the ICMP message received in the direction towards the peer.

So I see the following options on how to implement the wishes of the WG:

1) Remove just part (c), which is the most complex and likely most  
problematical aspect of preserving allocations. A preserving  
allocation would be redefined to be "MUST do the preferred behavior of  
(b), but without the ICMP relaying part. The extension document would  
define a new flag for allocations that also do ICMP relaying.

2) Remove parts (a) and (c). All allocations would be non-preserving.  
Non-preserving allocations would still say "SHOULD implement the  
preferred behavior, and if not possible, SHOULD implement alternate  
behavior".

3) Remove parts (a) and (c), and rewrite (b) to only contain the  
alternate behavior for each field. The text would say that non- 
preserving allocations SHOULD implement the alternative behavior. The  
extension document would define the preferred behavior and say that  
preserving allocations MUST implement the preferred behavior.  As a  
result, non-preserving allocations would never do the preferred  
behavior.

4) Remove parts (a), (b), and (c) and leave it undefined how servers  
set these IP header fields.

I think that option (2) is the one that makes the most sense.  In my  
opinion, the preferred behaviors listed in TURN-09 are not very  
controversial.

All this assumes that we DO NOT decide to add IPv4 to IPv6 relaying to  
the base specification (which is another open issue). If we add IPv4  
to IPv6 relaying, then the preferred and alternate behaviors will  
become more complex and more-or-less duplicate aspects of the NAT64 /  
NAT6 discussion.

Comments?

- Philip

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 30 Jul 2008 05:48:56 -0400

Philip,

I think this is really almost an editorial issue here. We agreed to 
remove the preserving behavior. That includes the ICMP treatment and all 
of the IP header field treatment. We need to document the non-preserving 
behavior only, which is relatively easy since there is not much there to 
say. So really, we need to leave only sufficient negotiation 
capabilities to allow it to be added later. We can use negotiation on 
the bits in the requested props header, which was what is in there now, 
or else use a new attribute in the mandatory space. Frankly the latter 
is my preference as it means we only need a single negotiation mechanism 
and not two.

-Jonathan R.

Philip Matthews wrote:
> At the BEHAVE session today, the WG voted to move the text on preserving 
> allocations to a separate extension draft. This e-mail is an attempt to 
> come to agreement on exactly what is meant by that decision.
> 
> The text in TURN-09 around preserving allocations is divided into three 
> parts:
> 
> allocation. This text describes where the P bit is located, how a client 
> can set the bit, and what a server does when it receives an Allocate 
> request with this bit set. Most of this text is general, defining how 
> REQUESTED-PROPS is a set of one-bit flags that are used to request 
> special properties of the allocation.
> 
> possible, then it SHOULD implement the alternate behavior. The text was 
> structured in this way because investigation showed that what can be 
> done in userland without special privileges varies from OS to OS. For 
> example, the preferred behavior for the DSCP field is to preserve it, 
> but if that is not possible because there is no way to read the DSCP 
> field on an incoming packet, then the alternate behavior is to set it to 
> Best Effort.
> 
> problematical aspect of preserving allocations. A preserving allocation 
> would be redefined to be "MUST do the preferred behavior of (b), but 
> without the ICMP relaying part. The extension document would define a 
> new flag for allocations that also do ICMP relaying.
> 
> alternate behavior for each field. The text would say that 
> non-preserving allocations SHOULD implement the alternative behavior. 
> The extension document would define the preferred behavior and say that 
> result, non-preserving allocations would never do the preferred behavior.
> 
> 4) Remove parts (a), (b), and (c) and leave it undefined how servers set 
> these IP header fields.
> 
> 
> the base specification (which is another open issue). If we add IPv4 to 
> IPv6 relaying, then the preferred and alternate behaviors will become 
> more complex and more-or-less duplicate aspects of the NAT64 / NAT6 
> discussion.
> 
> Comments?
> 
> - Philip
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 30 Jul 2008 06:03:46 -0400

Philip,

-Jonathan R.

---

From: Philip Matthews <[email-masked]>
Date: Wed, 30 Jul 2008 10:38:36 -0400

So are you happy with option 2 as the solution?

Why do you dislike the REQUESTED-PROPS attribute? It allows you to  
negotiate a new feature of an allocation using only one bit, rather  
than 8 bytes plus new error code, etc.

- Philip

On Wed, 30-Jul-08, at 05:48 , Jonathan Rosenberg wrote:
> remove the preserving behavior. That includes the ICMP treatment and  
> all of the IP header field treatment. We need to document the non- 
> preserving behavior only, which is relatively easy since there is  
> not much there to say. So really, we need to leave only sufficient  
> negotiation capabilities to allow it to be added later. We can use  
> negotiation on the bits in the requested props header, which was  
> what is in there now, or else use a new attribute in the mandatory  
> space. Frankly the latter is my preference as it means we only need  
> a single negotiation mechanism and not two.
>
> -Jonathan R.
>
> Philip Matthews wrote:
>> preserving allocations to a separate extension draft. This e-mail  
>> is an attempt to come to agreement on exactly what is meant by that  
>> decision.
>> defining how REQUESTED-PROPS is a set of one-bit flags that are  
>> used to request special properties of the allocation.
>> b) Tezt about how various fields in the IP header are handled.  
>> These fields are DSCP, ECN, TTL, Flow Label, the fragmentation  
>> fields, IPv4 options, and IPv6 extensions. For each of these  
>> fields, the text describes a preferred behavior and an alternate  
>> behavior. A preserving allocation MUST implement the preferred  
>> behavior. A non-preserving allocation SHOULD implement the  
>> preferred behavior, but if that is not possible, then it SHOULD  
>> implement the alternate behavior. The text was structured in this  
>> way because investigation showed that what can be done in userland  
>> without special privileges varies from OS to OS. For example, the  
>> preferred behavior for the DSCP field is to preserve it, but if  
>> that is not possible because there is no way to read the DSCP field  
>> on an incoming packet, then the alternate behavior is to set it to  
>> Best Effort.
>> c) Text on how to do relaying of ICMP messages. For example, this  
>> text describes how to send a special Data indication to the client  
>> that contains the ICMP message received in the direction towards  
>> the peer.
>> allocation would be redefined to be "MUST do the preferred behavior  
>> of (b), but without the ICMP relaying part. The extension document  
>> would define a new flag for allocations that also do ICMP relaying.
>> 2) Remove parts (a) and (c). All allocations would be non- 
>> preserving. Non-preserving allocations would still say "SHOULD  
>> implement the preferred behavior, and if not possible, SHOULD  
>> implement alternate behavior".
>> preserving allocations SHOULD implement the alternative behavior.  
>> The extension document would define the preferred behavior and say  
>> that preserving allocations MUST implement the preferred behavior.   
>> As a result, non-preserving allocations would never do the  
>> preferred behavior.
>> 4) Remove parts (a), (b), and (c) and leave it undefined how  
>> servers set these IP header fields.
>> I think that option (2) is the one that makes the most sense.  In  
>> my opinion, the preferred behaviors listed in TURN-09 are not very  
>> controversial.
>> All this assumes that we DO NOT decide to add IPv4 to IPv6 relaying  
>> to the base specification (which is another open issue). If we add  
>> IPv4 to IPv6 relaying, then the preferred and alternate behaviors  
>> will become more complex and more-or-less duplicate aspects of the  
>> NAT64 / NAT6 discussion.
>> Comments?
>> - Philip

---

From: Simon Perreault <[email-masked]>
Date: Wed, 30 Jul 2008 15:48:40 +0100

Philip Matthews wrote:
> negotiate a new feature of an allocation using only one bit, rather than 
> 8 bytes plus new error code, etc.

Does this have any significance?

Also, what do you mean by "new error code"? The server would just return 
a 420 (Unknow Attribute), as usual. This is not new.

I also prefer using a new comprehension-required attribute for the same 
reason as previously given. ("[...] it means we only need a single 
negotiation mechanism and not two.")
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 30 Jul 2008 15:55:16 +0100

> negotiation mechanism and not two.")

An additional problem with REQUESTED-PROPS is that it does not specify a
registry to define additional bits.  OTOH using only one bit instead of
8 bytes is nice.

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

---

From: Philip Matthews <[email-masked]>
Date: Wed, 30 Jul 2008 10:57:15 -0400

On Wed, 30-Jul-08, at 10:48 , Simon Perreault wrote:
> Also, what do you mean by "new error code"? The server would just  
> return a 420 (Unknow Attribute), as usual. This is not new.

With this approach, if you requested two or more new features, you  
would get back 420 and not know what part of the request failed.
With REQUESTED-PROPS, if the server cannot satisfy your request, you  
get back a REQUESTED-PROPS attribute with all supported bits set to 1.

>
>
> I also prefer using a new comprehension-required attribute for the  
> same reason as previously given. ("[...] it means we only need a  
> single negotiation mechanism and not two.")

---

From: Philip Matthews <[email-masked]>
Date: Wed, 30 Jul 2008 10:58:42 -0400

On Wed, 30-Jul-08, at 10:55 , Marc Petit-Huguenin wrote:
>> return
>> same
> registry to define additional bits.

Good point.
An oversight on my part.
Could be easily added to the IANA section though.

>  OTOH using only one bit instead of
> 8 bytes is nice.

This was my motivation for adding it.

---

From: Simon Perreault <[email-masked]>
Date: Wed, 30 Jul 2008 16:07:29 +0100

Philip Matthews wrote:
> With this approach, if you requested two or more new features, you would 
> get back 420 and not know what part of the request failed.

No, because it's right there in the UNKNOWN-ATTRIBUTES attribute 
returned by the server.

(Assuming you use one attribute per "feature".)

-- 
Please try Numb, a STUN/TURN server implementation.
Free access at http://numb.viagenie.ca/.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Philip Matthews <[email-masked]>
Date: Wed, 30 Jul 2008 22:01:47 -0400

Jonathan and I discussed my e-mail (below) in a phone call and agreed  
between the two of us to do option (3), instead of my original  
proposal of option (2).
Unless there is an objection, this is what we plan to do for the next  
TURN revision.

The text removed will be placed in a new I-D which we will request the  
WG to adopt as a WG item.

- Philip

On Tue, 29-Jul-08, at 13:41 , Philip Matthews wrote:
> fields are DSCP, ECN, TTL, Flow Label, the fragmentation fields,  
> IPv4 options, and IPv6 extensions. For each of these fields, the  
> text describes a preferred behavior and an alternate behavior. A  
> preserving allocation MUST implement the preferred behavior. A non- 
> preserving allocation SHOULD implement the preferred behavior, but  
> if that is not possible, then it SHOULD implement the alternate  
> behavior. The text was structured in this way because investigation  
> showed that what can be done in userland without special privileges  
> varies from OS to OS. For example, the preferred behavior for the  
> DSCP field is to preserve it, but if that is not possible because  
> there is no way to read the DSCP field on an incoming packet, then  
> the alternate behavior is to set it to Best Effort.
>
> that contains the ICMP message received in the direction towards the  
> peer.
>
>
> As a result, non-preserving allocations would never do the preferred  
> behavior.
>