Subject: [MMUSIC] Proposed approach for NICE

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 03 Jul 2008 10:21:41 -0400

Here is what I am thinking about for a revision of the NICE document. I 
think we have agreed we don't want to define an ICE subset or a new 
protocol. It also looks like each using protocol will have to make its 
own decisions about how to do various things - what features they need, 
which they don't, etc. So I think the best we can do is write a document 
that provides guidelines about the various parts of ICE, which ones 
might or might not be applicable to other specs, and gives some guidance 
on how to make use of the ICE spec.

I'd probably break this up into something like this:

1. ICE applicability

what kind of protocols can benefit from ICE - you need to be a 
session-establishing type of protocol, have a signaling mechanism 
through a central intermediarty that everyone can reach, etc.

2. gathering phase

talk about applying this part of ICE - its important to use exactly the 
same stun/turn protocols to reuse the server infrastructure. Might be 
different pacing, different prioritization

3. offer/answer

talk about generally what data needs to be exchanged, how each protocol 
will need to incorporate this into their own signaling protocols

4. connectivity checks

talk about how you should just reuse this part of ICE verbatim - 
including state machinery and stun messaging - that this is the KEY 
interop component if we ever want to do things like RTSP to SIP gateways 
or something, so we want this to be the same.

What might differ is pacing; talk about role selection and how that is 
kind of specific to sip but how to be compatible with it

point out what sections of the ICE spec you need to basically reference

5. subsequent signaling

discuss what the drivers are for this and when its needed and when its not

Does this seem like:

a. its useful to folks producing protocols that make use of ICE,
b. its a good direction

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: "Benny Prijono" <[email-masked]>
Date: Thu, 3 Jul 2008 16:29:56 +0100

Jonathan,

The single most important point from your post is that NICE will not
be another variant of ICE. There is only one ICE, and that is ICE. I'm
so thrilled that we've come to this agreement. In fact probaly we
should stop calling "this thing" NICE, as that gives people wrong
impression that somewhat this version of ICE is  more appropriate or
different or even simpler to use for another protocol than ICE. ICE is
ICE, and that's it. Take it or leave it.

So the next question then will be, is it worth it to write a document
to explain how to use ICE with non SIP/SDP protocol?

In my experience writing ICE in PJNATH [1], I always knew that the
bulk of ICE protocol is generic for any signaling protocols, and only
the SDP offer/answer part is specific to SIP. That's why I implemented
ICE in an SIP-independent library, and create a SDP wrapper on top of
that as a glue code to SIP.

So I expect anyone looking to integrate ICE into another protocol will
know that too, as well as to know that (s)he can modify various ICE
parameters (pacing timers, priority settings, etc.) without breaking
ICE.

So IMHO if we need to write such document, probably it just need to
contain this sentence only: "You MUST NOT implement ICE in such a way
that it's not compatible with ICE". ;-)

Just my 0.02p.

Cheers
 Benny

[1] http://www.pjsip.org/pjnath/docs/html/index.htm

On Thu, Jul 3, 2008 at 3:21 PM, Jonathan Rosenberg <[email-masked]> wrote:
> protocol. It also looks like each using protocol will have to make its own
> decisions about how to do various things - what features they need, which
> they don't, etc. So I think the best we can do is write a document that
> provides guidelines about the various parts of ICE, which ones might or
> might not be applicable to other specs, and gives some guidance on how to
> make use of the ICE spec.
>
> session-establishing type of protocol, have a signaling mechanism through a
> central intermediarty that everyone can reach, etc.
>
> 2. gathering phase
>
> talk about applying this part of ICE - its important to use exactly the same
> stun/turn protocols to reuse the server infrastructure. Might be different
> pacing, different prioritization
>
> 3. offer/answer
>
> talk about generally what data needs to be exchanged, how each protocol will
> need to incorporate this into their own signaling protocols
>
> 4. connectivity checks
>
> talk about how you should just reuse this part of ICE verbatim - including
> state machinery and stun messaging - that this is the KEY interop component
> if we ever want to do things like RTSP to SIP gateways or something, so we
> want this to be the same.
>
> What might differ is pacing; talk about role selection and how that is kind
> of specific to sip but how to be compatible with it
>

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Thu, 3 Jul 2008 14:30:07 -0600

Hi,

   Here is my input as a participant to this wg.

> a. its useful to folks producing protocols that make use of ICE,
I would think so.  I would however defer to implementers of non-SIP
clients, and look for XMPP folks and in particular to other IM clients
that implement ICE-like methods to chime in.  See
http://www.xmpp.org/extensions/xep-0176.html for what I would consider a
good example of a non-SIP usage of ICE.

