Subject: [MMUSIC] Concerned about role conflict resolution procedure in ICE-15

From: Philip Matthews <[email-masked]>
Date: Wed, 18 Apr 2007 10:50:19 -0400

Jonathan:

I am concerned about the conflict resolution procedure for
Controlling-End/Controlled-End that has been added in ICE-15.
I haven't seen the 3PCC cases where this problem supposedly exists,
and under my assumptions for when one can use ICE, I don't see how
the problem can arise. In my mind, the document is very clear that one
agent is the initial offerer and the other agent is the initial  
answerer, and
with those assumptions, the conflict resolution procedure is not needed.

All this means that I cannot evaluate whether the proposed mechanism
actually works or is even needed.

I think the document:
1) Needs to be explicit about the assumptions on when ICE can be used
     wrt. the offer/answer procedure.
2) Needs to give a reference to examples when the conflict resolution
     is needed.

If you or anyone else could give me details on a specific use case where
this problem arises, that would be very helpful.

- Philip

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 26 Apr 2007 09:25:42 -0400

Here is a 3pcc use case where both sides are controller:

           A         Controller          B
           |(1) INV()     |              |
           |<-------------|              |
           |(2) 200(SDP1) |              |
           |------------->|              |
           |              |(3) INV()     |
           |              |------------->|
           |              |(4) 200(SDP2) |
           |              |<-------------|
           |(5) ACK(SDP2')|              |
           |<-------------|              |
           |              |(6) ACK(SDP1')|
           |              |------------->|

INV() means an INVITE with no SDP.

This is actually a variant on 3pcc flow III, but with fewer messages. 
Its not one of the currently documented flows in RFC 3725 but it is in 
use. There are many further variations on this flow as well.

In this model, both A and B will believe they are controlling.

Interestingly, the cases I had thought of for both sides thinking they 
were controlled, doesn't work at all. So at the moment, the only real 
cases I have are for both sides being controlling.

Thats good, since it means the proposal in another note I am about to 
post will work.

Per your comment, I'd suggest that we add an appendix section on 'Why is 
the conflict resoltuion needed?' which describes this use case, and 
describes limitations. I don't want to beef up the main body text with 
what is just explanatory material.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 26 Apr 2007 16:25:34 +0100

Jonathan,

This use case breaks as soon as you include in the SDP offer anything
that is asymmetrical in nature, such as capability negotiation or MIKEY.
You would receive in an answer something you expect only in an offer. Do
we really want to spend effort trying to fix such broken
implementations?

John 

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: 26 April 2007 14:26
> To: Philip Matthews
> Cc: [email-masked]
> Subject: [MMUSIC] Re: Concerned about role conflict 
> resolution procedure inICE-15
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 26 Apr 2007 13:27:08 -0400

Nothing is black and white here. Is it worth a lot of effort? No. Fixing 
this however is relatively easy, and already done in -15. We have, all 
along, been making ongoing and concious decisions to make changes to ICE 
to make it as broadly deployable as possible. Real, pragmatic issues - 
SBCs that munge things, gateways that don't want to implement too much, 
detection of ALG. This has also included supporting as many 3pcc flows 
as possible, though many of them (and arguably all) are 'ugly'. This, to 
me, is another 3pcc flow to support, and being one that has seen some 
usage, I'd like to make ICE attractive there too.

-Jonathan R.

Elwell, John wrote:

>>>the problem can arise. In my mind, the document is very 
>>
>>clear that one
>>
>>>with those assumptions, the conflict resolution procedure 
>>
>>is not needed.
>>
>>>1) Needs to be explicit about the assumptions on when ICE 
>>
>>can be used
>>
>>>2) Needs to give a reference to examples when the conflict 
>>
>>resolution
>>
>>>    is needed.
>>>
>>>If you or anyone else could give me details on a specific 
>>
>>use case where
>>

---

From: Philip Matthews <[email-masked]>
Date: Thu, 26 Apr 2007 14:06:33 -0400

A comment here.

Back at the Montreal meeting in summer 2006, there was a discussion  
on which network topologies we wanted to support. As some may recall,  
I had some example topologies that broke ICE-09, and wanted to extend  
ICE to handle them. We decided at that meeting that we would not  
support EVERY possible topology, but only ones that seemed more  
popular/reasonable. (I still claim that my topologies were not  
unreasonable, but I lost that argument). In fact, ICE-15 will support  
some of those topologies, but the controlling end has to do some  
stuff not described in the specification.

