Subject: [MMUSIC] ICE-14 is here

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 06 Mar 2007 23:09:50 -0500

Until it appears in the archives:
http://www.jdrosen.net/papers/draft-ietf-mmusic-ice-14.txt

This draft has had COUNTLESS edits made for the purposes of increased 
clarity and readability, too substantial to enumerate. The biggest one 
is increased use of sub-sections and bullets to break up text, per ekrs 
suggestions.

Technically, ice-14 is nearly identical to ice-13. Changes are all 
minor. These are sufficiently small that ice-13 and ice-14 are 
compatible, and that is a sign to me that this is done.

The specific technical changes are:

* spec was inconsistent on when you needed to include candidates -
   indicated in one place it is included in the media stream doesn't
   have a=inactive. In another place, its if the port is nonzero. It
   should be non-zero port. THis was fixed to be consistent.

* added a note in the SDP encoding section that you should include the
   most important media stream first since ICE checks will complete for
   it first

* added a note saying, if you learn your STUN server from DNS or
   something similar, use the same server IP/port for the entire
   session. Helps make sure the foundations are the same for all
   candidates from the same interfaces.

* additional error case: if your turn allocate request fails when
   gathering candidates, do a binding request so at least you get your
   server reflexive

* changed usage of a=inactive/sendonly for hold (vs 0.0.0.0) from
   SHOULD to MUST

* no longer require subsequent offers to include peer reflexive
   candidates that were learned; this used to be needed but isn't (and
   hasnt' actually been needed for a few iterations of ICE). Making
   inclusion MAY is better since otherwise ICE will slow down a bit.

* when an updated offer is sent in the COmpleted state for a media
   stream, MUST NOT include candidate attributes for non-selected
   pairs. USed to be SHOULD NOT, and there is no reason to EVER do
   this, and its likely to be confusing, so I made MUST NOT

* fixed a really obscure corner case bug; basically once a request
   arrives with the USE_CANDIDATE, you can cease retransmits for other
   checks, but ONLY those that are lower priority. Spec didn't have
   that ONLY case, introducing a possible race condition

* the aggressive nomination algorithm (previously called proactive
   selection) can produce transient selected pairs for media, and
   several updated offers. Spec is now recommending waiting one second
   before sending an updated offer, to avoid transient offers.

* fixed a bug in the handling of the remote-candidates attribute. This
   bug got introduced when we added the idea of ice
   mismatches. Previously, if you got an offer with a=remote-candiates,
   you used those values in the m and c lines, and then included all of
   your current candidates in a=candidate attributes. It was possible
   that the a=remote-candidates (and conseuqently, m and c-line values)
   didn't match any existing candidate yet, since a check that will
   produce them is in progress. This used to be OK, but then we made it
   so that you had to have a candidate matching the m/c-line. The fix
   for this is somewhat painful, I'm afraid. YOu need to hold the offer
   until the checks complete, and then send the answer.

* added some text hinting at how RTP/RTCP mux would work, so that it
   is clear that the mechanism in draft-ietf-avt-rtp-and-rtcp-mux works
   with ICE. Not referencing that draft however, or copying any of its
   normative text or mechanism

* documented how ICE and ANAT work together, and how you could use ICE
   for v4/v6 selection without ANAT. DOesnt make a recommendation on
   whether you should or shouldn't use ANAT, just provides the
   considerations for the choice.

There are no open issues I'm aware of. There are no outstanding changes 
required that I am aware of. I believe this document is ready for WGLC now.

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

---

From: Dafydd Harries <[email-masked]>
Date: Thu, 8 Mar 2007 19:40:44 +0000

> http://www.jdrosen.net/papers/draft-ietf-mmusic-ice-14.txt

§2.6 says:

   Consequently, ICE assigns one of the agents in the role of the
   CONTROLLING AGENT, and the other of the CONTROLLED AGENT.  The
   controlled agent gets to nominate which candidate pairs will get used
   for media amongst the ones that are valid.  It can do this in one of
   two ways - using REGULAR NOMINATION or AGGRESSIVE NOMINATION.

