Re: [mif] Comments on draft-ietf-mif-happy-eyeballs-extension-07

[GangChen <[e-mail]>]

Hello Russ, thank you for the comments. My reply is inline.

2015-12-17 8:24 GMT+08:00, Russ White <[e-mail]>:
>
> I'm not on the MIF mailing list (I don't think), but some comments based on
> my reading of the draft, at any rate --
>
>
> ==
> In multiple interface context, the problems raised by hosts with multiple
> interfaces have been discussed.
>
> I would remove this sentence.

Same comment is in another thread. I will remove the sentence.

> ==
> Happy Eyeballs (HE) [RFC6555]
> described how a dual-stack client can determine the functioning path
> to a dual-stack server. It's using stateful algorithm to help
> applications quickly determine if IPv6 or IPv4 is the most fast path
> to connect a server.
>
> I would reword -- perhaps --
>
> Happy Eyeballs (HE) [RFC6555] describes how a dual-stack client can
> determine the fastest path to a dual-stack server by employing a stateful
> algorithm to quickly discover if the IPv4 or IPv6 path is faster.

good to me. To combine the comments from the another thread,

"fastest" will be changed to "the most fast"


> ==
> That is a good method to achieve smart path
> selection. However, the assumption is a single-homed context. The
> interaction with multiple interfaces is deferred for further study.
>
> Perhaps --
>
> While this is a good method to achieve smart path selection, it assumes a
> single-homed device. Interaction with multiple interfaces was deferred for
> further study.
>
> Although the problem here is I'm not certain if this is supposed to be a
> single device, or a single interface device, or ... When I read "single
> homed," I tend to think of a device with a single upstream connection,
> rather than a device with multiple interfaces. The two concepts -- dual
> homing and multiple interfaces -- are actually unrelated. I think multiple
> interfaces is meant here, rather than single homed (?).

HE(Happy Eyeball,RFC6555) is single-homed assumed.
 HE-MIF is for a multi-homed node.
Referring to the terminology in RC6418, multi-homing node and the node
with multiple
interfaces are interchangeable. I like the sentence you proposed. Only
the "device" may
be better to be changed as "node":

"While this is a good method to achieve smart path selection, it assumes a
single-homed node targeted. Interaction with multiple interfaces was
deferred for
further study.


> ==
> This memo has been proposed to extend happy eyeballs algorithm to fit
> into the multiple interfaces architecture. Several additional
> considerations have been elaborated to analyze the user demands and
> initiate HE-MIF connections. It allows a node with multiple
> interfaces picking a fast flow path.
>
> Perhaps --
>
> This memo proposes extensions to the HE algorithm defined in [RFC6555] to
> support multiple interfaces, such that a node with multiple interfaces can
> choose the fastest available path for any particular flow.

Combining with previous comments, I will avoid using the word of "algorithm".
Since RFC6555 only define the requirements for the algorithm, HE-MIF also only
produces the requirement. Another concern is to state "any particular flow".
HE-MIF is mainly for connection-oriented transports (e.g., TCP, SCTP). Flow may
have broader scope. Here is a change proposal.


"This memo proposes extensions to the Happy Eyeball(HE) defined in [RFC6555] to
fit into multiple provisioning domain architecture, such that a node
with multiple
interfaces can choose the most fast path for a particular
connection-oriented flow."


> ==
> would always prefer WiFi because it'
> cheap and fast-speed normally.
>
> Should be something like --
>
> would normally be to prefer the WiFi connection because it's both less
> expensive and has a higher available bandwidth.
>
> ==
> User assumes the WiFi is working,
> because the node already got IP address from WiFi. However, he can't
> run applications due to Internet connectivity being unavailable.
>
> I don't know that the user is assuming anything -- rather the device is
> choosing which link to use for what, so it's the software on the device
> that's doing the assuming here, I think.
>
> Perhaps --
>
> In this situation, a device might assume the WiFi link can reach
> destinations on the global Internet, for instance because a valid IP
> address
> has been assigned through some process on the interface. However, this
> might
> not be the case for several reasons, such as authentication requirements,
> instability at layer 2, or even, perhaps, the WiFi being connected to a
> local network with no global Internet reachability.

That is a good suggestion. just a little bit of wording:

In this situation, a node might assume the WiFi link can reach
destinations on the global Internet, because a valid IP address
has been assigned on the interface. However, this might
not be the case for several reasons, such as authentication requirements,
instability at layer 2, or even, perhaps, the WiFi being connected to a
local network with no global Internet reachability.




