Re: [MMUSIC] Updating the pacing of ICE connectivity checks

Ari Keränen <> Mon, 11 March 2013 04:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7406621F891C for <>; Sun, 10 Mar 2013 21:32:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.949
X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pEDYpRNsGmof for <>; Sun, 10 Mar 2013 21:32:49 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CE7F321F892F for <>; Sun, 10 Mar 2013 21:32:48 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f316d0000028db-09-513d5e6f4334
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 8F.E9.10459.F6E5D315; Mon, 11 Mar 2013 05:32:47 +0100 (CET)
Received: from ( by ( with Microsoft SMTP Server id; Mon, 11 Mar 2013 05:32:47 +0100
Received: from ( []) by (Postfix) with ESMTP id 1842C237A; Mon, 11 Mar 2013 06:32:47 +0200 (EET)
Received: from (localhost []) by (Postfix) with ESMTP id 9DFDE54503; Mon, 11 Mar 2013 06:32:44 +0200 (EET)
Received: from (localhost []) by (Postfix) with ESMTP id E1282534A4; Mon, 11 Mar 2013 06:32:43 +0200 (EET)
Message-ID: <>
Date: Mon, 11 Mar 2013 00:32:46 -0400
From: Ari Keränen <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: mmusic <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCLMWRmVeSWpSXmKPExsUyM+JvjW5+nG2gwYo11hYdk9kspi5/zOLA 5DHl90ZWjyVLfjIFMEVx2aSk5mSWpRbp2yVwZRy4285e8Eeh4vG6WSwNjHOluhg5OSQETCTW /XvOBmGLSVy4tx7I5uIQEjjJKHH58zImkISQwAZGiWlzeCASuxglpr49wQLhrGWUmHJtBhuc s376UbAWXgFtiR13zgLZHBwsAqoSfz7ogITZBOwlbk64zg5iiwokSzxr2Q1VLihxcuYTFhBb REBGYu+mzcwgNrOAocS7GZ1g5wkLuEi8bvrGBjJSSCBH4tk1dZAwp4CvxLmv35kgym0lLsy5 zgJhy0s0b53NDPGZmsTVc5uYIZ5Rlbj67xXjBEbRWUg2z0LSPgtJ+wJG5lWM7LmJmTnp5Yab GIEhf3DLb90djKfOiRxilOZgURLnDXO9ECAkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBMeR1 3pEOgW6+Q1Ul8+fv67bP4pX9IteavfWzhPnyKRPfCL6b+T36zMJPP9aa5y3pOLwrkiePOeNE hO2CxO+Wcjfm6jMWmDs/k132dP/pp6JTTRy1q6Y9WBuicK7BMN5FunXd38Vqt4vFpY4VtMRP uRkZecTO0FMst6jiioGdX8+hE+v2tDAXKrEUZyQaajEXFScCAJFRVbFHAgAA
Cc: "Cullen Jennings (fluffy)" <>
Subject: Re: [MMUSIC] Updating the pacing of ICE connectivity checks
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 11 Mar 2013 04:32:50 -0000


Playing around with the numbers: the connectivity check messages are 
(depending on usernames) about 100 bytes each and bandwidth requirement 
for G.711 is about 80 Kbps. For connectivity checks that would translate 
to roughly one check every 10ms. So, assuming G.711 capable network, one 
every 20 ms should be somewhat safe also from bandwidth point of view.

For total port usage, we have already the 100 candidates max RECOMMENDED 
value (

And NAT timing, I think 20ms is quite "fast enough" (50 candidate pairs 
started during first seconds) for a lower bound.

So, along these lines, I'd propose the following for non-RTP traffic:

- MUST NOT set Ta lower than 20ms.
- RECOMMENDED 100 ms if no better information is available.
(this would be the new conservative guess)
- MAY use external information if such is available (e.g., RTP-like 
formula for bandwidth) to set lower Ta than the recommended.

Then, both agents need to agree on the pacing for the checks to go 
forward in sync. For this purpose, they should indicate in the 
offer/answer what they are ready to use as the Ta and the highest of the 
two would be used.

(as individual)

On 2/21/13 10:25 PM, Cullen Jennings (fluffy) wrote:
> This is a hard problem to figure out but glad it is being tackled as
> the current draft was fiction created to get it approved more.
> I'd be tempted to think of their being a few different things to
> conserve or constraints we need to not exceed
> 1) nat timing
> 2) total ports in usage on the NAT
> 3) bandwidth usage that is not congestion controlled
> For 1) I'm not seeing any reasons to move off the 20 ms lower bound -
> but if someone has empirical data that would be nice as the empirical
> data we are basing this on is old.
> For 2) some Carrier Grade Nats (CGNs) are restricting a given client
> to something like 1000 ports. There may be other limits too. It might
> be worth setting up ICE so that a given ICE client never used more
> than 100 ports at a time. I think this is a new type of constraint
> that is not a big deal today but may be a bigger deal in the future
> and we should consider it in an ICE bis.
> For 3) Its very hard to come up with something that is fast enough
> that the media guys like it and slow enough the transport folks are
> sure it is safe. My strawman proposal would be use more more
> bandwidth than G.711 with 20 ms packets as we have been doing that
> all over the place - without congestion control  - and the internet
> has not melted down.
> On Feb 14, 2013, at 6:49 AM, Ari Keränen <>
> wrote:
>> Hi all,
>> Updating the pacing parameter, Ta, of ICE for non-RTP traffic (for
>> background, see [1] and [2]), as discussed at the Atlanta meeting,
>> will be one of the important changes in the new version of ICE.
>> Currently the RFC5245 says (for non-RTP traffic) "Ta SHOULD be
>> configurable, SHOULD have a default of 500 ms, and MUST NOT be
>> configurable to be less than 500 ms."
>> This results in very slow pace of starting connectivity checks if
>> ICE is used with non-RTP traffic. With RTP, the Ta is calculated
>> based on the expected bandwidth used by the RTP stream and can be
>> down to 20 ms. Therefore, many current implementations apparently
>> ignore the "MUST NOT" above and set Ta to something lower.
>> The quite conservative value of 500 ms was originally chosen
>> because of the fear of congesting the links with the connectivity
>> check messages. This is obviously still a valid concern, but would
>> suggesting something lower still make sense? How low would it be
>> reasonably safe to go? What is currently used in practice? Can we
>> come up with a formula similar to RTP (perhaps based on expected
>> bandwidth usage)?
>> Cheers, Ari
>> [1] [2]
>> _______________________________________________ mmusic mailing
>> list