Subject: [MMUSIC] Comments on draft-rosenberg-mmusic-ice-nonsip

From: Philip Matthews <[email-masked]>
Date: Fri, 7 Mar 2008 07:04:45 -0500

Below are some comments on this draft. I have grouped the comments by  
subject matter.

Comments on the subset of ICE chosen:
* I think this draft should allow multiple streams between the two  
clients. I feel this is useful in non-SIP contexts. For example, my  
draft draft-matthews-p2psip-id-loc requires multiple streams for non- 
SIP purposes. I suggest this draft simply point out the  
simplifications that occur if there is only one stream.

Comments on the MIME object:
* I think this draft should not require the MIME object of section  
15, but simply present it as one possible encoding. The draft should  
instead list the parameters that ICE needs as input, and allow  
protocols to use other encodings instead. Protocols may also derive  
some of these ICE-related parameters from other fields in their  
protocol messages, rather than pass them explicitly.
For example, right now the HIP work is proposing to use an encoding  
that is more consistent with HIP. HIP is a binary protocol, so a text- 
based encoding seems a bit out-of-place. Moreover, the HIP work is  
proposing to not generate an ICE-specific username fragment and  
password, but use the Host Identity Tag (HIT) as the username  
fragment, and the keying material derived from the Diffie-Helmman  
exchange as the password. Thus these fields of the MIME object are  
not needed for HIP.

Comments on Terminology:
* I dislike the term "session protocol". In SIP/SDP, it is the direct  
connection which is the "session", not the signaling protocol, so the  
"session protocol" should be the protocol that runs over the direct  
connection. I suggest that you replace the sentence "NICE works only  
with protocols that fit the pattern of a session protocol" with "NICE  
only works with signaling protocols that have a rendezvous mechanism".

* In section 2, the document talks about establishing sessions  
between "hosts". I think it should instead talk about sessions  
between clients or protocol instances or similar.

* The document introduces the terms "Initiate Message/Accept Message"  
and "Initiator/Responder" in place of ICE's "Offer/Answer" and  
"Offerer/Answerer". Though the new terms might be better than the  
existing terms, I think it will just be confusing to have to  
different sets of terms for the same concept. Anyone who implements  
NICE and any protocol designers who use NICE will have to at least  
skim draft-ietf-mmusic-ice and become familiar with the Offer/Answer  
terminology there, so I don't see the point of introducing new  
terminology.

Other Comments:
* The comment about ICE depending on the confidentiality and  
integrity of the offer/answer exchange is an important one and should  
not be buried in the Security Considerations section. Instead, I  
suggest you add this to the section on "Can my protocol use NICE?",  
which should become a normative section (rather than an informative  
section)

- Philip

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

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Fri, 7 Mar 2008 14:36:10 +0200

> simplifications that occur if there is only one stream.

IMHO, if you need multiple streams, you better use plain ICE. If NICE gets 
support for multiple streams and/or components, it will become so much like 
ICE, that I don't think there will be significant added value... ?

On the other hand, multiple streams multiply the chance of traversal failures 
and the setup latency. I would especially expect that an overlay network 
would mux/tunnel over a single network flow between any couple of peers.

> protocol messages, rather than pass them explicitly.

Agreed. This would put an arbitrary limitations on the scope of the protocol.

-- 
Rémi Denis-Courmont

---

From: Philip Matthews <[email-masked]>
Date: Fri, 7 Mar 2008 17:05:10 -0500

> would mux/tunnel over a single network flow between any couple of  

In my view, what the NICE document does is separate out the SIP- 
specific parts of ICE from the rest of ICE, something that we should  
have done from the start. All the other stuff that Jonathan mentions  
in the NICE document is SIP-specific, but I don't see multiple  
streams as being SIP-specific. For example, the ID-LOC application is  
not SIP-specific.

If you read what NICE says about multiple streams, it just says "do  
ICE with just one component".

One other thing. I don't actually expect people to do NICE  
implementations that are distinct from ICE implementations. All the  
document really does is give people guidance on how to use ICE for  
non-SIP applications.

- Philip

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Sun, 9 Mar 2008 13:13:50 +0200

Le Saturday 08 March 2008 00:05:10 ext Philip Matthews, vous avez écrit :
> streams as being SIP-specific.

Every single intricacy from ICE could be made non-SIP specific... This is just 
a matter of definition.

Multiple streams (and worse, multiple components, and worse multiple streams 
AND multiple components) are the biggest implementation annoyance in ICE:

- First, it forces the implementor to run some "global" pacing algorithm for 
the whole ICE session. Normally, multiple streams and multiple components are 
isolated (e.g. separate RTP and RTCP flows sessions), that need not know 
about each other. It also makes timer computation more complicated.

