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

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

Hi Emil,

Thanks for the review. Please see inline

> -----Original Message-----
> From: Emil Ivov [mailto:[e-mail]]
> Sent: Monday, June 24, 2013 7:32 PM
> To: Tirumaleswar Reddy (tireddy)
> Cc: [e-mail]
> 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 

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

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"

> 
> 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, 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.

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

> 
> > 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: [e-mail]
> > [mailto:[e-mail]] 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
> > [e-mail] https://www.ietf.org/mailman/listinfo/mmusic
> >
> 
> --
> https://jitsi.org