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 <wangaijun@tsinghua.org.cn>
wrote:

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

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