- Second, multiple components and multiple streams increase the amount of ICE 
traffic and setup delay linearly.

- Third, they multiply the chance of traversal failure exponentially.

If you design a NEW protocol, you definitely want to avoid multiple streams 
and/or multiple components. You can still have multiple flows between a pair 
of nodes at a given time, e.g. a "DHT" flow, a phonecall signaling flow and a 
media flow. *But* you should NOT negotiate them in the same ICE session - 
they have independent time span anyway.

SIP needs multiple streams *because* it is Offer/Answer. If it weren't for 
O/A, SIP could do ICE with only one stream per session and one component per 
stream. It could simply serialize the ICE session setups. Unfortunately, O/A 
is too rigid for this.

> For example, the ID-LOC application is not SIP-specific.

> document really does is give people guidance on how to use ICE for

I DO expect people to do both. Those who have SIP will want to use a common 
ICE stack. Those who have something more NAT-friendly, will want to have 
something MUCH simpler (e.g. an RTSP server on a public IP address).

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 09 Mar 2008 09:19:17 -0400

inline:

Philip Matthews wrote:
> In my view, what the NICE document does is separate out the SIP-specific 
> parts of ICE from the rest of ICE, something that we should have done 
> from the start. 

We DID do that from the start. Early versions of ICE were defined as a 
meta-protocol. But it was so hard to understand we punted it.

> All the other stuff that Jonathan mentions in the NICE 
> document is SIP-specific, but I don't see multiple streams as being 
> SIP-specific. For example, the ID-LOC application is not SIP-specific.

I'll respond to this directly from your first note..

> 
> If you read what NICE says about multiple streams, it just says "do ICE 
> with just one component".

Right.

> document really does is give people guidance on how to use ICE for 

Correct. NICE is not meant for SIP, its meant for non-SIP. And thats a 
worry - if we end up making NICE simpler and then people use it with SIP 
instead of ICE, that would be bad. Though I believe it would interop.

-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: Jonathan Rosenberg <[email-masked]>
Date: Sun, 09 Mar 2008 09:26:01 -0400

I think the real meta-question on this draft, is whether:

   a. it is the same functionality as ICE, but not tied to SIP
   b. it is (a) plus a subsetting, removing features that we think only 
SIP needs

The list of things in the (b) bucket that I removed were:

   1. multiple streams
   2. multiple components per stream
   3. updating ICE parameters mid-negotiation
   4. restarting ICE
   5. role conflict detection
   6. ICE mismatches
   7. default candidates
   8. ice-lite
   9. forking support
   10. frozen algorithm
   11. remote candidates mechanism

So first we need to decide path a or b, and then we can discuss which of 
the above get included or not.

few more comments below:

Philip Matthews wrote:
> draft draft-matthews-p2psip-id-loc requires multiple streams for non-SIP 
> purposes. I suggest this draft simply point out the simplifications that 
> occur if there is only one stream.
> 
> 
> * I think this draft should not require the MIME object of section 15, 
> but simply present it as one possible encoding. The draft should instead 
> list the parameters that ICE needs as input, and allow protocols to use 
> other encodings instead. Protocols may also derive some of these 
> ICE-related parameters from other fields in their protocol messages, 
> rather than pass them explicitly.
> For example, right now the HIP work is proposing to use an encoding that 
> is more consistent with HIP. HIP is a binary protocol, so a text-based 
> encoding seems a bit out-of-place. Moreover, the HIP work is proposing 
> to not generate an ICE-specific username fragment and password, but use 
> the Host Identity Tag (HIT) as the username fragment, and the keying 
> material derived from the Diffie-Helmman exchange as the password. Thus 
> these fields of the MIME object are not needed for HIP.

OK. I got a few folks that said they hated this MIME thing. THe 
intention was that it was optional - there if you want it. I think it 
would be a fine idea to have a section that also lists the params you'd 
need to include if you didn't use the MIME object.

> only works with signaling protocols that have a rendezvous mechanism".

OK.

> 
> * In section 2, the document talks about establishing sessions between 
> "hosts". I think it should instead talk about sessions between clients 
> or protocol instances or similar.
> 
> existing terms, I think it will just be confusing to have to different 
> sets of terms for the same concept. Anyone who implements NICE and any 
> protocol designers who use NICE will have to at least skim 
> draft-ietf-mmusic-ice and become familiar with the Offer/Answer 
> terminology there, so I don't see the point of introducing new terminology.

Hmm, well I thought it was confusing to use the same terms when this is 
not based on O/A anymore.

-Jonathan R.

---

From: Philip Matthews <[email-masked]>
Date: Sun, 9 Mar 2008 22:36:38 -0400

On Sun, 9-Mar-08, at 09:26 , Jonathan Rosenberg wrote:

>   b. it is (a) plus a subsetting, removing features that we think  
> only SIP needs
>
>
> So first we need to decide path a or b, and then we can discuss  
> which of the above get included or not.

Right now, I vote for (a) for the following reasons:
* I think we want to encourage just one "ICE" protocol, not an ICE  
and a NICE protocol. This is because I think we will find things we  
want to change/fix with ICE and having two protocols will make things  
harder.
* I think that selecting the list in the (b) bucket will be hard, at  
least until we get more experience.

>
> few more comments below:
>
> Philip Matthews wrote:
>> Below are some comments on this draft. I have grouped the comments  
>> by subject matter.
>> clients. I feel this is useful in non-SIP contexts. For example,  
>> my draft draft-matthews-p2psip-id-loc requires multiple streams  
>> for non-SIP purposes. I suggest this draft simply point out the  
>> 15, but simply present it as one possible encoding. The draft  
>> should instead list the parameters that ICE needs as input, and  
>> allow protocols to use other encodings instead. Protocols may also  
>> derive some of these ICE-related parameters from other fields in  
>> their protocol messages, rather than pass them explicitly.
>> For example, right now the HIP work is proposing to use an  
>> encoding that is more consistent with HIP. HIP is a binary  
>> protocol, so a text-based encoding seems a bit out-of-place.  
>> Moreover, the HIP work is proposing to not generate an ICE- 
>> specific username fragment and password, but use the Host Identity  
>> Tag (HIT) as the username fragment, and the keying material  
>> derived from the Diffie-Helmman exchange as the password. Thus  
> intention was that it was optional - there if you want it. I think  
> it would be a fine idea to have a section that also lists the  
> params you'd need to include if you didn't use the MIME object.

Sounds like we agree.

>
>> Comments on Terminology:
>> * I dislike the term "session protocol". In SIP/SDP, it is the  
>> direct connection which is the "session", not the signaling  
>> protocol, so the "session protocol" should be the protocol that  
>> runs over the direct connection. I suggest that you replace the  
>> sentence "NICE works only with protocols that fit the pattern of a  
>> session protocol" with "NICE only works with signaling protocols  
>> that have a rendezvous mechanism".
>
> OK.
>
>> * The document introduces the terms "Initiate Message/Accept  
>> Message" and "Initiator/Responder" in place of ICE's "Offer/ 
>> Answer" and "Offerer/Answerer". Though the new terms might be  
>> better than the existing terms, I think it will just be confusing  
>> to have to different sets of terms for the same concept. Anyone  
>> who implements NICE and any protocol designers who use NICE will  
>> have to at least skim draft-ietf-mmusic-ice and become familiar  
>> with the Offer/Answer terminology there, so I don't see the point  
>> of introducing new terminology.
>
> Hmm, well I thought it was confusing to use the same terms when  
> this is not based on O/A anymore.

Personally, I have not found it confusing. For the NAT traversal for  
HIP work, I think in terms of an "ICE Offer" and an "ICE Answer" and  
of two endpoints (the Offerer and Answerer) even though it has  
nothing to do with SDP.

---

From: Philip Matthews <[email-masked]>
Date: Sun, 9 Mar 2008 22:41:59 -0400

On Sun, 9-Mar-08, at 09:19 , Jonathan Rosenberg wrote:

>> specific parts of ICE from the rest of ICE, something that we  
>> should have done from the start.
>
> We DID do that from the start. Early versions of ICE were defined  
> as a meta-protocol. But it was so hard to understand we punted it.

My apologies. I do remember that. And I remember finding the MIME  
schema totally incomprehensible...

>
>
>> All the other stuff that Jonathan mentions in the NICE document is  
>> SIP-specific, but I don't see multiple streams as being SIP- 
>> specific. For example, the ID-LOC application is not SIP-specific.
>
>> If you read what NICE says about multiple streams, it just says  
>> "do ICE with just one component".
>
> Right.
>
>> implementations that are distinct from ICE implementations. All  
>> the document really does is give people guidance on how to use ICE  
>> for non-SIP applications.
>
> Correct. NICE is not meant for SIP, its meant for non-SIP. And  
> thats a worry - if we end up making NICE simpler and then people  
> use it with SIP instead of ICE, that would be bad. Though I believe  
> it would interop.

Personally, I think we want just one set of implementations that can  
be used with both SIP and other protocols. I think that SIP will be  
the application that will drive the initial ICE deployment and help  
find all the bugs. The other protocols can then ride SIP's coat-tails  
and use well-tested ICE implementations.