Subject: [BEHAVE] Summary of TURN open-issues call on Monday, 28 Jan 2008

From: Philip Matthews <[email-masked]>
Date: Mon, 28 Jan 2008 17:06:11 -0500

NOTE: Those on the CC list have action items assigned to them.

TURN open-issues call on Monday, 28 Jan 2008

Attendees:
Philip Matthews
Jonathan Rosenberg
Rohan Mahy
Cullen Jennings
Eric Rescorla
Lars Eggert
Marc Petit-Huguenin
Derek MacDonald
Remi Denis-Courmond
Bob Andreasen

*) Stateful allocation issue: In general, sending an Allocate Request  
on 5-tuple where there is an existing allocation is not allowed;  
instead, to refresh the allocation the client uses the Refresh  
Request.  However, there is the issue that, over UDP, retransmissions  
are allowed. Everyone agrees on the high-level concept, but there  
were some comments about the exact text in the TURN-06 document.
There was a lot of discussion here, which I did not capture. However,  
in the end this seems to boil down to the best way of implementing  
the above high-level intent.
ACTION: Rohan to send proposed text to the mailing list by the end of  
Wed, 30 Jan 2008.

*) Framing for STUN-formatted messages. Rohan did not like the  
decision taken on the 20 Dec 2008 call that STUN-formatted messages  
would not be framed. He argued that we should revert to the way  
things were done in TURN-05. After discussion, a vote was taken and  
everyone except Rohan either said "don't care" or "leave as in TURN-06"
DECISION: STUN-formatted messages will not be framed.

*) Codepoints for new errors. There was the question of what  
codepoints to assign the three new error conditions identified in  
TURN-06. With very little discussion, everyone agreed that using 400  
Bad Request for these cases was fine.
DECISION: Remove this new error codes and use 400 Bad Request instead.

*) Client sending data before the ChannelBind success response  
received. The question was: what should the document say about doing  
this? TURN-06 says the client SHOULD wait, but EKR pointed out that  
the client not doing so does not harm interoperability. The following  
proposal was made:
- The client MAY send before receiving a success response
- The spec will list the pros and cons of not waiting:
	- (Pro) Uses the channel faster
	- (Con) Might result in loss of data because (a) over UDP the  
initial ChannelBind Request might get lost, and (b) the server might  
be unable to allocate the channel
	- (Con) If data is lost, then the app might resend which result in  
much more delay than if the client just waited.
DECISION: The proposal is adopted.

*) Port Adjacency (and related issues). Should an application be able  
to request that the server reserve the "next-highest" port?  A number  
of people had suggested (on the mailing list) that this feature be  
ditched, but others had argued that the feature was needed. In the  
discussions, all those who had argued that the feature be dropped  
were ultimately willing to keep the feature. The following proposal  
was made:
- If the server can honor the request, the next-highest port is  
reserved until allocated (on a separate 5-tuple) via a request for  
that specific port or until the lower-numbered allocation expires.
Philip proposed that a server could simply not implement this  
feature, but many implementors argued that this would make clients  
too complex.
Cullen argued that the mechanism for actually allocating the next- 
highest port allows a client to request an specific port, which he  
does not like.
Rohan noted that the REQUESTED-PORT-PROPS attribute also allows the  
client to request an odd-numbered port.
DECISION: The proposal is adopted and implementing the feature is a  
MUST.
DECISION: The ability to request odd ports will be removed
ACTION: Cullen to propose a new mechanism that avoids his concerns by  
Friday, 1 Feb 2008.

*) Preserving bits in the IP header. When relaying packets, how  
should various IP header bits be set?
There was general agreement that the path between the client and the  
peer should be considered as two distinct connections (client <-->  
server and server <--> peer). However, we were not able to make much  
progress beyond that.
EKR proposed that, as a guiding principle, we should only mandate  
stuff that could be implemented in a userland application that does  
not have special (= root) privileges. Philip pointed out that we can  
divide implementations into two groups: TURN servers running on  
dedicated machines, where root permission and/or a kernel  
implementation might be reasonable; and TURN servers in a peer-to- 
peer environment, where a user-land implementation with no special  
privileges is highly desirable.
There was general agreement on these two points.
However, we were unable to make much progress in deciding what to do  
about specific bits (e.g., the DF bit). A lot of the discussion  
revolved around what the existing APIs allow an application to do.
The discussion then moved to discussing packets that exceed the MTU  
and how to handle this case, as this situation is highly affected by  
how IP header bits are set. However, we were still unable to find a  
good solution to this case.
ACTIONS:
	- Remi will research what can and cannot be done with existing Linux  
APIs.
	- EKR will research what can and cannot be done with existing BSD  
and MacOS APIs.
	- Derek will research what can and cannot be done with existing  
Windows APIs.
	- Philip will research what SOCKS (version 5.1) and IP-in-IP  
tunneling says about this problem.

At this point, time ran out, and a decision was made to try to  
schedule a second call during the week of Feb 4th.
ACTION: Philip to poll attendees for times they can make a second call.

- Philip

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

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 29 Jan 2008 11:31:19 +0100

With my individual hat on!

Philip Matthews skrev:
> 
> *) Preserving bits in the IP header. When relaying packets, how should 
> various IP header bits be set?

I personally don't agree with this characterization when it comes to UDP 
on both legs. Because in this case unless you threat this as a single 
end to end path that are bounced of an reflector, the TURN server will 
be required to resolve for example the UDP congestion control problems 
between the server and its peers. It also will need QoS reservation and 
path MTU discovery signalling interfaces. The amount of information that 
needs to be sent between the TURN client and the Turn server for each 
packet will be significantly increased.

Even in the case of TCP -> UDP is problematic. I don't see your 
agreement to work in the real world.

> EKR proposed that, as a guiding principle, we should only mandate stuff 
> that could be implemented in a userland application that does not have 
> special (= root) privileges. 

I think this requirement may result in that no solutions exist with most 
current operating systems.

Philip pointed out that we can divide
> implementations into two groups: TURN servers running on dedicated 
> machines, where root permission and/or a kernel implementation might be 
> reasonable; and TURN servers in a peer-to-peer environment, where a 
> user-land implementation with no special privileges is highly desirable.
> about specific bits (e.g., the DF bit). A lot of the discussion revolved 
> around what the existing APIs allow an application to do.
> The discussion then moved to discussing packets that exceed the MTU and 
> how to handle this case, as this situation is highly affected by how IP 
> header bits are set. However, we were still unable to find a good 
> solution to this case.
> ACTIONS:

I do understand the desire to not require kernal land or otherwise 
privileged implementations but if that is the only way of ensuring that 
things are done correctly, then they are that.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------