Re: [rtcweb] Filling in details on "trickle ICE"

Lishitao <lishitao@huawei.com> Wed, 29 August 2012 06:35 UTC

Return-Path: <lishitao@huawei.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30E0111E80A4 for <rtcweb@ietfa.amsl.com>; Tue, 28 Aug 2012 23:35:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 jVQU6j35t3UL for <rtcweb@ietfa.amsl.com>; Tue, 28 Aug 2012 23:35:02 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A11C411E80A2 for <rtcweb@ietf.org>; Tue, 28 Aug 2012 23:35:01 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AJC80469; Wed, 29 Aug 2012 06:35:00 +0000 (GMT)
Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 29 Aug 2012 07:34:28 +0100
Received: from SZXEML428-HUB.china.huawei.com (10.72.61.36) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 29 Aug 2012 14:34:55 +0800
Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.70]) by szxeml428-hub.china.huawei.com ([10.72.61.36]) with mapi id 14.01.0323.003; Wed, 29 Aug 2012 14:34:48 +0800
From: Lishitao <lishitao@huawei.com>
To: Emil Ivov <emcho@jitsi.org>, Bernard Aboba <bernard_aboba@hotmail.com>
Thread-Topic: [rtcweb] Filling in details on "trickle ICE"
Thread-Index: AQHNggtM/okNr7r4mEK0m/1/TyZDY5dol3CAgAABRICAAAOYgIAACHQAgAADxICAABZ7AIAAM/2AgAATuQCABIpzAIAABfEAgAAHh4CAAAEEgIAAEn+AgAADmYCAAAbdgIAAfw4AgAIdnDA=
Date: Wed, 29 Aug 2012 06:34:48 +0000
Message-ID: <DA165A8A2929C6429CAB403A76B573A5146979BB@szxeml534-mbx.china.huawei.com>
References: <CABcZeBMzgAs=hK38hCjS7t6yLjkTydS2TQUb8R3rBbRKGakVdQ@mail.gmail.com><CABcZeBMFUFjU=FQo5LeJrcMfajeae0j+PWw5U2g5dUQNcJLWaA@mail.gmail.com><CABkgnnXiL3_U+Hci9ooDqBCsoV3KF8pwgcf9zbuN6EKZkK+aiQ@mail.gmail.com><CABcZeBNkkH93ybuMWoFg-ddKWnRgdn2Vgyb50W21A2GoMWxw6Q@mail.gmail.com><CABkgnnXQ25ZYNqeO+=FsYDR3aNvFS2zvrKWGs5o=h8m+Eq=Y+Q@mail.gmail.com><3B8DB12B-ABB3-4AC2-A0A0-93DC62C619D3@iii.ca><CABkgnnU3ecmhUwCYHmppwLJz-nbSA6=VRF7nF7wcpb+5QAWmdQ@mail.gmail.com>, <E17CAD772E76C742B645BD4DC602CD81069D82BF@NAHALD.us.int.genesyslab.com>, <AE1A6B5FD507DC4FB3C5166F3A05A4840E4E7B56@tk5ex14mbxc272.redmond.corp.microsoft.com>, <E17CAD772E76C742B645BD4DC602CD81069D8500@NAHALD.us.int.genesyslab.com>, <AE1A6B5FD507DC4FB3C5166F3A05A4840E4E7C02@tk5ex14mbxc272.redmond.corp.microsoft.com>, <503BDC75.7050008@stpeter.im> <BLU002-W2286956624CC6600038246993A20@phx.gbl> <503BEEFD.40301@jitsi.org> <BLU169-DS457B54FA311A048E5E68B093A20@phx.gbl> <503C5F54.5000309@jitsi.org>
In-Reply-To: <503C5F54.5000309@jitsi.org>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.138.73.37]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Filling in details on "trickle ICE"
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Aug 2012 06:35:03 -0000

> From your other mail:
> 
> > Details of the updated offer are described in RFC 5245 Section 9.1.2.2:
> 
> I am not sure how 9.1.2.2 would apply here given that it's about sending
> updated offers once ICE has completed. It even says that:
> 
>     The agent MUST include candidate attributes for candidates matching
>     the default destination for each component of the media stream, and
>     MUST NOT include any other candidates.
> 
> Did you instead mean to quote section 9.1.2.1 which contains the following:
> 
>    The agent
>    MAY include additional candidates it did not offer previously, but
>    which it has gathered since the last offer/answer exchange, including
>    peer reflexive candidates.
> 
> 9.1.2.1 does indeed refer to updating ICE for "Existing Media Streams
> with ICE Running".
> 
> While I agree that this does look like trickling I am not sure it was
> intended to be used in exactly the same way that we are discussing here
> and the text is not enough to cover a proper trickling implementation.
> 
> The main issue is that there's currently nothing in 5245 that would
> allow an agent to determine if more candidates are to be expected. If
> trickling is in use there's no way for a controlled agent to know that
> (or if) more candidates are to be expected. This creates a race
> condition which may result in the controlled agent moving into the "ICE
> Failed" state before it has received all candidates from the controlling
> agent.

Agree, and AFAIK, what described in RFC 5245 is not the exact mechanism as ICE trickling. 

Moreover, using SDP for ICE trickling is not a good idea, because, the reason by using ICE trickling is to shorten 
the negotiation time, but the offerer can not send another update SDP offer which including the new candidates 
to the answerer unless the offerer has received the first SDP answer, this cannot increase the negotiation procedure.


> Such premature failures can happen very easily if the first offer only
> contains addresses that can be determined as unusable without even
> running any checks. This would be the case for an IPv4-only host
> receiving an offer with IPv6 candidates only (and vice versa). One can
> probably come up with a few more cases like this one.
> 
> > If the issue is lack of clarity in
> > XEP-0176, shouldn't that be brought up in the XSF, which owns the
> > specification?
> 
> Nope, XEP-0176 would be crystal clear if the IETF comes up with a
> document that explains how ICE agents should behave in situations where
> addresses continue to arrive after the original offer.


> Emil
> 
> --
> https://jitsi.org
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb