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

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

> -----Original Message-----
> From: Varun Singh [mailto:[e-mail]]
> Sent: Saturday, December 27, 2014 12:00 AM
> To: Aijun Wang
> Cc: Tirumaleswar Reddy (tireddy); [e-mail]
> Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-stun-
> path-data-00.txt
> 
> Hi Aijun,
> 
> Responses inline.
> 
> On Fri, Dec 26, 2014 at 1:45 PM, Aijun Wang <[e-mail]>
> 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:[e-mail]]
> > Sent: Friday, December 26, 2014 5:35 AM
> > To: Aijun Wang
> > Cc: Tirumaleswar Reddy (tireddy); [e-mail]
> >
> >
> > 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
> <[e-mail]>
> > wrote:
> >
> > Hi, Reddy
> >
> > Please see the reply inline below.
> >
> >> -----Original Message-----
> >> From: Tirumaleswar Reddy (tireddy) [mailto:[e-mail]]
> >> Sent: Wednesday, December 24, 2014 6:03 PM
> >> To: Aijun Wang; [e-mail]
> >> Subject: RE: [tram] FW: New Version Notification for
> >> draft-reddy-tram-stun-path-data-00.txt
> >>
> >> > -----Original Message-----
> >> > From: tram [mailto:[e-mail]] On Behalf Of Aijun Wang
> >> > Sent: Wednesday, December 24, 2014 12:07 PM
> >> > To: Tirumaleswar Reddy (tireddy); [e-mail]
> >> > 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.
> >> >
> >> > -----Original Message-----
> >> > From: tram [mailto:[e-mail]] On Behalf Of Tirumaleswar
> >> > Reddy
> >> > (tireddy)
> >> > Sent: Tuesday, December 23, 2014 11:29 PM
> >> > To: [e-mail]
> >> > 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: [e-mail] [mailto:[e-mail]]
> >> > 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
> >> >
> >> > _______________________________________________
> >> > tram mailing list
> >> > [e-mail]
> >> > https://www.ietf.org/mailman/listinfo/tram
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > tram mailing list
> >> > [e-mail]
> >> > https://www.ietf.org/mailman/listinfo/tram
> >
> >
> >
> > _______________________________________________
> > tram mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tram
> >
> >
> >
> > --
> > http://www.netlab.tkk.fi/~varun/
> 
> 
> 
> --
> http://www.netlab.tkk.fi/~varun/