Re: [MMUSIC] ICE candidate address selection update draft

"Pal Martinsen (palmarti)" <> Thu, 09 August 2012 17:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9572B21F86EC for <>; Thu, 9 Aug 2012 10:13:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KmGQmrT1eMSg for <>; Thu, 9 Aug 2012 10:13:31 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8713D21F86E4 for <>; Thu, 9 Aug 2012 10:13:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=5468; q=dns/txt; s=iport; t=1344532411; x=1345742011; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=MVocEhtwzvd9zd3OYnRhDxgDDZ21twa1RL0hTa1WQS0=; b=VXLuATjM88+31xEf2C61NLoPKcVVlnzQMfAeRGpeHL+MSglCG8epOawT mBE3eOMPX2t2EWC0OY5/MJujYJmJhCmVdf/BcU0mlCMmm5q4kPM3ttZMu /Q8VqP0St9TdRFnO2zNdrix9MQCm3VmLuivV519XFdGiPgKgEqdOT/fDB A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.77,741,1336348800"; d="scan'208";a="110059695"
Received: from ([]) by with ESMTP; 09 Aug 2012 17:13:31 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id q79HDUZa016420 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Aug 2012 17:13:30 GMT
Received: from ([]) by ([]) with mapi id 14.02.0298.004; Thu, 9 Aug 2012 12:13:30 -0500
From: "Pal Martinsen (palmarti)" <>
To: "Dan Wing (dwing)" <>
Thread-Topic: [MMUSIC] ICE candidate address selection update draft
Date: Thu, 09 Aug 2012 17:13:29 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <C3759687E4991243A1A0BD44EAC823034DF5B10A45@BE235.mail.lan> <092c01cd746c$5e7c8040$1b7580c0$@com> <C3759687E4991243A1A0BD44EAC823034DF5B10A86@BE235.mail.lan> <> <0e2801cd757f$98a72680$c9f57380$@com>
In-Reply-To: <0e2801cd757f$98a72680$c9f57380$@com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-tm-as-product-ver: SMEX-
x-tm-as-result: No--51.293400-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Jonathan Lennox <>, "<>" <>
Subject: Re: [MMUSIC] ICE candidate address selection update draft
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: Thu, 09 Aug 2012 17:13:32 -0000

On Aug 8, 2012, at 6:05 PM, Dan Wing <> wrote:

>> -----Original Message-----
>> From: Pal Martinsen (palmarti) []
>> Sent: Tuesday, August 07, 2012 11:30 AM
>> To: Jonathan Lennox
>> Cc: Dan Wing (dwing); Ari Keranen;
>> Subject: Re: [MMUSIC] ICE candidate address selection update draft
>> On Aug 7, 2012, at 11:53 AM, Jonathan Lennox <>
>> wrote:
>>> On Tuesday, August 7 2012, "Dan Wing" wrote to "'Jonathan Lennox',
>> 'Ari Keranen'," saying:
>>>> Mine would be to take the list of IPv6 and IPv4 addresses and try
>> them
>>>> in the order described by ICE (which currently recommends following
>>>> the OS's default, which is sometimes hard to get depending on the
>> OS).
>> From a ICE multi platform library developer that is somewhat of a
>> nightmare.
>> Guess it can be solved by having a reasonable interface that the
>> application
>> that uses the library can fill in the defaults. Having reasonable
>> default values
>> is important as some platforms might not be able to set the values.
>>>> But if the first IPv6 candidate didn't return a connectivity checks
>>>> quickly (let's say, 150ms), initiate a connectivity check on the
>>>> highest priority IPv4 address next.  In that 150ms, based on ICE's
>>>> pacing, many IPv6 addresses will have been tried.  150ms gives
>> plenty
>>>> of time for IPv6 to 'win', before using an IPv4 resource that is
>>>> likely shared with IPv4-only devices.
>>> Can't this result in the endpoints getting out of sync with the order
>> of the checklist?  If one side has started IPv4 while the other hasn't,
>> you won't have the outbound packets coming from one side to create the
>> port bindings.
>> It can at least potentially introduce more "kamikaze" packets and delay
>> the result. The STUN transaction have 10 retransmits and would timeout
>> long after the checklist is empty.
>> To maintain the speed of ICE negotiation and keep call setup times low
>> I think we should consider looking at the pacing of the conn checks.
>> The rationale behind the pacing was not to overwhelm the NATs.
> Yes.  And also to reduce the concern that ICE connectivity checks 
> could flood a link.
>> Have the
>> world move slightly towards better NATs? Looking from the perspective
>> of an endpoint sending 1080p60 video streams the pacing seem a bit
>> conservative?
> The problem, even at the time, was not pps or bandwidth throughput of
> the NATs.  Rather, it was that NATs would not create new mappings
> quick enough and drop the STUN Binding Request.  This would be re-
> transmitted and make it through the NAT, but that retransmit was 
> obviously harmful for call setup times.  As all the connectivity
> checks are supposed to be sent from the same source address and
> port on the client, a new mapping is only necessary for NATs which
> have "address dependent mapping" or "address and port dependent
> mapping" behavior.
> I just checked, and couldn't find a test of UDP mapping speed
> at, 
> draft-jennings-behave-test-results, or 
>  Perhaps there
> are tests available somewhere else.
Thanks for clearing that up.

>> And how does the different paths (IPv4, IPv6, multi
>> homed) impact the pacing? Could we do more in parallel without
>> overwhelm the NATs?
> I'm sure we could.
> We could also be more aggressive with STUN retransmissions, and
> less aggressive at trying new candidates.  That depends on our 
> confidence that the candidates are in the proper order, and if
> we can move a connection to a new candidate.  RTP can be moved
> pretty easily; TCP cannot.  Before ICE completes, we could move
> RTP sessions around without draft-wing-mmusic-ice-mobility.
More agressive STUN retransmits would help speeding up things for RFLX 

> It is probably worth backing up and enumerating the problem(s) we 
> have with ICE, and then deciding what we want to solve.
Yes, you are right.

Keeping the number of connectivity checks at a minimum by removing the 
ones that will never work as this documents describes is probably what we
want from this document. 

>> I am wondering if we could do something smart with prioritising the
>> checklist and triggered checks to make sure IPv6 wins if there is
>> connectivity? I have to little understanding if IPv6 and all the
>> different addresses to clearly formulate the idea at the moment.
>> (Hoping this may trigger something for someone.)
> ICE was written before there was wide acceptance that the IPv6 path
> is sometimes broken.  Tweaking ICE to better accommodate that reality
> seems worthwhile.

Prioritising IPv6 over IPv4 is all about choosing from the valid_list and that is 
currently up to the different implementations to decide. Is it worthwhile having 
a separate document describing that?


> -d
>> .-.
>> Pål-Erik
>>> --
>>> Jonathan Lennox
>>> _______________________________________________
>>> mmusic mailing list