Surely this should be "The controlling agent gets to nominate...".

-- 
Dafydd

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 8 Mar 2007 22:31:01 -0500

Some comments on ICE-14.

4.3/16 (Example SDP):
The examples all include candidates with "typ local", whereas the BNF
and the description of <cand-type> say that this should be "typ host".

The examples also all use numeric foundations, whereas the grammar
allows 1*ice-char.  To avoid implementor confusion, it might be better
to use an alphanumeric token for the foundation in the examples instead.

5.7.3:
The algorithm for check list pruning says "construct pairs for each of
your reflexive candidates, replace the local candidate in each of them
with its base, and then remove the duplicate pairs."  Is the outcome
of this process actually different from the simpler algorithm "don't
construct pairs based on local reflexive candidates"?  (Unless maybe
a reflexive candidate has a higher priority than its base host
candidate?)

5.7.4/5.8:
The check list "Completed" state seems poorly named; as far as I can
tell, entering it doesn't actually mean that all the list's checks
have completed, only that all its checks have been started.

7.1.2.2:
The discussion says "If the STUN transaction generated a response
between 200 and 299".  STUN success responses don't have numeric
codes; only error responses do, since the numeric codes are part of
the ERROR-CODE attribute.  I assume this should be "If the STUN
transaction generated a success response" instead.

7.2.1.3:
In the case when a triggered check is generated before the SDP answer
is received, does this count as "the pair is not already on the check
list", so you generate a new check based on the received priority?  Or
do you wait until you've received the SDP answer (and thus constructed
the check lists) before deciding whether this is a new or existing
check?  (The latter makes more sense to me, but a strict reading of
the section implies the former.)

Also, when the SDP answer is received, do all the pending triggered
checks start simultaneously, or do you space them out based on Ta?

10:
The spec says to use STUN Binding Indications for STUN-based
keepalives, and the STUN spec ([12]) is cited as a reference.
However, STUN does not actually specify any semantics for Binding
Indications, only for Binding Requests and Binding Responses.
(Should a Binding Indication include an XOR-MAPPED-ADDRESS attribute?)

-- 
Jonathan Lennox
[email-masked]

---

From: Jonathan Lennox <[email-masked]>
Date: Sun, 18 Mar 2007 15:14:34 -0400

Two more comments on ICE-14.

1.  Section 7.2.1.3 says that when it receives a request for a check in the
In-Progress state, an endpoint SHOULD perform an immediate retransmit of the
check's STUN binding request.

My question is, how does this affect the regular STUN retransmission
mechanism?  Is it just an extra packet, invisible to regular STUN
retransmission, or does it count towards the maximum 7 retransmissions of a
STUN request?  When should you schedule the next retransmission of the STUN
request, after this immediate retransmission? 

2.  It's not clear to me that the unfreezing algorithm works correctly if
media streams have disjoint (or even non-identical) sets of candidate
foundations.  For example, consider audio and video being processed at
different devices with distinct IP addresses:

   m=audio 45664 RTP/AVP 0
   c=IN IP4 192.0.2.3
   a=rtpmap:0 PCMU/8000
   a=candidate:H1 1 UDP 2130706178 10.0.1.1 8998 typ host
   a=candidate:SR1 1 UDP 1694498562 192.0.2.3 45664 typ srflx raddr 10.0.1.1 rport 8998
   m=video 55664 RTP/AVP 96
   c=IN IP4 192.0.3.3
   a=rtpmap:96 H264/90000
   a=candidate:H2 1 UDP 2130706178 10.0.2.1 9998 typ host
   a=candidate:SR2 1 UDP 1694498562 192.0.3.3 55664 typ srflx raddr 10.0.2.1 rport 9998

I don't see how the check lists for the second media stream ever unfreeze.
Initially, of course, only the first media stream is active; as its checks
complete, ICE only tries to unfreeze checks with foundations matching <H1, 
-remote-> or <SR1, -remote->.  The second media stream's check list never
enters the active state for either end of the ICE exchange.

