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

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 24 Dec 2014 01:33:18 +0000

Inline [TR]

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

On Tue, Dec 23, 2014 at 12:55 PM, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:
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.

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>

Ok, but the "for idempotent packets" part is missing.

[TR] Yes, updated draft.

To be clear: is there any difference in behavior for Binding vs Allocate requests ?

[TR] No. TURN server as usual remembers the transaction ID to deal with retransmission of Allocate requests, so it can identify that Allocate request is retransmitted with only change in the ReTransCnt value.

-Tiru

Simon

---

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

> -----Original Message-----
> From: tram [mailto:[email-masked]] On Behalf Of Brandon Williams
> Sent: Wednesday, December 24, 2014 12:57 AM
> To: [email-masked]
> 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.

Yes, the primary use case for PATH-CHARACTERISTICS is to use in ICE connectivity checks. The other use case that needs further discussion is: When an endpoint discovers multiple TURN servers  then this new attribute can be used with Allocate requests to determine the priority amongst the relayed candidates (https://tools.ietf.org/html/draft-patil-tram-turn-serv-selection-00#section-3.3). But as you mentioned it does not represent end-to-end characteristics and ICE connectivity checks with PATH-CHARACTERISTICS would help to choose a TURN server that provides better path characteristics. 

-Tiru

> 
> --Brandon
> 
> --
> 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: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 29 Dec 2014 14:51:26 +0000

> From: Varun Singh [mailto:[email-masked]]
> Sent: Saturday, December 27, 2014 12:00 AM
> To: Aijun Wang
> Cc: Tirumaleswar Reddy (tireddy); [email-masked]
> 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. 

Yes, that is the intent of the specification. Use cases with or without multiple interfaces could be:
[1] draft-williams-peer-redirect: Test both the relayed candidates and pick the best relayed candidate to use.
[2] draft-ietf-ppsp-base-tracker-protocol: In PPSP, perform ICE connectivity checks with list of peers in the swarm and select seeder(s) for fetching content.

-Tiru

> 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.
> 
> 
> >
> >
> >
> > 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]
> >
> >
> > Hi Aijun,
> > Comments inline.
> > Cheers,
> > Varun.
> > On Thursday, December 25, 2014, Aijun Wang
> <[email-masked]>
> > wrote:
> >
> > 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
> >> draft-reddy-tram-stun-path-data-00.txt
> >>
> >> > From: tram [mailto:[email-masked]] On Behalf Of Aijun Wang
> >> > Sent: Wednesday, December 24, 2014 12:07 PM
> >> > To: Tirumaleswar Reddy (tireddy); [email-masked]
> >> > 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
> >
> >
> >
> > 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.
> >
> >
> >
> > 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.
> >
> > 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.
> >
> >
> >
> >> > 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.
> >>
> > 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.
> >
> >
> >
> > 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: 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
> >> >
> >> > 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
> >> >
> > http://www.netlab.tkk.fi/~varun/
> 
> 
> 
> --
> http://www.netlab.tkk.fi/~varun/

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 31 Dec 2014 06:19:17 +0000

Inline [TR]

From: tram [mailto:[email-masked]] On Behalf Of Simon Perreault
Sent: Tuesday, December 30, 2014 8:07 PM
To: Brandon Williams
Cc: [email-masked]; Aijun Wang
Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-stun-path-data-00.txt

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.

-Tiru

Simon