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

From: Jonathan Lennox <[email-masked]>
Date: Wed, 30 Jul 2014 15:10:41 +0000

(Moving this discussion to MMusic.  I suggest further discussion drop the tram list, unless it cycles back around to a TURN-specific issue.)

On Jul 29, 2014, at 1:57 PM, Justin Uberti <[email-masked]> wrote:
> 
> The one thing we need to do is update ICE to allow the CONTROLLING side to make dynamic decisions about which pair to use, instead of being forced to use PRIORITY (which is what 5245 says). I am going to try to write this up before Hawaii. 

This is equivalent to using regular nomination, but saying that an endpoint can send media on any Confirmed candidate pair, not just the Selected one, right?

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.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 30 Jul 2014 10:12:11 -0700

(Completing the move)

> This is equivalent to using regular nomination, but saying that an endpoint can send media on any Confirmed candidate pair, not just the Selected one, right?

I like this idea.  I don't know what this does to other
implementations, but Firefox would probably be OK with that based on
my quick check of the code.

The only caveat on that is that we need to have a remote candidate for
the flow before it gets delivered.  We create candidates based on one
of three conditions, as 5245 requires: we have received a valid check
from that remote address, we have received a check response from that
remote address, or the remote address was signaled.  If we are
trickling, that could mean that valid packets get discarded for some
time.  I think that the only downside there is that the sender needs
to retransmit their DTLS handshake packets.

That approach more or less renders aggressive nomination pointless, doesn't it?

---

From: Justin Uberti <[email-masked]>
Date: Wed, 30 Jul 2014 13:59:48 -0700

On Wed, Jul 30, 2014 at 8:10 AM, Jonathan Lennox <[email-masked]> wrote:

>
> (Moving this discussion to MMusic.  I suggest further discussion drop the
> tram list, unless it cycles back around to a TURN-specific issue.)
>
> > The one thing we need to do is update ICE to allow the CONTROLLING side
> to make dynamic decisions about which pair to use, instead of being forced
> to use PRIORITY (which is what 5245 says). I am going to try to write this
> up before Hawaii.
>
> This is equivalent to using regular nomination, but saying that an
> endpoint can send media on any Confirmed candidate pair, not just the
> Selected one, right?
>

It's a bit more than that - the controlled endpoint has to also synchronize
on the candidate pair, which means that it needs to know what its selected
pair should be, using logic other than what is outlined in
http://tools.ietf.org/html/rfc5245#section-11.1.1 (which says use the
highest priority nominated pair).

So it becomes:
- controlling side can pick any nominated candidate pair it wants to be its
selected pair
- controlled side should use presence of media from controlling side to
decide selected pair (for secure media), or some TBD attribute (for
non-secure media)
- controlling side can tell controlled side when it is OK to discard
candidate pairs that it has nominated (so that the controlling side can
still safely do the switch to a new pair). This is probably done by having
the controlled side keep all candidates alive that have received a check
from the controlling side in the past XX seconds.

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

---

From: Justin Uberti <[email-masked]>
Date: Wed, 30 Jul 2014 14:04:09 -0700

> to retransmit their DTLS handshake packets.

I don't follow the logic here. If a pair is on the valid list (I assume
that is what Jonathan means by Confirmed), you have received a check
response.

---

From: Jonathan Lennox <[email-masked]>
Date: Wed, 30 Jul 2014 21:14:37 +0000

On Jul 30, 2014, at 4:59 PM, Justin Uberti <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, Jul 30, 2014 at 8:10 AM, Jonathan Lennox <[email-masked]<mailto:[email-masked]>> wrote:

It's a bit more than that - the controlled endpoint has to also synchronize on the candidate pair, which means that it needs to know what its selected pair should be, using logic other than what is outlined in http://tools.ietf.org/html/rfc5245#section-11.1.1 (which says use the highest priority nominated pair).

So it becomes:
- controlling side can pick any nominated candidate pair it wants to be its selected pair
- controlled side should use presence of media from controlling side to decide selected pair (for secure media), or some TBD attribute (for non-secure media)
- controlling side can tell controlled side when it is OK to discard candidate pairs that it has nominated (so that the controlling side can still safely do the switch to a new pair). This is probably done by having the controlled side keep all candidates alive that have received a check from the controlling side in the past XX seconds.

You’ve just reinvented regular nomination — your “TBD attribute” is regular nomination’s USE-CANDIDATE.

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

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.

---

From: Emil Ivov <[email-masked]>
Date: Wed, 30 Jul 2014 23:48:56 +0200

The main problem with the aggressive version of regular nomination is stuff
like DTLS/SRTP (that's actually already kind of an issue with today's
aggressive nomination).

