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

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 24 Jun 2013 13:06:08 +0000

Hi all,

we have updated the draft based on the comments received during IETF 86 to compare MICE with ICE restart and Trickle ICE (Section 6 "Comparison to ICE Restart and Trickle ICE"). comments and suggestions are welcome.

Best Regards,
--Authors.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, June 24, 2013 1:06 PM
To: Prashanth Patil (praspati); Tirumaleswar Reddy (tireddy); Dan Wing (dwing); Pal Martinsen (palmarti)
Subject: New Version Notification for draft-wing-mmusic-ice-mobility-04.txt

A new version of I-D, draft-wing-mmusic-ice-mobility-04.txt
has been successfully submitted by Dan Wing and posted to the
IETF repository.

Filename:	 draft-wing-mmusic-ice-mobility
Revision:	 04
Title:		 Mobility with ICE (MICE)
Creation date:	 2013-06-24
Group:		 Individual Submission
Number of pages: 19
URL:             http://www.ietf.org/internet-drafts/draft-wing-mmusic-ice-mobility-04.txt
Status:          http://datatracker.ietf.org/doc/draft-wing-mmusic-ice-mobility
Htmlized:        http://tools.ietf.org/html/draft-wing-mmusic-ice-mobility-04
Diff:            http://www.ietf.org/rfcdiff?url2=draft-wing-mmusic-ice-mobility-04

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

---

From: Emil Ivov <[email-masked]>
Date: Mon, 24 Jun 2013 16:02:12 +0200

Hey Tiru,

On 24.06.13, 15:06, Tirumaleswar Reddy (tireddy) wrote:
> Hi all,
>
> we have updated the draft based on the comments received during IETF
> 86 to compare MICE with ICE restart and Trickle ICE (Section 6
> "Comparison to ICE Restart and Trickle ICE"). comments and
> suggestions are welcome.

Thanks for doing this.

A few comments on that comparison:

> 6.2. Break Before Make - Trickle ICE
>
> o If Trickle ICE [I-D.rescorla-mmusic-ice-trickle] is used for RTP
> Mobility then in case of Break before Make,
>
> 1. Trickle ICE can begin connectivity checks while the endpoint
> is still gathering candidates and can considerably shorten the
> time necessary for ICE processing to complete. It still
> involves the overhead of step 1 explained in section
> Section 6.1.

The said overhead being SIP re-registration, I don't see how trickle-ice 
and mice are in a different position here. Why would one be able to 
restart attempts without it, while the other wouldn't?

> 2. The endpoint would learn host candidates and inform them to
> the remote peer in offer, the remote peer will provide its
> candidates in answer. The host, server reflexive, peer
> reflexive and relayed candidates of the remote peer may not
> change and the remote peer does not have to gather the
> candidates again. Trickle ICE will test local host candidates
> with all types of remote candidates provided by the remote
> peer in the answer. If the ICE peer is behind NAT performing
> end-point independent mapping and filtering then ICE
> connectivity checks initiated by the endpoint to the remote
> peer will succeed.

Actually that's what you'd need the NAT to be without trickle ICE so 
that break-before-make mice would succeed (which I've already expressed 
as a concern with this draft).

Using trickle ICE would allow you to succeed with endpoint dependent 
filtering because the remote party would also start checks in your 
direction.

I guess what I am trying to say is that it doesn't make sense for mice 
not to use trickle ICE for this case.

> 3. Trickle ICE must be supported by both endpoints for it be
> used.

I am not sure I understand this argument. Any kind of mobility 
management would have to be supported by both pears in order to be used.

Cheers,
Emil

>
> Best Regards, --Authors.
>
> -----Original Message----- From: [email-masked]
> [mailto:[email-masked]] Sent: Monday, June 24, 2013 1:06
> PM To: Prashanth Patil (praspati); Tirumaleswar Reddy (tireddy); Dan
> Wing (dwing); Pal Martinsen (palmarti) Subject: New Version
> Notification for draft-wing-mmusic-ice-mobility-04.txt
>
>
> A new version of I-D, draft-wing-mmusic-ice-mobility-04.txt has been
> successfully submitted by Dan Wing and posted to the IETF
> repository.
>
> Filename:	 draft-wing-mmusic-ice-mobility Revision:	 04 Title:
> Mobility with ICE (MICE) Creation date:	 2013-06-24 Group:
> Individual Submission Number of pages: 19 URL:
> http://www.ietf.org/internet-drafts/draft-wing-mmusic-ice-mobility-04.txt
>
>
Status: 
http://datatracker.ietf.org/doc/draft-wing-mmusic-ice-mobility
> Htmlized:
> http://tools.ietf.org/html/draft-wing-mmusic-ice-mobility-04 Diff:
> http://www.ietf.org/rfcdiff?url2=draft-wing-mmusic-ice-mobility-04
>
> 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
>