> b. its a good direction
It seems to be inline with my understanding of the wg feedback on NICE
to date.

More inline,
Jean-Francois.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Jonathan Rosenberg
> Sent: Thursday, July 03, 2008 8:22 AM
> To: IETF MMUSIC WG
> Subject: [MMUSIC] Proposed approach for NICE
> 
> which they don't, etc. 
Yes, with the note that an ICE stack should be able to get used by those
implementations without having to modify it.  That is to say that NiCE
is an injective function of ICE in terms of compliance to MUST
requirement verbs.  Could the NICE draft use some XML mapping of ICE to
provide meaningful stubs for implementers beyond aBNF?

> So I think the best we can do is write a
> document
> might or might not be applicable to other specs, 
My understanding of the feedback to date is that some folks did not want
a profile of ICE.  It is ICE usage, but whatever is a MUST in ICE
remains a MUST in NICE.  For example, the gathering of candidates and
the computation of foundations, etc. must follow the strict procedures
as required in ICE - no compromise there.

> and gives some guidance on how to make use of the ICE spec.
Yes.

> same stun/turn protocols to reuse the server infrastructure. Might
> be2

I would agree that this is the critical part.  As a point of reference,
it would be good to see how the NICE section here aligns with section
5.5 of http://www.xmpp.org/extensions/xep-0176.html.

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 05 Jul 2008 13:09:45 +0300

I am not sure whether this is really such a useful effort.

There aren't too many protocols that are going to make use of ICE as 
there aren't too many protocols anyway. We have been experimenting with 
ICE for usage with MIP and HIP. The work has not gone very far yet. The 
lack of progress had nothing todo with this type of document. The work 
in XMPP is already finished and hence this document will not help them 
either.

Avoiding being too focused in the ICE specification when it comes to the 
usage of SIP could have been nice but that hasn't caused too many 
problems -- just took longer to read it. Since you have to read through 
the specification anyway when you want to make use of ICE I doubt that 
items (1)-(4) from your list below would provide any more insight.

So, who would make use of this document?

Ciao
Hannes

Jonathan Rosenberg wrote:
> Here is what I am thinking about for a revision of the NICE document. 
> I think we have agreed we don't want to define an ICE subset or a new 
> own decisions about how to do various things - what features they 
> need, which they don't, etc. So I think the best we can do is write a 
> document that provides guidelines about the various parts of ICE, 
> which ones might or might not be applicable to other specs, and gives 
> some guidance on how to make use of the ICE spec.
>
> talk about applying this part of ICE - its important to use exactly 
> the same stun/turn protocols to reuse the server infrastructure. Might 
> be different pacing, different prioritization
>
> 3. offer/answer
>
> talk about generally what data needs to be exchanged, how each 
> protocol will need to incorporate this into their own signaling protocols
>
> 4. connectivity checks
>
> interop component if we ever want to do things like RTSP to SIP 
> gateways or something, so we want this to be the same.
>

---

From: Ari Keranen <[email-masked]>
Date: Mon, 07 Jul 2008 18:04:54 +0300

Hi,

I've been implementing an ICE library that will be used for HIP NAT 
traversal and I found the NICE draft useful. I think it's good to have a 
document that explicitly tells you which parts of ICE are safe (and 
which not) to ignore if you are using ICE in other than SIP environment.

> 4. connectivity checks
[...]
> What might differ is pacing; 

IMO, this would be a really important part of the NICE document. The 
pacing formulas etc. in the ICE draft seem to be well thought out for 
RTP but I'm not that convinced of the non-RTP case. For example, minimum 
RTO of 500ms seems quite high to me. Some discussion and design 
guidelines or maybe even a few "timer profiles" that implementors could 
reference to could be useful.

Yes.

Yes.

Cheers,
Ari

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 8 Jul 2008 09:56:53 +0300

> reference to could be useful.

As far as I remember, it used to be 100ms, but that was too fast for WAN radio 
links.

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 8 Jul 2008 10:23:13 +0300

> in XMPP is already finished and hence this document will not help them

A rough list of things that may cause simplification:

* Multiple components:
Protocols should avoid using multiple inter-dependent UDP flows, as it adds 
complexity and increases the failure rate. ICE has this because of RTCP 
running on a different port than RTP.

