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

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 23 Dec 2014 15:29:25 +0000

This draft describes a mechanism for an endpoint to discover the path characteristics using STUN.
Comments and suggestions are welcome.

-Tiru
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, December 23, 2014 8:37 PM
To: Varun Singh; Tirumaleswar Reddy (tireddy); Dan Wing (dwing); Varun Singh; Tirumaleswar Reddy (tireddy); Pal Martinsen (palmarti); Dan Wing (dwing); Pal Martinsen (palmarti)
Subject: New Version Notification for draft-reddy-tram-stun-path-data-00.txt

A new version of I-D, draft-reddy-tram-stun-path-data-00.txt
has been successfully submitted by Tirumaleswar Reddy and posted to the IETF repository.

Name:		draft-reddy-tram-stun-path-data
Revision:	00
Title:		Discovery of path characteristics using STUN
Document date:	2014-12-23
Group:		Individual Submission
Pages:		9
URL:            http://www.ietf.org/internet-drafts/draft-reddy-tram-stun-path-data-00.txt
Status:         https://datatracker.ietf.org/doc/draft-reddy-tram-stun-path-data/
Htmlized:       http://tools.ietf.org/html/draft-reddy-tram-stun-path-data-00

Abstract:
   A host with multiple interfaces needs to choose the best interface
   for communication.  Oftentimes, this decision is based on a static
   configuration and does not consider the path characteristics, which
   may affect the user experience.

   This document describes a mechanism for an endpoint to discover the
   path characteristics using Session Traversal Utilities for NAT (STUN)
   messages.  The measurement information can then be used to influence
   the endpoint's Interactive Connectivity Establishment (ICE) candidate
   pair selection algorithm.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Simon Perreault <[email-masked]>
Date: Tue, 23 Dec 2014 10:35:30 -0500

Cool.

One thing caught my eye:

   To resolve the issue of
   identical request and response packets in a STUN transaction, this
   document changes that retransmission behavior for idempotent packets.

Is this actually true? I didn't find any such change.

Simon

On Tue, Dec 23, 2014 at 10:29 AM, Tirumaleswar Reddy (tireddy) <
[email-masked]> wrote:
> To: Varun Singh; Tirumaleswar Reddy (tireddy); Dan Wing (dwing); Varun
> Singh; Tirumaleswar Reddy (tireddy); Pal Martinsen (palmarti); Dan Wing
> (dwing); Pal Martinsen (palmarti)
> URL:
> http://www.ietf.org/internet-drafts/draft-reddy-tram-stun-path-data-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-reddy-tram-stun-path-data/
> Htmlized:
> http://tools.ietf.org/html/draft-reddy-tram-stun-path-data-00
>
>
> Abstract:
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
>
> The IETF Secretariat
>
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram
>

---

From: Jonathan Lennox <[email-masked]>
Date: Tue, 23 Dec 2014 15:58:05 +0000

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

---

From: 🔓Dan Wing <[email-masked]>
Date: Tue, 23 Dec 2014 08:11:09 -0800

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

-d

---

From: 🔓Dan Wing <[email-masked]>
Date: Tue, 23 Dec 2014 08:13:01 -0800

> Is this actually true? I didn't find any such change.

I agree it is not well described or separated from the rest of the text, but what we want to do is described in 3.0:

   If a client wishes to determine the path characteristics, it inserts
   the PATH-CHARACTERISTIC attribute in a STUN request.  In the PATH-
   CHARACTERISTIC attribute client sends the number of times the STUN
   request is retransmitted with the same Transaction ID.  

-d

> 
> Simon
> 
> On Tue, Dec 23, 2014 at 10:29 AM, Tirumaleswar Reddy (tireddy) <[email-masked]> wrote:

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 23 Dec 2014 17:55:22 +0000

From: Simon Perreault [mailto:[email-masked]]
Sent: Tuesday, December 23, 2014 9:06 PM
To: Tirumaleswar Reddy (tireddy)
Cc: [email-masked]
Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-stun-path-data-00.txt

Cool.

One thing caught my eye:

   To resolve the issue of

It is explained in section 3.1

