Subject: [mif] WGLC for MIF happy eyeballs

From: Hui Deng <[email-masked]>
Date: Tue, 8 Dec 2015 19:47:10 +0800

Hello all
 
We have two weeks WG last call for below document:
https://www.ietf.org/archive/id/draft-chen-mif-happy-eyeballs-extension-04.txt
 
Please send your comments to this thread.
This WGLC will end on Dec. 22nd.
 
Best regards,
 
Cochairs.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 8 Dec 2015 13:45:32 +0100 (CET)

> This WGLC will end on Dec. 22nd.

The above link is wrong, it links to a 3 year old revision of the 
document.

https://tools.ietf.org/html/draft-ietf-mif-happy-eyeballs-extension-07 
seems to be the latest.

It's also my opinion that I would not want this document sent off until we 
have decided what to do with the rest of the MIF documents, it's my 
opinion that the WGLC call is premature. I believe that MIF-HE is 
important, but I also think we should be more ready with the rest of the 
architecture before we ship this document off.

Some other comments:

I would like to see "3/4G interface" replaced with "mobile data interface" 
or "3GPP interface" or something else.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Hui Deng <[email-masked]>
Date: Tue, 8 Dec 2015 21:03:57 +0800

Apologize for mistake, thanks a lot for Mikael's correct,
 
Please go with that link
 
Best regards,
 
DENG Hui 
 
> Date: Tue, 8 Dec 2015 13:45:32 +0100
> From: [email-masked]
> To: [email-masked]
> CC: [email-masked]; [email-masked]
> Subject: Re: [mif] WGLC for MIF happy eyeballs
>

---

From: GangChen <[email-masked]>
Date: Wed, 9 Dec 2015 15:39:32 +0800

Mikael,

Many thanks for the comments.

> architecture before we ship this document off.

It's true to desirably have very clear views of relevant mif documents
before the send-off. Yet, I still see the chance to collect wglc
comments considering the follows:
1) MIF-HE is not a draft of MPVD cluster.
2) wglc is MIF-HE targeted. We seek wg revisiting on the wg product
quality and fix bugs.

> or "3GPP interface" or something else.

Sure. It will be fixed. thank you.

BRs

Gang

> _______________________________________________
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif
>

---

From: Daniel Migault <[email-masked]>
Date: Tue, 15 Dec 2015 14:00:20 -0500

Hi,

Please see my comments for
https://tools.ietf.org/html/draft-ietf-mif-happy-eyeballs-extension-07.
I think it is important for the WG to have such a document.

BR,

Daniel

Section Introduction:

"""   In multiple interface context, the problems raised by hosts with
   multiple interfaces have been discussed.  The MIF problem
   statement[RFC6418] described the various issues when using a wrong
   domain selection on a MIF node.  """

I think the first sentence should be removed. It does not bring any
information. In addition, it seems contradicting the second sentence
with one problem and multiple issues.

s/the most fast/fastest/

I assume the goal of the document is describe MIF-HE to adapt the HE
concept to the multiple provisionning domain architecture. If I am correct,
I think it would be good to have it explicitely mentioned.

MIF-HE should be in the terminology section.

I am not an english native speaker, but I guess this sentence should
checked. I also suspect there are multiple nits that should be fixed.

s/A MIF node has both 3/4G and WiFi interface./Assume a MIF node has
both a 3/4 G interface and a Wifi interface/

s/it' cheap/it is cheap/ maybe cheap should be avoided as well.

s/User/The user/

s/got IP/got an IP/

s/users have/the user has/

s/Users may won't want /Users may not want/

"""For instance, they may prefer to wait a little bit of time but not
forever.""" I do not think that is correct. The user may rather accept to
define an appropriate time slot for the node to attend to set a Wifi
connexion.

"""Users may won't want the wait time too short, because the 3G path for
most people is more expensive than WiFi path."""

This sentence is not clear to me. I assume that if 3G/4G is more expensive,
the user is more likely to provide the Wifi more time to set a
communication.

Section 3.

s/Hard set/Hard Set/

Section 4.2

The section mentions a bootstart URL and then enumerates "e.g. Windows
Vista, Windows 7, Windows Server 2008 and iOS." I think what you mean is
that the URL may not be standardized but may be specific to each OS. If I
am correct, I do not think that is relevant, since it may be provided by
anyone including the ISPs.

Maybe that is obvious, but I think we shoudl specify that L2 connectivity
has been checked. Otherwise I am not sur ethis is the only possibility. It
could also be a firewall for example in an corporate environment. Maybe it
would be good to specify the assumption that leads to this conclusion, so
if this assumption changes, the document may still be valid. In other
words, we should avoid to hav ethat document bound to such assumption.
Maybe another alternative is to restrict the scope of the draft to captive
portable as it seems this is the main use case addressed.

