Subject: [BEHAVE] Comments on draft-ietf-behave-turn-04

From: Brian Hibbard <[email-masked]>
Date: Fri, 31 Aug 2007 17:38:53 -0500

TCP
------
I'm unclear on exactly how the TCP Connect request is supposed to  
work.  I noticed that there is nothing in TURN-04 that says how an  
allocation enters LISTEN, although previous versions stated that an  
allocation would enter LISTEN at the time of allocation.

If the intent is that simultaneous open is the sole means by which  
allocations can connect to each other, I have a difficult time  
believing this is feasible.  In order for that to work as true  
simultaneous open, the SYNs must cross on the wire. Assuming a BSD- 
ish implementation, if they don't cross on the wire, you have the  
possibility that a SYN will be received on a socket that is still in  
the CLOSED pseudo-state.    On Mac OSX, the SYN received in CLOSED  
(socket is bound but not listen()ing ) is silently absorbed and both  
sides will retransmit until something that looks similar to  
simultaneous open happens.  On Linux, when SYN is received in CLOSED  
(as before--bound but not listening), an RST is transmitted, and the  
connection attempt is terminated.   Unless there is some means  
outside of TURN  to guarantee that Connect requests are sent such  
that SYNs literally cross on the wire (so that both receivers are in  
SYN_SENT and not CLOSED), I don't see how you can expect that  
mechanism to work well.  Of course, there are things one might do to  
suppress the RST so SYN retransmissions might occur, but an RST to a  
SYN received in CLOSED doesn't sound wrong to me.

Therefore, it looks better to establish a good way to manage whether  
an allocation is LISTENing, or that it is actively connecting, and  
that it is not doing both simultaneously.  Previously on the BEHAVE  
list, a way to do both was brought up, but, while interesting, sounds  
like an exploit and forces an implementation into the dark nether  
regions of platform-specific behavior.  The fact that  the socket API  
doesn't allow a bind() if a socket is already listen()ing is  
something TURN should respect.  Besides, most clients that get  
retrofitted with TURN probably want to treat TURN as a shim in their  
transports to the greatest extent possible, and won't be interested  
in building a bunch of special behavior around TURN's peculiar LISTEN- 
while-Connect-request capability even if you did manage to solve that  
issue.  Those implementations would simply grab a new port when they  
want to make a new connection--just like how everyone does today.

Also, multiplexing traffic across multiple TCP connections within a  
single allocation has been brought up on the list before.  I agree  
that it would be powerful and desirable to do that...if you could do  
it properly.  It's the "properly" part that scares me.  I think there  
is a class of use cases that this mechanism could support well.  Such  
cases would be where only one of the connections is sending "lots" of  
traffic, and the other(s) are sending "little".   (Ignore, for the  
time being, how the TURN server would distinguish this subset of  
possibilities and allow them while suppressing the others a priori.)  
This presumes that we have a good way to adjudicate BANDWIDTH control.

 From the spec, it sounds like BANDWIDTH is meant to cap the traffic  
on the allocation.  Is this for the sum off all permissions, and in  
both directions?  Exactly what the TURN server does to constrain this  
traffic hasn't been addressed.  Discarding chunks of data in TCP  
could cause a painful loss of framing for higher level protocols,  
such as SIP.   The only other options that are obvious are to  
throttle reading from the client and all of the allocation's peer  
connections and let TCP manage the congestion, or tear down with  
RST.   Exactly how you divide the bandwidth between reading each of  
the connections involved needs a lot of discussion.  It would be  
terrible if the media stream starved the signaling stream, and TURN  
can't tell the difference.

Therefore, I would be greatly relieved if multiple TCP connections on  
a single allocation were not supported.

Set Active Destination
----------------------------------
For UDP, it would be reasonable to suggest that the client start  
using Send indications shortly before (perhaps as long as one  
second?) sending a Set Active Destination request to clear the  
current active destination.  This would help the case that some of  
the packets sent prior to the SAD are processed by the server after  
the SAD is processed, due to packet ordering.

Thanks,

Brian Hibbard
Estacado Systems

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