> ==
> With HE-MIF, users can indicate their
> desire with some setting on the phone. For instance, they may prefer
> to wait a little bit of time but not forever. After the timer is
> expired, users would finally give up the WiFi path and try to
> establish connection over 3G path. Users may won't want the wait
> time too short, because the 3G path for most people is more expensive
> than WiFi path.
>
> This is a bit difficult to understand. I think what is probably meant here
> is something like --
>
> With the extensions described in this draft, users could indicate their
> willingness to switch from the apparently higher speed WiFI link to the
> lower speed, and more expensive, mobile wireless connection. This
> switchover
> could be accomplished by the user setting a timer indicating how long they
> are willing to wait for a connection to establish across a less expensive
> link before reverting to a more expensive link.


This sentence is also commented in another thread. You may want to review
the current sentence:

      With HE-MIF, users can indicate their desire with
      some setting on the phone. For instance, they may prefer to wait an
      appropriate time slot but not forever. After the timer is
      expired, users may finally give up the WiFi path and try to
      establish connection over 3GPP mobile network path.  Users may not want
      a very short timer, because the mobile network path for most people is
      more expensive than WiFi path. An appropriate timer is desired to balance
      user experience and expenditure.

For the bandwidth of wifi comparing to wireless link, it's almost same
if user swith to 4G link. 4G has 100Mbps speed.

> ==
> A node has WiFi and 3/4G access simultaneously. In mobile network,
> IPv6-only may be preferable since IPv6 has the potential to be
> simpler than dual-stack. WiFi access still remains on IPv4. The
> problem is caused by policy confliction.
>
> I'm not certain what this section is trying to say, other than the
> commonsense -- if IPv6 isn't available on a particular connection, then
> IPv6
> flows shouldn't be sent across that connection?

This section intends to describe the confliction  btw source address
selection principle
and user preference. If IPv6 on the wireless link and Ipv4 on the wifi
link, wireless
link will be selected according to the source address selection
principle but user
may prefer the wifi link.


> ==
> It serves upper
> applications and initiates HE-MIF connections to below level API
> subsequently. Going through the process, MIF nodes could pick an
> appropriate interface which would correspond to user demands.
>
> I'm not certain what this means... What is "upper" and "lower" in relation
> to here?

The sense of "upper" originally is derived from MIF API framework.
I guess "upper" can be removed here.

> ==
> Hard Set: It contains
>
> The "it" isn't needed here --
>
> Hard Set: Contains...
>
> ==
> This might provide an
> interface for applications constraints or delivering operator's
> policies.
>
> Is this a set of parameters, or an interface to a set of parameters? It
> seems unclear here. I suspect this is just a set of parameters, so this
> section might want to say --
>
> Contains parameters which must be complied with when choosing which
> interface and protocol through which a particular flow should be directed.
> These should be seen as constraints on the choice, such as provider
> policies, support for IPv4 or IPv6, and other parameters which would
> prevent
> a particular interface and transport from being used by a particular flow.
> Parameters in the hard set should be easy to use and understand; when
> several parameters in the hard set are in conflict, the user's preference
> should be prioritized.
>
> I'm not certain about the point of the last sentence -- it seems, to me,
> that the provider might want the right to enforce a specific rule. I don't
> know if this is fully accounted for here or not.

thank you for the proposal, i will update accordingly.
The last sentence is to weight user choice. Once the confliction btw provider
enforced rules and user preference, hard set should take user choice
as first priority.

> ==
> deliver the customized
> policies in particular network environments due to
>
> Should probably be --
>
> deliver policies in particular network environments because of ...

Ack

> ==
> Soft Set: It contains factors involving in the selection of the
> fastest path. The following is considered as for the
> justification.
>
> Might be better as --
>
> Soft Set: Contains factors which impact the selection of the path across
> which a particular flow should be transmitted among the available
> interfaces
> and transports which meet the hard set requirements described above.
> Examples might include:

good to me.


> ==
> Corresponding to the two sets of parameters, a HE-MIF node may take a
> two-steps approach.
>
> I don't know why this should be a "may." It seems, to me, based on the way
> the hard set parameters are defined in the draft, any and all hard set
> parameters must be satisfied before a link/transport pair can be used at
> all
> for a particular flow.

That was discussed backing to 2012.10.

"may" indicates the case if only one interface is left after the firs
step, second step is not executed.

BRs

Gang



> ==
>
> HTH...
>
> :-)
>
> Russ
>
> _______________________________________________
> mif mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mif
>