TURN TCP

1
TURN TCP

• Rohan Mahy
• rohan_at_ekabal.com

2
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,
  especiallywhen using multiple peers.
• Most users are not using TCP peers anyway

3
More on blocking / fair sharing
window full, connection stalled
stop reading in caseincoming data is forpeer 1.
peer 2 data waits
Peer 1
TURN Server
TURN Client
Peer 2
empty pipe, blocked by peer 1
Peer 1
fast peer 1 takes more than its fair shareof
slow link
fast link
TURN Server
TURN Client
slow link
slow link
Peer 2
4
Some proposals design team discussed

• Ignore problem during setup, transition to single
  peer.
• Dont 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 dont send data
  past the ltngtth octet quota. Quota gets updated
  when window is at least half empty.
• Only allow one TCP peer per connection to client
• Dont 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.

5
Pros and Cons

• One-peer per client connection
• 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.
• Cons
• 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

6
Next Steps

• Agree on whats important about end result
• Fill out possible approaches more fully
• Get volunteers
• Compare the approaches that look promising