Subject: RE: [MMUSIC] Remaining ICE open issues

From: "Kevin Johns" <[email-masked]>
Date: Tue, 17 Oct 2006 11:05:11 -0600

Jonathan,

I will not be able to participate in todays call. I looked over your
open issues and have provided my thoughts below.

Kevin 

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Monday, October 16, 2006 12:57 PM
To: IETF MMUSIC WG
Subject: [MMUSIC] Remaining ICE open issues

On the last ICE call, I indicated that I thought we were mostly done,
but that I'd check for straggler open issues. Here is my list of whats
closed and whats left, which we'll discuss on the call tomorrow. Please
let me know if you see something that is an issue in your mind and not
on either list:

Open
----

MacDonald-1: Determination of controlling endpoint: through O/A
negotiation or heuristic?
Status: actively debating
<kcj> no strong opinion at this point. Simple is better at this point.

MacDonald-2: where should we put text for ICE-for-gateways, and should
we hold up ICE for it?
Status: actively debating
<kcj> I think this is a great idea. If we can architect ICE such that
documenting ICE-for-Gateways in a separate RFC then I am ok with this.
However, given this is often difficult to do, I am not keen on ICE
implementators needed to read two RFCs and having separate procedures to
implement.

Issue #5: Removing a peer derived candidate. There is currently no way
to do it.
Status: I suggested no one asked for this feature anyway, may as well
leave it as is. No responses posted.
<kcj> no opinion

Issue #8: The need for connectivity preconditions when you are running
ICE is far from clear.
Status: I put some text in -11 around this; saying they are only needed
if you want the explicit signaling they provide. Need some feedback on
whether this text is OK.
<kcj> have not had time to review -11

Issue #9 (never posted AFAICT - just in the slides). Question is that
3pcc Flow III doesnt work with ICE-10.
Status: Whether it will work depends on the algorithm for selecting the
controlling entity. This has to be something that survives reordering of
m/c lines, which can happen in flow III.
<kcj> Given that flow IV can accomplish pretty much the same thing as
flow III, I don't have any issues with this.

Issue #10: ICE hammer. STUN checks themselves can cause lots of traffic
on the network, and can be used to launch an attack. What to do about
it?
Status: I posted some ideas on the list, no response.
<kcj> have to go find this posting. Must have missed it.

Issue #11: ICE pacing. Should we allow ICE checks to go faster if codecs
are at a faster rate?
Status: There was some discussion of this on the calls, no real
conclusion. We did agreed to make the Ta interval configurable and that
some research would ideally be needed to find a good value. But thats
about it.
<kcj> There might be some policy implications with the pacing. Case in
point is IMS and GPRS access networks. In this architecture from what I
can tell, there has to be a flow in place to even do connectivity
checks. It is unclear is a default flow can be used for such
capabilities. Further, they have expressed concern with ICE since the
STUN Relay accepts allocation requests on the same IP and port as the
actually media for relaying. This forces them to open a default rule to
allow for the allocation, but that then opens up to free media. One way
to address this is to install a default rule that has such policy
restrictions the media would not flow well. If we pace things to
quickly, then the rule may start to get in the way...

Issue #12: (never posted, in slides only). Question is whether to adjust
the retransmit interval for STUN when used with ICE. Argument is that
ICE transactions will often completely timeout
Status: My suggestion in the slides and in the related discussion on
behave was to leave it alone
<kcj> no opinion

Issue #15: Obfuscation of candidate lines to protect from generic ALG
Status: I propoed we not do this. There was agreement on the list from
Francois and Christer. But it has come up on the calls.
<kcj> I agree, we should not do this.

Holmberg-1: Christer proposed a way to return a STUN Server in a
REGISTER response. The idea is to find one in a local network.
Status: I proposed it be out of scope for ICE. Some back-and-forth with
Christer, not clear where we are. I still think its out of scope.
<kcj> I agree this is out of scope.

Holmberg-2: Christer raised an issue about handling of new media streams
in a re-offer. You basically need to start a fresh.
Status: I agree; with the ICE-states below, the idea is that there would
be a set of logic that applies in the 'running' state, anda  stream
enters the running state when its new. My plan is to make changes in
ice-12 to accomodate this. But would be good to make sure we're aligned
on the approach.
<kcj> Sounds reasonable.

Holmberg-3: ICE checks for inactive lines? b=0 lines?
Status: we agree ice checks are done if a line is a=inactive. Christer
asks about b=0. Not clear.

Holmberg-6: Reliable provisionals
Status: Christer argues that the stuff in ICE about resending the 18x
until a stun request arrives is a hack, we should be requiring reliable
provisionals. No conclusion in discussions.
<kcj> I kind of agree with Christer especially since the first set of
STUN checks are going to fail given the race condition of setting up the
NAT bindings at the remote end. Seems you are guaranteed to always have
to re-send the 18x...

Closed
-------

Issue #1: Unified or separate checks across media streams
Conclusion: ICE-11 has separate checks, though still coupled via the
Frozen algorithm

Issue #2: 32 bit space limit for priorities
Conclusion: New formula in ICE-11 provides more than enough space

