Subject: Re: [MMUSIC] Questions and observations on ICE-19.

From: "Guylain Lavoie" <[email-masked]>
Date: Sun, 1 Jun 2008 01:13:31 -0400

Hi all,

20.

There seems to be a small ambiguity in ICE19 section 9.2.2.3, although I
might well be wrong.

Here is a scenario...

Both sides are ICE-Full, the controlling side is using aggressive
nomination. The SDP exchange consists of only one media with only one
component and only two candidate pairs. The first candidate pair does
not have connectivity and the second one has connectivity.

Supposed that the controlling side first check fails but the second one
succeed. And that at the same time the controlled side has not yet
received the answer to its equivalent check for the second candidate
pair. When the controlled side tries to perform its triggered check for
this second pair, it must set the pair to waiting before adding it to
the triggered check queue (second 7.2.1.4).

The controlling side then changes the state of the media check list to
complete and this in turn set the state of the ICE processing to
complete. The controlling side sends a new offer with the attributes
a=remove-candidate.

If the controlling side is fast enough, the timing is right and the SDP
offer (with a a=remote-candidate) beats the connectivity check answer to
the controlled side and also beats the triggered check (some 20ms
later), it is possible that we may have to process section 9.2.2.3 with
the first candidate pair in the failed state and a second in the waiting
state. 

The section 9.2.2.3 says that if the candidate pair composed on the
offer default destination and offer a=remote-candidate is not in the
valid list, the check has "lost" the race.

In that case, there are two possibilities. According to the
documentation, none of them seems applicable since the controlled side
still has a pairs in the waiting state.

The documentation looks ambiguous because it only considers the state
in-progress.

Here is a version of the text that I am referring too.

   o  If none of the pairs are In-Progress, and at least one is Failed,
      it is most likely that a network failure, such as a network
      partition or serious packet loss, has occurred.  The agent SHOULD
      generate an answer for this media stream as if the remote-
      candidates attribute had not been present, and then restart ICE
      for this stream.

   o  If at least one of the pairs are In-Progress, the agent SHOULD
      wait for those checks to complete, and as each completes, redo the
      processing in this section until there are no losing pairs.

Should I understand that when the documentation is referring to "none of
the pairs are in-progress", that this voluntarily ignores pairs with
state frozen and waiting?

I think that the condition should also mandate for the code to wait for
pairs that are in the waiting states to finish. Maybe even candidate
pairs that are still in the frozen state should be waited for. This
would give us some more time to process the triggered check queue and
possibly wait for incoming connection check response that are still
transiting on the network. Without this, the scenario should just fail
because no pair is in-progress and one is in the failed state.

However, as a possibly better solution, I do not see why we could not
say that only pairs

1.	that were nominated by the controlling side (and that are not
yet validated on the controlled side)
or
2.	pairs that match the offer default destination and
a=remote-candidate

are waited for, if they are frozen, waiting or in-progress, instead of
only if in-progress. All other pairs could then be left unchecked or
considered failed automatically.

What should the implementation do when something like this occurs? Is
this something that is possible with the current specification?

Thanks,
Guylain

-----Original Message-----
From: Guylain Lavoie 
Sent: May 26, 2008 1:27 AM
To: [email-masked]
Cc: 'Jonathan Rosenberg'
Subject: Questions and observations on ICE-19.

Hello everyone,

I am sorry to be this late in the process but I was really busy on the
implementation of draft-ietf-mmusic-ice-19.
I have some questions and observations on the document. By the way,
great job! The draft is way better than just a few versions ago.

Best Regards,
Guylain

1.	In section 4.1.1.2, it is written that using a single STUN/TURN
server improves the performance of ICE. How does it improve the
performance? On what basis? Obviously the gathering will be faster, but
I suspect that something else what meant.

2.	In section 5.7.1, it is written that a local candidate is paired
with a remote candidate if the two candidates have the same component ID
and have the same IP address version. The protocol should also be taken
into account.

3.	In section 5.7.1, it is written that number of components is
equal to the minimum across both agents of the maximum component. The
code does not tell what to do if there is no component in common. Since
component ID that are not in common does not create failure, I assume
that the media will be automatically considered as succeeded if no
component ID are in common. Am I right?

