Subject: [MMUSIC] ICE issue 1: avoiding the STUN flood

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 25 Jul 2005 10:44:10 -0400

The algorithm in the ICE spec, as currently specified, has each endpoint 
doing a connectivity check from each of its candidates, to each of its 
peer candidates, completely in parallel. If you have a multi-homed host 
with two interfaces, and you have a STUN, TURN server, and you are 
dual-stack, you end up with 12 candidates and 144 parallel connectivity 
checks to a similarly equipped peer.

This presents several problems:

1. Magnus had raised this concern some time back, about the congestion 
load on the network with the checks. This is becoming significant.

2. There have been reports of NATs that, if the packet rates are too 
high, revert to symmetric behaviors. They also limit the number of ports 
that they'll allocate in some cases.

As such, we need to adjust the ICE algorithm to deal with this. I have a 
suggested approach, and I am sure there are others.

The idea is not to do the checks in parallel, but to start with highest 
priority pairs first. Each endpoint would basically order each candidate 
pairing. The ordering would be such that the highest priority pairings 
are tried first, followed by next lower, and so on. Each endpoint 
throttles its connectivity checks at a constant rate, such that the 
bandwidth consumed by those checks is no more than some percentage of 
the RTP traffic rate for the largest codec in the offer/answer exchange.

Once a check has succeeded, the endpoint ceases all further checks and 
then does a re-invite to use that successful candidate in the m/c-line. 
Probably some random delays need to be added to avoid the glare 
condition. I'd suggest that the answerer wait an additional 1-2 seconds, 
and the offerer be the one to immediately try the updated offer.

This algorithm has the benefit of pacing out the stun traffic in a way 
similar to RTCP, avoiding pointless checks by doing it for higher 
priority candidates first, and (I think) speeding up convergence.

Suggestions, comments or improvements?

I'd need to do some work to come up with specific numbers so that this 
works reasonably well.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic