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

From: Justin Uberti <[email-masked]>
Date: Fri, 17 Jul 2015 18:00:58 -0700

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.

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)
- do we need some way to negotiate use of passive-aggressive nomination, to
prevent the above problems
- do we need some way to suppress use of aggressive nomination, to allow us
to avoid needing to support regular, passive-aggressive, and aggressive
nomination in future clients

Are there any other concerns that I missed?

---

From: Roman Shpount <[email-masked]>
Date: Sat, 18 Jul 2015 05:53:44 -0400

On Fri, Jul 17, 2015 at 9:00 PM, Justin Uberti <[email-masked]> wrote:

> - do we need some way to negotiate use of passive-aggressive nomination,
> to prevent the above problems
> - do we need some way to suppress use of aggressive nomination, to allow
> us to avoid needing to support regular, passive-aggressive, and aggressive

I am not sure if it was brought up at IETF 92, but there is also ability to
discover asymmetric paths using ICE.
_____________
Roman Shpount

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 19 Jul 2015 08:01:57 +0200

On Jul 18, 2015, at 03:01, Justin Uberti <[email-masked]> wrote:
> 
> At IETF 92, we discussed passive-aggressive nomination, which allows implementations to
> 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 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 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".

> 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. 

> - 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". 

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

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Sun, 19 Jul 2015 09:47:38 +0000

On 19 Jul 2015, at 08:01, Bernard Aboba <[email-masked]<mailto:[email-masked]>> wrote:

On Jul 18, 2015, at 03:01, Justin Uberti <[email-masked]<mailto:[email-masked]>> wrote:

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.

+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.

+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

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