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

[Simon Perreault <[e-mail]>]

Magnus Westerlund wrote, on 23/01/10 01:04 AM:
> 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?

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?

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

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?

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

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

> 4. Section 5.3, shouldn't the connection attempt be checked against the
> 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 [e-mail], so I wonder why this text isn't
already in the draft...)

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

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