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

[Varun Singh <[e-mail]>]

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