Re: [MMUSIC] Next steps on "passive-aggressive" nomination

On 19 Jul 2015, at 08:01, Bernard Aboba <bernard_aboba@hotmail.com<mailto:bernard_aboba@hotmail.com>> wrote:

On Jul 18, 2015, at 03:01, Justin Uberti <juberti@google.com<mailto:juberti@google.com>> wrote:

At IETF 92, we discussed passive-aggressive nomination, which allows implementations to
a) send media as soon as a single check succeeds (like aggressive nom)
b) give the controlling side full discretion in terms of which pair to select (like regular nom)
c) allow the controlled side to know when nomination is complete (like regular nom)

The conclusion from IETF 92<http://www.ietf.org/proceedings/92/minutes/minutes-92-mmusic#h.vqmjfv9a7r6k> was that this looked promising (although we *might* want to have some SDP signaling to control when it is used). We also agreed to solicit alternate proposals and decide at IETF 93 which proposal we wanted to proceed with. On that topic, I am currently aware of one competing proposal, namely this document<https://tools.ietf.org/html/draft-jennings-mmusic-ice-fix-00> from Cullen.

[BA] I would not classify Cullen's proposal as "competing" because it proposes designing a new protocol, whereas "nombis" is based on RFC 5245.  While Cullen does outline issues that might require a new protocol (such as timing issues that could arise when there are many candidate pairs), new protocols are rarely the solution to interoperability issues, since they are as likely to create new interop problems as to fix existing ones. This is particularly true with WebRTC, where the fastest path to ICE interop is probably to clearly define the expected behavior and then "test and fix".

+1.

A ICE2 spec should probably only be written if there are use-cases we can not support with ICE or if we can do things significantly easier or faster. This is probably hard to achieve if we want it to be backwards compatible.

Recent changes where things seems to be moving in a more muxing direction also make things simpler for current ICE implementations.

I have asked for agenda time to discuss the comments that came up at IETF 92, namely:
- potential interoperability concerns with endpoints that only do regular nomination (may drop media that arrives before USE-CANDIDATE)
- potential interoperability concerns with endpoints that only do aggressive nomination (may ignore selected pair indicated in USE-CANDIDATE; may drop media before USE-CANDIDATE; may not send media until USE-CANDIDATE)

[BA] While I can see the value of implementing nombis and then testing it against ICE implementations that claim compliance with RFC 5245, worrying about all the potential interop issues with non-compliant implementations could be a potential rathole, because it involves deciding which non-compliant behavior to bless, just when WebRTC has created new motivation to implement RFC 5245 as specified.

+1.

Having more implementations showing up at the IETF hackathon would be fun. Hacking up a simple ICE testbed that the various implementations could hook into would be a nice start.

.-.
Pål-Erik

- do we need some way to negotiate use of passive-aggressive nomination, to prevent the above problems

[BA] Automatic fallback would be better if possible, because legacy implementations cannot be expected to support new negotiation proposals - and if they were willing to expend effort to improve interop, implementing missing functionality and nombis would be a better use of resources than improving the ability to signal "I do not support feature X of RFC 5245".

<Mail Attachment.txt>_______________________________________________
mmusic mailing list
mmusic@ietf.org<mailto:mmusic@ietf.org>
https://www.ietf.org/mailman/listinfo/mmusic