"""If anything is abnormal, it assumes there is a proxy on the path. """

The following sentence is not clear to me:

"""Parameters in a soft set should considered at this stage."""

s/option[RFC6731]/option [RFC6731]/

"""Those information may weight a
   particular interface to be preferred [one prior] to others sending
   resolving requests."""

There should be a white space before [RFC as well as "(".

---

From: GangChen <[email-masked]>
Date: Wed, 16 Dec 2015 15:14:48 +0800

> I think it is important for the WG to have such a document.

Thank you, Daniel. Please see my reply inline.

> with one problem and multiple issues.

Agree. I have updated in my local copy.

> MIF-HE should be in the terminology section.

Good suggestion. I add new terminology section.
For the completeness, the new section will mention both HE and HE-MIF.

    <section title="Terminology">
      <t>This document makes use of following terms:</t>
      <t><list style="symbols">
      <t>Happy Eyeballs (HE): it specifies requirements [RFC6555] for algorithms
       that reduce user-visible delay of dual-stack hosts within a
single home. </t>

      <t>HE-MIF: it adopts HE methodology to the multiple
      provisioning domain architecture. It describes requirements for algorithms
      that offer connectivity tests to the PVD-aware and non-PVD-aware
nodes [RFC7556].</t>
      </list></t>

    </section>

> s/it' cheap/it is cheap/ maybe cheap should be avoided as well.

I edit the sentence as follows:

[OLD]
   A MIF node has both 3/4G and WiFi interface.  When the node enters a
   WiFi area, a common practice would always prefer WiFi because it'
   cheap and fast-speed normally.

[NEW]
   Assuming a MIF node has both 3GPP mobile network interface and WiFi
   interface, a common practice would always prefer WiFi connection when
   the node enters a WiFi area.

> s/Users may won't want /Users may not want/

Those have been corrected. thank you.

> define an appropriate time slot for the node to attend to set a Wifi

The sentence in the draft doesn't conflict with your thoughts. It may get clear
if change some words.

[OLD]
For instance, they may prefer to wait a little bit of time but not forever.

[NEW]
For instance, they may prefer to wait an appropriate time slot but not forever.

> the user is more likely to provide the Wifi more time to set a

As you mentioned, the user may accept an appropriate time slot to wait
on wifi connection. Once the time slot is expired, the user likely
switch over to 3G/4G path to get connection.
This sentence intend to say this time slot can't set too short, as
user likely gives several tries on free wifi.
I try to make following changes.

[OLD]
   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.

[NEW]
   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.

> anyone including the ISPs.

You may suggest to not limited to specific OS implementation if I
understand correctly.
This draft doesn't mandate any implementation, it's just a example.
The draft could change the description similar with RFC7556

"In current implementations, some nodes already implement this, e.g., by trying
to reach a dedicated web server (see [RFC6419])."

> portable as it seems this is the main use case addressed.

Captive portable is the major use case. I'm unable to figure out a good way
to avoid the restriction. It's much appreciated if you have good texts added to
the draft.

> """Parameters in a soft set should considered at this stage."""

The parameters in the soft set is defined in section 3. I will the
reference like

[NEW]

 """The soft set parameters defined in section 3 should considered at
this stage."""

> There should be a white space before [RFC as well as "(".

That will be modified

many thanks

BRs

Gang

---

From: Zhen Cao <[email-masked]>
Date: Thu, 17 Dec 2015 15:34:23 +0100

Dear All,

To clarify,  I read the draft indicated by this link
https://tools.ietf.org/html/draft-ietf-mif-happy-eyeballs-extension-07

I find the document is ready to be published.  (Actually it should be
published earlier.  This problem was well recognized at the very
beginning, but now it seems  the interest has declined. )

Some editorial comments to the abstract:

Old:  Currently the interface selection in multi-interface environment is
   exclusive - only one interface can be used at the time, frequently
   needing manual intervention.

- I do like this argument, neither should any MIFers, since the MIF wg
has developed many solutions to help interface selection based on
domain names, APNs, PvDs.

Cheers,
Zhen

---

From: GangChen <[email-masked]>
Date: Fri, 18 Dec 2015 09:42:08 +0800

Hello Zhen,

Thank you for the comments.
I would like to propose the following new texts for the abstract:

This memo proposes extensions to the Happy Eyeball(HE) defined in RFC6555 to
fit into multiple provisioning domain architecture. Happy Eyeballs in
MIF would make the
selection process smoother by using the connectivity checks over a
pre-filtered interfaces according to defined policy.  This would
choose the fastest interface with an automatic fallback.

Please kindly to check.

BRs

Gang

---

From: "Liubing (Leo)" <[email-masked]>
Date: Fri, 18 Dec 2015 09:52:21 +0000

Hi all,

I support moving forward this document as an informational RFC. It provides valuable information for application developers to consider.

Minor comments:
1) Regarding the document name
In my mind, I already have the impression that "Happy Eyeballs" mainly regarding to IPv4/IPv6 selection; and besides, it is a concrete algorithm that machine could behave accordingly. In comparison, this document in my mind is more like a guidance on "Interface selection" than a concrete algorithm, and it doesn't focus on IPv4/IPv6 priority issue.
But I won't fight for the document naming issue. Just a personal feeling. If others are ok with the current name, I'm ok too.

2) Section 5
In this section, there are two implementation approaches provided. One is application internal implementation, which requires no additional API work; the other is the enhanced MIF-API.
The two approaches seem more or less contrary to me. So, the section 5 seems like an open question, that which approach is better. Does this document have some preference between the two?

