Appendix B. Design Motivations

ICE contains a number of normative behaviors that may themselves be simple, but derive from complicated or non-obvious thinking or use cases that merit further discussion. Since these design motivations are not neccesary to understand for purposes of implementation, they are discussed here in an appendix to the specification. This section is non-normative.

B.1. Pacing of STUN Transactions

STUN transactions used to gather candidates and to verify connectivity are paced out at an approximate rate of one new transaction every Ta milliseconds. Each transaction, in turn, has a retransmission timer RTO that is a function of Ta as well. Why are these transactions paced, and why are these formulas used?

Sending of these STUN requests will often have the effect of creating bindings on NAT devices between the client and the STUN servers. Experience has shown that many NAT devices have upper limits on the rate at which they will create new bindings. Experiments have shown that once every 20 ms is well supported, but not much lower than that. This is why Ta has a lower bound of 20 ms. Furthermore, transmission of these packets on the network makes use of bandwidth and needs to be rate limited by the agent. Deployments based on earlier draft versions of this document tended to overload rate-constrained access links and perform poorly overall, in addition to negatively impacting the network. As a consequence, the pacing ensures that the NAT device does not get overloaded and that traffic is kept at a reasonable rate.

B.2. Candidates with Multiple Bases

Section 4.1.3 talks about eliminating candidates that have the same transport address and base. However, candidates with the same transport addresses but different bases are not redundant. When can an agent have two candidates that have the same IP address and port, but different bases?

Consider a case where an offerer is multihomed. It has one IP address on a private network C, and another on network A which is NATed to network B. The offerer obtains a host candidate on C and a host candidate on A. It performs a STUN query from A, which passes through the NAT and is assigned a binding that happens to match the IP:port on C. Now, the offerer has obtained a server reflexive candidate with a transport address that is identical to a host candidate. However, the server reflexive candidate has a different base than the host candidate.

B.3. Purpose of the <rel-addr> and <rel-port> Attributes

The candidate attribute contains two values that are not used at all by ICE itself -- <rel-addr> and <rel-port>. Why is it present?

There are two motivations for its inclusion. The first is diagnostic. It is very useful to know the relationship between the different types of candidates. By including it, an agent can know which relayed candidate is associated with which reflexive candidate, which in turn is associated with a specific host candidate. When checks for one candidate succeed and not for others, this provides useful diagnostics on what is going on in the network.

The second reason has to do with off-path Quality of Service (QoS) mechanisms. When ICE is used in environments such as PacketCable 2.0, proxies will inspect the SDP and extract the IP address and port for media traffic to establish guaranteed QoS. When a relayed candidate is selected, the proxy needs the server reflexive candidate towards the TURN server to request QoS from the access router. By carrying the translation in the SDP, the proxy can use that transport address.

B.4. Importance of the STUN Username

ICE requires the usage of message integrity with STUN using its short-term credential functionality. The actual short-term credential is formed by exchanging username fragments in the SDP offer/answer exchange. The need for this mechanism goes beyond just security; it is actually required for correct operation of ICE in the first place.

Consider agents L, R, and Z in overlapping private networks. L sends an offer to Z. Z provides host candidates. R happens to be using the same IP:port as Z. L sends a STUN request which goes to R instead of Z. If R just replied, L would believe it has connectivity to Z. To fix this, the STUN short-term credential mechanisms are used. The username fragments are sufficiently random that it is highly unlikely that R would be using the same values as Z. Consequently, R would reject the STUN request since the credentials were invalid.

B.5. The Candidate Pair Priority Formula

The priority for a candidate pair has an odd form. It is:

pair priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0)

Why is this? When the candidate pairs are sorted based on this value, the resulting sorting has the MAX/MIN property. This means that the pairs are first sorted based on decreasing value of the minimum of the two priorities. For pairs that have the same value of the minimum priority, the maximum priority is used to sort amongst them. If the max and the min priorities are the same, the controlling agent's priority is used as the tie-breaker. This creates the MAX/MIN sorting. MAX/MIN ensures that, for a particular agent, a lower-priority candidate is never used until all higher-priority candidates have been tried.

B.6. The remote-candidates Attribute

The a=remote-candidates attribute exists to eliminate a race condition between the updated offer and the response to the STUN Binding request that moved a candidate into the Valid list. To eliminate this condition, the actual candidates at R that were selected by the offerer (the remote candidates) are included in the offer itself, and the answerer delays its answer until those pairs validate.

B.7. Why Are Keepalives Needed?

Once media begins flowing on a candidate pair, it is still necessary to keep the bindings alive at intermediate NATs for the duration of the session. Normally, the media stream packets themselves meet this objective. However, if media is put on hold, or if silence suppression is used, media transmission may cease sufficiently long for NAT bindings to time out. For these reasons, the media packets themselves cannot be relied upon. ICE defines a simple periodic keepalive utilizing STUN Binding indications.

B.8. Why Prefer Peer Reflexive Candidates?

Section 4.1.2 requires that the type preference for peer reflexive candidates always be higher than server reflexive. Why is that? The reason has to do with the security considerations. It is much easier for an attacker to cause an agent to use a false server reflexive candidate than it is for an attacker to cause an agent to use a false peer reflexive candidate. Consequently, attacks against address gathering with Binding requests are thwarted by ICE by preferring the peer reflexive candidates.

B.9. Why Send an Updated Offer?

Both agents can send media once ICE checks complete, without waiting for an updated offer. Indeed, the only purpose of the updated offer is to "correct" the SDP so that the default destination for media matches where media is being sent based on ICE procedures.

Why is the updated offer/answer exchange needed at all? In practice, numerous components along the signaling path look at the SDP information (e.g., for QoS, NAT traversal, diagnostics). For these tools to continue to function without change, the core property of SDP -- that the existing, pre-ICE definitions of the addresses used for media must be retained. For this reason, an updated offer must be sent.

B.10. Why Are Binding Indications Used for Keepalives?

The primary reason has to do with network QoS mechanisms. If an agent is sending media packets, and then receives a Binding request, it would need to generate a response packet along with its media packets. This will increase the actual bandwidth requirements and introduce jitter. Using a Binding Indication allows integrity to be disabled, allowing for better performance.

B.11. Why Is the Conflict Resolution Mechanism Needed?

The condition when both agents believe they are controlled shows up in third party call control cases. For example, a controller sends an offerless INVITE to agent A, which responds with an offer. The controller then sends an offerless INVITE to agent B, which responds with an offer. The controller uses the offers to generate answers. When this flow is used, ICE will run between agents A and B, but both will believe they are in the controlling role. With the role conflict resolution procedures, this flow will function properly.