Subject: [MMUSIC] Re: Substantive ICE WGLC comments

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 23 Jun 2006 14:58:39 -0400

inline.

Rohan Mahy wrote:

> Hi Folks,
> 
> I think ICE is looking quite good from a technical perspective.  I have
> a few  substantive comments which mostly have to do with terminology and
> clarity of  explaining the mechanism.  I'll send out my NITS in a
> separate email.
> 
> 1) I already sent out my comment that we should not be using the term
> "answer"  when we mean "early SDP" or "courtesy SDP".

I disagree here per my note.

> 
> 2) I also sent out a proposed outline, which I think would help readers
> and  particularly implementors digest and find their way through this
> necessarily  lengthy spec.

I'll address the reorg comments last.

> 
> 3) The term lexicographic is used in the text, and is NOT what we want,
> as it  implies "dictionary" search order, which is inherently language
> specific, and  definitely wrong for comparing candidate IDs made out of
> base64 characters.
> 
> lexicographic: "of or relating to lexicography"
> lexicography: "The process or work of writing, editing, or compiling a
> dictionary"
> 
> For example, in a real lexicographic sort in English upper and lower
> case are  sorted together ("a" comes before "B") and spaces are sorted
> after "z" ("basin  wrench" comes after "basinet"). Other languages are
> different. Some langauges  even have digraphs which are sorted in
> non-character code order (ex: "ch" comes  after "z").
> 
> We want reverse "ASCII sort order"
> 
> Proposed replacement text for Section 7.5 (2nd and 34rd para):
>   Recall that when each candidate is encoded into SDP, it contains a
>   qvalue between 1 and 0, with 1 being the highest priority.  Peer
>   reflexive candidates, learned through the procedures described in
>   Section 7.10 also have a priority between 0 and 1.  For each media
>   stream, the native candidates are ordered based on their qvalues,
>   with higher q-values coming first.  Amongst candidates with the same
>   qvalue, they are ordered based on candidate ID, using reverse
>   ASCII sort order.  For example, the candidate with candidate
>   ID "agD" sorts before the candidate with ID "ad7", and both of those
>   follow the candidate with ID "zz".
> 
>   The usage of a reverse ASCII sort order is important; as discussed
>   in Section 13, it allows peer-derived candidates to be preferred over
>   native ones.
> 
> and later in 7.5:
> s/Amongst those pairs that share
>   the same value for their smaller sequence number and the same value
>   for their larger sequence number, the larger of the two candidate IDs
>   in each pair are selected, and the pairs are lexicographically
>   ordered in reverse by that candidate ID, largest first.
> /Amongst those pairs that share
>   the same value for their smaller sequence number and the same value
>   for their larger sequence number, the larger of the two candidate IDs
>   in each pair are selected, and the pairs are ordered in reverse ASCII
> 
>   order of the candidate ID, largest first. /
> 
> and finally in Section 11.1
> 
> s/the ordering algorithm in Section 7.5 will use
>   the reverse lexicographic order of the candidate ID iself
> /the ordering algorithm in Section 7.5 will use
>   the reverse ASCII sort order of the candidate ID itself/

OK. Hopefully this is clearer.

> 
> 4) There are a few places which I point out in the NITS where the
> document talks about candidates, but should be talking about components
> or transport addresses.  We need to be careful about this.

Agree. I'll try to get a cereful pass through on this.

> 
> 5) The terminology section could be pretty overwhelming.  I think it
> would be useful to describe the terminology wrt to candidates in terms
> of candidate properties.  For example, the "derivation" of a candidate
> could be "local", "server", "relayed", or "derived".  The "sdp-active"
> property for a candidate is either true or false.  The "side" of a
> candidate is either "native" or "remote".  When we do ICE TCP a
> candidate can have a "direction" property as well ("active", "passive",
> "actpass", etc.)

I think the way to address this is to greatly expand the overview, which 
now defines all of these terms with examples through a natural 
progression of explaining the spec, and then the terminology section 
follows. I'm not sure changing from 'terms' to 'properties' would lend 
much more clarity by itself.

> 
> 6) Since our discussions about PRACK, I have been on the lookout for
> complexity added for corner cases. 

Ice has a bunch of that, no doubt. TO some degree ice is struggling to 
meet as many corner cases as possible so it makes voip just work. 90% of 
the cases is not good enough.

