Re: [MMUSIC] New Version Notification for draft-wing-mmusic-ice-mobility-01.txt

Emil Ivov <emcho@jitsi.org> Tue, 18 September 2012 09:41 UTC

Return-Path: <emil@sip-communicator.org>
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 0C99C21F87D7 for <mmusic@ietfa.amsl.com>; Tue, 18 Sep 2012 02:41:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 PvlQAfZl8TZL for <mmusic@ietfa.amsl.com>; Tue, 18 Sep 2012 02:41:38 -0700 (PDT)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5991621F87D6 for <mmusic@ietf.org>; Tue, 18 Sep 2012 02:41:37 -0700 (PDT)
Received: by wgbdr13 with SMTP id dr13so4110022wgb.13 for <mmusic@ietf.org>; Tue, 18 Sep 2012 02:41:36 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=yDicBX4ePeA60s8TE9j1J0HgE0A6dnJ8AxWorBHbSLE=; b=QNmq6p6cpc3mUpxTWvyb+f4acy8rU+6oi4+OP0f3KfP0sXxD4wSA+3+BHTr7sdsbPM CFnuiZBSb6IwP1tKz7By1e5ZdWcpS/yhRZjM4z1ZbmtlMONl5QkbjLoZ5SHd1T6O0I5i kffYwBOIt1I5UXPcZxn89FeN1inKGbhNFaqGbuh1D4QrzEGX5JbfGQ7CmULQKD8IOpPn 0exWRloR9oBs2g7weYkEB63RMFtizoqmHA6bEaEb2At2tOHZ3b1kFxVTfatkup5KZ7Ew dXZXpGfVEP4qfIr52Y5l+rOP8s7Vv8A/kpNdHAIFrNW3xINbxb7RaUDjYefVZGEyKLOC I2WA==
Received: by 10.180.85.167 with SMTP id i7mr22128922wiz.8.1347961296420; Tue, 18 Sep 2012 02:41:36 -0700 (PDT)
Received: from pastropnet.u-strasbg.fr ([2001:660:4701:1001:6d9e:5cc0:90cb:9fbb]) by mx.google.com with ESMTPS id dp8sm30979187wib.3.2012.09.18.02.41.33 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 18 Sep 2012 02:41:35 -0700 (PDT)
Message-ID: <505841CE.30602@jitsi.org>
Date: Tue, 18 Sep 2012 11:41:34 +0200
From: Emil Ivov <emcho@jitsi.org>
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>
References: <913383AAA69FF945B8F946018B75898A052D666F@xmb-rcd-x10.cisco.com> <5051A76A.7090606@jitsi.org> <913383AAA69FF945B8F946018B75898A147AA88C@xmb-rcd-x10.cisco.com> <5057592B.9070904@jitsi.org> <913383AAA69FF945B8F946018B75898A147AB415@xmb-rcd-x10.cisco.com>
In-Reply-To: <913383AAA69FF945B8F946018B75898A147AB415@xmb-rcd-x10.cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQm6mvO+9IzTX534T7YqUJDHkcY5tfG9JYwzvPtKyNGj79Zgit8a4isksvxMfvw9rsBb1KMf
Cc: "Prashanth Patil (praspati)" <praspati@cisco.com>, "mmusic@ietf.org" <mmusic@ietf.org>, "Dan Wing (dwing)" <dwing@cisco.com>
Subject: Re: [MMUSIC] New Version Notification for draft-wing-mmusic-ice-mobility-01.txt
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: Tue, 18 Sep 2012 09:41:39 -0000

Hey Tiru,

On 18.09.12, 04:56, Tirumaleswar Reddy (tireddy) wrote:
>> -----Original Message----- From: Emil Ivov
>> [mailto:emcho@jitsi.org] Sent: Monday, September 17, 2012 10:39 PM 
>> To: Tirumaleswar Reddy (tireddy) Cc: mmusic@ietf.org; Dan Wing
>> (dwing); Prashanth Patil (praspati); Pal Martinsen (palmarti) 
>> Subject: Re: [MMUSIC] New Version Notification for
>> draft-wing-mmusic-ice- mobility-01.txt
>> 
>> Hey Tiru,
>> 
>> On 17.09.12, 18:47, Tirumaleswar Reddy (tireddy) wrote:
>>> Hi Emil -
>>> 
>>> Thanks for the comments. we are in the process of updating the
>>> draft -
>>> 
>>> We are planning to add the high-lighted sentence in Introduction,
>>> please let us know if you have any further comments.
>>> 
>>> Although ICE does allow an "ICE restart", this is done by sending
>>> a re-INVITE which goes over the SIP signaling path. The SIP
>>> signaling path is often slower than the media path (which needs
>>> to be recovered as quickly as possible), consumes an extra half
>>> round trip, and incurs an additional delay if the mobility event
>>> forces the endpoint to re-connect with its SIP proxy. *When a
>>> device changes its IP address, it is necessary for it to
>>> re-establish connectivity with its SIP proxy, which can be
>>> performed in parallel with the steps described in this
>>> document.* This document describes how mobility is performed
>>> entirely in the media path, without the additional delay of
>>> re-establishing SIP connectivity, issuing a new offer/answer, or
>>> the complications of multiple SIP offers. This document considers
>>> re-establishing bi-directional media the most critical aspect of
>>> a successful mobility event, and its efforts are towards meeting
>>> that goal.
>>> 
>>> We will also added the following text at the end of section 3.1
>>> 
>>> *The Mobile device would also in parallel re-establish connection
>>> with the SIP proxy and if the ICE connectivity checks in the
>>> previous steps are not successful then issues new offer/answer
>>> and restarts ICE.*
>> 
>> The above statement implies that the mobile node would need to
>> first declare failure of ICE mobility and only then would it try an
>> ICE restart. Yet, declaring failure would take many seconds with
>> the default STUN timers so as a result handover latency is probably
>> going to worsen more often than not.
> 
> The only reason I can think why ICE Mobility would fail and ICE
> restart succeed is because of Simultaneous Mobility

Well ... I might be missing something but it seems to me that the only
time it would succeed would be when there's a direct reachability
between the mobile node's new address and their correspondent.

This would be the case when the mobile node has moved into the same
NATed network as the correspondent, or when the correspondent has a
public address with no one to perform endpoint dependent filtering in
front of them.

In all other situations (which would likely represent the majority of
the cases) ICE mobility would fail and one would need to perform an ICE
restart.

Emil

