renomination

[pc...@suitabletech.com]

There was some IETF work on ICE 'renomination' started last year (draft-thatcher-ice-renomination, draft-thatcher-ice-network-cost). WebRTC has implemented some of the logic described in those drafts.

Our application needs to roam seamlessly between wifi access points (on one end only) using multiple interfaces. We were looking into using the renomination feature to achieve this goal.

However, after experimenting a little, we found that the current WebRTC implementation is too aggressive in pruning connections and extremely conservative in its pinging. This leads to a situation where the controlling side is trying to renominate its backup connection. But the controlled side refuses to switch because that backup connection has been pruned or has not been pinged recently (and is thus not writable).

By modifying the pinging to be more aggressive, we’ve have been able to force renominations.

For now, we have resorted to a modified version of WebRTC in our code and use C++ clients on both sides. Ultimately, we would like to use a web client on the controlled side. Has anybody been able to make renomination work on Chrome?

[Taylor Brandstetter]

Can you explain more about the problem, and what you had to change in your modified version?

Each connection should be kept alive as long as it received something in the last 30 seconds. So when it's "renominated", I'd expect the other endpoint to receive the renomination binding request successfully, and switch to that connection after the current one stops receiving packets. But I could be forgetting something.

As for making it work in Chrome, the logical next step would be enabling it through an experiment, and verifying there are no regressions.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/b951127b-5700-416e-a62b-1244cdb772f5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[pc...@suitabletech.com]

Does the current connection need to completely stop receiving packets before renomination switches? I am trying to achieve a seamless connection change before the current connection stops. 

Our application has a controlling side with multiple wifi interfaces. In my experiment, I implement a NetworkMonitorInterface to force renomination. This is a hack, but I set the AdapterType of the preferred interface to ADAPTER_TYPE_WIFI and the other one to ADAPTER_TYPE_CELLULAR. I can see the controlling side trigger renomination of the preferred connection when I call NetworkMonitorInterface::OnNetworksChanged().

The controlled side gets flooded with ping packets from the new connection at this point. It tests checks the new connection by calling P2PTransportChannel::ShouldSwitchSelectedConnection(). The first test that ShouldSwitchSelectedConnection() performs is !ReadyToSend(new_connection) which looks at the writable property (controlled side). At this point, the current connection is writable but the new connection is not writable. So the switch stops here until the new connection is made writable.

My modification on the controlled side to is to P2PTransportChannel::OnCheckAndPing(). I made it ping the potential new connection. The new connection status switches to writable when it's pinged after renomination starts. ShouldSwitchSelectedConnection() returns true for the new connection immediately after the ping.

[Taylor Brandstetter]

Ok, so it sounds like there are two main issues here:

1. If the network interface currently being used goes away, the controlling ICE agent doesn't renominate a new pair (unless the old interface is cellular and the new one is Wi-Fi).
2. The controlled side doesn't immediately send a triggered check when it receives the renomination, which delays it switching to the new pair.

Does that sound accurate? If so I'll create bugs to track these problems. Thanks for your thorough explanation, by the way.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/ac33909a-d678-4c5a-86df-56711f7fd315%40googlegroups.com.

[pc...@suitabletech.com]

1. This isn't really a problem for me. I wasn't clear in my previous message why I implement a custom NetworkMonitorInterface. Our device has separate logic that finds the preferred wifi interface. I want control over which wifi interface WebRTC renominates. Faking the ADAPTER_TYPE_CELLULAR is how I change the port's network cost. This is working OK.

 

2. Pretty much accurate. When the controlled side receives pings from a renominated connection, the switch doesn't happen because the writable state remains false. It seems that controlled side waits for the active connection to stop before pinging the unused candidates. If the active connection is poor but not dead, the switch does not happen.

Thanks!

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

[Taylor Brandstetter]

 Our device has separate logic that finds the preferred wifi interface. I want control over which wifi interface WebRTC renominates

Ah, ok. So the issue is more that we don't provide an API to override the default "network cost" computation. It seems like it would be a good idea to add this, maybe after more progress is made in standardizing it.

It seems that controlled side waits for the active connection to stop before pinging the unused candidates.

This is the part I don't fully understand yet; why doesn't the controlling side send a triggered check from OnCheckAndPing->FindNextPingableConnection->FindOldestConnectionNeedingTriggeredCheck? Is there something preventing this, or does it just not happen fast enough?

Anyway, here's a bug; we can continue discussion there: https://bugs.chromium.org/p/webrtc/issues/detail?id=7586

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/4eab3dee-69ca-43f9-9870-53f458d159f1%40googlegroups.com.