-- 
https://jitsi.org

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 25 Jun 2013 12:41:44 +0000

Hi Emil,

Thanks for the review. Please see inline

> From: Emil Ivov [mailto:[email-masked]]
> Sent: Monday, June 24, 2013 7:32 PM
> To: Tirumaleswar Reddy (tireddy)
> Cc: [email-masked]
> Subject: Re: [MMUSIC] FW: New Version Notification for draft-wing-mmusic-ice-
> mobility-04.txt
> 
> Hey Tiru,
> 
> restart attempts without it, while the other wouldn't ?

Mobility using ICE will be started without waiting for SIP re-registration to start (performed entirely in the media path). Please refer to the explanation in http://tools.ietf.org/html/draft-wing-mmusic-ice-mobility-04#section-3.1 

> as a concern with this draft).

Yes, we have updated the draft about the concern you raised last time

Section 3.1 
...
Mobility using ICE could fail in case of Simultaneous Mobility or if the ICE peer is behind NAT that performs Address-Dependent Filtering
(see Section 5 of [RFC5245])....

And this concern could be addressed by either of the following techniques - Section 3.2 "Keeping unused relayed candidates active" or Appendix 
A.2.1.  "Keeping unused candidates in the valid list active"

> filtering because the remote party would also start checks in your

The problem in the above scenario is endpoint would just learn host candidates and inform them to the remote peer in offer, so if the endpoint is behind endpoint independent filtering NAT and the remote peer is behind endpoint dependent filtering NAT (Let's say NAT X). The STUN connectivity checks sent by the endpoint will be blocked by X, STUN connectivity checks initiated by the remote peer will fail to reach the endpoint because it is behind NAT.

> not to use trickle ICE for this case.

MICE can be used with Trickle ICE, we are only responding to comments in the last IETF asking for the benefits of MICE in comparison with ICE restart and Trickle ICE.

> management would have to be supported by both pears in order to be used.

when only one endpoint supports MICE, TURN server can be used to provide mobility (Section 5 - "Mobility using TURN"). The endpoint will use local relayed candidates for communicating with the remote peer. Even If endpoint roams and gets a new IP address, it will continue to reach the remote peer using the local relayed candidates as explained in section 5 (using the MOBILITY-TICKET). The remote peer will not even be aware that the endpoint IP address has changed.

Regards,
--Tiru.

---

From: Emil Ivov <[email-masked]>
Date: Tue, 25 Jun 2013 17:12:26 +0200

Hey Tiru,

On 25.06.13, 14:41, Tirumaleswar Reddy (tireddy) wrote:
>> -----Original Message----- From: Emil Ivov
>> [mailto:[email-masked]] Sent: Monday, June 24, 2013 7:32 PM To:
>> Tirumaleswar Reddy (tireddy) Cc: [email-masked] Subject: Re:
>> [MMUSIC] FW: New Version Notification for draft-wing-mmusic-ice-
>> mobility-04.txt
>>
>> Hey Tiru,
>>
>>> we have updated the draft based on the comments received during
>>> IETF 86 to compare MICE with ICE restart and Trickle ICE (Section
>>> 6 "Comparison to ICE Restart and Trickle ICE"). comments and
>>> suggestions are welcome.
>>
>> Thanks for doing this.
>>
>>> o If Trickle ICE [I-D.rescorla-mmusic-ice-trickle] is used for
>>> RTP Mobility then in case of Break before Make,
>>>
>>> time necessary for ICE processing to complete. It still involves
>>> the overhead of step 1 explained in section Section 6.1.
>>
>> The said overhead being SIP re-registration, I don't see how
>> trickle-ice and mice are in a different position here. Why would
>> one be able to restart attempts without it, while the other
>> wouldn't ?
>
> Mobility using ICE will be started without waiting for SIP
> re-registration to start (performed entirely in the media path).
> Please refer to the explanation in
> http://tools.ietf.org/html/draft-wing-mmusic-ice-mobility-04#section-3.1

Yes, sure. What would prevent you from doing the same if you were to do 
mobility with trickle ICE? Obviously, the trickle updates would need to 
through the SIP server and they would potentially have to be 
re-authenticated, but nothing stops you from engaging in the semantics 
defined in MICE just because you are also doing trickle ICE.

>>> candidates in answer. The host, server reflexive, peer reflexive
>>> and relayed candidates of the remote peer may not change and the
>>> remote peer does not have to gather the candidates again. Trickle
>>> ICE will test local host candidates with all types of remote
>>> candidates provided by the remote peer in the answer. If the ICE
>>> peer is behind NAT performing end-point independent mapping and
>>> filtering then ICE connectivity checks initiated by the endpoint
>>> to the remote peer will succeed.
>>
>> Actually that's what you'd need the NAT to be without trickle ICE
>> so that break-before-make mice would succeed (which I've already
>> expressed as a concern with this draft).
>
> Section 3.1 ... Mobility using ICE could fail in case of Simultaneous
> Mobility or if the ICE peer is behind NAT that performs
> Address-Dependent Filtering (see Section 5 of [RFC5245])....

What I am saying is that rather than just warning about it, you could 
also resolve it with trickle ICE.

> And this concern could be addressed by either of the following
> techniques - Section 3.2 "Keeping unused relayed candidates active"

True. But this would be suboptimal.

> or Appendix A.2.1.  "Keeping unused candidates in the valid list
> active"

Not true. Keeping your server reflexive candidates alive wouldn't change 
anything in the case of a NAT with EPD filtering.

>> Using trickle ICE would allow you to succeed with endpoint
>> dependent filtering because the remote party would also start
>> checks in your direction.
>
> The problem in the above scenario is endpoint would just learn host
> candidates and inform them to the remote peer in offer,

I don't get this. Why would an endpoint only inform of host candidates? 
It would also inform of server-reflexive candidates as soon as it 
discovers them.

> so if the
> endpoint is behind endpoint independent filtering NAT and the remote
> peer is behind endpoint dependent filtering NAT (Let's say NAT X).
> The STUN connectivity checks sent by the endpoint will be blocked by
> X, STUN connectivity checks initiated by the remote peer will fail to
> reach the endpoint because it is behind NAT.

Again, this is the case *without* trickle ICE. If however you allowed 
trickle ICE to help MICE, the endpoint that's behind the EPD filtering 
NAT would eventually learn about your new candidates and also start 
sending checks there.

>> I guess what I am trying to say is that it doesn't make sense for
>> mice not to use trickle ICE for this case.
>
> MICE can be used with Trickle ICE, we are only responding to comments
> in the last IETF asking for the benefits of MICE in comparison with
> ICE restart and Trickle ICE.

My point is that MICE can not only be used with but also optimized with 
trickle ICE and made more reliable.

Cheers,
Emil

> when only one endpoint supports MICE, TURN server can be used to
> provide mobility (Section 5 - "Mobility using TURN"). The endpoint
> will use local relayed candidates for communicating with the remote
> peer. Even If endpoint roams and gets a new IP address, it will
> continue to reach the remote peer using the local relayed candidates
> as explained in section 5 (using the MOBILITY-TICKET). The remote
> peer will not even be aware that the endpoint IP address has
> changed.
>
> Regards, --Tiru.
>
>>
>> Cheers, Emil
>>
>>
>>
>>>
>>> Best Regards, --Authors.
>>>
>>> [mailto:[email-masked]] Sent: Monday, June 24, 2013
>>> 1:06 PM To: Prashanth Patil (praspati); Tirumaleswar Reddy
>>> (tireddy); Dan Wing (dwing); Pal Martinsen (palmarti) Subject:
>>> New Version Notification for
>>> draft-wing-mmusic-ice-mobility-04.txt
>>>
>>>
>>> A new version of I-D, draft-wing-mmusic-ice-mobility-04.txt has
>>> been successfully submitted by Dan Wing and posted to the IETF
>>> repository.
>>>
>>> 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
>>>
>>
>> -- https://jitsi.org
>

-- 
https://jitsi.org

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 26 Jun 2013 11:53:18 +0000

Hi Emil,

Please see inline

> Sent: Tuesday, June 25, 2013 8:42 PM
> mobility with trickle ICE ? Obviously, the trickle updates would need to

There seems to be some confusion, we also agree that MICE can be used with trickle ICE. There was comment when Dan presented this draft in IETF 86 that If trickle ICE is used then MICE is not required, we are only trying to address that comment.

> also resolve it with trickle ICE.

Based on your last comment we have updated the draft that the above problem will be handled by doing SIP re-registration/ICE restart in parallel, so that if MICE fails ICE restart would succeed for EPD filtering use-case. If endpoints support Trickle ICE it will also help in this scenario.

> anything in the case of a NAT with EPD filtering.

The unused candidates from other interfaces are kept-alive using STUN Binding request/response with the remote peer (it's explained in Appendix "A.2.1.1. Sending keep alive requests"). This approach can be used as a fail-over technique but brings in overhead and is only mentioned as a optional technique. 

> I don't get this. Why would an endpoint only inform of host candidates ?

Yes, I meant host candidates would be learnt quickly and informed to the remote peer using Trickle ICE (in step 1). The endpoint would also in parallel learn the server-reflexive candidates which would take some time, these candidates would be informed subsequently (in step 2). Step 1 could fail if remote peer is behind EPD filtering NAT, but step 2 would eventually succeed.

> NAT would eventually learn about your new candidates and also start

Agreed.
 
Best Regards,
--Tiru.