I am wondering if we are getting to the same point with call flows?  
It seems that this call flow violates some basic assumptions about  
how the offer/'answer works. ICE assumes that one agent sends an  
offer and the other sends an answer. From what I understand about the  
call flow below (correct me if I am wrong),  both ends send offers,  
and this is the problem.

Personally, I think we should restrict ICE to offer/answer scenarios  
unless others think that offer/offer scenarios are important to  
support (in which case we need to carefully rethink things).

- Philip

On 26-Apr-07, at 13:27 , Jonathan Rosenberg wrote:

> Nothing is black and white here. Is it worth a lot of effort? No.  
> Fixing this however is relatively easy, and already done in -15. We  
> have, all along, been making ongoing and concious decisions to make  
> changes to ICE to make it as broadly deployable as possible. Real,  
> pragmatic issues - SBCs that munge things, gateways that don't want  
> to implement too much, detection of ALG. This has also included  
> supporting as many 3pcc flows as possible, though many of them (and  
> arguably all) are 'ugly'. This, to me, is another 3pcc flow to  
> support, and being one that has seen some usage, I'd like to make  
> ICE attractive there too.
>
> -Jonathan R.
>
> Elwell, John wrote:
>
>> Jonathan,
>>> From: Jonathan Rosenberg [mailto:[email-masked]] Sent: 26  
>>> April 2007 14:26
>>> To: Philip Matthews
>>> Cc: [email-masked]
>>> Subject: [MMUSIC] Re: Concerned about role conflict resolution  
>>> procedure inICE-15
>>>
>>> This is actually a variant on 3pcc flow III, but with fewer  
>>> messages. Its not one of the currently documented flows in RFC  
>>> 3725 but it is in use. There are many further variations on this  
>>> flow as well.
>>>
>>> Interestingly, the cases I had thought of for both sides thinking  
>>> they were controlled, doesn't work at all. So at the moment, the  
>>> only real cases I have are for both sides being controlling.
>>>
>>> Thats good, since it means the proposal in another note I am  
>>> about to post will work.
>>>
>>> Per your comment, I'd suggest that we add an appendix section on  
>>> 'Why is the conflict resoltuion needed?' which describes this use  
>>> case, and describes limitations. I don't want to beef up the main  
>>> body text with what is just explanatory material.
>>>
>>> Thanks,
>>> Jonathan R.
>>>
>>>
>>> Philip Matthews wrote:
>>>
>>>
>>>> Jonathan:
>>>>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 26 Apr 2007 15:47:15 -0400

inline.

Philip Matthews wrote:

> A comment here.
> 
> Back at the Montreal meeting in summer 2006, there was a discussion  on 
> which network topologies we wanted to support. As some may recall,  I 
> had some example topologies that broke ICE-09, and wanted to extend  ICE 
> to handle them. We decided at that meeting that we would not  support 
> EVERY possible topology, but only ones that seemed more  
> some of those topologies, but the controlling end has to do some  stuff 
> not described in the specification.

That was a case for a lot of extra work to cover them. This is really no 
extra work.

> 
> I am wondering if we are getting to the same point with call flows?  It 
> seems that this call flow violates some basic assumptions about  how the 
> offer/'answer works. ICE assumes that one agent sends an  offer and the 
> other sends an answer. From what I understand about the  call flow below 
> (correct me if I am wrong),  both ends send offers,  and this is the 
> problem.

Actually careful here; this does in fact happen in some of the 
legitimate call flows in RFC 3725 also (flow III, which ICE supports). 
It just so happens that ICE doesn't kick in until the subsequent 
re-invite in that flow. However it is common practice to do this kind of 
thing and then fixup the offer to make it a matching answer. That is the 
meaning of the prime (offer2') in the call flows in flow III.

I'd also note that, as I said, I'm aware of deployments with this flow, 
so its not a corner case.

What I don't understand is, why are we reopening this. We more or less 
concluded on this at the last meeting. We agreed on an approach. I put 
it in. There was a concern that this might make a simpler ANAT solution 
impossible, but it turns out not to be the case. I don't understand why 
we need to overturn this. I'm really eager to keep churn to the spec to 
a minimum.

-JOnathan R.

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 27 Apr 2007 08:04:36 +0100

Jonathan,

Whilst I don't think this is a case we really NEED to solve, I can live
with the simple solution as already documented in ICE-15.

John 

> Sent: 26 April 2007 20:47
> To: Philip Matthews
> Cc: Elwell, John; IETF MMUSIC WG
> Subject: Re: [MMUSIC] Re: Concerned about role conflict