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

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

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