Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?)

[Jonathan Lennox <[e-mail]>]

On Jul 30, 2014, at 5:59 PM, Justin Uberti <[e-mail]<mailto:[e-mail]>> wrote:

On Wed, Jul 30, 2014 at 2:14 PM, Jonathan Lennox <[e-mail]<mailto:[e-mail]>> wrote:
Thus the suggestion I’m making — do regular nomination, but allow media to be sent on any valid pair prior to selection.  (Yes, re-reading 5245, I should have said “Valid” rather than “Confirmed”.  I mis-remembered the terminology.)

Understood. But controlled side needs some way to know what pair it should use to send media, so we need some way to indicate this. Would this be done via USE-CANDIDATE? If so, we could end up with multiple USE-CANDIDATEs as we figure out the ideal path to use, which doesn't fit exactly with regular nomination as defined in 5245, but otherwise seems exactly like what I am proposing. Basically, controlled side uses the pair that it most recently received USE-CANDIDATE on as its selected pair.

Oh, that’s true, it has to pick something.

In the semantic I’m suggestion, I think it doesn’t matter what it picks — it could choose any valid pair, just like the controlling agent does, since it knows that’s a working round-trip path.

For both sides, if you receive media on any candidate (from an IP and port from which you’ve received a valid connectivity check), accept it.  USE-CANDIDATE is then just an optimization that lets you close down the unselected candidates.

I don’t think you want a rule of “most recently received USE-CANDIDATE” to determine the selected pair.  Checks will race each other, especially when the paths’ RTTs are very different.

In my model, there is only ever one USE-CANDIDATE sent per component — i.e., it works like pure regular nomination, except for the “early media”.

5245 says that an ICE endpoint MUST be prepared to receive media on any candidate, but only sends on the Selected candidate pair.  I don’t know if this means, in practice, that ICE-bis could change to the behavior I’ve described above and still be backward compatible, or if there’d need to be some sort of ice-option negotiation to indicate that this early media (oh, dread phrase) is acceptable.

Yes, I think we need a new ICE option, or else old ICE impls in the controlled role will be surprised when they think the selected pair is A but media arrives on B. We've already seen a number of implementations have issues with this.

Do they have issues receiving media if there is no selected pair yet?  This would be nonconformant with 5245, but nevertheless wouldn’t surprise me.

Since the controlled side sends the ClientHello in the typical case, this isn't usually a problem. The issue that is most often seen is that the ServerHello comes from B instead of A and is ignored.

These are all in cases when the controlling endpoint is using aggressive nomination, though, right?  Do you have any data for regular nomination, i.e. media received before any USE-CANDIDATE attribute?