Subject: [MMUSIC] Substantive ICE WGLC comments

From: "Rohan Mahy" <[email-masked]>
Date: Thu, 4 May 2006 09:09:39 -0700

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".

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.

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/

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.

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.)

6) Since our discussions about PRACK, I have been on the lookout for
complexity added for corner cases.  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.

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..."

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.

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.

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