Subject: [MMUSIC] Comment on draft-wing-mmusic-ice-mobility-01

From: Martin Thomson <[email-masked]>
Date: Wed, 12 Sep 2012 17:07:26 -0700

I think that this is a worthwhile problem to solve.  I have a concern
about the mechanism.

Specifically:

   3.  If this interface is the only suitable interface for media (that
       is, other suitable interfaces have been lost), then the
       connectivity check from the previous step SHOULD also include the
       USE-CANDIDATE attribute to signals an aggressive nomination (see
       Section 2.6 of [RFC5245]), and media MAY immediately begin
       flowing over that interface.

This assumes that the IP:port pair that was previously in use reaches
the same host from the new interface.  I understand the desire to send
straight away, and requiring aggressive nomination even where it is
not normally used is reasonable, but sending prior to a connectivity
check is not a good idea.

Note: Step 4 of the same procedure is initiated on the *other* ICE
peer.  That is, the one that is not suffering a mobility event.  That
is very much unclear from the text.

--Martin

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 17 Sep 2012 17:30:20 +0000

> -----Original Message-----
> From: Martin Thomson [mailto:[email-masked]]
> Sent: Monday, September 17, 2012 10:09 PM
> To: Tirumaleswar Reddy (tireddy)
> Cc: Dan Wing (dwing); Prashanth Patil (praspati); Pal Martinsen (palmarti)
> Subject: Re: Re : [MMUSIC] Comment on draft-wing-mmusic-ice-mobility-01
> 
> Hi Tiru,
> 
> Is there any particular reason that you did not include the mmusic
> list in your reply ?
Added mmusic list.
> 
> Would it not be sufficient to make the following observations (which
> don't even require RFC 2119 language):
>  - a new interface arriving triggers the creation of a new local candidate
>  - a new local candidate is added to a pair with all known remote candidates
>  - connectivity checking can be performed on new candidate pairs
>  - aggressive nomination might be more efficient if the interface
> change leaves you with no active interfaces (if it weren't already
> obvious that 1 RTT < 2 RTT)

Aggressive nomination explained in section 3.1 is only relevant for scenarios involving "break before make" and not for other scenarios. 
If it is "make before break" then the Mobile Device can re-establish connection with SIP proxy using the new interface, gather new candidates for the new interface, send updated offer/answer and use ICE restart. Only after the media starts flowing using the new interface disable the old interface.

we will include more description on when it should be used.

> 
> Signalling MOBILITY-EVENT is not something that is adequately
> explained by your text, concentrating as it does on the what and not
> the why.  I might infer from the behaviour that MOBILITY-EVENT
> indicates that other interfaces are invalid.  

Yes, this is scenario of interest to Mobility using ICE.

> I would prefer not to
> have the valid lists cleared completely as a result of a *new*
> interface.  The behaviour you describe is more appropriate for the
> event where all existing interfaces drop.
> I'd prefer to see a clear description of the semantics of the
> MOBILITY-EVENT.  
> The more that I think on it, the less I am convinced
> of its value.  For instance, I believe it to be a better model to
> assume that ICE never completes, it just occasionally produces a
> usable pair of transport addresses.  I'd be happy to be convinced
> otherwise, of course.
> 
> 
> Nits:
> ICE doesn't talk about media streams.  It might be good to use
> terminology consistent with RFC 5245.

Thanks, we will fix that in the next version.

--Tiru.

> 
> --Martin
> 
> On 17 September 2012 05:44, Tirumaleswar Reddy (tireddy)
> <[email-masked]> wrote:
> > Hi Martin –
> >
> >
> >
> > Thanks for the comments, please see inline [Tiru]
> >
> >
> >
> >> Message: 1
> >
> >> Date: Wed, 12 Sep 2012 17:07:26 -0700
> >
> >> From: Martin Thomson <[email-masked]>
> >
> >> To: [email-masked]
> >
> >> Subject: [MMUSIC] Comment on draft-wing-mmusic-ice-mobility-01
> >
> >> Message-ID:
> >
> >>     <[email-masked]>
> >
> >> Content-Type: text/plain; charset=UTF-8
> >
> >>
> >
> > Our intention is to send media straight away only after ICE connectivity
> > check is successful using aggressive nomination. We will fix the text for
> > point 3.
> >
> >
> >
> >>
> >
> > We are updating sections 3.1 and 3.2, Please let know if the below
> > explanation makes it better
> >
> >
> >
> > 3.1.  Gaining an Interface
> >
> >
> >
> >    When gaining an interface which is suitable to send media by the
> >
> >    host's policy (if any), the ICE endpoint performs ICE Mobility.  ICE
> >
> >    Mobility is performed by:
> >
> >
> >
> >    1.  The ICE endpoint clears its ICE check list and ICE Valid List.
> >
> >
> >
> >    2.  The ICE endpoint initiating an ICE connectivity check on the new
> >
> >        interface, with the MOBILITY-EVENT attribute.
> >
> >
> >
> >        flowing over that interface after ICE connectivity check is
> > successful.
> >
> >
> >
> >    4.  The ICE endpoint performs "Discovering Peer Reflexive Candidates"
> >
> >        (Section 7.1.3.2.1 of [RFC5245]), "Constructing a Valid Pair"
> >
> >        (Section 7.1.3.2.2 of [RFC5245]), "Updating Pair States" (Section
> >
> >        7.1.3.2.3 of [RFC5245]), and "Updating the Nominated Flag"
> >
> >        (Section 7.1.3.2.4 of [RFC5245]).
> >
> >
> >
> >    5.  If the ICE connectivity check succeeds then ICE agents creates a
> >
> >        new pair, adds the pair to the valid list and marks it as
> >
> >        selected.  The ICE agent can now send media using the newly
> >
> >        selected candidate pair, even if it is running in Regular
> >
> >        Nomination mode.
> >
> >
> >
> >    6.  Once ICE connectivity checks for all of the media streams are
> >
> >        completed, the controlling ICE endpoint follows the procedures in
> >
> >        Section 11.1 of [RFC5245], specifically to send updated offer if
> >
> >        the candidates in the m and c lines for the media stream (called
> >
> >        the DEFAULT CANDIDATES) do not match ICE's SELECTED CANDIDATES
> >
> >        (also see Appendix B.9 of [RFC5245]).
> >
> >
> >
> > 3.2.  Receiving ICE Mobility event
> >
> >
> >
> >    A STUN Binding Request containing the MOBILITY-EVENT attribute MAY be
> >
> >    received by an ICE endpoint.  If this is received before the endpoint
> >
> >    is in the ICE Completed state, it should be silently discarded.
> >
> >
> >
> >    The agent remembers the highest-priority nominated pairs in the Valid
> >
> >    list for each component of the media stream, called the previous
> >
> >    selected pairs.  It continues sending media to that address until it
> >
> >    finishes with the steps described below.  Because those packets might
> >
> >    not be received due to the mobility event, it MAY cache a copy of
> >
> >    those packets.
> >
> >
> >
> >    1.  The ICE endpoint clears its ICE check list and ICE Valid List.
> >
> >
> >
> >    2.  The ICE agent constructs a pair whose local candidate is equal to
> >
> >        the transport address on which the STUN request was received with
> >
> >        MOBILITY-EVENT attribute, and a remote candidate equal to the
> >
> >        source transport address where the STUN request came from.  The
> >
> >        ICE agent will perform triggered check using this new pair and if
> >
> >        the connectivity check is successful, the pair is then added to
> >
> >        the valid list.  The agent sets the nominated flag in the valid
> >
> >        pair to true and can now use the new pair for sending media.
> >
> >
> >
> > --Tiru.
> >
> >
> >
> >>
> >
> >> --Martin
> >
> >