> we are trying to
> solve the problem in a different way (This text is yet to be
> published in the next version of the draft)
> 
> 3.3 Simultaneous Mobility
> 
> Mobile device SHOULD include MOBILTY-ROAM attribute in all of its 
> STUN requests and STUN responses.  If the ICE peer also includes 
> MOBILTY-ROAM attribute in all its STUN requests and STUN responses 
> then it means both the endpoints are mobile and can roam at the same 
> time between networks.  In order to support simultaneously mobility 
> without breaking media sessions between them, both ICE agents MUST 
> perform the following steps :
> 
> 1.  The ICE agent will keep the relayed candidates alive using 
> Refresh transaction, as described in [RFC5766].
> 
> 2.  When gaining an interface, the ICE agent will refresh it's 
> allocation with TURN server using Section 4.2.
> 
> 3.  The ICE agent will perform the steps described in Section 3.1.
> 
> 4.  If the ICE connectivity check succeeds only with local and
> remote relayed candidates, it suggests that even the other peer is 
> roaming at the same time.  The ICE agent creates a new pair using the
> relayed candidates, adds the pair to the valid list and marks it as
> selected.  The ICE agent can now send media using the newly selected
> relayed candidate pair.  The Mobile device in parallel re-establishes
> connection with SIP proxy, issues new offer/answer and restarts ICE.
> Hence media will only be sent briefly on TURN relays.
>> 
>> Besides, even in cases where ICE mobility succeeds, an ICE restart
>> could still allow the use of higher priority candidates.
> 
> ICE Mobility will pick the candidates on the new interface based on
> priority (RFC 3484 or latest RFC 6724). Is there any specific case
> you have in mind that ICE restart would pick higher priority
> candidates and not ICE Mobility other than Simultaneous Mobility
> problem ?
> 
> --Tiru.
> 
>> 
>> Wouldn't it make more sense to always perform an ICE restart in
>> parallel and basically consider ICE mobility a best effort attempt
>> to shorten handover latency?
>> 
>> Emil -- https://jitsi.org
>>> 
>>> --Tiru.
>>> 
>>>> -----Original Message----- From: Emil Ivov
>>>> [mailto:emcho@jitsi.org] Sent: Thursday, September 13, 2012
>>>> 2:59 PM To: Tirumaleswar Reddy (tireddy) Cc: mmusic@ietf.org 
>>>> Subject: Re: [MMUSIC] New Version Notification for
>>>> draft-wing-mmusic-ice- mobility-01.txt
>>>> 
>>>> Hey Tiru,
>>>> 
>>>> One thing that I think this document is not very clear about is
>>>> its relationship to standard mobility handling (i.e. through
>>>> ICE restart).
>>>> 
>>>> As far as I can see, ICE restart is only mentioned when
>>>> describing its inefficiency.
>>>> 
>>>> You did confirm in Vancouver that ICE Mobility is only meant as
>>>> an optimisation that would only take place until the ICE
>>>> restart completes but I don't see it anywhere in the text. Or
>>>> am I missing something?
>>>> 
>>>> Cheers, Emil
>>>> 
>>>> On 20.07.12, 13:36, Tirumaleswar Reddy (tireddy) wrote:
>>>>> Hi all,
>>>>> 
>>>>> Dan, Prashanth and I have submitted a draft that explains
>>>>> how endpoint mobility can be achieved using ICE.  Two
>>>>> mechanisms are shown, one where both endpoints support ICE
>>>>> and another where only one endpoint supports ICE. When only
>>>>> one endpoint supports ICE, a TURN server provides mobility.
>>>>> 
>>>>> _http://www.ietf.org/internet-drafts/draft-wing-mmusic-ice-mobility-
>>
>>>>> 
01.txt_
>>>>> 
>>>>> Please let know your comments. If time permits we'd present
>>>>> the draft in Vancouver.
>>>>> 
>>>>> Regards, Tiru.
>>>>> 
>>>>>> -----Original Message----- From: Tirumaleswar Reddy
>>>>>> (tireddy) Sent: Friday, July 20, 2012 3:18 PM To:
>>>>>> _mmusic@ietf.org_
>> <mailto:mmusic@ietf.org> Subject: FW: New
>>>>>> Version Notification for draft-wing-mmusic-ice-
>>>>>> mobility-01.txt
>>>>>> 
>>>>>> -----Original Message----- From:
>>>>>> _internet-drafts@ietf.org_
>> <mailto:internet-drafts@ietf.org>
>>>>>> _[mailto:internet-drafts@ietf.org]_
>>> <mailto:[mailto:internet-drafts@ietf.org]> Sent: Tuesday, July
>>> 17, 2012 3:52
>>>>>> AM To: Dan Wing (dwing) Cc: Prashanth Patil (praspati); 
>>>>>> Tirumaleswar Reddy (tireddy) Subject: New Version
>>>>>> Notification for draft-wing-mmusic-ice-mobility- 01.txt
>>>>>> 
>>>>>> 
>>>>>> A new version of I-D, draft-wing-mmusic-ice-mobility-01.txt
>>>>>> has been successfully submitted by Dan Wing and posted to
>>>>>> the IETF repository.
>>>>>> 
>>>>>> Filename:   draft-wing-mmusic-ice-mobility Revision:
>>>>>> 01 Title: Mobility with ICE (MICE) Creation date:
>>>>>> 2012-07-16 WG ID: Individual Submission Number of pages: 12
>>>>>> URL: 
>>>>>> _http://www.ietf.org/internet-drafts/draft-wing-mmusic-_ 
>>>>>> ice-mobility-01.txt Status: 
>>>>>> _http://datatracker.ietf.org/doc/draft-wing-mmusic-ice-_
>>>>>> mobility Htmlized:
>>>>>> _http://tools.ietf.org/html/draft-wing-mmusic-ice-_ 
>>>>>> mobility-01 Diff: 
>>>>>> _http://tools.ietf.org/rfcdiff?url2=draft-wing-mmusic-_ 
>>>>>> ice-mobility-01
>>>>>> 
>>>>>> Abstract: This specification describes how endpoint
>>>>>> mobility can be achieved using ICE.  Two mechanisms are
>>>>>> shown, one where both endpoints support ICE and another
>>>>>> where only one endpoint supports ICE.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> The IETF Secretariat
>>>>> _______________________________________________ mmusic
>>>>> mailing list _mmusic@ietf.org_ <mailto:mmusic@ietf.org>
>>> _https://www.ietf.org/mailman/listinfo/mmusic_
>>>>> 
> 

-- 
Emil Ivov, Ph.D.                       67000 Strasbourg,
Project Lead                           France
Jitsi
emcho@jitsi.org                        PHONE: +33.1.77.62.43.30
https://jitsi.org                      FAX:   +33.1.77.62.47.31