When it's RTP you don't care where you get it from as long as you do. If
it's a DTLS client halo then what do you do exactly?

Can the controlling agent simply respond on a different valid pair than the
one on which it received it? (This is what Chrome currently does but its
frowned upon by the DTLS/SRTP draft which binds the context to a specific
address:port). Does the controlled agent need to resend it on the new pair
after it gets the USE-CANDIDATE?

What about other protocols? Do they all need to say how they are to be used
with ICE? I hope not and I hope we can find a generic approach for all of
them. For example: all early non-acknowledged reliable data has to be
resent on the nominated pair. This would imply a DTLS neg restart as Martin
suggested.

--sent from my mobile
On 30 Jul 2014 11:14 PM, "Jonathan Lennox" <[email-masked]> wrote:

>
>  On Jul 30, 2014, at 4:59 PM, Justin Uberti <[email-masked]> wrote:
>
>  It's a bit more than that - the controlled endpoint has to also
> synchronize on the candidate pair, which means that it needs to know what
> its selected pair should be, using logic other than what is outlined in
>  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.)
>
>    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
>  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.
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>
>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 30 Jul 2014 14:57:01 -0700

On 30 July 2014 14:04, Justin Uberti <[email-masked]> wrote:
>
> I don't follow the logic here. If a pair is on the valid list (I assume that
> is what Jonathan means by Confirmed), you have received a check response.

If you are sending, this isn't an issue.  It's the receiver that needs
to concern itself with having to receive packets on any one of up to
100 candidate pairs.  It will have seen a check on the pair
previously, but it might not have generated a check itself yet.  This
can happen when trickling.

---

From: Justin Uberti <[email-masked]>
Date: Wed, 30 Jul 2014 14:59:26 -0700

> should have said “Valid” rather than “Confirmed”.  I mis-remembered the

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.

>  This would be nonconformant with 5245, but nevertheless wouldn’t surprise

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.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 30 Jul 2014 15:01:29 -0700

> after it gets the USE-CANDIDATE?

RFC 5764 says this:
   A single DTLS-SRTP session only protects data carried over
   a single UDP source and destination port pair.

But I'll postulate that this is only because the alternative (a
shifting substrate) was not yet conceived.  There is nothing in (D)TLS
that requires anything of the underlying transport protocol,
intentionally.  (c.f., tcpinc wg)

Firefox code seems to be OK (at least superficially) with the idea
that packets can arrive from anywhere.  However, I can see why some
implementations might get sad if things shift around.

---

From: Justin Uberti <[email-masked]>
Date: Wed, 30 Jul 2014 15:05:21 -0700

> implementations might get sad if things shift around.
Agreed. I think unless there is some dependency on the lower layer protocol
specifics (which should be uncommon, if at all), the expectation should be
that ICE is a generic, dynamic packet transport (AKA shifting substrate).

---

From: Martin Thomson <[email-masked]>
Date: Wed, 30 Jul 2014 15:06:05 -0700

On 30 July 2014 14:59, Justin Uberti <[email-masked]> wrote:
> Basically, controlled side uses the pair that it most recently received
> USE-CANDIDATE on as its selected pair.

That's pretty good.  It would potentially allow us to move the active
pair around in future (i.e., mobility stuff) without massive backward
compatibility breaks too.  Unilaterally even.

> ServerHello comes from B instead of A and is ignored.

Yeah, this works out pretty well, unless you have the offerer picking
an active role intentionally.  (We've had some errors come up recently
where there was confusion about which role was which; we definitely
want to avoid that.)

---

From: Jonathan Lennox <[email-masked]>
Date: Wed, 30 Jul 2014 22:20:51 +0000

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

On Wed, Jul 30, 2014 at 2:14 PM, Jonathan Lennox <[email-masked]<mailto:[email-masked]>> 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”.

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?

---

From: Martin Thomson <[email-masked]>
Date: Wed, 30 Jul 2014 15:28:21 -0700

On 30 July 2014 15:20, Jonathan Lennox <[email-masked]> wrote:
>
> 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”.

If the controlled peer really does use this as a signal that it's safe
to close out other candidates, then you really do have to have just
the one instance.  Is attaching that semantic safe?  I assume that we
would have to signal in both directions that this new meaning is
acceptable first.  (a=ice-options again)

---

From: Jonathan Lennox <[email-masked]>
Date: Wed, 30 Jul 2014 22:51:08 +0000

> acceptable first.  (a=ice-options again)

5245 8.3.1:
   Once ICE processing
   has reached the Completed state for all peers for media streams using
   those candidates, the agent SHOULD wait an additional three seconds,
   and then it MAY cease responding to checks or generating triggered
   checks on that candidate.  It MAY free the candidate at that time.