> I think some of the behavior around
> changing ICE Passwords falls into that category.  I think it will be
> extremely uncommon to change an ICE password, but I can see the use for it
> (for example for 3pcc controllers).  However, requiring agents that never
> update an ICE password themselves to accept old and new ICE passwords 
> and to
> run a timer for this case seems unnecessarily complex and puts the 
> burden of
> implementation in the wrong place.  I propose that if an ICE password is
> changed, the password is changed immediately with no Tpw timer.  I also
> propose that the only time the password is allowed to be changed is when 
> all
> the candidates for a particular m-line are new candidates.  This addresses
> Flemming's motivation (3pcc) without introducing badness.  I couldn't find
> any motivation for changing the password because it was compromised (I am
> assuming do to forking).  Even so, the only effective way to get out from
> under an attack due to a compromised ICE password is to abandon the 
> relevant
> candidates.
> 
> Proposed text to replace the last paragraph of 7.11.1:
> Subsequent offers MUST contain a=ice-pwd attributes that specify the
> password for the candidates for each media stream.  If any of the 
> candidates
> for a particular m-line are the same as the previous offer, the ICE 
> password
> for that m-line MUST be the same.  If all of the candidates for a 
> particular
> m-line are different from the previous offer, the ICE password for that
> m-line MAY be different.  Note that it is permissible to use a 
> session-level
> attribute in one offer, but to provide the same password as a media-level
> attribute in a subsequent offer.  This is not a change in password, just a
> change in its representation.

I don't feel that strongly on this. I do think it works with the basic 
3pcc case. Text accepted.

> 
> 7) In the last paragraph of Section 7.12 (keepalives), I think it is
> reasonable to send RTP No-op even if the other end does not support it, but
> I'd like to make it clear that if you shouldn't send comfort noise to your
> peer unless the peer agrees this is OK.  Dean actually has a very funny 
> poem
> reminiscent of the Dr Suess rhyme "Green Eggs and Ham".  Dean's poem is
> begins "I do not like your comfort noise..."

Yeah, I've seen the poem in fact :)

If my peer advertises support for NEITHER comfort-noise or rtp no-op 
though, I don't see why one is any better than the other. Both would 
either be discarded because of an unknown PT, or both would be accepted 
by a confused implementation. I actually would suggest maformed RTP 
packets; ie.., ones with an incorrect RTP version. These stand the best 
chance of getting kicked out by an implementation while still keeping 
the nat binding open.

Thats what I've put into the draft.

> 
> 8) I am worried about the 5th paragraph of Section 7.13.  This para says 
> you
> must stop using a candidate you were using for early media Tlo (5 secs)
> after an answer is reliably received.  First, I think this reinforces my
> beef about calling an early SDP an answer throughout the document, because
> in this paragraph you really do mean a *answer*.  Second, I am concerned
> that we are giving both ends 5 seconds to get through a new offer/answer
> exchange, when SIP allows 32 secs.  If a new offer arrives 6.5 seconds 
> after
> the answer, there will be a short gap in the media.  The text should at
> least mention that this can happen.  The tradeoff is between how long you
> use a non-active candidate that may be wrong and the risk of not using a
> working media stream that you just haven't gotten an offer for yet.

Well, you know I disagree on the early answer terminology bit.

That said, this section is still confusing around the term 'reliably', 
and I've changed it to be a bit clearer:

<t> If a candidate pair is selected for early media, an agent MAY send
media on that candidate pair, even if it is not the same as the active
candidate pair. However, to deal with cases in which the offerer and
answerer do not agree on the eventual selection of this candidate for
promotion to active (a rare but possible case), the agent MUST
discontinue using the candidate pair for sending media Tlo seconds
after the next opportunity its peer would have to send an updated
offer.  In the case of an answer delivered in a 200 OK to an offer in
a SIP INVITE (regardless of whether that same answer appeared in an
earlier unreliable provisional response), this would be Tlo seconds
after receipt of the ACK. Tlo SHOULD be configurable and SHOULD have a
default of 5 seconds. This time represents the amount of time it
should take the offerer to perform its connectivity checks, arrive at
the same conclusion about the viability of the early candidate, and
then generate an updated offer promoting it to active. If, after Tlo
seconds, no updated offer arrives, the answerer MUST cease using the
early candidate. Media MAY be sent to the active candidate pair if it
is in the Valid or Recv-Valid state.  </t>

> 
> 9) Section 7.14.  Please mention in the 2nd paragraph that you have to
> determine if a peer supports ICE on a *per-fork* basis.
> 

Good point. Added. This is unfortunate actually since it reduces the 
effectiveness of ICE. An agent may not know about all branches for a 
while, and it would have to accept media until it was sure none of them 
were ICE-unawares.

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