Subject: Re: [tram] New Version Notification for draft-reddy-tram-stun-path-data-00.txt

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 6 Jan 2015 12:19:42 +0000

> -----Original Message-----
> From: tram [mailto:[email-masked]] On Behalf Of Aijun Wang
> Sent: Tuesday, January 06, 2015 9:13 AM
> To: 'Brandon Williams'; Pal Martinsen (palmarti); Tirumaleswar Reddy
> (tireddy)
> Cc: 'Simon Perreault'; [email-masked]; 'Varun Singh'
> Subject: Re: [tram] New Version Notification for draft-reddy-tram-stun-path-
> data-00.txt
> 
> Hi, All:
> 
> The draft that given by Reddy illustrating some drawback of the current ICE
> solution(RFC5245), and actually provided another possible solution to
> improve it.  

ICE regular and aggressive nomination have certain drawbacks which will be dealt as part of ICE continuous nomination work in mmusic WG, ICE algorithm changes will not be covered in this draft. Note that this draft can also be used with regular ICE when there is no noticeable impact in setting up the media session,  It depends on the number of candidate pairs, time interval for pacing ICE connectivity checks and RTO values.

> I agree also that it is necessary for ICE to check connectivity
> continuously, but still hesitate to agree add more additional function to its
> role(such as RTT, loss rate, pathmtu etc.).

Why ?
Periodic ICE connectivity checks for media streams for consent freshness is already covered in http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-11 

> 
> The better solution may be to check the connectivity continuously, especially
> for the newly up interface, but only limited to the connectivity characteristic.
> The application layer should balance among these available interfaces that
> given by ICE, using their own RTT, loss rate detection and path-mtu finding
> solution. This can also reduce the latency of interface switching of the
> endpoint.

ICE continuous nomination allows checks on new interfaces and the path characteristics discovered using ICE can be used to switch-over the media stream to a new interface. It is discussed in http://juberti.github.io/draughts/nombis/draft-uberti-mmusic-nombis.html#section-3.1 

-Tiru

> 
> Best Regards.
> Aijun Wang.
> 
> > -----Original Message-----
> > From: Brandon Williams [mailto:[email-masked]]
> > Sent: Tuesday, January 06, 2015 7:09 AM
> > To: Pal Martinsen (palmarti); Tirumaleswar Reddy (tireddy)
> > Cc: Aijun Wang; Varun Singh; Simon Perreault; [email-masked]
> > Subject: Re: [tram] New Version Notification for
> > draft-reddy-tram-stun-path-data-00.txt
> >
> > Hi Pål-Erik,
> >
> > You wrote: Down play ICE usage. Focus on what a TRAM drafts should
> focus on.
> > (In this case provide RTT and loss information)
> >
> > I'm not certain exactly what you're looking for in the text. I don't
> > really see a meaningful use case for the RTT and loss stats outside of
> > the end-to-end context of the ICE use case, since using partial path
> > stats for decision making will often generate bad results. Do you see
> > a use case other than ICE? Or are you simply suggesting that the draft
> > should avoid referencing a specific use case altogether?
> >
> > Thanks,
> > --Brandon
> >
> >
> > On 01/05/2015 04:01 AM, Pal Martinsen (palmarti) wrote:
> > >
> > >> On 05 Jan 2015, at 08:27, Tirumaleswar Reddy (tireddy)
> > >> <[email-masked] <mailto:[email-masked]>> wrote:
> > >>
> > >>> -----Original Message-----
> > >>> From: tram [mailto:[email-masked]] On Behalf Of Aijun Wang
> > >>> Sent: Sunday, January 04, 2015 6:12 AM
> > >>> To: 'Varun Singh'; Tirumaleswar Reddy (tireddy)
> > >>> Cc: 'Simon Perreault'; [email-masked] <mailto:[email-masked]>;
> > >>> 'Brandon Williams'
> > >>> Subject: Re: [tram] FW: New Version Notification for
> > >>> draft-reddy-tram-stun-
> > >>> path-data-00.txt
> > >>>
> > >>> Hi, Singh, Reddy and Simon:
> > >>>
> > >>> I admitted that the path characteristic can be one factor to be
> > >>> considered and can be used to assist the endpoints to select the
> > >>> appropriate path. The main point of this value that different from
> > >>> other criteria defined in RFC5245 is that this value will be
> > >>> changed dynamically and is not determined.
> > >>> Consider the ICE connectivity check will be only done once for one
> > >>> communication session, is it appropriate for it to rely on one
> > >>> unreliable value to make the decision?
> > >>
> > >> No, consent freshness and ICE continuous nomination explain that
> > >> ICE connectivity checks happen even after candidates are nominated
> > >> for the media session. An interface can be picked based on the
> > >> current path characteristics, continue with ICE checks on other
> > >> interfaces or new interfaces discovered later and switch-over when
> > >> a better candidate pair is available.  For more information refer
> > >> to the discussion in mmusic WG
> > >> (http://juberti.github.io/draughts/nombis/draft-uberti-mmusic-nombis.
> > >> html)
> > >
> > > I do agree with Aijuns point that RFC5245 limits the usability of
> > > this draft. But as you point out there is a lot of discussions going
> > > on regarding how we can improve ICE, not all of those discussions
> > > are well known. To catch up, reading the MMUSIC mailing-list is
> > > probably a good
> > idea.
> > >
> > > To make it easier to read the draft I would propose to do the
> > > following in the next version.
> > >
> > > - Rename draft to “RTT and loss measurements of STUN Transactions”.
> > > Path characteristics seems to hint that other things like bandwidth
> > > and so on is also included.
> > > - Down play ICE usage. Focus on what a TRAM drafts should focus on.
> > > (In this case provide RTT and loss information)
> > >
> > >
> > > The DISCUSS draft
> > > (http://tools.ietf.org/id/draft-martinsen-tram-discuss-01.txt) also
> > > have the ability to provide useful information, but it requires
> > > support from the network to achieve this.
> > >
> > >
> > >>
> > >>> What would you do if it select one idle pair at first but it
> > >>> become congest later?
> > >>>
> > >>> I think the dynamic path selection should be left to and be
> > >>> considered by the application layer itself, such as RTCP protocol
> > >>> etc.
> > >>
> > >> In case of MPRTP,  Path characteristics discovered using ICE will
> > >> be used for picking the interface for the primary sub-flow and
> > >> interfaces for subsequent sub-flows and MPRTP RTCP report can be
> > >> used later for load balancing.
> > >>
> > >
> > > A short summary of my understanding of the MMUSIC ICE discussions is:
> > > - Use ICE to build a valid list
> > > - Redefined how we use that valid list. (Keeping pairs warm so we
> > > can switch to them fast ++)
> > > - Redefine when and how we chose an active candidate pair to send
> > > media
> > on.
> > >
> > > .-.
> > > Pål-Erik
> > >
> > >> -Tiru
> > >>
> > >>>
> > >>> Best Regards.
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: Varun Singh [mailto:[email-masked]]
> > >>>> Sent: Wednesday, December 31, 2014 7:50 PM
> > >>>> To: Tirumaleswar Reddy (tireddy)
> > >>>> Cc: Simon Perreault; Brandon Williams; [email-masked]
> > >>>> <mailto:[email-masked]>; Aijun Wang
> > >>>> Subject: Re: [tram] FW: New Version Notification for
> > >>>> draft-reddy-tram-stun-path-data-00.txt
> > >>>>
> > >>>> On Wed, Dec 31, 2014 at 8:19 AM, Tirumaleswar Reddy (tireddy)
> > >>>> <[email-masked] <mailto:[email-masked]>> wrote:
> > >>>>> Inline [TR]
> > >>>>> On Tue, Dec 30, 2014 at 9:31 AM, Brandon Williams
> > >>>>> <[email-masked]
> > <mailto:[email-masked]>>
> > >>>>> wrote:
> > >>>>>
> > >>>>> You are correct that the currently published RFC makes the path
> > >>>>> quality information harder to use in a meaningful way. However,
> > >>>>> there is ongoing work in both tram and mmusic focused on
> > >>>>> allowing more dynamic path selection that can use performance
> > >>>>> metrics rather than the currently defined static priorities.
> > >>>>> This draft is just one piece of that
> > >>>> bigger picture.
> > >>>>>
> > >>>>>
> > >>>>> You're right, of course, but if there's no way to make practical
> > >>>>> use of this draft with regular ICE, then that's useful
> > >>>>> information that needs to go into the draft. Ideally with
> > >>>>> pointers to the bigger picture you
> > >>>> mentioned.
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> [TR] we will update the introduction section to make it clear.
> > >>>>> This draft can be used with regular ICE when there is no
> > >>>>> noticeable impact in setting up the media session. It depends on
> > >>>>> the number of candidate pairs, time interval (Ta) for pacing ICE
> > >>>>> connectivity checks and
> > >>> RTO values.
> > >>>>>
> > >>>>
> > >>>> True. Path characteristics can be used in addition to the
> > >>>> proprietary criteria the endpoint currently implements. i.e., if
> > >>>> the endpoints wants to stop checking because it met its defined
> > >>>> criteria and was using the path characteristics as part of the
> > >>>> STUN messages, it could still use the path characteristics for
> > >>>> those candidates to make further
> > >>> decisions.
> > >>>>
> > >>>>
> > >>>>
> > >>>> --
> > >>>> http://www.netlab.tkk.fi/~varun/
> > >>>
> > >>>
> > >>>
> > >>> _______________________________________________
> > >>> tram mailing list
> > >>> [email-masked] <mailto:[email-masked]>
> > >>> https://www.ietf.org/mailman/listinfo/tram
> > >>
> > >> _______________________________________________
> > >> tram mailing list
> > >> [email-masked] <mailto:[email-masked]>
> > >> https://www.ietf.org/mailman/listinfo/tram
> > >
> >
> > --
> > Brandon Williams; Senior Principal Software Engineer Emerging Products
> > Engineering; Akamai Technologies Inc.
> 
> 
> 
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram

---

From: "Aijun Wang" <[email-masked]>
Date: Wed, 7 Jan 2015 13:38:55 +0800

Hi, Reddy,

Please see the reply inline.

Best Regards.

> From: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
> Sent: Tuesday, January 06, 2015 8:20 PM
> To: Aijun Wang; 'Brandon Williams'; Pal Martinsen (palmarti)
> Subject: RE: [tram] New Version Notification for
> > draft-reddy-tram-stun-path- data-00.txt
> >
> > Hi, All:
> >
> > The draft that given by Reddy illustrating some drawback of the
> > current ICE solution(RFC5245), and actually provided another possible
> > solution to improve it.
> 
> ICE regular and aggressive nomination have certain drawbacks which will be
> dealt as part of ICE continuous nomination work in mmusic WG, ICE algorithm
> changes will not be covered in this draft. Note that this draft can also be used
> with regular ICE when there is no noticeable impact in setting up the media
> session,  It depends on the number of candidate pairs, time interval for pacing
> ICE connectivity checks and RTO values.
> 
> > continuously, but still hesitate to agree add more additional function
> > to its role(such as RTT, loss rate, pathmtu etc.).
> 
> Why ?

The functions for detecting RTT, loss rate etc. are useful but not reliable and deterministic. Can you assure the applications that relied on them will be more efficiency and reliable? I prefer to putting all usable interfaces into a pool(via ICE continuously checking proposal) and give more flexibility to the application. More detections and decision can be made by the upper layer, not the ICE itself.
There are other large questions for the connectivity, for example, the NAT punching for the BEHAVE-compliant NAT devices and non BEHAVE-compliant NAT devices, the selection of appropriate TURN server when the TURN server are distributed deployed, the communication between IPv4 endpoint, IPv4/IPv6 endpoint and IPv6 endpoint etc. I think ICE should focus more on the solution of these challenges.

> Periodic ICE connectivity checks for media streams for consent freshness is
> already covered in
> http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-11
> 
I was also curious that how this problem that mentioned in this draft is raised. If the corresponding endpoint doesn't want to receive the data from other endpoint, it need just close the TCP/UDP session that built by ICE process, why should we use the consent freshness check?

> >
> > The better solution may be to check the connectivity continuously,
> > especially for the newly up interface, but only limited to the connectivity
> characteristic.
> > The application layer should balance among these available interfaces
> > that given by ICE, using their own RTT, loss rate detection and
> > path-mtu finding solution. This can also reduce the latency of
> > interface switching of the endpoint.
> 
> ICE continuous nomination allows checks on new interfaces and the path
> characteristics discovered using ICE can be used to switch-over the media
> stream to a new interface. It is discussed in
> http://juberti.github.io/draughts/nombis/draft-uberti-mmusic-nombis.html#se
> ction-3.1
> 
> -Tiru
> 
> >
> > Best Regards.
> > Aijun Wang.
> >
> > > really see a meaningful use case for the RTT and loss stats outside
> > > of the end-to-end context of the ICE use case, since using partial
> > > path stats for decision making will often generate bad results. Do
> > > you see a use case other than ICE? Or are you simply suggesting that
> > > the draft should avoid referencing a specific use case altogether?
> > >
> > > Thanks,
> > > --Brandon
> > >
> > >
> > > >>> appropriate path. The main point of this value that different
> > > >>> from other criteria defined in RFC5245 is that this value will
> > > >>> be changed dynamically and is not determined.
> > > >>> Consider the ICE connectivity check will be only done once for
> > > >>> one communication session, is it appropriate for it to rely on
> > > >>> one unreliable value to make the decision?
> > > >>
> > > >> ICE connectivity checks happen even after candidates are
> > > >> nominated for the media session. An interface can be picked based
> > > >> on the current path characteristics, continue with ICE checks on
> > > >> other interfaces or new interfaces discovered later and
> > > >> switch-over when a better candidate pair is available.  For more
> > > >> information refer to the discussion in mmusic WG
> > > > this draft. But as you point out there is a lot of discussions
> > > > going on regarding how we can improve ICE, not all of those
> > > > discussions are well known. To catch up, reading the MMUSIC
> > > > mailing-list is probably a good
> > > idea.
> > > >
> > > > Path characteristics seems to hint that other things like
> > > > bandwidth and so on is also included.
> > > > (http://tools.ietf.org/id/draft-martinsen-tram-discuss-01.txt)
> > > > also have the ability to provide useful information, but it
> > > > requires support from the network to achieve this.
> > > >
> > > >
> > > >>
> > > >>> considered by the application layer itself, such as RTCP
> > > >>> protocol etc.
> > > >>
> > > >>>>> You are correct that the currently published RFC makes the
> > > >>>>> path quality information harder to use in a meaningful way.
> > > >>>>> However, there is ongoing work in both tram and mmusic focused
> > > >>>>> on allowing more dynamic path selection that can use
> > > >>>>> performance metrics rather than the currently defined static
> priorities.
> > > >>>>> You're right, of course, but if there's no way to make
> > > >>>>> practical use of this draft with regular ICE, then that's
> > > >>>>> useful information that needs to go into the draft. Ideally
> > > >>>>> with pointers to the bigger picture you
> > > >>>> mentioned.
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>> noticeable impact in setting up the media session. It depends
> > > >>>>> on the number of candidate pairs, time interval (Ta) for
> > > >>>>> pacing ICE connectivity checks and
> > > >>> RTO values.
> > > >>>>>
> > > >>>>
> > > >>>> proprietary criteria the endpoint currently implements. i.e.,
> > > >>>> if the endpoints wants to stop checking because it met its
> > > >>>> defined criteria and was using the path characteristics as part
> > > >>>> of the STUN messages, it could still use the path
> > > >>>> characteristics for those candidates to make further
> > > >>> decisions.
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>> --
> > > Brandon Williams; Senior Principal Software Engineer Emerging
> > > Products Engineering; Akamai Technologies Inc.
> >
> >
> >