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

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

> -----Original Message-----
> From: Emil Ivov [mailto:[e-mail]]
> Sent: Monday, September 17, 2012 10:39 PM
> To: Tirumaleswar Reddy (tireddy)
> Cc: [e-mail]; 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,
> 
> On 17.09.12, 18:47, Tirumaleswar Reddy (tireddy) wrote:
> > 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.*
> 
> 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, 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.
> 
> 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:[e-mail]]
> >> Sent: Thursday, September 13, 2012 2:59 PM
> >> To: Tirumaleswar Reddy (tireddy)
> >> Cc: [e-mail]
> >> 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
> >>
> >> 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: [e-mail]_
> <mailto:[e-mail]> Subject: FW: New
> >> >> Version Notification for draft-wing-mmusic-ice- mobility-01.txt
> >> >>
> >> >> -----Original Message----- From: [e-mail]_
> <mailto:[e-mail]>
> >> >> _[mailto:[e-mail]]_
> > <mailto:[mailto:[e-mail]]> 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
> >> > [e-mail]_ <mailto:[e-mail]>
> > _https://www.ietf.org/mailman/listinfo/mmusic_
> >> >