Subject: [MMUSIC] Still more questions and comments on draft-ietf-mmusic-ice-08

From: Philip Matthews <[email-masked]>
Date: Thu, 27 Apr 2006 14:08:49 -0400

Jonathan:

Below are some more questions and comments on draft-ietf-mmusic-ice-08.

- Philip

Technical comments and questions
============================

1)  If there are three m/c lines in the SDP, does the agent construct  
three candidate pair check orderings,
      or just one ordering containing the candidates for all three  
media streams?
      Viewed another way, is there just one Ta timer, or one Ta timer  
per m/c line?
      Taking this even farther, if the agent is taking to two or more  
different remote agents (because it is
      trying to establish two different call legs, perhaps for the  
same call or perhaps for different calls),
      then is the result one or multiple candidate pair check orderings?
      (It seems to me that, to reduce the load on intervening NATs,  
there should be just one.)

2)  When an agent receives a STUN Request, section 7.8 seems to say  
that the agent validates
       the request and sends a reply based only on local information.  
In particular, the USERNAME
       is validated by checking for a match on the local tid (and not  
the remote tid).
       The reason for this seems to be the case when an the offerer  
receives a STUN Request but has
       not yet received the answer from the remote agent. (This case  
is presumably pretty common since
       STUN Requests go directly, but signaling goes indirectly).
       In this case, the text seems to say that the STUN Request is  
validated and a STUN response sent
       immediately,  and information about the STUN Request is stored  
for further processing once
       the answer is received.
       However, I can see implementations deciding instead to ignore  
STUN Requests where there is not
       an exact match for the USERNAME.  I can see them doing this  
for three reasons:
       a) It is easier. In this case, there is no need to queue up  
information about the STUN Request for
           later processing when the answer arrives.
       b) For security. The agent might be acting as a STUN server  
for more than one STUN usage, and use the
           USERNAME to differentiate the usages. For security and  
because of DoS attacks, the agent
           simply ignores STUN Requests with unknown USERNAMES.
       c) Better validity checking. If an agent just does a prefix  
match, then USERNAMES corresponding
           to illegal transport address combinations are not detected.
           For example, a request with USERNAME "Lxx:1:Ryy: 
2" (mismatched component ids) or
           a request where the candidates are from different media  
streams, or use different transport addresses, etc.
       My proposal is that:
        - An agent always does an exact match against the USERNAME  
when a STUN Request arrives.
        - The answerer waits some time (say 50 or 100 msec) before  
starting its connectivity checks,
          or waits until it receives a STUN Request from the offerer,
          or doesn't bother waiting at all (because things will work  
out anyway after retries).

3) Another reason to do an exact match against the USERNAME might be  
the following.
     Consider two agents, L and R and a candidate pair Lxx:1:Ryy:2.
     L sends a STUN Request for this pair and receives a success  
response, and thus
     moves its local state machine into the Recv-Wait state.
     R sends a STUN Request for this pair, but due to some problem,
     L does not like this request, and sends an error response,
     which causes R to give up and move into the Invalid state.
     At this point, L continues to send STUN Requests each Tr interval ,
     and R replies with a success response, and the candidate pair  
remains stuck
     in the (RECV-WAIT, INVALID) state combination.
     To avoid this problem, it might be appropriate for an agent to  
return an error response,
     when its local state machine is in the Invalid state.

4) According to section 7.10.1, when an agent receives a STUN request  
and discovers a new
     peer reflexive transport address, the agent generates a new  
candidate id from candidate IDs
     of the candidate pair specified by the USERNAME:
           "In particular, the candidate ID is constructed by
            concatenating the remote candidate ID with the native  
candidate ID (without the colon)."
     It is possible, due to routing changes or a glitch in the  
intervening NAT(s),
     that the same candidate pair might generate TWO or more peer  
reflexive transport addresses.
     For example, say L and R are the two agents. The network in  
which R resides is configured
     to send packets through NAT box N1 in normal use, but if N1  
fails, packets are sent through
     NAT box N2.
     For a given candidate pair, R sends multiple STUN Requests to L.  
It may be that the first
     STUN Request goes through N1, but the second goes through N2.  
This causes L to see
     two different peer reflexive transport addresses for the same  
USERNAME.
     These two peer reflexive transport addresses will be assigned  
the same candidate ID by L,
     violating the rule that candidate IDs must be unique.
     I can see two possible ways to handle this situation:
     a) Append a string to the candidate ID to ensure they are unique  
(e.g., "1", "2", ...),  OR
     b) Use the last (or the first) peer reflexive transport address  
seen for this USERNAME.
     Option (a) is may be tricky, especially when the remote  
(generating) candidate has multiple components,
     so I suggest option (b).

5)  How are two candidate IDs of different lengths compared? My  
assumption is that the shorter
      one is padded at the end with Null's (0x00) until the two IDs  
have the same length.
      Is this correct?
      If so, then am I just confused, or is there an error in the  
following sentence?
        "For example, the candidate with candidate ID agD is greater  
than the candidate with ID ad7,
         and both of those are greater than the candidate with ID zz."
     I would have thought that, in reverse lexicographic order, the  
IDs would have be ordered as
     zz, agD, ad7, since the "zz" is padded at the end with a Null  
character.

6) If agent L has two candidates with the same derived address (but  
different local addresses)
    and picks one of the candidates as the one to put in the m/c  
line, then as the spec points out,
    the remote agent won't know which candidate the m/c line  