Issue #3: limits on number of media streams
Conclusion: Resolve in ICE-11 by having separate check lists for each
stream. Now there are no limits on the number of media streams

Issue #4: when is ICE done?
Conclusion: this is NOT in iCE-11 yet. We have agreed to signal
conclusion via the stun checks, and to have the stun checks indicate
which pairs are selected. ICE is done when the done flag has been set
for each component of each media stream by the controlling entity.

Issue #6: what to do if keepalives fail?
Conclusion: a few comments agreed wiFrom [email-masked] Tue Oct 17 13:16:43 2006
Content-class: urn:content-classes:message
Subject: RE: [MMUSIC] Remaining ICE open issues
Date: Tue, 17 Oct 2006 11:05:11 -0600
From: "Kevin Johns" <[email-masked]>
To: "Jonathan Rosenberg" <[email-masked]>,
	"IETF MMUSIC WG" <[email-masked]>
Cc: 

Jonathan,

I will not be able to participate in todays call. I looked over your
open issues and have provided my thoughts below.

Kevin 

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Monday, October 16, 2006 12:57 PM
To: IETF MMUSIC WG
Subject: [MMUSIC] Remaining ICE open issues

On the last ICE call, I indicated that I thought we were mostly done,
but that I'd check for straggler open issues. Here is my list of whats
closed and whats left, which we'll discuss on the call tomorrow. Please
let me know if you see something that is an issue in your mind and not
on either list:

Open
----

MacDonald-1: Determination of controlling endpoint: through O/A
negotiation or heuristic?
Status: actively debating
<kcj> no strong opinion at this point. Simple is better at this point.

MacDonald-2: where should we put text for ICE-for-gateways, and should
we hold up ICE for it?
Status: actively debating
<kcj> I think this is a great idea. If we can architect ICE such that
documenting ICE-for-Gateways in a separate RFC then I am ok with this.
However, given this is often difficult to do, I am not keen on ICE
implementators needed to read two RFCs and having separate procedures to
implement.

Issue #5: Removing a peer derived candidate. There is currently no way
to do it.
Status: I suggested no one asked for this feature anyway, may as well
leave it as is. No responses posted.
<kcj> no opinion

Issue #8: The need for connectivity preconditions when you are running
ICE is far from clear.
Status: I put some text in -11 around this; saying they are only needed
if you want the explicit signaling they provide. Need some feedback on
whether this text is OK.
<kcj> have not had time to review -11

Issue #9 (never posted AFAICT - just in the slides). Question is that
3pcc Flow III doesnt work with ICE-10.
Status: Whether it will work depends on the algorithm for selecting the
controlling entity. This has to be something that survives reordering of
m/c lines, which can happen in flow III.
<kcj> Given that flow IV can accomplish pretty much the same thing th my suggestion to do nothing, that
this was otuside the scope of ICE to solve

Issue #7: forking and receipt of media
Conclusion: ICE had this statement that you don't play media you receive
unless you had received a check. This completely fails with forking. So,
the functionality was removed from -11

Issue #13: when to send media?
Conclusion: We agreed (though this is not in ICE-11) that media could be
sent once done-ness is signaled via ICE, and could flow in both
directions. I will have that in ICE-12

Issue #14: ICE states? DO we need them?
Conclusion: Not in ICE-11, but we agreed I think that this made sense. I
was going to add the three states per media stream. The need for this
goes along with the resolution to #13.

Holmberg-4; Option tag?
Status: agreed to add an option tag. This will go into ice-12

Holmberg-5: port of zero? IP address of 0.0.0.0?
Status: we agreed that no checks are sent for port of zero. We agree
that checks are not sent for IP address of 0.0.0.0, and text needs to be
added to say that ICE endpoints cannot use that to implement call hold
when talking to another endpoint. That will go into ice-12

Matthews-1: spec mentions several times decisions made on whether you
are the offerer or answerer. What if an O/A is in progress while the
decision ahs to be made and this causes role reversal? Its a race
condition.
Status: agreed that, if needed, the role would be based on the initial
role of offerer vs. answerer

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

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

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

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 18 Oct 2006 17:38:53 -0700

> until a stun request arrives is a hack, we should be 
> requiring reliable provisionals. No conclusion in discussions.

NATs are hacks, too.  While two hacks don't make a beautiful architecture,
ICE's hack can also be viewed as a different means to the same end --
reliable 18x's when it matters.

> <kcj> I kind of agree with Christer especially since the first 
> set of STUN checks are going to fail given the race condition of 
> setting up the NAT bindings at the remote end.  Seems you are 
> guaranteed to always have to re-send the 18x...

I don't follow your argument that there's a race condition that will force
18x to be retransmitted.  Could you explain that?

-d

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 19 Oct 2006 22:02:17 +0200

Hi, 

>>Status: Christer argues that the stuff in ICE about 
>>resending the 18x until a stun request arrives is a hack, we should be
requiring 
>>reliable provisionals. No conclusion in discussions.
> 
>NATs are hacks, too.  While two hacks don't make a beautiful 
>architecture, ICE's hack can also be viewed as a different 
>means to the same end -- reliable 18x's when it matters.

