[MMUSIC] ICE aggressive nomination problem

Ari Keranen <ari.keranen@nomadiclab.com> Wed, 19 December 2012 17:50 UTC

Return-Path: <ari.keranen@nomadiclab.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B947121F886B for <mmusic@ietfa.amsl.com>; Wed, 19 Dec 2012 09:50:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eqw7VBkhQELu for <mmusic@ietfa.amsl.com>; Wed, 19 Dec 2012 09:50:48 -0800 (PST)
Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by ietfa.amsl.com (Postfix) with ESMTP id 03DFE21F842C for <mmusic@ietf.org>; Wed, 19 Dec 2012 09:50:48 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 78FDC4E6F2 for <mmusic@ietf.org>; Wed, 19 Dec 2012 19:50:46 +0200 (EET)
X-Virus-Scanned: amavisd-new at nomadiclab.com
Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H45TC-6uELvI for <mmusic@ietf.org>; Wed, 19 Dec 2012 19:50:46 +0200 (EET)
Received: from tri62.nomadiclab.com (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTPSA id 091814E6E9 for <mmusic@ietf.org>; Wed, 19 Dec 2012 19:50:46 +0200 (EET)
Message-ID: <50D1FE75.9060709@nomadiclab.com>
Date: Wed, 19 Dec 2012 19:50:45 +0200
From: Ari Keranen <ari.keranen@nomadiclab.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: "mmusic@ietf.org" <mmusic@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [MMUSIC] ICE aggressive nomination problem
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Dec 2012 17:50:48 -0000

Hi all,

Going through the ICE spec reminded me of one old problem with 
aggressive nomination that I discussed with Philip Matthews back when 
ICE was published:

Two endpoints L and R. L is the offerer and controlling end. There are 
two possible paths, and just one component.

Since L is using aggressive nomination, it sets the USE-CANDIDATE flag 
in each Binding request. However, the Binding response for the first 
path does not make it back to L. When the second check succeeds, L 
immediately stops ICE processing and uses the second path. However, R 
thinks the first path is being used.

Initially, L will use path 2 for data, while R will use path 1. 
Eventually, both paths will fail, because L is only sending keep-alives 
on path 2, while R is only sending them on path 1.

L                                         R
  <--------- Bind req ---------------------  ]
  ---------- Bind resp ------------------->  ]  Path 1
  ---------- Bind req, USE-CAND ---------->  ]
       X <-- Bind resp --------------------  ]

  <--------- Bind req ---------------------  ]
  ---------- Bind resp ------------------->  ]  Path 2
  ---------- Bind req, USE-CAND ---------->  ]
  <--------- Bind resp --------------------  ]

---


Any good ideas how to fix this? Should the controlling agent just keep 
retransmitting even after successful nomination (for how long)?

The updated offer (if we make that MUST in all cases) will help to 
detect the problem though and this could also be added to the list of 
"reasons for not using aggressive nomination unless you really have to".


Cheers,
Ari