Subject: [v6ops] RFC6555 / Multiple interfaces

From: "Asveren, Tolga" <[email-masked]>
Date: Sat, 24 Dec 2016 15:52:35 +0000

Dan, V6ops chairs,

Was/Is there a technical reason why RFC6555 does not address use of multiple interfaces, e.g. WiFi and LTE, in addition to different IP address families?  Would you consider such an enhancement -assuming no technical issues- as a candidate for a potential RFC6555-bis or as a new work item?

Thanks,
Tolga

---

From: Fred Baker <[email-masked]>
Date: Mon, 26 Dec 2016 14:42:08 -0800

> On Dec 24, 2016, at 7:52 AM, Asveren, Tolga <[email-masked]> wrote:
> 

It addresses matters in which the application has more than one address to choose from, and the outcome of its choice potentially varies from address to address and from event to event. The document discusses IPv4 and IPv6; from my perspective, there is no significant reason it couldn’t be between two IPv4 addresses, or among a long list of IPv6 addresses. The issue is the fact of making a choice, and not wanting to wait for a TCP timeout before wondering about the next. 

Whether the address in question is applied to an Ethernet, a Wifi, an LTE interface, or something else, is a layer that it presumes the application to not see or not be vitally interested in. If the device wanted to prefer Wifi over LTE, for example, it could choose to try the address associated with the Wifi before the LTE, and if it turned out that the Wifi didn’t work at that instant, the LTE would likely wind up being chosen.

Speaking strictly for myself, I would want to see the argument made as to why this need further work. If I were to embrace and extend 6555, I might do it in a single sentence very similar to my opening sentence in this reply.

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 27 Dec 2016 08:34:55 +0000

> > Was/Is there a technical reason why RFC6555 does not address use of
> multiple interfaces, e.g. WiFi and LTE, in addition to different IP address
> families?  Would you consider such an enhancement -assuming no technical
> issues- as a candidate for a potential RFC6555-bis or as a new work item?
> 
> It addresses matters in which the application has more than one address to
> choose from, and the outcome of its choice potentially varies from address
> to address and from event to event. The document discusses IPv4 and IPv6;
> from my perspective, there is no significant reason it couldn’t be between
> two IPv4 addresses, or among a long list of IPv6 addresses. The issue is the
> fact of making a choice, and not wanting to wait for a TCP timeout before
> wondering about the next.
> 
> Whether the address in question is applied to an Ethernet, a Wifi, an LTE
> interface, or something else, is a layer that it presumes the application to not
> see or not be vitally interested in. If the device wanted to prefer Wifi over
> LTE, for example, it could choose to try the address associated with the Wifi
> before the LTE, and if it turned out that the Wifi didn’t work at that instant,
> the LTE would likely wind up being chosen.
> 
> Speaking strictly for myself, I would want to see the argument made as to
> why this need further work. If I were to embrace and extend 6555, I might do
> it in a single sentence very similar to my opening sentence in this reply.
[TOLGA] Agreed on all technical points. Agreed also that what is needed is probably a short section with a few paragraphs. 
Regarding the question "Why do we need this explanation?": I think the answer is similar to why RFC6555 was needed to start with. Overall, the idea (both for this potential mini-extension and happy-eyeballs in general) is relatively straightforward and can be categorized as "common sense" (or if I dare to say a "no-brainer"). Nonetheless specifying it in an IETF document still has benefits as it gets more legs to be deployed/promoted widely. And let's don’t forget there still is some normative behavior defined in RFC6555 by using RFC2119 verbiage. I think the extension about use of multiple interfaces would have a few such sentences as well. 
So, as a summary, I don’t think the extension would require any "architectural changes" in the happy-eyeballs philosophy, is needed/would be used though and I wouldn’t expect it to consume much energy. I can craft some text if there is a "Go" from the V6ops WG/Chairs.

---

From: Mark Smith <[email-masked]>
Date: Tue, 27 Dec 2016 19:43:29 +1100

Courtesy of Fred a while back. Multi-addressing is a form of multihoming.

https://tools.ietf.org/html/draft-baker-happier-eyeballs-00

On 27 Dec. 2016 19:05, "Asveren, Tolga" <[email-masked]> wrote:

> [TOLGA] Agreed on all technical points. Agreed also that what is needed is
> probably a short section with a few paragraphs.
> Regarding the question "Why do we need this explanation?": I think the
> answer is similar to why RFC6555 was needed to start with. Overall, the
> idea (both for this potential mini-extension and happy-eyeballs in general)
> is relatively straightforward and can be categorized as "common sense" (or
> if I dare to say a "no-brainer"). Nonetheless specifying it in an IETF
> document still has benefits as it gets more legs to be deployed/promoted
> widely. And let's don’t forget there still is some normative behavior
> defined in RFC6555 by using RFC2119 verbiage. I think the extension about
> use of multiple interfaces would have a few such sentences as well.
> So, as a summary, I don’t think the extension would require any
> "architectural changes" in the happy-eyeballs philosophy, is needed/would
> be used though and I wouldn’t expect it to consume much energy. I can craft
> some text if there is a "Go" from the V6ops WG/Chairs.
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 28 Dec 2016 08:21:09 +1300

> Courtesy of Fred a while back. Multi-addressing is a form of multihoming.

Yes, if the different interfaces use different addresses. It's not as if
RFC6555 ignores this issue: see sections 5.3 and 5.4. And it's not as if
the former MIF WG ignored this issue:
https://datatracker.ietf.org/doc/draft-ietf-mif-happy-eyeballs-extension/
which is still an active document.

    Brian

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 31 Dec 2016 06:01:23 +0100 (CET)

> which is still an active document.

MIF was put into hibernation by AD, so while this might be an active 
document, MIF is no longer an active WG.

This of course makes me a sad panda. It was done because of lack of 
interest, but if people are interested in working in this area then if we 
can gather enough people that show interest, AD might change his mind.

-- 
Mikael Abrahamsson    email: [email-masked]