So, just because we're dealing with something you regard being a hack,
it justifies for us to also start doing hacks? 

I don't think that is the right direction to take...

Regards,

Christer

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 19 Oct 2006 13:13:21 -0700

> >>resending the 18x until a stun request arrives is a hack, 
> >>we should be requiring reliable provisionals. No conclusion 
> >>in discussions.
> > 

I said ICE's hack can also be viewed as a different means
to the same end (reliable 18x responses).  That is how I
view it.  Sending additional SIP signaling is about as
significant a 'hack', but all in the SIP signaling plane.

As you no doubt recall, there has been significant objection
in the past for ICE to require reliable provisional responses.

I doubt that has changed.

-d

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 19 Oct 2006 22:27:32 +0200

Hi, 

>>>>Status: Christer argues that the stuff in ICE about resending the 
>>>>18x until a stun request arrives is a hack, we should be 
>>So, just because we're dealing with something you regard 
>>being a hack, it justifies for us to also start doing hacks?
>> 
>I said ICE's hack can also be viewed as a different means to 
>the same end (reliable 18x responses).  That is how I view 
>it.  Sending additional SIP signaling is about as significant 
>a 'hack', but all in the SIP signaling plane.
> 

Has this been discussed in SIP/SIPPING (yes, I know many of the people
there are also following the MMUSIC work)?

And, as I asked before, for how long would you keep re-transmitting the
18x, if there is no STUN request coming to "acknowledge" it (you cannot
assume there will be a STUN request, e.g. in case there is some
NAT/gate/GW in the path which will not pass it)? I don't think we can
use words as "send a few re-transmits", or "re-transmit for a while", in
a standards specification.

Regards,

Christer

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 24 Oct 2006 09:31:31 -0400

inline.

> a standards specification.

It doesn't say that. It says to use the retransmit intervals and timers 
as defined in RFC 3262, but that the retransmissions stop when you 
receive a STUN request or a PRACK (as opposed to just a PRACK with rfc3262).

-Jonathan R.

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Mon, 30 Oct 2006 21:34:31 +0100

Hi, 

>>And, as I asked before, for how long would you keep re-transmitting 
>>the 18x, if there is no STUN request coming to 
>>"acknowledge" it (you cannot assume there will be a STUN request, e.g.
in case 
>>there is some NAT/gate/GW in the path which will not pass it)? I don't

>>think we can use words as "send a few re-transmits", or "re-transmit
for 
>>a while", in a standards specification.
> 
>It doesn't say that. It says to use the retransmit intervals 
>and timers as defined in RFC 3262, but that the 
>retransmissions stop when you receive a STUN request or a 
>PRACK (as opposed to just a PRACK with rfc3262).

I think that also the following 3262 deviations should be clarified
(eventhough one may consider them obvious), in addition to the text
saying that this 18x can not be used for offer/answer purpose:

1. If the UAC supports 100rel, the UAS MUST use it, and not use the STUN
request as acknowledgement. Ie the re-transmisson will not cease if a
STUN request is received before the PRACK.

2. If 100rel is not used, and there is no STUN request before the
re-transmission timeout (64*T1), the UAS shall not reject the INVITE
just because the 18x "failed".

3. The RFC3262 rule, saying that the first reliable 18x must be
acknowledged before futher reliable 18xs are sent, does not apply.

4. When 200 OK is sent, the re-transmission of 18x (if still ongoing) is
ceased.

Regards,

Christer

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 31 Oct 2006 13:03:08 -0500

I'm OK with #2-#4 but I dont see the point of #1. Why?

-Jonathan R.

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Tue, 31 Oct 2006 20:29:55 +0100

Hi, 

>I'm OK with #2-#4 but I dont see the point of #1. Why?

I was maybe a little unclear. What I meant was that if both the UAC AND
the UAS support 100rel, they should use it, because if reliable
transport of 18x is needed I think that the standardized 100rel
mechanism should be used. 

I think that the STUN-acknowledgement mechanism should only be used if
100rel is not supported. Isn't that the reason the STUN-acknowledgement
was defined in the first place - to allow UASs that do not support
100rel to still use ICE?

Regards,

Christer

> "acknowledge" it (you 
> >>>cannot assume there will be a STUN request, e.g.
> > 
> > in case
> > 
> >>It doesn't say that. It says to use the retransmit intervals and 
> >>timers as defined in RFC 3262, but that the retransmissions 
> stop when 
> >>you receive a STUN request or a PRACK (as opposed to just a 
> PRACK with 
> >>rfc3262).
> > 
> > 
> > 1. If the UAC supports 100rel, the UAS MUST use it, and not use the 
> > STUN request as acknowledgement. Ie the re-transmisson will 
> not cease 
> > if a STUN request is received before the PRACK.
> > 
> > 4. When 200 OK is sent, the re-transmission of 18x (if 
> still ongoing) 
> > is ceased.
> > 
> > Regards,
> > 
> > Christer
> > 
> 
> --