Subject: Re: [Ice] Brian Haberman's No Objection on charter-ietf-ice-00-03: (with COMMENT)

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Thu, 1 Oct 2015 08:27:59 +0000

> On 01 Oct 2015, at 06:07, Ben Campbell <[email-masked]> wrote:
> 
> On 30 Sep 2015, at 23:03, Ben Campbell wrote:
> 
>> I think the key differences are threefold (not counting the fact that ICE predates 6724 and 6555 :-) ):
>> 
>> -- ICE is historically about NAT traversal. This has a few implications: It is concerned with address:port pairs, not just addresses. Candidates often represent things like a direct path to a native address/port, a NAT address/port, and an address/port at a TURN relay. These need to be prioritized just like with the address selection mechanisms--but with active connectivity checks to speed up the selection process.
>> 
>> -- ICE is designed to be used with real-time signaling protocols (e.g. SIP, WebRTC, xmpp). These allow endpoints to express explicit preferences about candidate priority, rather than static rules.
>> 
>> -- ICE connectivity checks are also used to by WebRTC to let endpoints express consent to receive media.
>> 
>> Does any of this help?
> 
> Oops, missed one (There are _four_ key differences...)
> 
> -- ICE is designed for real-time media applications, where the user experience is badly impacted if you have noticeable delay between signaling a session, and actually getting media to flow.
> 
> 
I think that was a good summary.

ICE does not care about things like “default route” and things like that… It is pretty pragmatic and topology agnostic. Get hold of all our local candidates ( any interface with an IPv4 or IPv6 the OS lets you open up a port on). It will then pair those with the remote candidates and do a lot of connectivity checks to see what actually works. This behaviour can be a bit unexpected from a network point of view, where they might think that an application would only use the standard default route and so on. One of the goals of creating a new ICE WG is to help facilitate discussions between app and network folks. 

.-.
Pål-Erik

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

---

From: Simon Perreault <[email-masked]>
Date: Thu, 1 Oct 2015 08:19:23 -0400

> Just a question for my own edification... How does the address selection
> mechanism in ICE work/play with the address selection done at the IP
> layer?  We have address selection mechanisms described in RFCs 6724 and
> 6555 (and others) and address selection issues/requirements described in
> RFCs 5220 and 5221.  Not sure how all those fit with a higher-layer
> protocol making similar decisions.

In addition to what others have said, ICE *does* refer to RFC 3484 for
assigning priorities to candidates, so there's that. And Pål-Erik has a
draft tweaking some of that behaviour:

https://tools.ietf.org/html/draft-ietf-mmusic-ice-dualstack-fairness-02

I suppose that that draft would move to the new ICE WG, so in a way the
answer to your question could be "the new WG will work on that".

Simon