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

From: Emil Ivov <[email-masked]>
Date: Thu, 13 Sep 2012 12:29:14 +0300

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: [email-masked] Subject: FW: New
>> Version Notification for draft-wing-mmusic-ice- mobility-01.txt
>> 
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] 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 
> [email-masked] https://www.ietf.org/mailman/listinfo/mmusic
> 

-- 
Emil Ivov, Ph.D.                       67000 Strasbourg,
Project Lead                           France
Jitsi
[email-masked]                        PHONE: +33.1.77.62.43.30
http://jitsi.org                       FAX:   +33.1.77.62.47.31

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 17 Sep 2012 16:47:15 +0000

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.

--Tiru.

> -----Original Message-----
> From: Emil Ivov [mailto:[email-masked]]
> Sent: Thursday, September 13, 2012 2:59 PM
> To: Tirumaleswar Reddy (tireddy)
> Cc: [email-masked]
> Subject: Re: [MMUSIC] New Version Notification for draft-wing-mmusic-ice-
> mobility-01.txt
>
> Hey Tiru,
>
> >> Friday, July 20, 2012 3:18 PM To: [email-masked]<mailto:[email-masked]> Subject: FW: New
> >> -----Original Message----- From: [email-masked]<mailto:[email-masked]>
> >> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> Sent: Tuesday, July 17, 2012 3:52
> > [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/mmusic
> >
>
> --
> [email-masked]<mailto:[email-masked]>                        PHONE: +33.1.77.62.43.30

---

From: Emil Ivov <[email-masked]>
Date: Mon, 17 Sep 2012 19:08:59 +0200

Hey Tiru,

On 17.09.12, 18:47, Tirumaleswar Reddy (tireddy) wrote:
> 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.
>  
> *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.

Besides, even in cases where ICE mobility succeeds, an ICE restart could
still allow the use of higher priority candidates.

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
>> > _http://www.ietf.org/internet-drafts/draft-wing-mmusic-ice-mobility-01.txt_
>> >
>> >> Friday, July 20, 2012 3:18 PM To: [email-masked] <mailto:[email-masked]> Subject: FW: New
>> >> -----Original Message----- From: [email-masked] <mailto:[email-masked]>
>> >> _[mailto:[email-masked]]_
> <mailto:[mailto:[email-masked]]> Sent: Tuesday, July 17, 2012 3:52
>> >> _http://www.ietf.org/internet-drafts/draft-wing-mmusic-_
>> >> _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
>> >>
>> > [email-masked] <mailto:[email-masked]>
> _https://www.ietf.org/mailman/listinfo/mmusic_
>> >

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 18 Sep 2012 02:56:51 +0000

> Sent: Monday, September 17, 2012 10:39 PM
> Cc: [email-masked]; Dan Wing (dwing); Prashanth Patil (praspati); Pal
> Martinsen (palmarti)

The only reason I can think why ICE Mobility would fail and ICE restart succeed is because of Simultaneous Mobility, 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.
> 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.

> >> >> Friday, July 20, 2012 3:18 PM To: [email-masked]
> <mailto:[email-masked]> Subject: FW: New

---

From: Emil Ivov <[email-masked]>
Date: Tue, 18 Sep 2012 11:41:34 +0200

Hey Tiru,

On 18.09.12, 04:56, Tirumaleswar Reddy (tireddy) wrote:
>> -----Original Message----- From: Emil Ivov
>> [mailto:[email-masked]] Sent: Monday, September 17, 2012 10:39 PM 
>> To: Tirumaleswar Reddy (tireddy) Cc: [email-masked]; 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,
>> 
>>> 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.
>>> 
>>> *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)
> 
> 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:[email-masked]] Sent: Thursday, September 13, 2012
>>>> 2:59 PM To: Tirumaleswar Reddy (tireddy) Cc: [email-masked] 
>>>> 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
>>>> 
>>>>> 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:
>>>>>> [email-masked]
>>>>>> -----Original Message----- From:
>>>>>> [email-masked]
>> <mailto:[email-masked]>
>>>>>> 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://datatracker.ietf.org/doc/draft-wing-mmusic-ice-_
>>>>>> mobility Htmlized:
>>>>>> _http://tools.ietf.org/html/draft-wing-mmusic-ice-_ 
>>>>>> mobility-01 Diff: 
>>>>>> 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 [email-masked] <mailto:[email-masked]>