Have I overlooked something?  Or does this need to be resolved in ICE?

My suggestion as to how to solve this is to say that the "first" (lowest
stream/lowest component) instance of every foundation starts out in the
Waiting state, even if this isn't actually stream 1 component 1.  However,
this means that more than one stream's check list can start out active, and
I'm not sure what the implications of this would be.

-- 
Jonathan Lennox
[email-masked]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 19 Mar 2007 09:25:39 -0400

> and the description of <cand-type> say that this should be "typ host".

fixed.

> to use an alphanumeric token for the foundation in the examples instead.

Well, the spec actually recommends a basic sequence number. So the 
format is consistent with the recommendation.

> a reflexive candidate has a higher priority than its base host

Yes, its different. I had it the way you described briefly as I was 
working on the ICE redesign for -10. It didn't work for the reason as 
you point out: priority order is wrong.

Actually, this is a bug in the other direction.

Completed really does mean that I've had a check succeeded and so ICE is 
'done'. If I run out of periodic checks in teh check list, you shouldn't 
set the state to Completed; ICE will basically time out at some point. 
So instead once all checks timeout you would move it to Failed, which 
would be a new state. If checks for a media stream failed the 
controlling agent would remove to stream or terminate the session if all 
fail. I'll add that.

> transaction generated a success response" instead.

fixed.

> is received,

You can't do that. You have to wait for the answer.

> does this count as "the pair is not already on the check

Latter. I've clarified.

> checks start simultaneously, or do you space them out based on Ta?

All at the same time. I noted that.

> (Should a Binding Indication include an XOR-MAPPED-ADDRESS attribute?)

Yeah. This is because I basically did not get to properly update 
rfc3489bis for this meeting.

-Jonathan R.

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 19 Mar 2007 10:33:56 -0400

> format is consistent with the recommendation.

Where is this recommended?  I searched through ICE-14 looking at all
mentions of "foundation" and "sequence", and I didn't find it.

> you point out: priority order is wrong.

So I guess it's equivalent to "don't construct pairs based on local
reflexive candidates, and for pairs based on local host candidates use the
highest priority associated of any candidates using it a base for the local
candidate priority."  But that's not particularly simpler than the
"construct/replace/prune" algorithm, so the current text is fine.

> controlling agent would remove to stream or terminate the session if all 

Okay.

At what point does the stream stop counting towards the N in Ta/N, though?
Only when it reaches Completed/Failed, or does it also stop counting towards
N when it exhausts its Waiting/Frozen checks?  (Once a stream has no more
Waiting/Frozen checks, its Ta timer doesn't do anything, clearly.)

-- 
Jonathan Lennox
[email-masked]

---

From: "Brian Stucker" <[email-masked]>
Date: Tue, 20 Mar 2007 23:58:45 -0500

Jonathan,

Reading through the spec. Found this around page 26:

---

If the agent is utilizing RTCP, it MUST encode
   the RTCP candidate using the a=rtcp attribute as defined in RFC 3605
   [2].  If RTCP is not in use, the agent MUST signal that using b=RS:0
   and b=RR:0 as defined in RFC 3556 [5].

   The transport addresses that will be the default destination for
   media when communicating with non-ICE peers MUST also be present as
   candidates in one or more a=candidate lines.

   ICE provides for extensibility by allowing an offer or answer to
   contain a series of tokens which identify the ICE extensions used by
   that agent.  If an agent supports an ICE extension, it MUST include
   the token defined for that extension in the ice-options attribute.

   The following is an example SDP message that includes ICE attributes
   (lines folded for readability):

       v=0
       o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1
       s=
       c=IN IP4 192.0.2.3
       t=0 0
       a=ice-pwd:asd88fgpdd777uzjYhagZg
       a=ice-ufrag:8hhY
       m=audio 45664 RTP/AVP 0
       a=rtpmap:0 PCMU/8000
       a=candidate:1 1 UDP 2130706178 10.0.1.1 8998 typ local
       a=candidate:2 1 UDP 1694498562 192.0.2.3 45664 typ srflx raddr
   10.0.1.1 rport 8998

---

Bug is that the example SDP uses neither RFC-3605, nor RFC-3556, which
if I understand the preceeding paragraphs is required and at the moment,
somewhat ironic.

:)