<snip>
   This specification updates one the STUN message structuring rules
   explained in Section 6 of [RFC5389] that resends of the same request
   reuse the same transaction ID and are bit-wise identical to the
   previous request.  The ReTransCnt in the PATH-CHARACTERISTIC
   attribute will be incremented by 1 for every re-transmission and the
   re-transmitted STUN request MUST be bit-wise identical to the
   previous request except for the ReTransCnt value.
</snip>

-Tiru

Simon

On Tue, Dec 23, 2014 at 10:29 AM, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:
This draft describes a mechanism for an endpoint to discover the path characteristics using STUN.
Comments and suggestions are welcome.

-Tiru

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, December 23, 2014 8:37 PM
To: Varun Singh; Tirumaleswar Reddy (tireddy); Dan Wing (dwing); Varun Singh; Tirumaleswar Reddy (tireddy); Pal Martinsen (palmarti); Dan Wing (dwing); Pal Martinsen (palmarti)
Subject: New Version Notification for draft-reddy-tram-stun-path-data-00.txt

Abstract:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat

_______________________________________________
tram mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tram

---

From: Simon Perreault <[email-masked]>
Date: Tue, 23 Dec 2014 12:57:41 -0500

>    previous request except for the ReTransCnt value.

Ok, but the "for idempotent packets" part is missing. To be clear: is there
any difference in behaviour for Binding vs Allocate requests?

Simon

---

From: Brandon Williams <[email-masked]>
Date: Tue, 23 Dec 2014 14:26:50 -0500

On 12/23/2014 12:57 PM, Simon Perreault wrote:
>
> Ok, but the "for idempotent packets" part is missing. To be clear: is
> there any difference in behaviour for Binding vs Allocate requests?
>
> Simon

I agree that the draft needs a bit of clarification about usage.

I think the authors intend the new attribute to be used primarily 
(exclusively?) in the STUN Binding messages used for ICE connectivity 
checks. That way, it ends up representing the characteristics for 
end-to-end connectivity, not just the "first mile" into the relay. That 
said, the draft doesn't explicitly call this out, so confirmation on 
intent from the authors would be good.

--Brandon

-- 
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.

---

From: "Aijun Wang" <[email-masked]>
Date: Wed, 24 Dec 2014 14:36:50 +0800

Hi, Reddy:

I doubt the feasibility of this probe process. For UE that has multiple
interfaces, the OS of the UE will automatically choose only one default
interface for communicating. According to this draft, the ICE agent within
the UE will try every possible interface to send the STUN packet? This will
make the connection time between two endpoints unacceptable.

Best Regards. 

-----Original Message-----
From: tram [mailto:[email-masked]] On Behalf Of Tirumaleswar Reddy
(tireddy)
Sent: Tuesday, December 23, 2014 11:29 PM
To: [email-masked]
Subject: [tram] FW: New Version Notification for
draft-reddy-tram-stun-path-data-00.txt

This draft describes a mechanism for an endpoint to discover the path
characteristics using STUN.
Comments and suggestions are welcome.

-Tiru
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, December 23, 2014 8:37 PM
To: Varun Singh; Tirumaleswar Reddy (tireddy); Dan Wing (dwing); Varun

A new version of I-D, draft-reddy-tram-stun-path-data-00.txt
has been successfully submitted by Tirumaleswar Reddy and posted to the IETF
repository.

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 24 Dec 2014 10:02:47 +0000

> From: tram [mailto:[email-masked]] On Behalf Of Aijun Wang
> Sent: Wednesday, December 24, 2014 12:07 PM
> To: Tirumaleswar Reddy (tireddy); [email-masked]
> interface for communicating. 

No, MPTCP on mobile devices already uses multiple interfaces (for example Apple uses MPTCP for Siri).  MPRTP (draft-ietf-avtcore-mprtp-00) also uses multiple interfaces.

> According to this draft, the ICE agent within the
> UE will try every possible interface to send the STUN packet? 
> This will make
> the connection time between two endpoints unacceptable.

The new attribute can be added to the STUN binding request/response used for ICE connectivity checks and does not introduce any additional messages.

