Turn tcp
This presentation is the property of its rightful owner.
Sponsored Links
1 / 6

TURN TCP PowerPoint PPT Presentation


  • 72 Views
  • Uploaded on
  • Presentation posted in: General

TURN TCP. Rohan Mahy [email protected] 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.

Download Presentation

TURN TCP

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Turn tcp

TURN TCP

Rohan Mahy

[email protected]


Why split out tcp peers from turn

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


More on blocking fair sharing

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


Some proposals design team discussed

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.


Pros and cons

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


Next steps

Next Steps

  • Agree on what’s important about end result

  • Fill out possible approaches more fully

  • Get volunteers

  • Compare the approaches that look promising


  • Login