Regards,
Brian

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 22 Mar 2007 10:53:27 -0400

Guilty as charged. I will fix.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 23 Mar 2007 18:04:32 -0400

> 'below the application level'.  How about if we point out DSCP
> explicitly (like in ice-14) and add half a sentence that hand-waves
> at layer 2 QoS markings?
> 
> -d
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 23 Mar 2007 18:04:32 -0400

inline.

> mentions of "foundation" and "sequence", and I didn't find it.

Actually I think I was thinking of local pref. Anyway its perfectly 
valid to use a counter for this. There are a million ways you can 
incorrectly infer grammar from examples.

> Waiting/Frozen checks, its Ta timer doesn't do anything, clearly.)

If waiting/frozen are exhausted, then the check list is either done 
(succeeded or failed) or all checks are in progress. So it would stop 
counting when this is true, meaning there are no checks in the Waiting 
or Frozen state. I'll clarify.

Also as you pointed out to me, this should be Ta*N not Ta/N. Oops.

-Jonathan R.

List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mmusic>,
	<mailto:[email-masked]?subject=subscribe>
Errors-To: [email-masked]

inline.

> mentions of "foundation" and "sequence", and I didn't find it.

Actually I think I was thinking of local pref. Anyway its perfectly 
valid to use a counter for this. There are a million ways you can 
incorrectly infer grammar from examples.

> Waiting/Frozen checks, its Ta timer doesn't do anything, clearly.)

If waiting/frozen are exhausted, then the check list is either done 
(succeeded or failed) or all checks are in progress. So it would stop 
counting when this is true, meaning there are no checks in the Waiting 
or Frozen state. I'll clarify.

Also as you pointed out to me, this should be Ta*N not Ta/N. Oops.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 26 Mar 2007 09:47:30 -0400

inline.

> request, after this immediate retransmission? 

Hmm, good question. I think what makes sense is this. Lets say the
current retransmit interval is 50ms, and you are 22ms into it. If you
send a triggered retransmit, you cancel the one in 22ms and send the
next 50ms from now. However either would work really, this is almost an
implementation guideline.

> I don't see how the check lists for the second media stream ever unfreeze.

Errr, ummm. Gack. Bug.

> Have I overlooked something?  Or does this need to be resolved in ICE?

It needs to be resolved.

> I'm not sure what the implications of this would be.

I noodled on this a bit, and think the right answer is this:

1. first, a single media stream is picked. The pairs are grouped by 
foundation, and then from each group a single pair is unfrozen. This 
guarantees that for the first media stream you have initially unfrozen 
every possibility, without depending on the component ID values.

2. Once the first media stream completes (or fails), you unfreeze all of 
the other frozen streams. You do that by unfreezing the pairs with the 
same foundation ID as ones in the valid list for the one that just 
finished. If none get unfrozen that way, you unfreeze by doing what I 
just described in step 1.

I'm pretty sure this is guaranteed to complete.

Great catch.

-Jonathan R.

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 26 Mar 2007 11:00:29 -0400

> implementation guideline.

The question is if STUN itself needs to say anything about this case.  (Just
what you need, I know, more things to change in 3489bis.)  The other
question is if immediate retransmission is allowed to supersede STUN's
maximum of 7 request retransmissions.

> I'm pretty sure this is guaranteed to complete.

I'm pretty sure it will too, but I'm worried it would take too long, if some
candidate pairs' checks are disappearing into a black hole. (Given STUN's
recommended 100 ms initial RTT estimate, 3489bis-06 says a STUN transaction
takes 7900 ms to time out.)

-- 
Jonathan Lennox
[email-masked]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 26 Mar 2007 11:56:28 -0400

inline.