3) Section 6.4
"Interface changing should only happen at the beginning of
new session in order to keep flow continuity for ongoing TCP session."
There might be always multiple sessions running in a phone at the same time, so I guess it would be very difficult to achieve this. So, maybe simply saying this is also out of scope.

Best regards,
Bing

From: mif [mailto:[email-masked]] On Behalf Of Hui Deng
Sent: Tuesday, December 08, 2015 9:04 PM
To: Mikael Abrahamsson
Cc: Margaret; [email-masked]
Subject: Re: [mif] WGLC for MIF happy eyeballs

Please go with that link

Best regards,

DENG Hui

> From: [email-masked]<mailto:[email-masked]>
> To: [email-masked]<mailto:[email-masked]>
> CC: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> Mikael Abrahamsson email: [email-masked]<mailto:[email-masked]>

---

From: GangChen <[email-masked]>
Date: Sat, 19 Dec 2015 18:33:58 +0800

Hello Bing,

Thank you for the comments. My reply is inline.

2015-12-18 17:52 GMT+08:00, Liubing (Leo) <[email-masked]>:
> Hi all,
>
> I support moving forward this document as an informational RFC. It provides
> valuable information for application developers to consider.
>
> Minor comments:
> In my mind, I already have the impression that "Happy Eyeballs" mainly
> regarding to IPv4/IPv6 selection; and besides, it is a concrete algorithm
> that machine could behave accordingly. In comparison, this document in my
> mind is more like a guidance on "Interface selection" than a concrete
> algorithm, and it doesn't focus on IPv4/IPv6 priority issue.
> But I won't fight for the document naming issue. Just a personal feeling. If
> others are ok with the current name, I'm ok too.

Just state my thought:
Several major considerations, such as connectivity testing and fastest
path selection, are derived from happy eyeballs.
Adoption in the document title intends to describe a view of
documented mechnism as heuristic as possible.

> 2) Section 5
> In this section, there are two implementation approaches provided. One is
> application internal implementation, which requires no additional API work;
> the other is the enhanced MIF-API.
> The two approaches seem more or less contrary to me. So, the section 5 seems
> like an open question, that which approach is better. Does this document
> have some preference between the two?

The HE-MIF could accomandate those two approaches.
Preference to any specific implementation is going beyond the document scope.
I guess best way is to live in the reality.

> There might be always multiple sessions running in a phone at the same time,
> so I guess it would be very difficult to achieve this. So, maybe simply
> saying this is also out of scope.

Thank you for pointing this out.
New texts would be:
"The flow continuity due to interface change is beyond the scope of
this document"

BRs

Gang
>> CC: [email-masked]<mailto:[email-masked]>;
>> [email-masked]<mailto:[email-masked]>

---

From: Zhen Cao <[email-masked]>
Date: Wed, 23 Dec 2015 10:55:27 +0800

The new text looks fine to me. Thanks.

---

From: [email-masked]
Date: Wed, 23 Dec 2015 01:58:05 -0800 (PST)

Hi all，

I have read the latest version. Since mif PVD architecture has been finalized and mif happy eyeball will not affect the architecture I think this document is ready for moving forward.

One editorial comment：We'd better use Wi-Fi instead of WiFi in the document.

Dapeng Liu

—<br>通过 <a href="https://www.dropbox.com/mailbox">Mailbox </a>发送

2015 年 12月 8 日 星期二 7:47 PM，Hui Deng <[email-masked]> 写道：

Hello all

Best regards,

Cochairs.