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

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 5 Jan 2015 07:27:33 +0000

> -----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]; '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)

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

-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]; 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/
> 
> 
> 
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Mon, 5 Jan 2015 09:01:34 +0000

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

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.

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

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:

_______________________________________________
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

---

From: Brandon Williams <[email-masked]>
Date: Mon, 05 Jan 2015 18:10:25 -0500

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:
>>
>>> Cc: 'Simon Perreault'; [email-masked] <mailto:[email-masked]>; 'Brandon
>>> Williams'
>> 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.
>
> - 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.
>
>
>>
>> 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.
>>
>
>>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>>> Inline [TR]
>>>>> <[email-masked] <mailto:[email-masked]>>
>>>>> wrote:
>>>>>
>>> [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>

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

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

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 6 Jan 2015 11:42:38 +0800

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

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.

Best Regards.
Aijun Wang.

> 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
> 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
> 
> 
> >>> Cc: 'Simon Perreault'; [email-masked] <mailto:[email-masked]>;
> >>> 'Brandon Williams'
> >>> 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.
> >>> communication session, is it appropriate for it to rely on one
> >>> unreliable value to make the decision?
> >>
> >> 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
> > 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.
> >
> > - 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.
> >>
> >> 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.
> >>
> >
> >>>>> 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.
> >>>>
> >>>>
> >>>>
> >>>> --
> Brandon Williams; Senior Principal Software Engineer Emerging Products
> Engineering; Akamai Technologies Inc.

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Tue, 6 Jan 2015 09:31:48 +0000

> On 06 Jan 2015, at 00:10, Brandon Williams <[email-masked]> wrote:
> 
> 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?
> 

What I had in mind with downplay was to not use so many words describing ICE in the abstract and introduction. We can safely remove the first paragraph in both the abstract and introduction. We do not want to mandate how ICE should use this, but only say that this is useful for the different ICE scenarios. 

So the new abstract will be:
"This document describes how to extend Session Traversal Utilities for
  NAT (STUN) to measure the transaction RTT and count lost transaction
  packets.  This information can be used by Interactive Connectivity
  Establishment (ICE) to improve the active path selection.”

New Introduction:
"This draft extends STUN [RFC5389] to distinguish STUN responses to
  re-transmitted requests and assists the client in determining the
  path characteristics round-trip time (RTT) and packet loss in each
  direction between endpoints.

  When measuring RTT on stun requests re-transmits can cause an
  otherwise-good path to appear flawed.  However, STUN's retransmission
  algorithm [RFC5389] cannot determine the round-trip time if a STUN
  request packet is re-transmitted, because each packet request and
  retransmission is identical.

  To resolve the issue of identical request and response packets in a
  STUN transaction, this document changes that retransmission behavior
  for idempotent packets.  In addition to determining RTT, it is also
  desirable to detect which path direction caused packet loss,
  described as "bi-directional path characteristics," below.  This is
  achieved by defining a new STUN attribute and requires compliant STUN
  (TURN, ICE) servers to count retransmitted request packets.”

.-.
Pål-Erik

>>>> considered
>>>> considered by the

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Tue, 6 Jan 2015 09:52:27 +0000

> On 06 Jan 2015, at 04:42, Aijun Wang <[email-masked]> wrote:
> 
> Hi, All:
> 
The draft identifies problems measuring end to end RTT and packet loss with the current defined STUN transaction solution. If that is solved it can provide useful information to the next generation of ICE specs. We can fix STUN problems here in TRAM, new ICE solutions should ideally be discussed in MMUSIC. But some crossover is unavoidable. 

I would also like to point out that at least some webRTC ICE implementations have a different solution to this problem. As they only can send a STUN packet every 50ms(?), they chose to simplify the connectivity checks by ignoring the STUN Transaction part. They will fire off a new STUN packet every x ms, and if it happen to be a retransmit it will get a new Transaction ID.  This approach makes it trivial to measure RTT. 

> 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 a…
Much of this can be decided at the application level if we provide the right building blocks on the lower layers. I agree that making ICE to smart without letting the application decide vital parts is a slippery slope. 

.-.
Pål-Erik

---

From: Varun Singh <[email-masked]>
Date: Mon, 5 Jan 2015 13:23:20 +0200

Hi Aijun,

Snipped most of the previous message, just responding to the RTCP/STUN messages.

>> From: tram [mailto:[email-masked]] On Behalf Of Aijun Wang

[snip!]

> 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 use…

IMO the RTCP or application layer will finally pick the paths, the
STUN packets expose preliminary metrics (RTT and loss) to the RTP
layer. This helps the RTP layer determine if the path is (or which
paths are) capable of meeting the delay requirements of the multimedia
application (different for conversational, live, VoD, etc.) without
sending any media packets. Then it is up to the congestion control
algorithm (at the RTP layer) to schedule media packets on those paths,
observe if they have sufficient capacity. If not the RTP layer can add
more paths, or vary the encoding rate, or switch between existing
rates.

Cheers,
Varun