> maximum of 7 request retransmissions.

Sorry - I did clarify that in -15. That text says:

<t>If the state of that pair is In-Progress, the agent SHOULD generate
an immediate retransmit of the Binding Request for the check in
progress. This is to facilitate rapid
completion of ICE when both agents are behind NAT. It is RECOMMENDED
that, after the immediate retransmit, the next retransmission occur T
milliseconds later, where T is the current STUN retransmit
interval. If the immediate retransmit causes the total number of
requests transmitted to equal the maximum value defined in <xref
target="RFC3489bis"/>, the agent SHOULD NOT send any further
retransmits.
</t>

so in other words the max of 7 still holds.

> takes 7900 ms to time out.)

I don't know how to speed this up without either changing the timer for 
the STUN timeout, or by unfreezing the other media streams before the 
first one fails. THe latter could be done I suppose, but at extra 
complexity (likely another timer) for improvement of the performance of 
a corner case. The primary use case for ICE is that there will be 
candidates of the same foundation across media streams, which is why I 
missed this error case to begin with. Only in really unusual cases 
should the first media stream fail, and then we succeed in other media 
streams.

I want ICE to be 'zippy' in the best of network conditions (no NATs), 
with increasing latency penalty as network conditions get uglier. I 
think thats the right tradeoff here.

-Jonathan R.

---

From: Philip Matthews <[email-masked]>
Date: Thu, 29 Mar 2007 10:48:27 -0400

> implementation guideline.

Since I asked a similar question about the ICE-08 draft, I suggest  
you say
something explicit about this in the document.

---

From: Philip Matthews <[email-masked]>
Date: Thu, 29 Mar 2007 10:53:05 -0400

> "construct/replace/prune" algorithm, so the current text is fine.

A slightly simpler algorithm would be "only construct pairs using  
base candidates".
This might give a slightly different ordering than the current  
algorithm, but the set
of resulting checks would be the same (since, in Jonathan's  
algorithm, checks
that say "send from a server-reflexive candidate" are later replaced  
with a check
that sends from the associated base candidate).

- Philip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 29 Mar 2007 12:56:21 -0400

This issue is explicitly addressed in the -15 which just went to WGLC 
(yay!).

-Jonathan R.

Philip Matthews wrote:

> Since I asked a similar question about the ICE-08 draft, I suggest  you say

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 29 Mar 2007 12:56:21 -0400

-Jonathan R.

Philip Matthews wrote:

>>> mechanism?  Is it just an extra packeX-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Cc: Jonathan Lennox <[email-masked]>, IETF MMUSIC WG <[email-masked]>
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mmusic>,
	<mailto:[email-masked]?subject=unsubscribe>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mmusic>,
	<mailto:[email-masked]?subject=subscribe>
Errors-To: [email-masked]

What you are proposing would alter the order from the ones desired based 
on priority. The current text achieves this goal. I'd like to close this 
issue, so unless you see a real problem with the current text, lets move on.

-Jonathan R.

Philip Matthews wrote:

> A slightly simpler algorithm would be "only construct pairs using  base 
> candidates".
> of resulting checks would be the same (since, in Jonathan's  algorithm, 
> checks

t, invisible to regular STUN

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 29 Mar 2007 12:55:51 -0400

-Jonathan R.

---

From: Philip Matthews <[email-masked]>
Date: Thu, 29 Mar 2007 13:26:23 -0400

Sorry, I should have added the following:

     However, the on-the-wire efficiency of the two algorithms are  
identical,
     and the gain in simplicity that I see is small, so I don't think  
we should
     change things at this late date.

- Philip

On 29-Mar-07, at 12:55 , Jonathan Rosenberg wrote:

> What you are proposing would alter the order from the ones desired  
> based on priority. The current text achieves this goal. I'd like to  
> close this issue, so unless you see a real problem with the current  
> text, lets move on.
>
> -Jonathan R.
>
> Philip Matthews wrote:
>
>
>> that say "send from a server-reflexive candidate" are later  
>> replaced  with a check