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

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

Hi Emil,

Please see inline

> -----Original Message-----
> From: Emil Ivov [mailto:[e-mail]]
> Sent: Tuesday, June 25, 2013 8:42 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 25.06.13, 14:41, Tirumaleswar Reddy (tireddy) wrote:
> > 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
> 
> 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.

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.

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

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.

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

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. 

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

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.

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

Agreed.
 
Best Regards,
--Tiru.

> 
> >> 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: [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
> >
> 
> --
> https://jitsi.org