TURNdraft-ietf-behave-turn-07

Philip Matthews, Avaya

Jonathan Rosenberg, Cisco

Rohan Mahy, Plantronics

What New?

• Two revisions (-06 and -07) since last meeting.

• Long list of changes in each revision.– See change list in document for details

• For time reasons, will focus on Open Issues first, and Major Changes second.

IP Header Bits (1)• New proposal (with JDR, Magnus, Lars)• Two types of allocations when doing UDP-to-

UDP relaying• “Fully-compliant”:

– Preserves ECN, DSCP, DF bits– Decrements TTL– Relays ICMP messages (TBD)– Think “RAW sockets or kernel implementation”

• “Partly-compliant” :– Does not do one or more of above.– Think “unprivileged user-space implementation”

IP Header Bits (2)• If the client requests a “fully-compliant”

allocation (using a new flag in the REQUESTED-PROPS attribute), then server must reject Allocate request if it can not satisfy the request.

• TCP-UDP relaying has less-stringent requirements (i.e., something easily implementable in user-space).

IP Header Bits (3)• Document will give guidance on when a

client should use a “fully-compliant” allocation. For example, when app:– Wants to use ECN, or– Requires a “proper” DSCP along the entire

path, or– Wants to use RFC1191-style PMTUD, or– Wants to use RFC4821-style PMTUD and

needs to discover the real MTU• If RFC4821-style PMTUD is used with a partly-

compliant allocation, then the value discovered may not be the true MTU.

ALTERNATE-SERVER (1)• TURN-05/-06:

– Attribute only allowed with 300 “Try Alternate” error response.

• No way to find out what real error code was– Required “positive knowledge” condition would not

occur on alternate server. • To avoid redirect loops

• TURN-07:– Attribute allowed with any error response.

• 300 “Try Alternate” is not used.– “Positive knowledge” not required. Instead, new

STUN rules say must wait 5 minutes before trying the same server again.

ALTERNATE-SERVER (2)• EKR, Cullen: Ditch this; just use SRV mechanism.• Marc P-H:

– Don’t use for load-balancing.– Change attribute to contain a domain name (rather than

an IP address and port)– Allows the server to dynamically redirect the client, as

opposed to the SRV mechanism which is more static.

• Proposal:– Remove ALTERNATE-SERVER from STUN for now.– Add later as a enhancement once a well-defined

mechanism exists.

BANDWIDTH (1)• Proposal for handling BANDWIDTH• BANDWIDTH attribute specifies a Token Bucket:

– Token Bucket Rate– Token Bucket Size

• Client MAY include BANDWIDTH in Allocate req– Client includes if it wants a service guarantee (e.g., for

voice or video)– Client does not include if it wants best-effort service

(e.g., for variable-rate data)

• If server cannot provide requested service, it rejects the request.– Server MAY include BANDWIDTH attribute in error

response specifying service guarantee it could provide

BANDWIDTH (2)Some possible server implementations:1. Server provides best-effort service only. Rejects

requests containing a BANDWIDTH attribute. 2. Server provides a simple controlled-load service

only. Ensures sum of token bucket rates does not exceed some max value. No policing.

– Suitable if server trusts clients not to send faster than advertized rate.

3. (2) + Policing each allocation using Token Bucket.– Appropriate if clients might send faster than

their advertized rate4. Mixing best-effort and controlled-load on same

server ??

BANDWIDTH (3)Questions:1. As proposed, the BANDWIDTH parameters are

modelled after IntServ’s Controlled-Load service. Should a different set of parameters be used (e.g., RFC 3890 - Bandwidth Modifier for SDP)?

2. As proposed, if the client wants controlled-load but the server only supports best-effort, the request is rejected, and the client must retry if it is willing to accept best-effort. Is this a problem?

3. As proposed, the bandwidth specified is the bandwidth on the client <-> server connection, and is the max of the traffic in each direction. It also includes control traffic. Should the bandwidth be measured differently?

Public TURN Servers• How do we handle authentication for public TURN

servers? • Option 1: Public TURN servers do not use

authentication.• Option 2: Public TURN servers use authentication;

client obtains username and password through out-of-band mechanism (e.g. user visits a webpage).

• Option 3: Don’t say anything about how to do this in the document.

• Proposal: Document will recommend option 2, and briefly describe how this could be done.

Lifetimes

• Permission lifetime: – 5 min (fixed); refresh by sending data to any peer with

same IP address OR using “empty” Send indication

• Channel lifetime:– 10 min (fixed); refresh by sending data on channel OR

rebinding channel to peer

• Allocation lifetime:– 10 min (default; client can request a longer time);

refresh using Refresh transaction

Other Changes• STUN-formatted messages are no longer framed• Completely reworked the mechanism for binding a

channel (EKR’s proposal)• Completely reworked the mechanism for

requesting an even port or a pair of ports (Cullen’s proposal)– Can no longer request a specific port

• 5-tuples cannot be re-used for two minutes after allocation expires. Clients must use a different port for a new

allocation