-Tiru

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

---

From: "Aijun Wang" <[email-masked]>
Date: Fri, 26 Dec 2014 00:36:03 +0800

Hi, Reddy

Please see the reply inline below.

> From: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
> Sent: Wednesday, December 24, 2014 6:03 PM
> To: Aijun Wang; [email-masked]
> Subject: RE: [tram] FW: New Version Notification for
> > Subject: Re: [tram] FW: New Version Notification for
> > draft-reddy-tram-stun- path-data-00.txt
> >
> > Hi, Reddy:
> >
> > I doubt the feasibility of this probe process. For UE that has
> > multiple interfaces, the OS of the UE will automatically choose only
> > one default interface for communicating.
> 
> No, MPTCP on mobile devices already uses multiple interfaces (for example
> Apple uses MPTCP for Siri).  MPRTP (draft-ietf-avtcore-mprtp-00) also uses
> multiple interfaces.
> 

The purpose of MPTCP and MPRTP is just contrary to your proposal. They just
want to utilize all the available paths for TCP or RTP chunk data transport,
but this draft just wants to select one best pair? On the other hand, there
is also other factor needed to be considered for selecting the underlying
network, for example the prices of different connection. I think the users
themselves should decide which one and how many interfaces can be used for
data transfer, not one of the application on their devices.

> > According to this draft, the ICE agent within the UE will try every
> > possible interface to send the STUN packet?
> > This will make
> The new attribute can be added to the STUN binding request/response used
for
> ICE connectivity checks and does not introduce any additional messages.
> 
The checking results can't be kept consistency all the time. How about the
selected interface become congested when it begins to transfer the chunk
data? From this point, the MPTCP and MPRTP may be more reasonable solution.
It can balance between different links/interfaces, not just select only one
that looks like idle.

> > draft-reddy-tram-stun-path- data-00.txt
> >
> > Singh; Tirumaleswar Reddy (tireddy); Pal Martinsen (palmarti); Dan
> > Wing (dwing); Pal Martinsen (palmarti)
tools.ietf.org.

---

From: "Aijun Wang" <[email-masked]>
Date: Fri, 26 Dec 2014 19:45:54 +0800

Hi, Varun,

ICE defines three types candidates: HOST CANDIDATE, REFELXTIVE CANDIDATE, RELAY CANDIDATE.  For UE that has multiple interfaces(for examples m interfaces), it will have 3*m CANDIDATE. If we uses the mechanism that described in this draft to select the best local interface, the UE must try all of these interfaces to send the STUN request message. Correspondingly, the communication pair will try  [3*m]*[3*m] times connectivity check to find the path that has best characteristics?