* Multiple medias:
Protocols should avoid using multiple independent UDP flows for the same 
reasons. This is in ICE because SIP must negotiate all media (m= lines) 
together within Offer/Answer. If a protocol really needs multiple media, it 
can try to negotiate them sequentially (-> RTSP?) which also simplifies 
things a lot.

* Role conflict:
This is needed because SIP has no requester/answerer asymmetry, at least when 
3pcc is used. When there is unambiguously a requester and an answerer (e.g. 
RTSP client/server), there is no need for this. Unfortunately, this is a bit 
more difficult to implement a simplification, as it violates the base ICE 
spec.
I suppose that's what Jonathan was referring to by "talk about role selection 
and how that is kind of specific to sip but how to be compatible with it".

And then you need to spell out which parameter need to be encoded.
And when ICE can/should (not) be used.

Coming to some specific protocols that could use ICE:

MIP is a client(MN)-server(HA) protocol. It should not even need to use ICE. 
The HA should sit on a public IP/port tuple, and receive UDP packets from the 
client (that does not preclude doing return routability checks). That's 
several order of magnitude simpler than using ICE, *and* it is just as 
reliable. At least, that's my take on it...

I suppose HIP-ICE already does assume a single media and a single component.

XMPP is very close to SIP in terms of ICE "requirements", since it uses 
RTP/RTCP in a similar way. The only thing that it might be to spare is role 
conflict handling, which is only needed because of 3pcc, I suppose. And even 
that might be a bad idea for the sake SIP-XMPP gateways.

RTSP could spare multiple components if it forces RTCP-mux when RTSP-ICE 
transport is used.

> So, who would make use of this document?

You have a point that there aren't that many protocols at this point. I wonder 
if there is any interest in ICE outside IETF and XSF protocols... Anybody 
heard of any?

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 08 Jul 2008 21:44:22 +0300

Hi Remi,

> A rough list of things that may cause simplification:
This  is exactly the type of things the protocol designer has to figure 
out when they work on their favorite protocol. Another document will not 
take a decision away from thinking about these things.

If these things are not sufficiently well explained then they should be 
fixed in ICE rather than adding another document.

> reliable. At least, that's my take on it...

I am not sure where you got that impression from.

I am not suggesting to use ICE between the MN and the HA. Instead, I am 
suggesting to use it between the MN and the CN.

> I suppose HIP-ICE already does assume a single media and a single component.
We are not fully sure.

> RTSP could spare multiple components if it forces RTCP-mux when RTSP-ICE 
... and they investigate this without having a NICE document.
> if there is any interest in ICE outside IETF and XSF protocols... Anybody 
When you look around then the Internet is not going towards a waist like 
described in draft-rosenberg-internet-waist-hourglass-00 but rather a 
model where the new waist is HTTP

So, do you think that there will be many protocols in the future with 
the characteristics required by ICE?

Ciao
Hannes

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 08 Jul 2008 21:35:47 -0400

Well, it was mostly really TSV AD conservatism ;)

Anyway, it seems like there is general interest in this document in the 
form proposed. I got some private feedback along those lines too. I'll 
submit a revised document and we can evaluate whether to move forward 
with that or not. Unfortunately odds are very high I'll miss the mmusic 
session Friday, but hopefully we can have someone else lead a discussion 
on it.

Thanks,
Jonathan R.

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 9 Jul 2008 16:44:39 +0300

On Tuesday 08 July 2008 21:44:22 ext Hannes Tschofenig, you wrote:
> > MIP is a client(MN)-server(HA) protocol. It should not even need to use
> > ICE. The HA should sit on a public IP/port tuple, and receive UDP packets
> > from the client (that does not preclude doing return routability checks).
> > That's several order of magnitude simpler than using ICE, *and* it is
> > just as reliable. At least, that's my take on it...
>

Then I stand corrected.

> > I suppose HIP-ICE already does assume a single media and a single

Aha? Using a single UDP flow not only simplifies your life as a protocol 
designer. It only simplifies the life of implementors. And then, it decreases 
the risk that the NAT screws things up. I am not an expert on HIP, though.

> ... and they investigate this without having a NICE document.

Indeed.

(...)
> > You have a point that there aren't that many protocols at this point. I
> > wonder if there is any interest in ICE outside IETF and XSF protocols...
> > Anybody heard of any?
>

HTTP is the waist of the Internet as seen by the corporate employee (including 
you and me) or civil servant.

Many real-time applications are using UDP especially games. Some bulk 
peer-to-peer applications do it as well, if only because it goes through NATs 
better than TCP. So there is UDP on the real Internet today, and it's not 
only DNS and RTP from SIP/RTSP/XMPP.