Subject: [Ice] Do we want to mandate all protocols supporting ICE and multiple transports to support transport switch on-the-fly before nomination?

From: Christer Holmberg <[email-masked]>
Date: Sat, 19 Nov 2016 09:27:12 +0000

Hi,

One potential issue that came to my mind while reading the SDP m- line thread.

Previously, before removal of aggressive nomination, while and endpoint might support both UDP and TCP for a protocol, it didn't have to be able to simultaneously use the protocol with both UDP and TCP, and switching between. Because, until nomination was done, no protocol data was sent. And, once nomination had been done, endpoints used the protocol with the selected transport.

Now, with the allowed-to-send-media-before-nomination rules, protocols basically have to support switch of transport (from UDP to TCP, and vice versa), until the nomination takes place.

Now, even people always say that a good designed protocol should be transport-independent, isn't *mandating* transport switching on-the-fly (before nomination takes place) by all protocols supporting ICE and multiple transports a bad thing to do?

Perhaps the ICE considerations of each protocol (RTP, BFCP etc) should indicate whether transport switching is supported, and whether there are protocol specific procedures associated with that. I guess a protocol could also specify that data shouldn't be sent in the first place before nomination has been done, if there are good reasons for that.

Regards,

Christer

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 19 Nov 2016 18:22:33 -0800

Christer --

With aggressive nomination, a TCP candidate-pair could be nominated, and
then a UDP candidate-pair could be nominated, and data could be sent on a
successful pair.  So "switching" can also occur.  Given that the controlled
peer needs to be able to receive on any successful pair, it has to be
prepared for receiving both UDP and TCP packets at the same time.

So how is "passive-aggressive" nomination more onerous than aggressive in
this respect?

On Nov 19, 2016 1:27 AM, "Christer Holmberg" <[email-masked]>
wrote:

> Previously, before removal of aggressive nomination, while and endpoint
> might support both UDP and TCP for a protocol, it didn’t have to be able to
> simultaneously use the protocol with both UDP and TCP, and switching
> between. Because, until nomination was done, no protocol data was sent.
> And, once nomination had been done, endpoints used the protocol with the
> selected transport.
>
>
>
> Now, with the allowed-to-send-media-before-nomination rules, protocols
> basically have to support switch of transport (from UDP to TCP, and vice
> versa), until the nomination takes place.
>
>
>
> Now, even people always say that a good designed protocol should be
> transport-independent, isn’t **mandating** transport switching on-the-fly
> (before nomination takes place) by all protocols supporting ICE and
> multiple transports a bad thing to do?
>
>
>
> Perhaps the ICE considerations of each protocol (RTP, BFCP etc) should
> indicate whether transport switching is supported, and whether there are
> protocol specific procedures associated with that. I guess a protocol could
> also specify that data shouldn’t be sent in the first place before
> nomination has been done, if there are good reasons for that.
>
>
>
> Regards,
>
>
>
> Christer
>
> _______________________________________________
> Ice mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ice
>
>

---

From: Roman Shpount <[email-masked]>
Date: Sun, 20 Nov 2016 18:20:50 -0500

Hi Christer,

Bernard have already addressed the issues related to aggressive nomination.

I also wanted to bring up that this group is also actively working on
continuous nomination. With continuous nomination "switching" between
candidate pairs can occur for a fairly long time and protocol cannot wait
for the nomination to complete. Requiring for the protocol to wait until
nomination is complete will make it incompatible with continuous nomination.

Finally, and most importantly, I wanted this group to examine the purpose
of tcp candidates. The way RFC 6544 is written, it implies that ICE creates
a complete framework for setting up TCP connections between two end points
with one or both of these end points located behind NAT. The document talks
about simultaneous open candidates, reflexive TCP candidates and setting up
relay for TCP connections. At the same time, in the actual implementations
tcp relay and reflexive candidate are redundant, and tcp candidates are
only used as a fail-over for udp candidates when udp is blocked by firewall
and one of the end points is on public IP address. I have not seen anybody
implementing the simultaneous open candidates and such candidates are
impossible to implement on some of the operating systems. All I see are
host active tcp candidates on the end points located behind NAT and host
passive tcp candidates on the end points located on public internet.

I would argue that creating a full framework for TCP connections and only
using tcp candidates for udp fail-over are two very different use cases.
They should be specified differently and cannot be used at the same time. I
think it would be better to spell this out and limit the tcp candidate use
case.

