1. Rohan Mahy rohan@ekabal.com
TURN TCP
Rohan Mahy

2. Why do we care again?
ICE-tcp and TURN-tcp very troubled documents – can we just drop them?
Major customers:
P2psip
TOTE (new)
Mediactrl (coming soon)
Whiteboarding (eventually)
So we need to work this!

3. Why split out TCP peers from TURN?
Head of line blocking problem and fair sharing
No consensus on best way to solve this problem. Need more consensus on requirements.
Transport Area asked us to make the protocol more robust and more general.
Lots of folks using STUN in ways we did not imagine. TURN likely to go same way. Could be used by HIP.
Not much thought about TCP error cases, especially when using multiple peers.
Most users are not using TCP peers anyway

4. More on blocking / fair sharing
window full,
connection stalled
stop reading in case incoming data is for peer 1. peer 2 data waits
Peer 1
TURN
Server
TURN
Client
empty pipe, blocked by peer 1
Peer 2
Peer 1
fast peer 1 takes more than its fair share of slow link
fast link
TURN
Server
TURN
Client
slow link
slow link
Peer 2

5. Some proposals design team discussed
Ignore problem during setup, transition to single peer.
Don’t send enough data to block the other peer. Ditch all but one peer before sending bulk data.
Transport ADs did not like this because it is not general, and it is impossible to enforce this.
Do full blown SSH-style per-channel windowing (TCP on top of application layer)
Convey per-peer window quotas
Similar to ssh per-channel sliding windows.
Each channel has a per-direction “don’t send data past the <n>th octet” quota. Quota gets updated when window is at least half empty.
Only allow one TCP peer per connection to client
Don’t accept additional peer TCP connections. Send an indication that incoming request is waiting, client can open connection to TURN server, request the same allocation, and connect to the new peer.
There could be many more.

6. Pros and Cons One-peer per client connection Per-peer window quotas
Pro: conceptually easy to understand
Cons:
breaks one flow per allocation assumption
adds an extra RTT of delay before exchanging data with an additional TCP peer. How often will this happen?
Per-peer window quotas
Pro: probably still simpler than SSH.
unproven: complex and requires a lot of modeling or experimental data to see if it will work
adds unknown amount of overhead
Impossible to evaluate without a consensus on requirements

7. Next Steps Agree on what’s important about end result
Fill out possible approaches more fully
Get volunteers
Compare the approaches that look promising