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

From: "Russ White" <[email-masked]>
Date: Wed, 16 Dec 2015 19:24:37 -0500

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.

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

==
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 (?).

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

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

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

==
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?

==
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?

==
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 paramenters, 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.

==
deliver the customized
policies in particular network environments due to

Should probably be --

deliver policies in particular network environments because of ...

==
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:

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

==

HTH...

:-)

Russ

---

From: GangChen <[email-masked]>
Date: Thu, 17 Dec 2015 12:43:50 +0800

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

> I would remove this sentence.

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

> 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"

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

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

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

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

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

> I'm not certain what this means... What is "upper" and "lower" in relation

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

> seems unclear here. I suspect this is just a set of parameters, so this

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 policies in particular network environments because of ...

Ack

> and transports which meet the hard set requirements described above.

good to me.

> parameters must be satisfied before a link/transport pair can be used at

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif
>