This will certainly make the connection process unacceptable. To solve such problem, we should prefer the process that described in the RFC5245(https://datatracker.ietf.org/doc/rfc5245/),  section 4.1.2.  “Prioritizing Candidates” first, then do the ICE connectivity check in sequence. The prioritizing algorithm should consider several factors, such as the security, prices, power consumption etc.  

The path characteristic, such as loss, RTT, jitter can also be considered, but this information should be acquired via other out-band method, not the in-band solution that described in this draft.

Best Regards.

Aijun Wang.

From: Varun Singh [mailto:[email-masked]] 
Sent: Friday, December 26, 2014 5:35 AM
To: Aijun Wang
Cc: Tirumaleswar Reddy (tireddy); [email-masked]
Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-stun-path-data-00.txt

Hi Aijun,

Comments inline.

Cheers,

Varun. 

On Thursday, December 25, 2014, Aijun Wang <[email-masked]> wrote:

Hi, Reddy

> From: Tirumaleswar Reddy (tireddy) [mailto:[email-masked] <javascript:;> ]
> To: Aijun Wang; [email-masked] <javascript:;> 
> > From: tram [mailto:[email-masked] <javascript:;> ] On Behalf Of Aijun Wang
> > To: Tirumaleswar Reddy (tireddy); [email-masked] <javascript:;> 

IMO the draft exposes two transport characteristics: RTT measurement, and loss (upstream and downstream path). While there may be additional metrics like jitter, power consumption, and as you point out money.

The users typically choose interfaces (allowing access to the 3G/LTE at the system level, but this can easily be exposed at the app level), which then becomes a system policy. And this mechanism can still work by skipping the candidate gathering phase for interfaces i.e., not allowed access by user/system settings.

for

The metrics gathered from the connectivity checks should be fed upwards into the rmcat or towards the congestion control, which can make the appropriate decision. 

> > From: tram [mailto:[email-masked] <javascript:;> ] On Behalf Of Tirumaleswar
> > Reddy
> > (tireddy)
> > To: [email-masked] <javascript:;> 
> > From: [email-masked] <javascript:;>  [mailto:[email-masked] <javascript:;> ]
tools.ietf.org.
> > [email-masked] <javascript:;> 
> > [email-masked] <javascript:;> 

_______________________________________________
tram mailing list
[email-masked] <javascript:;> 
https://www.ietf.org/mailman/listinfo/tram

-- 
http://www.netlab.tkk.fi/~varun/

---

From: Varun Singh <[email-masked]>
Date: Wed, 24 Dec 2014 15:16:49 +0200

Hi,

If we follow through with the proposal on continuous nomination, we should
be able to pick better candidate pairs (based on loss, RTT) as and when
they appear. However, we won't know the available capacity until we send
media packets on it, but that is the job for the RTP congestion control to
figure out anyway.

Cheers,
Varun.

On Wednesday, December 24, 2014, Aijun Wang <[email-masked]>
wrote:

> From: tram [mailto:[email-masked] <javascript:;>] On Behalf Of
> Tirumaleswar Reddy
> (tireddy)
> From: [email-masked] <javascript:;> [mailto:
> [email-masked] <javascript:;>]
> submission

---

From: Varun Singh <[email-masked]>
Date: Thu, 25 Dec 2014 23:34:50 +0200

Hi Aijun,

Comments inline.

Cheers,
Varun.

On Thursday, December 25, 2014, Aijun Wang <[email-masked]>
wrote:

> > From: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]
> <javascript:;>]
> Aijun Wang

IMO the draft exposes two transport characteristics: RTT measurement, and
loss (upstream and downstream path). While there may be additional metrics
like jitter, power consumption, and as you point out money.

> The users typically choose interfaces (allowing access to the 3G/LTE at
the system level, but this can easily be exposed at the app level), which
then becomes a system policy. And this mechanism can still work by skipping
the candidate gathering phase for interfaces i.e., not allowed access by
user/system settings.

> It can balance between different links/interfaces, not just select only one
The metrics gathered from the connectivity checks should be fed upwards
into the rmcat or towards the congestion control, which can make the
appropriate decision.

> Tirumaleswar

---

From: Varun Singh <[email-masked]>
Date: Fri, 26 Dec 2014 20:29:33 +0200

Hi Aijun,

Responses inline.

On Fri, Dec 26, 2014 at 1:45 PM, Aijun Wang <[email-masked]> wrote:
> Hi, Varun,
>
>
>
> ICE defines three types candidates: HOST CANDIDATE, REFELXTIVE CANDIDATE,
> RELAY CANDIDATE.  For UE that has multiple interfaces(for examples m
> interfaces), it will have 3*m CANDIDATE. If we uses the mechanism that
> described in this draft to select the best local interface, the UE must try
> all of these interfaces to send the STUN request message. Correspondingly,
> the communication pair will try  [3*m]*[3*m] times connectivity check to
> find the path that has best characteristics?
>

IMO, the endpoint would have to check the gathered interfaces any way. RFC5245
describes two mechanisms: Aggressive and Regular nomination to finally pick the
candidate pair to send media (Section 8.1.1.x).

This draft proposes that the endpoint could use the candidate pair with
better path characteristics instead of picking the highest priority pair.

