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

From: "Aijun Wang" <[email-masked]>
Date: Sun, 4 Jan 2015 08:41:49 +0800

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

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]; 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]> wrote:
> > Inline [TR]
> > On Tue, Dec 30, 2014 at 9:31 AM, Brandon Williams
> > <[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/

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 05 Jan 2015 06:12:07 -0700

On 12/23/2014 09:11 AM, 🔓Dan Wing wrote:
> 
> On Dec 23, 2014, at 7:58 AM, Jonathan Lennox <[email-masked]> wrote:
> 
>>
>> On Dec 23, 2014, at 10:29 AM, Tirumaleswar Reddy (tireddy) <[email-masked]> wrote:
>>
>>> This draft describes a mechanism for an endpoint to discover the path characteristics using STUN.
>>> Comments and suggestions are welcome.
>>
>> One other path characteristic that it would be useful to be able to learn is Path MTU.
>>
>> The natural way to do this would be to support the ICE attribute PADDING (0x0026) (from RFC 5780) in the ICE connectivity/consent STUN usages, though for backward compatibility we may need to resurrect the optional flavor of PADDING (0x8026) from draft-ietf-behave-nat-behavior-discovery-00.
>>
>> This doesn’t necessarily need to be specified in this same draft, of course, but it seems related.
> 
> Yes, we should determine the path's MTU.  Marc wrote http://tools.ietf.org/html/draft-petithuguenin-behave-stun-pmtud but it expired in 2009.
> 

Thanks Dan.  As it seems that there is some renewed interest in this draft, I published a new version few minutes ago.

This is the same text that was published back in 2009, just refreshed for new publication.  I'll publish a more complete version at the end of the week.

- -- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug