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

[Emil Ivov <[e-mail]>]

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?

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

Using trickle ICE would allow you to succeed with endpoint dependent 
filtering because the remote party would also start checks in your 
direction.

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.

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

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