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

["Aijun Wang" <[e-mail]>]

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:[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] <javascript:;> ]
> Sent: Wednesday, December 24, 2014 6:03 PM
> To: Aijun Wang; [e-mail] <javascript:;> 
> Subject: RE: [tram] FW: New Version Notification for
> draft-reddy-tram-stun-path-data-00.txt
>
> > -----Original Message-----
> > From: tram [mailto:[e-mail] <javascript:;> ] On Behalf Of Aijun Wang
> > Sent: Wednesday, December 24, 2014 12:07 PM
> > To: Tirumaleswar Reddy (tireddy); [e-mail] <javascript:;> 
> > 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] <javascript:;> ] On Behalf Of Tirumaleswar
> > Reddy
> > (tireddy)
> > Sent: Tuesday, December 23, 2014 11:29 PM
> > To: [e-mail] <javascript:;> 
> > 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] <javascript:;>  [mailto:[e-mail] <javascript:;> ]
> > 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] <javascript:;> 
> > https://www.ietf.org/mailman/listinfo/tram
> >
> >
> >
> > _______________________________________________
> > tram mailing list
> > [e-mail] <javascript:;> 
> > https://www.ietf.org/mailman/listinfo/tram



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



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