Subject: [BEHAVE] AD comments on draft-ietf-behave-turn-tcp-05

From: Magnus Westerlund <[email-masked]>
Date: Fri, 22 Jan 2010 17:04:44 +0100

Hi,

I have reviewed the TURN TCP document and have the following comments.

1. Section 3.4 and 5.2, if the Turn server takes time to complete the
Connect request, can additional connect or other TURN requests be issued
with one connect request outstanding?

2. Section 5.2: Any consideration for timeout for the TCP connection
attempt from the server? Is that purely a server implementation choice?
Some minimal value the client can expect? Maybe a option to specify a
timeout for the client would be appropriate here?

3. Section 5.2: Why is the initial data buffered? Isn't it better to not
read from the socket until its peer TCP connection is available. That
way the stream will not advance until the data can be forwarded. Here
some implementation experience would be good to capture.

4. Section 5.3, shouldn't the connection attempt be checked against the
permissions before being accepted?

5. Section 5.5, what about data sent to the server? I assume that the
peer expects that data is sent prior to closing the server to client
connection.

6. Section 6.4 and 6.5 I expect to be section 7 and 8.

I will expect a revised ID.

Cheers

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Simon Perreault <[email-masked]>
Date: Mon, 25 Jan 2010 12:34:30 +0900

> with one connect request outstanding?

Yes. As with any other STUN/TURN request, processing multiple requests in
parallel is allowed. The Connect request is special in that its processing
involves reaching across the Internet, but this is orthogonal.

Do you think it need to be mentioned explicitly?

> timeout for the client would be appropriate here?

Good thinking, thanks.

However, there are many other timeouts involved in the TCP state machine. I
don't expect the client to have control over all of them. Is the connection
timeout important enough to give control over it to the client?

I don't think client control over TCP timeouts is important given the expected
use cases for TURN.

The upper limit of the connection timeout can already be controlled by clients.
They can just close their connection to the server when it starts taking too
long. (Does this need to be mentioned explicitly?)

For the lower limit, how about mentioning that servers MUST ensure at least 10
seconds before connection timeout?

> way the stream will not advance until the data can be forwarded.

Whether data is buffered in kernel or user space is irrelevant from the point of
view of the protocol. It's an implementation detail.

> permissions before being accepted?

Yes and no.

The server needs to check permissions. This is an omission in section 5.3. It is
a big error that needs to be fixed. Thanks for noticing it.

However, the permission check needs to happen after the connection is accepted
but before the ConnectionAttempt indication is sent to the client. This is so
because a user-space implementation cannot know the identity of the peer before
calling accept(). So we accept the connection, then drop it if it fails the
permission check.

(I recall explaining this on [email-masked], so I wonder why this text isn't
already in the draft...)

> peer expects that data is sent prior to closing the server to client

Yes. In all three cases in section 5.5, the server needs to ensure that the
connection it is about to close is flushed. I will add text to this effect.
Thanks for noticing this.

> 6. Section 6.4 and 6.5 I expect to be section 7 and 8.

Yes.

> I will expect a revised ID.

I will produce one based on the output of this discussion.

Thanks,
Simon
-- 
DNS64 open-source   --> http://ecdysis.viagenie.ca
STUN/TURN server    --> http://numb.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org