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

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 23 Jun 2006 04:25:56 -0400

responses inline.

Philip Matthews wrote:

> 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?

Just one. It has to be that way. The q-values are relative only to
candidates within the same media stream. There is no way to obtain a
relative ordering across media streams. I do think that section 7.5 is
pretty clear that these various lists are per media stream.

>      Viewed another way, is there just one Ta timer, or one Ta timer  
> per m/c line?

It would be one Ta timer per m/c line. I've clarified that:

<t>Every Ta seconds, the agent starts a new connectivity check for a
transport address pair, for each media stream. Thus, if there are 3
media streams, the checks will be paced out at 3/Ta checks per
second. 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

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

There needs to be multiple timers, but you can keep the rate down by
reducing the value of Ta proportional to the number of media streams.
The draft doesn't say that, but I think its a good change to make. What
I did was define a separate timer Tb, used for connectivity checks. Ta
is the timer for gathering. Tb SHOULD scale with the number of media
streams, default is N*50ms.

That doesn't account for inter-dialog checks, but I think thats a
sufficiently rare case, and sufficiently complicated to do, that I'd
rather not specify that.

I also added a randomization factor in front of Tb, between .7 and 1.3.
Unless you do that, you are likely to get synchronization of
connectivity checks across media streams, which may interact badly with
NATs and who knows what else.

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

Right.

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

Right.

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

Sure, its easier not to do this. It also increases the latency big time.

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

No - this is a STUN server running on the rtp port. It makes no sense to
use it for other usages.

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

I strongly oppose this change. Latency has been a big issue for ICE, and
this is an automatic 100ms penalty. Also not clear that 100ms is big
enough. With the current text, you don't need a hard-to-tune timer here,
and it works as fast as it can. Sure, its a bit more complicated, but
this is hard stuff, what can I say.

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

This won't happen. The Tr interval is really only for the active
candidate once its promoted. That interval is HUGE - like 15s. 15s after
the first offer/answer exchange, we've either found a candidate pair
that works, promoted it, and removed the other candidates (including
this bad one), or the call has failed.

In any case, rejecting the stun requests because your own view of the
candidate pair is invalid is also a bad idea - it won't work with peer
reflexives, where this is likely to happen.

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

You need to split this into two different cases, since the two are
handled differently.

One case is where there is a nat failure mid-transaction, so that the
source IP address of two binding requests (which would be retransmits)
within the same transaction, as seen by the stun server, are different.
The second case is where the nat failure occurs between a pair of
successful checks.

The first case is challenging, and I basically agree with option (b) - 
using the first address in particular. I've added text in -09 to cover 
this case. Interestingly, there was a specific spot int he document 
where the condition where this might happen is mentioned, but the 
document said it was impossible to happen. I've changed that and 
described what to do.

The second case is actually handled well by ICE; it will properly notice 
the change in binding, revalidate and re-invite.

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

No. zz is small since it has two 'digits'. Just like 99 is less than 
112. However, this is all still not that clear since ROhan complained 
about it too, so I will try to make it clearer.

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

Good point. I've changed it so both of them go to the head. This 
required some changes in the text which discusses when to promote, and 
I've come up with a better description of that also.

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

I changed them to legal candidate IDs in cases where they weren't part 
of a figure, where four characters would make the figure too big. In 
that case, I called this out.

> 
> 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?

Its a bug, leftover I think. Text in parentheses was deleted.

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

It makes sense in a couple, but not all. I changed a few of them.

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

The document uses the term "a NAT" or "the NAT" when referring to the 
box, and just "NAT" when referring to the technology. I believe that is 
consistent with common usage.

> 
> 
> Section 7.1:
> 
> - "... transport addresses for each component of each component  match 
> ...".
>    I suggest deleting "for each component".

fixed.

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

ok.

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

ok.

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

IP-addr:port is widely used notation. Anyway I have explained it on 
first usage.

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

fixed.

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

ok.

> 
> - "ususally" should be "usually"

fixed.

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

done.

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

For ice alone, yes its all UDP.

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

normative. Its been moved with the rest of the normative text, separate 
from the example as you suggested.

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

fixed

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

ok.

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

right. changed it to the "selected" event.

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

ok

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

fixed up.

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

I think the original wording is fine, and consistent with how this 
statement is made throughout the rest of the document.

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

fixed.

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