You enter the “Completed” state once all components of all streams have sent or received (as appropriate) USE-CANDIDATE.

The “all peers” clause is needed for SIP, to handle forking cases.  For non-forking uses of ICE, “all peers” is equivalent to “the peer”.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 30 Jul 2014 15:57:42 -0700

>> acceptable first.  (a=ice-options again)

I was looking for a stronger signal.  This assumes that the active
pair is the one with the highest candidate for which USE-CANDIDATE has
been sent or received.  But we've been talking about making other
choices.  That would avoid the need for a 3s cleanup timer.

---

From: Justin Uberti <[email-masked]>
Date: Wed, 30 Jul 2014 16:23:12 -0700

On Wed, Jul 30, 2014 at 3:20 PM, Jonathan Lennox <[email-masked]> wrote:

>
>  On Jul 30, 2014, at 5:59 PM, Justin Uberti <[email-masked]> wrote:
>
>  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.
>
>
>  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”.
>

OK, I get it now. I think the main issues you face are:
1) Inability to selectively free candidates - all candidates except the
selected pair can be freed by the controlled side after USE-CANDIDATE.
2) No guarantee of symmetric RTP - remote side can use a different pair
than local side - and you can't resolve this without USE-CANDIDATE (see #1).
3) Potential issues when media arrives on non-nominated pair.

Given #3, I think I'd prefer to find a solution that also addresses #1/#2.

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

Not at this time.

---

From: Justin Uberti <[email-masked]>
Date: Wed, 30 Jul 2014 16:25:08 -0700

> when the paths’ RTTs are very different.

Agree, although this would be addressed by any of:
- receipt of secure media is considered an indication of the selected pair
- retransmit USE-CANDIDATE periodically on selected pair (need to do this
for consent anyway)
- REALLY-USE-CANDIDATE attribute

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 31 Jul 2014 12:50:51 +0200

2014-07-30 23:48 GMT+02:00 Emil Ivov <[email-masked]>:
> them. For example: all early non-acknowledged reliable data has to be resent
> on the nominated pair. This would imply a DTLS neg restart as Martin
> suggested.

+1

IMHO we need a way for ICE (all the flavors) to fully determine which
is the *only* pair in which media or DTLS can be sent, so a peer can
safely discard any RTP or DTLS packet coming from a source address
that does not match the selected/paired/confirmed address tuple.

And IMHO we also need that a ICE-Lite server implementation does not
need to keep a list of valid pairs or source addresses but just one
(chosen via ICE by the controlling peer).

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 31 Jul 2014 12:58:02 +0200

> compatibility breaks too.  Unilaterally even.

I must be missing something, but if the controlled receives two
USE-CANDIDATE, selects the last one as "selected pair" and reply to
them, then the controlling peer would probably use the first
USE-CANDIDATE as "selected pair" (it arrived before so most probably
its response arrived first to the controlling peer, and if it arrived
before it may be because it is a better option so had higher
PRIORITY).

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 31 Jul 2014 13:03:00 +0200

> - receipt of secure media is considered an indication of the selected pair

Please, consider DTLS rather than secure media. Secure media is easy
to handle regardless where it comes from. DTLS is not as you need a
separate context for each tuple.

If you mean that "the controlled must determine as selected pair that
on which it receives the *first* DTLS ClientHello, being a previously
validated ICE pair (so the source address is already known thanks to a
previous ICE transaction)" then that sounds better for me.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Justin Uberti <[email-masked]>
Date: Thu, 31 Jul 2014 12:08:50 -0700

On Thu, Jul 31, 2014 at 4:03 AM, Iñaki Baz Castillo <[email-masked]> wrote:

> to

As discussed earlier, DTLS does not require a separate context for each
tuple. DTLS should be agnostic about the lower layer protocol (and we
should probably create an errata to resolve this confusion).

---

From: Justin Uberti <[email-masked]>
Date: Thu, 31 Jul 2014 12:18:13 -0700

On Wed, Jul 30, 2014 at 4:23 PM, Justin Uberti <[email-masked]> 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.)
>>>
>>

Sounds like #3 is unlikely to be a problem given 5245 allows it.

What do others think about #1/#2? These seem to be the main differences
between Jonathan's proposal and my proposal.

---

From: Emil Ivov <[email-masked]>
Date: Thu, 31 Jul 2014 21:58:55 +0200

+1

--sent from my mobile

---

From: Emil Ivov <[email-masked]>
Date: Thu, 31 Jul 2014 22:30:27 +0200

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

While #3 is indeed allowed by 5245 I don't think current regular nomination
implementations would actually handle things that way. (Except for those
that started with aggressive nomination as the default).

