Subject: [BEHAVE] TURN: technical review by September 1

From: "Dan Wing" <[email-masked]>
Date: Mon, 30 Jul 2007 10:26:38 -0700

In Chicago at IETF-69 we explained the urgency around rfc3489bis ("STUNbis")
and TURN.  ICE needs to be published at the same time as rfc3489bis and TURN
because ICE normatively references those documents.  Rfc3489bis underwent
substantial revision between -06 and -08, and I just WGLC'd rfc3489bis-08 a
few minutes ago.  However, TURN is not yet ready to be WGLC'd.

We need technical review of draft-ietf-behave-turn-04
(http://tools.ietf.org/html/draft-ietf-behave-turn-04) especially by server
implementers and client implementers.  Thanks to our technical reviewing
volunteers, Francois Audet, Rémi Denis-Courmont, Alan Hawrlylshen, Alfred E.
Heggestad, Brian Hibbard, and Marc Petit-Huguenin.  Additional technical
reviewers are welcome!

Technical reviews are due by September 1.  During this technical review
please concentrate on deficiencies with the protocol (previously we have had
questions raised around framing, operation, and the authorization model),
difficulties in implementation, and conceptual flow and ease of
understanding the document itself.  Please refrain from mentioning
capitalization or spelling errors; these are expected to be corrected by the
authors during the creation of -05.  Please send your technical review to
the TURN authors (CC'd on this message) or to the BEHAVE mailing list.  

The first week of September a team will begin editing the document and will
submit TURN-05 the first of week October.  I expect that TURN-05 will be
WGLC'd.

-d

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

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 31 Jul 2007 12:16:18 +0300

Hey,

Rohan pointed out that congestion handling when there are multiple TCP 
sessions to remote peers was an open issue.

As far as I can tell, there is NO WAY to solve this, so long as we use a 
single TCP session between the client and the TURN server. It is inherent to 
how TCP works, and is the exact same issue that MSRP relays have. Regardless 
whether that breaks forking, I really think we simply cannot do that 
properly.

Take this scenario:

TURN client <-- TCP_C --> TURN server <-- TCP_A --> Peer A
                                      <-- TCP_B --> Peer B

Now consider that TCP_B session gets congested. At some point, TURN server 
output buffer for TCP_B gets full. Now so long as the client only sends data 
to peer A, every thing is fine. But if the client sends data to peer B, the 
TURN server gets stuck.

At this point, the server really can only do one of three things:
(1) queue an indefinitely big amount of data,
(2) stop dequeing data from the TURN client until TCP_B gets "decongested",
(3) drop data for B, and reset/timeout connection with B.

(1) is basically what MSRP does. Im my humble opinion, it is utterly broken; 
and I think we agreed this was not the way to go.

(2) is flawed, as communication between client and peer A will be unduly 
disrupted. It is an obvious security issue if A and B do not trust each 
others. Even then, it is probably unacceptable: if say, B looses connectivity 
for some reason, the flow to A will be totally disrupted until TCP_B 
connection times out. There are similar problem if connectivity to B is much 
slower or less reliable than that to A.

(3) has similar problems, though mirrored. Say we have a forked MSRP file 
transfer from client to peers. If the client knew the "bandwidth quotient" 
between A and B, it could send data to each at appropriate speed. But it does 
not, so the connection to B will fail, and only A will receive the file.

This is all the same problem as with MSRP: one cannot multiplex multiple TCP 
sessions on a single TCP session, not directly. I am not an IETF congestion 
control expert, but it all comes down to the need for the TURN client to 
maintain separate congestion control for each peers.

And then, there is the separate issue of how do we not turn this multiple 
connections "feature" into an open port service, which would allow running 
servers from behind a TURN relay.

-- 
Rémi Denis-Courmont

---

From: "Alfred E. Heggestad" <[email-masked]>
Date: Tue, 31 Jul 2007 21:17:05 +0200

Hi

I would agree with Rémi, that multiple peers per TURN client is a complex
scenario and I think the use-case for this must be reviewed.

The "Connection Status Indication" and the CONNECT_STAT attribute can only
indicate status of one (1) connection, and there is no way of mapping which
connection is indicated. This means that TCP connections can only be setup
one at a time.

I do not see a real use-case for multiple TCP/UDP peers per TURN client,
so my apologies if there are already many good use-cases for this, but I
think that TURN can be made much simpler if we only allow one peer per
TURN client. If a User-Agent wants two "channels", he can just start
two different TURN clients on the same host, but listening on different
ports.

/alfred

---

From: "Evgeniy Khramtsov" <[email-masked]>
Date: Wed, 1 Aug 2007 08:51:27 +1000

> two different TURN clients on the same host, but listening on different

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