-- 
Emil Ivov, Ph.D.                       67000 Strasbourg,
Project Lead                           France
Jitsi
[email-masked]                        PHONE: +33.1.77.62.43.30
https://jitsi.org                      FAX:   +33.1.77.62.47.31

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 18 Sep 2012 12:07:18 +0000

> Sent: Tuesday, September 18, 2012 3:12 PM

Hi Emil,

Thanks for the review.

I have assumed that the other Mobile Device (Correspondent Node in this case) would include MOBILITY-SUPPORT only in the following cases :
IPv6 Global Address, Correspondent Node is behind Endpoint-Independent Mapping/Filtering NAT as recommended in RFC 4787.

But to make it work in other scenarios where Correspondent Node(CN) is behind Address-Dependent Filtering/Mapping, CN can detect the NAT behavior using simple tests suggested in RFC 5780 and so not include MOBILITY-SUPPORT attribute.

[Even without ICE Mobility, if both Mobile devices are behind non-BEHAVE compliant NAT then ICE connectivity checks using host/server-reflexive candidates will fail and end up using UDP relay]

===
Section 3

Endpoints that support ICE Mobility perform ICE normally, and MUST also include the MOBILITY-SUPPORT attribute in all of their STUN requests and their STUN responses. The inclusion of this attribute allows the ICE peer to determine if it can achieve mobility using ICE or needs to use TURN (or needs to use some other mechanism, such as Mobile IP). To force the use of TURN to achieve ICE mobility, the ICE endpoint SHOULD NOT respond to ICE connectivity checks that have an IP address and port different from the TURN server, unless those connectivity checks contain the MOBILITY-SUPPORT attribute. In this way, the remote peer will think those other candidates are invalid (because its connectivity checks did not succeed).
===

--Tiru.

---

From: Emil Ivov <[email-masked]>
Date: Tue, 18 Sep 2012 14:49:44 +0200

Hey Tiru,

On 18.09.12, 14:07, Tirumaleswar Reddy (tireddy) wrote:
> I have assumed that the other Mobile Device (Correspondent Node in this
> case) would include MOBILITY-SUPPORT only in the following cases :
> IPv6 Global Address,

And I insist, even with IPv6 there should be no that performs endpoint
dependent filtering in front of the CN. Many corporate firewalls would
not allow incoming traffic unless it has been initiated from the inside.
Just as they would for IPv4.

> Correspondent Node is behind Endpoint-Independent
> Mapping/Filtering NAT as recommended in RFC 4787.

While 4787 is quite adamant about avoiding endpoint dependent mapping
this is not the case for endpoint dependent filtering:

  RTF 4787, REQ-8: ... If a more stringent filtering behavior is most
  important, it is RECOMMENDED that a NAT have an "Address-Dependent
  Filtering" behavior.

That text aside, while one could hope that (at least in certain parts of
the world) a decent number of CNs would be behind a NAT with endpoint
independent mapping, it is very rare to see commercial deployments with
endpoint independent filtering.

> But to make it work in other scenarios where Correspondent Node(CN) is
> behind Address-Dependent Filtering/Mapping, CN can detect the NAT
> behavior using simple tests suggested in RFC 5780 and so not include
> MOBILITY-SUPPORT attribute.

That kind of diagnostics are extremely difficult to apply in practice
(which is one of the reasons for ICE to exist) and even if they weren't,
disabling ICE mobility for NATs with endpoint dependent filtering would
leave you with very few cases where one would be able to use it.

> [Even without ICE Mobility, if both Mobile devices are behind non-BEHAVE
> compliant NAT then ICE connectivity checks using host/server-reflexive
> candidates will fail and end up using UDP relay]

Well again, NATs with endpoint dependent filtering are totally fine with
4787 and they do work with server-reflexive addresses.

Cheers,
Emil

--
https://jitsi.org

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 19 Sep 2012 14:45:09 +0000

> Sent: Tuesday, September 18, 2012 6:20 PM

Hi Emil,

Thanks for the detailed explanation. We will add details that ICE agent will try ICE Mobility and ICE restart in parallel. So that in case of Endpoint dependent filtering/Firewall scenarios even if ICE Mobility fails, ICE restart would succeed. 

[1]Endpoint independent mapping/filtering -> No issues with ICE Mobility.
[2]Endpoint dependent mapping -> ICE peers will have to use UDP relays. Mobile Devices will end up using the technique in section 4 of the draft (Mobility with TURN)

--Tiru.