1. TURN draft-ietf-behave-turn-07 Philip Matthews, Avaya Jonathan Rosenberg, Cisco Rohan Mahy, Plantronics

2. 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.

3. 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”

4. 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).

5. 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.

6. 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.

7. 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.

8. 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

9. 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 rate 4.Mixing best-effort and controlled-load on same server ??

10. 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?

11. 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.

12. 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

13. 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