>
>
> This will certainly make the connection process unacceptable. To solve such
> problem, we should prefer the process that described in the
> RFC5245(https://datatracker.ietf.org/doc/rfc5245/),  section 4.1.2.
> “Prioritizing Candidates” first, then do the ICE connectivity check in
> sequence. The prioritizing algorithm should consider several factors, such
> as the security, prices, power consumption etc.
>

I may be wrong, but the co-authors should correct me: AFAIU the proposal does
not change the order or the testing the list of candidates, but the
outcome of the
testing. i.e., once the candidates have been ordered and tested, the endpoint
can use the candidate pair with better path characteristics even though it has
a lower priority compared to the other successful candidates. Further, this
should be information

>
>
> The path characteristic, such as loss, RTT, jitter can also be considered,
> but this information should be acquired via other out-band method, not the
> in-band solution that described in this draft.

Sure, out-of-band mechanisms can be used as well. However, the endpoints are
anyway performing connectivity checks, it provides a perfect opportunity to get
some measurements before sending any media packets on those paths.
Further, the STUN packets are good enough for performing RTT measurements
as they are sent out at regular intervals.

> The users typically choose interfaces (allowing access to the 3G/LTE at the
> system level, but this can easily be exposed at the app level), which then
> becomes a system policy. And this mechanism can still work by skipping the
> candidate gathering phase for interfaces i.e., not allowed access by
> user/system settings.
>
>
>
> The metrics gathered from the connectivity checks should be fed upwards into
> the rmcat or towards the congestion control, which can make the appropriate
> decision.
>
>
>
>> -Tiru
>>
>> >
>> > Best Regards.
>> >

---

From: Simon Perreault <[email-masked]>
Date: Mon, 29 Dec 2014 09:48:07 -0500

On Fri, Dec 26, 2014 at 6:45 AM, Aijun Wang <[email-masked]>
wrote:
> This will certainly make the connection process unacceptable.
>

The ICE process is already how you describe (except there's usually only 1
relayed candidate per address family). That's why e.g., trickle ICE was
created: to speed things up.

This draft doesn't change the number of messages or candidates, so I view
this line of argument as applying to ICE in general, and therefore
irrelevant to this draft.

Simon

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 30 Dec 2014 08:40:50 +0800

Hi, Simon:

The process for ICE that described in RFC5245 is following:

 8.1.1.1.  Regular Nomination

   With regular nomination, the agent lets some number of checks

   complete, each of which omit the USE-CANDIDATE attribute.  Once one

   or more checks complete successfully for a component of a media

   stream, valid pairs are generated and added to the valid list.  The

   agent lets the checks continue until some stopping criterion is met,

   and then picks amongst the valid pairs based on an evaluation

   criterion.  The criteria for stopping the checks and for evaluating

   the valid pairs is entirely a matter of local optimization.

So, the ICE agent is not required to check all the connection possibility. Once this is not mandatory, the information that get from the “path characteristic attribute” is not complete, and can’t be used to  assist the selection of best path. If it requires to check all the connection possibility, the latency for connection will certainly be prolonged.

In another section of RFC5245, it is described as following:

8.1.2.  Updating States
 
   For both controlling and controlled agents, the state of ICE
   processing depends on the presence of nominated candidate pairs in
   the valid list and on the state of the check list.  Note that, at any
   time, more than one of the following cases can apply:
 
   o  If there are no nominated pairs in the valid list for a media
      stream and the state of the check list is Running, ICE processing
      continues.
 
   o  If there is at least one nominated pair in the valid list for a
      media stream and the state of the check list is Running:
 
      *  The agent MUST remove all Waiting and Frozen pairs in the check
         list and triggered check queue for the same component as the
         nominated pairs for that media stream.
 
      *  If an In-Progress pair in the check list is for the same
         component as a nominated pair, the agent SHOULD cease
         retransmissions for its check if its pair priority is lower
         than the lowest-priority nominated pair for that component.

This section demonstrated that the check list and checking process are controlled by the pair priority, the lowest priority pair will not be checked once some criterion is met. And we can also find in this RFC, that the pair priority is predefined, independence of the results of path characteristic. 

Best Regards.

Aijun Wang.

From: Simon Perreault [mailto:[email-masked]] 
Sent: Monday, December 29, 2014 10:48 PM
To: Aijun Wang
Cc: Varun Singh; [email-masked]; Tirumaleswar Reddy (tireddy)
Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-stun-path-data-00.txt

On Fri, Dec 26, 2014 at 6:45 AM, Aijun Wang <[email-masked]> wrote:

The ICE process is already how you describe (except there's usually only 1 relayed candidate per address family). That's why e.g., trickle ICE was created: to speed things up.

This draft doesn't change the number of messages or candidates, so I view this line of argument as applying to ICE in general, and therefore irrelevant to this draft.

Simon

---

From: Simon Perreault <[email-masked]>
Date: Tue, 30 Dec 2014 09:31:35 -0500

On Mon, Dec 29, 2014 at 7:40 PM, Aijun Wang <[email-masked]>
wrote:
>
> So, the ICE agent is not required to check all the connection possibility.
> Once this is not mandatory, the information that get from the “path
> characteristic attribute” is not complete, and can’t be used to  assist the
> selection of best path. If it requires to check all the connection
> possibility, the latency for connection will certainly be prolonged.

Ok I think I understand what you mean now: although this draft doesn't
change ICE behaviour per se, in practice the successful use of the STUN
attribute it introduces would require such a change. The behaviour change
is that the ICE agent now needs to perform connectivity checks on all
candidate pairs in order to be able to use the measured RTTs as input to
the nomination algorithm. Is this a fair rewording?

Thanks,
Simon

---

From: Brandon Williams <[email-masked]>
Date: Tue, 30 Dec 2014 09:31:51 -0500

Hi Aijun,

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.

--Brandon

On 12/29/2014 07:40 PM, Aijun Wang wrote:
> So, the ICE agent is not required to check all the connection
> possibility. Once this is not mandatory, the information that get from
> the “path characteristic attribute” is not complete, and can’t be used
> to  assist the selection of best path. If it requires to check all the
> connection possibility, the latency for connection will certainly be
> prolonged.
>
> This section demonstrated that the check list and checking process are
> controlled by the pair priority, the lowest priority pair will not be
> checked once some criterion is met. And we can also find in this RFC,
> that the pair priority is predefined, independence of the results of
> path characteristic.
>
> Best Regards.
>
> Aijun Wang.
>
> *From:*Simon Perreault [mailto:[email-masked]]
> *Sent:* Monday, December 29, 2014 10:48 PM
> *To:* Aijun Wang
> *Cc:* Varun Singh; [email-masked]; Tirumaleswar Reddy (tireddy)
> *Subject:* Re: [tram] FW: New Version Notification for
> On Fri, Dec 26, 2014 at 6:45 AM, Aijun Wang <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> ICE defines three types candidates: HOST CANDIDATE, REFELXTIVE
> CANDIDATE, RELAY CANDIDATE.  For UE that has multiple interfaces(for
> examples m interfaces), it will have 3*m CANDIDATE. If we uses the
> mechanism that described in this draft to select the best local
> interface, the UE must try all of these interfaces to send the STUN
> request message. Correspondingly, the communication pair will try
>   [3*m]*[3*m] times connectivity check to find the path that has best
> characteristics?
>
> The ICE process is already how you describe (except there's usually only
> 1 relayed candidate per address family). That's why e.g., trickle ICE
> was created: to speed things up.
>
> This draft doesn't change the number of messages or candidates, so I
> view this line of argument as applying to ICE in general, and therefore

---

From: Simon Perreault <[email-masked]>
Date: Tue, 30 Dec 2014 09:36:59 -0500

> defined static priorities. This draft is just one piece of that bigger

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.

Simon

---

From: Brandon Williams <[email-masked]>
Date: Tue, 30 Dec 2014 14:20:49 -0500

The draft already has a placeholder in the section on use cases to 
discuss the proposed ICE candidate nomination updates with a link to 
Justin's not-yet-submitted draft. My read of the introduction is that it 
intends to call out the problem of using this performance information in 
the context of RFC5245 defined priorities, but I agree that it could be 
clearer in that regard.

--Brandon

On 12/30/2014 09:36 AM, Simon Perreault wrote:
>
> 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.
>
>
> 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.
>
> Simon