For instance, in case of BFCP, TCP/BFCP can be used with TCP connection
framework, which would require a direct host to host connections, so
connections to reflexive addresses and some support for relay. This
framework however, is not ICE, and will not support UDP and will use BFCP
native framing. On the other hand, UDP/BFCP can naturally run on top of
ICE, use both udp and tcp candidates. The only tcp candidates used in this
case would be host candidates and BFCP running over tcp candidates will be
UDP/BFCP with  RFC 4571 framing as required by RFC 6544 (
https://tools.ietf.org/html/rfc6544#section-10.1).

I think most of this discussion is due to very limited design and analysis
that went into specification of BFCP with ICE. Once BFCP over ICE would be
well defined most of those issues will disappear.

Regards,

_____________
Roman Shpount

On Sat, Nov 19, 2016 at 9:22 PM, Bernard Aboba <[email-masked]>
wrote:

> On Nov 19, 2016 1:27 AM, "Christer Holmberg" <christer.holmberg@ericsson.
> com> wrote:
>
>> Hi,
>>
>>
>>
>> transport-independent, isn’t **mandating** transport switching
>> on-the-fly (before nomination takes place) by all protocols supporting ICE
>> and multiple transports a bad thing to do?
>>
>>
>>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 21 Nov 2016 09:55:13 +0000

Hi Bernard,

You are correct – the problem already existed in RFC 5245.

There is a difference, though:

When using aggressive nomination (RFC 5245) the endpoints could not switch between valid candidate pairs as they wish. At any given time, only the nominated pair with the highest-priority could be used, meaning that there was only one selected pair at any given time.

In 5245bis, media can be sent on any pair, and the switching can be done whenever, however, and there is no need to nominate to begin with, prior to sending media.

Regards,

Christer

From: Bernard Aboba [mailto:[email-masked]]
Sent: 20 November 2016 04:23
To: Christer Holmberg <[email-masked]>
Cc: [email-masked]
Subject: Re: [Ice] Do we want to mandate all protocols supporting ICE and multiple transports to support transport switch on-the-fly before nomination?

Christer --

With aggressive nomination, a TCP candidate-pair could be nominated, and then a UDP candidate-pair could be nominated, and data could be sent on a successful pair.  So "switching" can also occur.  Given that the controlled peer needs to be able to receive on any successful pair, it has to be prepared for receiving both UDP and TCP packets at the same time.

So how is "passive-aggressive" nomination more onerous than aggressive in this respect?

On Nov 19, 2016 1:27 AM, "Christer Holmberg" <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Previously, before removal of aggressive nomination, while and endpoint might support both UDP and TCP for a protocol, it didn’t have to be able to simultaneously use the protocol with both UDP and TCP, and switching between. Because, until nomination was done, no protocol data was sent. And, once nomination had been done, endpoints used the protocol with the selected transport.

Now, even people always say that a good designed protocol should be transport-independent, isn’t *mandating* transport switching on-the-fly (before nomination takes place) by all protocols supporting ICE and multiple transports a bad thing to do?

Perhaps the ICE considerations of each protocol (RTP, BFCP etc) should indicate whether transport switching is supported, and whether there are protocol specific procedures associated with that. I guess a protocol could also specify that data shouldn’t be sent in the first place before nomination has been done, if there are good reasons for that.

Regards,

Christer

_______________________________________________
Ice mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ice

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 21 Nov 2016 10:03:19 +0000

Hi,

I think it would be good to have text in 5245bis that explicitly says that either endpoints supporting protocol X need to be able to switch between candidate pairs (even if they use different transport), OR protocol X data must not be done prior to nomination (which, of course, would not work in continuous nomination scenarios).

Regards,

Christer

From: Roman Shpount [mailto:[email-masked]]
Sent: 21 November 2016 01:21
To: Christer Holmberg <[email-masked]>
Cc: [email-masked]; Bernard Aboba <[email-masked]>
Subject: Re: [Ice] Do we want to mandate all protocols supporting ICE and multiple transports to support transport switch on-the-fly before nomination?

Hi Christer,

I also wanted to bring up that this group is also actively working on continuous nomination. With continuous nomination "switching" between candidate pairs can occur for a fairly long time and protocol cannot wait for the nomination to complete. Requiring for the protocol to wait until nomination is complete will make it incompatible with continuous nomination.

Finally, and most importantly, I wanted this group to examine the purpose of tcp candidates. The way RFC 6544 is written, it implies that ICE creates a complete framework for setting up TCP connections between two end points with one or both of these end points located behind NAT. The document talks about simultaneous open candidates, reflexive TCP candidates and setting up relay for TCP connections. At the same time, in the actual implementations tcp relay and reflexive candidate are redundant, and tcp candidates are only used as a fail-over for udp candidates when udp is blocked by firewall and one of the end points is on public IP address. I have not seen anybody implementing the simultaneous open candidates and such candidates are impossible to implement on some of the operating systems. All I see are host active tcp candidates on the end points located behind NAT and host passive tcp candidates on the end points located on public internet.

I would argue that creating a full framework for TCP connections and only using tcp candidates for udp fail-over are two very different use cases. They should be specified differently and cannot be used at the same time. I think it would be better to spell this out and limit the tcp candidate use case.

For instance, in case of BFCP, TCP/BFCP can be used with TCP connection framework, which would require a direct host to host connections, so connections to reflexive addresses and some support for relay. This framework however, is not ICE, and will not support UDP and will use BFCP native framing. On the other hand, UDP/BFCP can naturally run on top of ICE, use both udp and tcp candidates. The only tcp candidates used in this case would be host candidates and BFCP running over tcp candidates will be UDP/BFCP with  RFC 4571 framing as required by RFC 6544 (https://tools.ietf.org/html/rfc6544#section-10.1).

I think most of this discussion is due to very limited design and analysis that went into specification of BFCP with ICE. Once BFCP over ICE would be well defined most of those issues will disappear.

Regards,

_____________
Roman Shpount

On Sat, Nov 19, 2016 at 9:22 PM, Bernard Aboba <[email-masked]<mailto:[email-masked]>> wrote:

Christer --

Regards,

Christer

---

From: Emil Ivov <[email-masked]>
Date: Mon, 21 Nov 2016 11:58:44 -0600

On 11/20/16 5:20 PM, Roman Shpount wrote:
> continuous nomination.

Personally I am not aware of any active work on this in the group. Am I 
missing something?

I am also opposed to trying to squeeze this into ICE's current version. 
Think we should think about a more serious redesign first.

Emil

-- 
https://jitsi.org

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 21 Nov 2016 18:33:18 +0000

Doesn't 5245bis already implement "continuous nomination", by making nominating "optional" (as you can send media before nomination)?

Regards,

Christer 

Sent from my iPhone

> On 21 Nov 2016, at 19.58, Emil Ivov <[email-masked]> wrote:
> 
> Personally I am not aware of any active work on this in the group. Am I missing something?
> 
> I am also opposed to trying to squeeze this into ICE's current version. Think we should think about a more serious redesign first.
> 
> Emil
> 
> -- 
> https://jitsi.org

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 21 Nov 2016 12:29:53 -0800

Christer said:

"When using aggressive nomination (RFC 5245) the endpoints could not switch
between valid candidate pairs as they wish. At any given time, only the
nominated pair with the highest-priority could be used, meaning that there
was only one selected pair at any given time."

[BA] Without multi-path RTP, peers may only send media on a single pair at
a time.  However, the receiving side may see intermingling of media on
multiple pairs, due to reordering or RTX, so a receiver needs to be
prepared to deal with that.

Note that ICEbis Section 4.3 requires an agent to be prepared to receive
media once candidate information is sent (even before sending a response to
a check!):

" Once an agent has sent its candidate information, that agent MUST be
   prepared to receive both STUN and media packets on each candidate."

So in practice,  "highest-priority" isn't of much help to the receiver (it
can't use that to stop listening on one or more candidates).

"In 5245bis, media can be sent on any pair, and the switching can be done
whenever, however, and there is no need to nominate to begin with, prior to
sending media."

[BA] While a "passive-aggressive" implementation may send media on any
valid pair and switch between them , unless multi-path RTP is negotiated,
it cannot send media on multiple pairs at once.  On the receiving side, as
with aggressive nomination, intermingling may occur.  So I'm not clear that
for a receiver things are all that different.

On Mon, Nov 21, 2016 at 1:55 AM, Christer Holmberg <
[email-masked]> wrote:

> When using aggressive nomination (RFC 5245) the endpoints could not switch
> between valid candidate pairs as they wish. At any given time, only the
> nominated pair with the highest-priority could be used, meaning that there
> was only one selected pair at any given time.
>
>
>
> In 5245bis, media can be sent on any pair, and the switching can be done
> whenever, however, and there is no need to nominate to begin with, prior to
> sending media.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
> *From:* Bernard Aboba [mailto:[email-masked]]
> *Sent:* 20 November 2016 04:23
> *To:* Christer Holmberg <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [Ice] Do we want to mandate all protocols supporting ICE
> and multiple transports to support transport switch on-the-fly before
> nomination?
>
>
>
> Christer --
>

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 21 Nov 2016 12:46:43 -0800

Emil said:

"

I am also opposed to trying to squeeze this into ICE's current version.
Think we should think about a more serious redesign first."

[BA] Since we are deprecating aggressive nomination, my understanding is
that the term "Continuous nomination" refers to an implementation that
utilizes "passive-aggressive" nomination, but does not nominate a
candidate-pair.  Such an implementation can send on any successful pair
(but only on one pair at a time, absent support for multi-path RTP).

If that understanding is correct (is it?) then "continuous nomination" is
not a "thing", but rather the absence of something, namely nomination (e.g.
"continuous non-nomination"?).

So you may not be missing "something", so much as the "absence of
something".  It is somewhat awkward to talk about "active work" on an
absence of something or squeezing an absence into something, which may
explain why you may not have been aware of its (non)-existence.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 21 Nov 2016 14:44:17 -0800

Christer said:

"Doesn't RFC 5245bis already implement "continuous nomination" by making
nominating "optional" (as you can send media before nomination)?"

[BA]  While RFC 52452bis makes it possible send media before nomination, I
don't think the current text enables an implementation to dispense with
nomination entirely.

For example, the text requires an implementation to be ready to receive as
soon as it sends candidate information. That implies that resources cannot
be freed until a candidate-pair has been nominated.

Since keeping resources alive indefinitely is problematic (e.g. from an
energy consumption standpoint), the implementations I am familiar with
utilize mechanisms to identify needed versus unneeded pairs.  For example,
a candidate removal extension can be used to identify pairs that can be
discarded (or pairs not to be checked), or consent mechanisms can be used
to identify pairs to be kept.

However, without these extensions or clarifications, I don't think we can
really say that RFC 5245bis enables nomination to be made optional.

BTW, since we are really talking about making nomination optional,
"continuous nomination" does not strike me as a good term to describe what
we're talking about.

On Mon, Nov 21, 2016 at 10:33 AM, Christer Holmberg <
[email-masked]> wrote:

> Doesn't 5245bis already implement "continuous nomination", by making
> nominating "optional" (as you can send media before nomination)?
>
> Regards,
>
> Christer
>
> Sent from my iPhone
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 22 Nov 2016 05:48:20 +0000

Hi Bernard,

To clarify: in all cases below, I agree peers can only send media on a single pair at a time. My issue was how that single pair is chosen: RFC allows peers to send-media-on-highest-priority-valid-pair while ICEbis allows peers to send-media-on-any-valid-pair.

…

>[BA] Without multi-path RTP, peers may only send media on a single pair at a time.  However, the receiving side may see
>intermingling of media on multiple pairs, due to reordering or RTX, so a receiver needs to be prepared to deal with that.

Correct. Probably another thing worth to explicitly point out in the spec.

>Note that ICEbis Section 4.3 requires an agent to be prepared to receive media once candidate information is sent (even before sending a response to a check!):
>
>So in practice,  "highest-priority" isn't of much help to the receiver (it can't use that to stop listening on one or more candidates).

We could always make things more strict in ICEbis, and say that media can only be sent on valid pairs. Because, how does the media sender even know that such media would even reach the peer?
Regards,
Christer

On Mon, Nov 21, 2016 at 1:55 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi Bernard,

Regards,

Christer

From: Bernard Aboba [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 20 November 2016 04:23
To: Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Ice] Do we want to mandate all protocols supporting ICE and multiple transports to support transport switch on-the-fly before nomination?

Christer --

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 22 Nov 2016 05:56:33 +0000

Hi,

>>"Doesn't RFC 5245bis already implement "continuous nomination" by making nominating "optional" (as you can send media before nomination)?"
>
>[BA]  While RFC 52452bis makes it possible send media before nomination, I don't think the current text enables an implementation to dispense with >nomination entirely.
>
>For example, the text requires an implementation to be ready to receive as soon as it sends candidate information. That implies that resources cannot be >freed until a candidate-pair has been nominated.
>
>Since keeping resources alive indefinitely is problematic (e.g. from an energy consumption standpoint), the implementations I am familiar with utilize >mechanisms to identify needed versus unneeded pairs.  For example, a candidate removal extension can be used to identify pairs that can be discarded (or >pairs not to be checked), or consent mechanisms can be used to identify pairs to be kept.

I do agree that there are good reasons why you should nominate, and maybe we need to add some text about that, and some guidance regarding when nomination should at latest be done.

For example, if there are no more pairs to test, should we say that nomination must be done at that point? That would also cover trickle, as in the case of trickly there would be more pairs to test :)

My point was that things will work (at least in theory) even if you don’t nominate.

>However, without these extensions or clarifications, I don't think we can really say that RFC 5245bis enables nomination to be made optional.

“optional” was perhaps wrong wording.

>BTW, since we are really talking about making nomination optional, "continuous nomination" does not strike me as a good term to describe what we're >talking about.

I agree :)

Regards,

Christer

On Mon, Nov 21, 2016 at 10:33 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Doesn't 5245bis already implement "continuous nomination", by making nominating "optional" (as you can send media before nomination)?

Regards,

Christer

Sent from my iPhone

> On 21 Nov 2016, at 19.58, Emil Ivov <[email-masked]<mailto:[email-masked]>> wrote:
>