4.	In section 5.7.3, it is written that for each pair where the
local candidate is server reflexive, the server reflexive candidate MUST
be replaced by its base. That same should probably be performed for peer
reflexive too. I bring this because in section 7.1.2.2.1, it is written
that it is possible to pair a local peer reflexive candidate with the
remote candidate once the user has sent a new offer. So, I guess that
the pruning should also affect local peer reflexive candidate pairs.

5.	In section 5.7.3, replace "adn" by "and".

6.	In section 6, nothing is said on how to react if the peer does
not support ICE, like it is told in section 5.1.

7.	In section 7.1.2.1, it is written that the candidate pair that
generated the 487 into the triggering check queue. I am wondering why
the role conflict must generate an error 487. Instead of returning an
error, the server side could just return a connectivity check response
with an additional attribute named something like "ROLE-CONFLICT". That
way, the client side would know that there is a role conflict and could
fix it and at the same time it could discover local peer reflexive would
having to perform another connectivity check . Since the client was able
to receive the 487, this means that there is connectivity. Please, can
someone explain why the server side absolutely needed to return an error
instead of just return a normal response with a flag telling "by the
way, there is a role conflict"?

8.	In section 7.1.2.1, there is a rule to make sure that the
response to a connectivity check is received from the same address to
where we sent the connectivity check in the first place. Why must we
enforce this symmetry? What good does it bring us? Would it be because
some codecs assume that the same jitter buffer statistics applies to
both sides of a media?

9.	In section 7.1.2.2.2, it is written the valid pair may be equal
to a different pair in the check list. How can this be?

10.	In section 7.1.2.2.3, the term "any check list" is used a few
times. Should it not be "the check list"? Same for "a check list" that
should maybe be "the check list". Please explain.

11.	In section 7.2.1.1, it is written that if the agent's
tie-breaker is larger than or EQUAL to the contents of the
ICE-CONTROLLING attribute, the agent generates a 487 but retain its
role. Ok fine, but why equal? The specification seems to become brittle
when this happens since both sides will send 487. Would it not be
possible for both sides to keep alternate their role between
ICE-CONTROLLING and ICE-CONTROLLED in an almost endless loop because
both are sending checks paced at 20ms. Ok, you could say that this
condition will be rare but it could probably happen for identical
machines that recently rebooted. Their random generator could for a
while be mostly synchronized.  Maybe I missed something. Please explain.

12.	In section 7.2.1.3, it is written that the agent does not pair a
new remote candidate with any local candidate. However, in the next
section, it says that the agent constructs a pair that includes this new
remote candidate. In section 7.1.2.2.1, there was a note saying that the
pairing will be performed in the next section. Could we add a similar
note there so that the text is less ambiguous?

13.	In section 7.2.1.4, it is written that we must wait the duration
of the transaction timeout for a response. I am maybe slow, but I did
not read this correctly until I read it ten times. Please change the
text to explain that we must wait the duration of the transaction
timeout for a response, and that we must also process the response if
one is received as if it was a response for the new connectivity check,
since it is equivalent. A little clarification would be appreciated.

14.	In section 8.1.1.1, it is written that the new connectivity
check with the USE-CANDIDATE attribute to force the nomination should
succeed. What should we do if it does not work? Should we try the next
valid pair in priority? What if there is none?

15.	Nowhere is it written what to do if a server reflexive
keep-alive returns a different mapped address.

16.	Connectivity check keep-alives are performed with indications.
It is written nowhere what to do if we do not receive a keep-alive or
media packets after TR timeout. I would expect this in cases where our
binding changed for some reason like when the NAT rebooted. Should we
perform a media restart? Should we even bother with that? I think so
because we really need a way to detect if something has gone wrong
without the user intervention.

17.	In section 9.1.3.2, the first paragraph does not make much sense
to me. Should it be the local candidate instead of the remote candidate?

18.	In section 9.3.1.4, It think that "lowest component ID" should
be used instead of "component ID of 1". Left over from a previous draft?

19.	In section 15.1, there seems to be a problem with the grammar.
extension-att-name and extension-att-value are byte-string and delimited
with SP. However, byte-string includes SP. The grammar seems to be
ambiguous.

Guylain Lavoie
Technical Product Manager
M5T, a Division of Media5 Corporation
Web: http://www.m5t.com
Email: [email-masked]
Tel: +1-819-829-1008, ext: 662
Fax: +1-819-829-1342

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