#1 and #2 can be important for ICE libs that just return a socket for the
app to use (the do need to know whem to return it)

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 1 Aug 2014 00:11:02 +0200

2014-07-31 21:08 GMT+02:00 Justin Uberti <[email-masked]>:
> tuple. DTLS should be agnostic about the lower layer protocol (and we should
> probably create an errata to resolve this confusion).

Of course DTLS is low layer agnostic (so it can be carried over UDP,
TCP or whatever) but the fact is that it must be carried over a
"transport" (whatever a transport is). And when it is carried over UDP
it is needed that we create a separate DTLS session/context for each
remote address (IP:port). This is, you cannot open a UDP socket and
deliver there DTLS packets coming from different source addresses.
Instead you need to maintain a DTLS session/context per each source
address. So let's say that DTLS requires a separate transport for each
session (whichever a transport is a TCP connection, a UDP IP:port
tuple or any other data multiplexing solution).

For example, in the case of a ICE-Lite server this is what I expect:

1) The client sends ICE Binding requests and the server replies to
them (ok, a single UDP socket with responses sent to each source
address is ok).
2) At some point the client sends a Binding request with USE-CANDIDATE.
3) Upon that the server can safely determine that the remote address
is the source address from which that Binding request arrived, and can
*safely* ignore any DTLS or SRTP/SRTCP packet coming from any other
source address.

My concern is: is bullet 3) 100% true with the current set of
specifications plus the new proposed ICE mechanism? The fact is that
RFC 5764 states that a peer must be ready to receive "media" in any of
the offered ICE candidates, but that breaks everything, specifically
when it comes to DTLS (as said above that would require that the peer
creates a separate DTLS session for each different source address from
which "media" receipt is considered "valid").

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 1 Aug 2014 00:13:17 +0200

2014-08-01 0:11 GMT+02:00 Iñaki Baz Castillo <[email-masked]>:
> The fact is that
> the offered ICE candidates,

Sorry, I mean RFC 5245 (ICE).

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 1 Aug 2014 00:17:38 +0200

> that started with aggressive nomination as the default).

Yes, RFC 5245 allows media coming on non-nominated pair. But note that
RFC 5245 knows nothing about DTLS. I strongly expect that RFC 5245
would not allow that in case of DTLS-SRTP given that allowing DTLS
coming from "any" source address adds too much complexity.

My understanding of ICE is that it should be the definitive tool to
*establish a transport* and once it concludes, the "application data"
(let's say DTLS and SRTP) must be delivered over the selected pair,
and data coming from any other source should be safely discarded.
Sadly RFC 5245 does not mandate that but given that RFC 5245bis is a
work in progress I hope this requirement is added.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Martin Thomson <[email-masked]>
Date: Thu, 31 Jul 2014 15:28:16 -0700

> coming from "any" source address adds too much complexity.

I disagree.  I think that the general idea that the flow endpoints
might change is inherent in ICE.

There is obviously a point at which it is expedient for a range of
reasons to nail things down to a single pair of addresses.  That
includes cleanup and some SDP interactions, along with some fun
middlebox issues.  So we have an ICE process that completes, but ICE
doesn't actually *need* to complete.  It's primary goal is to find
some way to get the packets through.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 1 Aug 2014 00:40:11 +0200

> some way to get the packets through.

If you allow "application data" coming from a source address which is
not the ICE nominated one then you must specify how such an
application data must behave when ICE is used to determine the network
path(s). As said before:

- For SRTP/SRTCP it is not a big deal given than you manage each RTP
packet separately (no matter where it comes from as long as it can be
decrypted with the previously negotiated keys).

- For DTLS it means complexity in the sense that a separate DTLS
session/context is required for each "transport".

- For any other network protocol new rules should be specified.

So I would like that ICE is used to determine a *single* and
*definitive* (at least until it is not restarted by STUN/ICE
procedures) network path. Life becomes easier and any kind of
application data can be easily carried once ICE completes (and
provides a *single* network path).

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Martin Thomson <[email-masked]>
Date: Thu, 31 Jul 2014 17:34:28 -0700

> session/context is required for each "transport".

Not really.  DTLS "says" that, but it doesn't functionally rely on a
stable 5-tuple in any real fashion.

Other protocols that rely on UDP are likely to be similar.  Reliance
in name only.

---

From: Justin Uberti <[email-masked]>
Date: Thu, 31 Jul 2014 18:06:38 -0700

> Other protocols that rely on UDP are likely to be similar.  Reliance

Think of ICE as a virtual socket. At higher layers, you don't know the
address of the remote endpoint or exactly how it will be contacted, but you
know if you send something on the virtual socket it will make it to the
remote endpoint. That's all DTLS needs to know.