1 / 14

TURN

TURN. Jonathan Rosenberg Cisco. Status. Design team formed around getting TURN in shape for WGLC Myself, Dan Wing, Rohan Mahy, Philip Matthews Had calls 2-3 times a week since beginning of September Worked on addressing list comments and other lingering issues i.e., active destinations.

nelson
Télécharger la présentation

TURN

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. TURN Jonathan Rosenberg Cisco

  2. Status • Design team formed around getting TURN in shape for WGLC • Myself, Dan Wing, Rohan Mahy, Philip Matthews • Had calls 2-3 times a week since beginning of September • Worked on addressing list comments and other lingering issues • i.e., active destinations

  3. Changes • TCP allocations removed • Buffering/congestion control issues • IESG guidance: needs to be made general purpose • Added channel concept • Allowed us to remove active destination concept • Basically allows a large number of ‘active’ destinations

  4. 16 bit length, 16 bit channel # Using length adds consistency with TCP Desire for 32 bit alignment Want enough channel #s ALL data between client and TURN server starts with header TURN data Unencapsulated data Channel 0 used for TURN Other channels explicitly allocated Channels Channel # Length TURN message or Application data

  5. Channel #’s independent in each direction Each channel bound to a specific remote IP/port Send and Data indications include channel #s Receipt of Send or Data indication triggers ChannelConf Client (or server) can send unencapsulated after ChannelConf No way to deallocate channels Not likely to run out – adds complexty to support dealloc Channel Allocation Send (alloc channel=7) 0 0 ChannelConf (channel=7) Data 7 Client Server

  6. Other Models Considered • Separate ChannelBind transaction in each direction • Con: requires client to implement server transaction machine • Con: more inefficient for video to non-ICE peers • Single channel number, allocated by client using ChannelBind transaction • Could work, not necessarily simpler • Use of transaction rather than indication means it can take longer to get to unencapsulated data

  7. Changes Contd • TURN on its own port now • Required due to framing • Removed set active destination  • New Refresh method rather than new Allocation • Refresh fails if allocation doesn’t exist • Why? Client needs to know if allocation is dead or not since channel bindings linked to allocation

  8. Changes Cont’d • SRV changes based on DNS directorate review • _turns._tcp instead of _turn._tls • REMOTE_ADDRESS renamed to PEER_ADDRESS • Removed move feature • Concerns about us doing a mobility protocol with only one part of what mobility protocols do (binding update) • Can be added later as an extension • Elected not to add v6/v4 translation • Prefer to keep base TURN thin and address as an extension

  9. Changes Cont’d • NAT Reboot case unaddressed • Not clear this is a real issue • Documents problem that after reboot you might get someone elses binding – not TURN specific • RELAY_ADDRESS and PEER_ADDRESS use xor-mapped format • Terminology: “peer” as the thing on the other side of TURN server

  10. Open Issue #1: Bandwidth param • Currently very underspecified • What does server do if media is in excess? • How is bandwidth defined? Leaky bucket? • What it is used for by server? • Purpose was to help do load management • Alternative model: random load balancing and monitor capacity so you always have enough • Is anyone using this or plan to? Would like to remove

  11. Server needs to accept Allocate retransmits but reject new Allocate transactions Implies that server has to be transaction stateful Is this OK? Open Issue #2: Stateful Alloc Alloc OK Alloc 487 Alloc OK retransmit Alloc 487

  12. Open Issue #3: Address vs. Address and Port Restriction • EKRs proposal yesterday • Pro • If TURN server is address and port restricted, we can eliminate Send and Data indications entirely • Cons • Causes use of two TURN servers in many common cases • Need to drop or buffer 1xRTT worth of data until Channel Allocation transaction completes. More a problem for video to non-ICE peers. • Propose to keep current model

  13. Open Issue #4: Port Adjacency • Current text says server can accept adjacency request but not honor it, and thus subsequent odd request is rejected • Propose that • Request accepted only if odd higher port is allocated • Server holds it for 30 seconds

  14. Open Issue #5: Port numbers • Current spec says: • The server SHOULD only allocate ports in the range 1024-65535 • Derek wants a MUST • Note that, it is not this restriction which prevents running a mail or DNS server • Main reason would be to avoid confusing middleboxes making assumptions on service associated with port number • Proposal: keep SHOULD

More Related