Gathering policy tweaking

[robin-raymond]

Current gather policy is defined as:

enum RTCIceGatherPolicy {
    "all",
    "nohost",
    "relayonly"
};

I think I'd prefer a more granular control over what's going on although I don't know the best way to express in WebIDL, something akin to a bit field:

In C++ it would be something like:

enum RTCIceGatherPolicy {
  All = ..., // all listed without changing default prioritization

  Host = 0x00000001,
  ServerReflexive = 0x00000002,
  Relay = 0x00000004,
  PeerReflexive = 0x00000008,

  HostIpv4 = 0x00000100,
  HostIpv6 = 0x00000200,
  HostUdp = 0x00001000,
  RelayUdp = 0x00002000,
  HostTcp = 0x00004000,
  RelayTcp = 0x00008000,

  Lan = 0x00010000,
  WLan = 0x00020000,
  WWan = 0x00040000,
  Vpn = 0x00080000
};

Maybe this? Not sure...

  // prioritization overrides / changes
  PrioritizeIpv4OverIpV6 = 0x01000000,
  PrioritizeTcpOverUdp = 0x02000000,
  PrioritizeRelayOverHost = 0x04000000,

[robin-raymond]

http://lists.w3.org/Archives/Public/public-ortc/2014Apr/0032.html

[rshpount]

We should also add a flag to gather permanent vs temporary IPv6 local IP
addresses.

---

Roman Shpount

On Sat, Apr 12, 2014 at 3:56 PM, Robin Raymond notifications@github.comwrote:

Current gather policy is defined as:

enum RTCIceGatherPolicy {
"all",
"nohost",
"relayonly"
};

I think I'd prefer a more granular control over what's going on although I
don't know the best way to express in WebIDL, something akin to a bit field:

In C++ it would be something like:

enum RTCIceGatherPolicy {
All = ..., // all listed without changing default prioritization

Host = 0x00000001,
ServerReflexive = 0x00000002,
Relay = 0x00000004,
PeerReflexive = 0x00000008,

HostIpv4 = 0x00000100,
HostIpv6 = 0x00000200,
HostUdp = 0x00001000,
RelayUdp = 0x00002000,
HostTcp = 0x00004000,
RelayTcp = 0x00008000,

Lan = 0x00010000,
WLan = 0x00020000,
WWan = 0x00040000,
Vpn = 0x00080000,

// prioritization overrides / changes
PrioritizeIpv4OverIpV6 = 0x01000000,
PrioritizeTcpOverUdp = 0x02000000,
PrioritizeRelayOverHost = 0x04000000,
};

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/54
.

[robin-raymond]

We are removing the prioritization from this gather proposal. Think we'd like to do that based on a different way.

[juberti]

I understand the intent here, but I think it will be challenging to cover all the combinations. For example, how to express that you want/don't want IPv6 UDP relay candidates allocated.

My suggestion is to simply keep the existing policies from 1.0, and add additional policies as use cases require them.

[robin-raymond]

related: http://lists.w3.org/Archives/Public/public-ortc/2014Apr/0128.html

Resolved above simply by being more expansive:

enum RTCIceGatherPolicy {
  "hostUdpIpv4",
  "hostUdpIpv6",
  "hostTcpIpv4"
  "hostTcpIpv6",
  "relayUdpIpv4",
  "relayUdpIpv6",
  "relayTcpIpv4",
  "relayTcpIpv6",

  "serverReflexive", // alt: "srflx"
  "peerReflexive",    // alt: "prflx"

  "lan",
  "wlan",
  "wwan",
  "vpn"
};

These would be treated as "or"ed cumulated values and then gather policy is simply a RTCIceGatherPolicy [].

Since it operates like a bit field we can add other 'combination' enums representing common stuff like for easy access to particular sets of options:

partial enum RTCIceGatherPolicy {
  "all", // want entire list of candidates
  "nohost", // subtract all host interfaces
  "relayonly", // subtract all but relay interfaces
  "nowwan", // subtract wwan interfaces
}

[rshpount]

What about different types of ipv6 host addresses such temporary vs
permanent vs toredo tunnels? Should we just add more enum values?

[robin-raymond]

Some of that I suspect will get resolved with "happy eyeballs" stuff yet to be decided. I'd like to see the result of that before I make comment or anything special is added.

[juberti]

I still think this is rushing ahead without any guidance from use cases; the grammar here is more complex that the current situation, but still cannot express simple concepts like "no ipv4".

Please, let's have the use cases drive this discussion rather than the possibilities.

[robin-raymond]

FYI - this is not for 1.1 (current spec) and only a 1.2 option (at best) but I am trying to get the discussion started. Since it's not slated for 1.1, I've hesitated bring it to the list for that reason. But at the same time the current gather policy in 1.1 isn't going to work for us "as is".

For example, "wwan" needs to be something we can selectively gather against or not for mobile. "wwan" can be a costly interface, especially with roaming and we may chose to never use it or to only use it for audio but never for video.

The other issue is that some of these options are not mutually exclusive in the current gather policy. For example, if I don't want any "host" candidates or perhaps even forcefully use "relayonly" but keep the "wwan" restriction in place, it's simply not expressible in the current 1.1 gather policy API.

As for saying "no ipv4", sure, it's expressible. Perhaps not in an ideal mechanism but it can be done. If you treat the options as cumulative "ORed" first, then subtractive filtered out it will work. So for example, if you wanted to say "no IPv4" and no "wwan", you could express it as: ["hostUdpIpv6", "hostTcpIpv6", "relayUdpIpv6", "relayTcpIpv6", "serverReflexive", "serverReflexive", "lan", "wlan", "vpn"].

I'm not saying the expressiveness is perfect - far from it. I'm certainly not happy with it yet. But throwing some spaghetti on the wall, letting it percolate in time, then fixing it is the first step towards getting a comprehensive policy. Use cases are vital, but IMHO so are domain driven design proposal that can be teased out with those given use cases. I like a healthy balance of the two design philosophies (which aren't completely mutually exclusive).

Your comments about lack of guidance from use cases is fair and true. We simply do not know all the use cases we want (and might want) yet. That's also the reason I'm getting this out there is because I want to help further understand and tease out the use-cases.

[juberti]

How do you prevent serverReflexive from gathering IPv4?

[robin-raymond]

The original thought was that these are reflexive "mirrors" of firewall addresses representing host candidates so if you get all the reflected addresses for the hosts you have locally and you only have option to turn on/off reflexive as a whole. This is where knowing the use cases needed is vital to make proper decisions.

Mind you, I can see a reason why people might want "no IPv6" but I don't see why people might want some IPv6 on some interfaces but not others. If we allow selective picking of IPv4 vs IPv6 then we'll likely have to do it per interface too, e.g. "no IPv4 on wwan" and "only IPv6 on wlan". It get's pretty nutty.

Martin long ago suggest we simply make the "onlocalcandidate" event cancellable, so if the candidate was generated by the system it could be cancelled during the processing of the "onlocalcandidate" event. That doesn't quite work perfectly if there's a race window in which the candidate is active until it's cancelled. But that could be easily resolved if the local candidate was considered frozen until after the "onlocalcandidate" event was processed to know if the candidate will ultimately be used or not. There's no burden on the application programmer since they do not need to call the cancel method in the event but it does add a bit of complexity to the ice engine to support this feature. In the end, this solution is probably better than having a never ending list of complexly combined filter options / grammar. We would need to add an interface type to be able to make some good decisions, e.g. "lan", "wlam", "wwan", "vpn" so a check could be made to filer out "wwan" interfaces.

[aboba]

Can the desired functionality be provided by removeLocalCandidate()?