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

From: "Ben Campbell" <[email-masked]>
Date: Wed, 30 Sep 2015 23:03:03 -0500

On 30 Sep 2015, at 11:57, Brian Haberman wrote:

> Brian Haberman has entered the following ballot position for
> charter-ietf-ice-00-03: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut 
> this
> introductory paragraph, however.)
>
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/charter-ietf-ice/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> 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.

You don't ask easy questions, do you :-) I was hoping one of the really 
deep ICE experts would jump in (A little help, guys?) but I will give it 
a shot:

There are some similarities between ICE and some of the general 
address-selection rules in that an ICE implementation has to make some 
similar choices. There's some similarity with the happy-eyeball's "try 
everything and see what works" model.

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?

Thanks!

Ben.

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 30 Sep 2015 23:07:09 -0500

On 30 Sep 2015, at 23:03, Ben Campbell wrote:

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

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.