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

Hey Tiru,

On 25.06.13, 14:41, Tirumaleswar Reddy (tireddy) wrote:
> Hi Emil,
>
> Thanks for the review. Please see inline
>
>> -----Original Message----- From: Emil Ivov
>> [mailto:emcho@jitsi.org] Sent: Monday, June 24, 2013 7:32 PM To:
>> Tirumaleswar Reddy (tireddy) Cc: mmusic@ietf.org Subject: Re:
>> [MMUSIC] FW: New Version Notification for draft-wing-mmusic-ice-
>> mobility-04.txt
>>
>> 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 ?
>
> 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.

>>> 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).
>
> 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])....

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

>>> 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.
>
> 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.
>>>
>>> -----Original Message----- From: internet-drafts@ietf.org
>>> [mailto:internet-drafts@ietf.org] 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 mmusic@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>
>>
>> -- https://jitsi.org
>

-- 
https://jitsi.org