corresponds to. The spec recommends
    the remote agent just guesses and picks one to move to the head  
of the check ordering.
    Wouldn't it be better to:
      - Move BOTH candidates to the head of the ordering, or
      - Somehow indicate in the SDP which candidate was chosen?
   In other words, this case breaks the requirement that both  
endpoints create the same
   candidate pair check ordering.

7)  Am I correct in saying that none of the example candidate IDs in  
the document are actually legal?
      Because they are all too short?
      If so, it might be useful to use realistic candidate IDs or at  
least say something about this.

8) In section 7.6, there is the sentence:
           "The check is started for the first transport address pair  
in the transport address
            pair check ordered list (which will be part of the active  
candidate) that is
            in the Waiting state"
     I don't understand the part in parentheses.
     Don't we check all the pairs, not just the pairs associated with  
the active candidate?

Editorial comments
===============

General:

- In a number of places in the document, you use the phrase   
"reflexive or relayed"
   where it would be more general and more accurate to say "derived".
   (For example, "reflexive or relayed candidate", rather than  
"derived candidate", etc).

- In the first part of the document, you use "NAT" to mean the  
technology (i.e., "Network Address Translation"),
   for example in "Numerous solutions have been proposed for allowing  
these protocols to
    operate through NAT" in section 1.  But later in the document,  
you start using "NAT" to
    mean a single box (i.e., "Network Address Translator"), for example
    "...when two agents are separated by a NAT ..."  in section 7.10.
   It would be nice if you were consistent.
   In my opinion, the most common usage is to use "NAT" to refer to a  
single device and "NATs" when
   referring to multiple devices. However, I would be happy with  
another solution as long as the usage
   was consistent and made explicit.

Section 7.1:

- "... transport addresses for each component of each component  
match ...".
    I suggest deleting "for each component".

Section 7.3:

-      "even if the transport address from a previous  session was  
being recycled."
   For consistency (in verb tense) with the rest of the sentence,  
suggest changing "was" to "is".

-    "In this case, thats ...".
   "thats" should be either "that's" or "that is".

-    "10.0.1.1:8866 and 8877".
   I understand what you are trying to say here,  but you never  
explain this notation,
   and this paragraph is the only place in the document where you use  
it.
   (It is not, for example, legal in the a=candidate lines).
   Furthermore, you have just been talking about using a colon to  
construct tids and usernames.
   Perhaps write this in a different way to make sure the reader  
understands?
   Note also that a few sentences later, you say
          "A will send a STUN request to 10.0.1.1:8866 and 8877"
   when what you really mean is
          "A will send one STUN request to 10.0.1.1:8866 and another  
STUN request to 10.0.1.1:8877".

-     "To fix this, tid takes on ..."
   For consistency with previous usage, I think there should be a  
"the" before "tid", so the sentence reads
        "To fix this, the tid takes on ..."

- "ususally" should be "usually"

Section 7.4:

- (first two PPs) The intermixing of the running example and the  
specification in these paragraphs
   is a bit confusing, because it is not clear which statements are  
normative and which just apply
   to the example. Suggest splitting the example out into its own  
paragraph.

-      "If an offer/answer exchange took place for a session  
comprised of an audio
          and a video stream, and each agent had two candidates per  
media
          stream, there would be 8 candidate pairs, 4 for audio and 4  
for video."
    If an offer or answer can have candidates with different  
transport protocols
    (not sure if this is allowed -- I asked this question in my last  
message),
    then this assumes all candidates have the same transport protocol.

-       "Returning to the previous example, for each of the 8  
candidate pairs,
          there would be two transport address pairs - one for RTP,  
and one for
          RTCP.  If one candidate has more components than the other,  
those
          extra components will not be part of a transport address  
pair, won't
          be validated, and will effectively be treated as if they  
weren't
          included in the candidate pair in the first place."
    The first sentence seems to assume that the audio and video  
streams will use RTCP,
    and so both ends offered two components in each candidate.
    The second sentence then confuses things further -- is this  
supposed to be a continuation
    of the example, or a normative statement?

Section 7.6:

-       "The state machine has six states - waiting, testing, Recv- 
Valid, Send-Valid, Valid and Invalid."
     I think  "waiting" and "testing" should be capitalized.

- Immediately after the state transition diagram, I suggest giving a  
brief description
   of the meaning of each state.
   Though there are some descriptions later on, I think it would be  
nice to have the descriptions
   complete and all together in one place

-  The notation in the state diagram indicates that the state machine  
moves from Waiting to Testing
    when timer Ta expires. However, this is true only if the state  
machine is the next in line to start testing.

-      "... captures the progress of connectivity checks."
    Grammar: Insert a "the" before "connectivity"?

-         "This is done by  computing the matching transport address  
pair for each Binding
             Request.  This is done by examining the USERNAME of the  
incoming  Binding Request. "
    Suggest rewording these sentences along the following lines:
          "This is done by determining the matching transport address  
pair for each incoming STUN message.
           For an incoming Binding Request message, this is done by  ...
           For an incoming response message, this is done by ...

-        "Extensions to ICE that describe other transport protocols  
SHOULD
            describe the state machine and the procedures for  
connectivity checks."
     To be clearer and more precise, perhaps reword as follows?
          "Extensions to ICE that describe other transport protocols  
SHOULD
           describe the state machine and procedures for those  
protocols."

-     "... in Figure 5"
    Missing period at end of sentence.

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