Subject: [MMUSIC] ICE IPv4/IPv6 DualStack Fairness and Tunneled Interfaces

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Mon, 5 Jan 2015 13:15:48 +0000

Hi

We just posted a new version of the ICE IPv4/IPv6 Fairness draft
(http://www.ietf.org/internet-drafts/draft-martinsen-mmusic-ice-dualstack-fairness-01.txt)

We tried to address the comments we got regarding tunnelled interfaces during the mmusic session in Hawaii.

We added the following text to the introduction:
"Applications should also take special care to prioritize network
 interfaces know to be unreliable.  For example certain tunnel
 services might provide unreliable connectivity.  This specification
 does not provide any guidelines on how to prioritize different
 network interfaces.  This is best solved by the application itself
 and the best solution would vary from use-case to use-case.”

And later in the algorithm description:
"This leaves enough address space
  to further play with the values if different interface priorities
  needs to be added.  This is especially useful if tunneled interfaces
  with bad connectivity are known to exist.”

We also moved the algorithm description to the main body and added:
"The algorithm described in this section MAY be used by an
  implementation to introduce IPv4/IPv6 dual stack fairness.
  Implementations implementing their own algorithm must take care not
  to break any ICE compatibility.  Se Section Section 4 for details.”

It is worth noticing that this drafts only aims to introduce some fairness among IPv4 and IPv6 to avoid excessive delays if one of the paths is completely broken. We feel that further checklist optimisation based on application knowledge regarding interface behaviour is out of scope (Not to say a difficult problem to solve if you want an optimal solution in all possible scenarios).

.-.
Pål-Erik

---

From: Simon Perreault <[email-masked]>
Date: Mon, 5 Jan 2015 08:42:33 -0500

Since I participated in the discussion on this topic in Honolulu, allow me
to say this: works for me! :)

Simon

On Mon, Jan 5, 2015 at 8:15 AM, Pal Martinsen (palmarti) <[email-masked]
> wrote:

> (
> http://www.ietf.org/internet-drafts/draft-martinsen-mmusic-ice-dualstack-fairness-01.txt
> )
>
>  It is worth noticing that this drafts only aims to introduce some
> fairness among IPv4 and IPv6 to avoid excessive delays if one of the paths
> is completely broken. We feel that further checklist optimisation based on
> application knowledge regarding interface behaviour is out of scope (Not to
> say a difficult problem to solve if you want an optimal solution in all
> possible scenarios).
>
>  .-.
> Pål-Erik
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>
>

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Mon, 26 Jan 2015 12:04:09 +0000

Hi,

I would like to emphasis that the important aspect of this document is to make developers aware of a potential problem when dealing with ICE and IPv4/IPv6 dual-stack. It outlines what developers should care about, and includes a possible algorithm that can be directly implemented or modified to suit other needs.

Unless someone finds the algorithm directly harmful, I would like to ask the chairs to ask the group for adoption.

.-.
Pål-Erik

On 05 Jan 2015, at 14:42, Simon Perreault <[email-masked]<mailto:[email-masked]>> wrote:

Since I participated in the discussion on this topic in Honolulu, allow me to say this: works for me! :)

Simon

On Mon, Jan 5, 2015 at 8:15 AM, Pal Martinsen (palmarti) <[email-masked]<mailto:[email-masked]>> wrote:
Hi

.-.
Pål-Erik

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

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 26 Jan 2015 05:20:16 -0800

Without correctly prioritizing tunneled interfaces (which are the ones most likely to cause a problem) the proposed algorithm has no benefits and should be removed. 

What good is it to state the problem
and then to provide a worthless solution?

> On Jan 26, 2015, at 4:04 AM, Pal Martinsen (palmarti) <[email-masked]> wrote:
> 
> Hi,
> 
> 
>> On 05 Jan 2015, at 14:42, Simon Perreault <[email-masked]> wrote:
>> 
>>> On Mon, Jan 5, 2015 at 8:15 AM, Pal Martinsen (palmarti) <[email-masked]> wrote:
>>> Hi
>>>

---

From: Simon Perreault <[email-masked]>
Date: Mon, 26 Jan 2015 08:51:22 -0500

On Mon, Jan 26, 2015 at 8:20 AM, Bernard Aboba <[email-masked]>
wrote:

> Without correctly prioritizing tunneled interfaces (which are the ones
> most likely to cause a problem) the proposed algorithm has no benefits and
> should be removed.
>

Bernard,

Did you read the latest revision? It seems to be providing exactly what
you're asking for:

   Applications should also take special care to prioritize network
   interfaces know to be unreliable.  For example certain tunnel
   services might provide unreliable connectivity.  This specification
   does not provide any guidelines on how to prioritize different
   network interfaces.  This is best solved by the application itself
   and the best solution would vary from use-case to use-case.

Or do you think we should be more prescriptive?

Simon

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Mon, 26 Jan 2015 20:04:09 +0000

Hi,

On 26 Jan 2015, at 14:51, Simon Perreault <[email-masked]<mailto:[email-masked]>> wrote:

On Mon, Jan 26, 2015 at 8:20 AM, Bernard Aboba <[email-masked]<mailto:[email-masked]>> wrote:
Without correctly prioritizing tunneled interfaces (which are the ones most likely to cause a problem) the proposed algorithm has no benefits and should be removed.

Based on my own experience with my own ISP (Sorry for not having more statistical correct examples) there are tons of problems with native IPv6 addresses when they start rolling out IPv6. In addition to that I managed to turn on dhcpv6 on my router as well, thus giving all my machines in my home those weird dc00 addresses for some reason.

In my opinion it is not worthless to spell out what a developer safely can play with without breaking ICE interop.

Bernard,

Did you read the latest revision? It seems to be providing exactly what you're asking for:

In addition to the above the algorithm example states:

   This leaves enough address space
   to further play with the values if different interface priorities
   needs to be added.  This is especially useful if tunneled interfaces
   with bad connectivity are known to exist.  The highest value should
   be given to the address family that should be prioritized.

It would be fun sorting out how we could prioritise all the different interface types, but that is beyond the scope of this draft.

.-.
Pål-Erik

Simon