Subject: [MMUSIC] Re: Part 4 of questions/comments on draft-ietf-mmusic-ice-08

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

inline.

Philip Matthews wrote:

> Jonathan:
> 
> Here are some more comments and questions about this draft.
> Hope they help.
> These are probably the last comments I will have time to send before
> the WGLC closes.
> 
> 
> And, BTW, it is clear that you have put a HUGE effort into this work.
> Many thanks for all this!!
> I think this stuff we be very useful.
> 
> - Philip
> 
> 
> Technical questions and comments
> ============================
> 
> 1) Perhaps I am just dense, but I am finding it difficult to  determine 
> which portions of
>     the procedures specified in the new STUN draft (draft-ietf- 
> behave-rfc3489bis-03)
>     actually apply when ICE is used. When I sat down to try to write  
> some pseudo-code
>     to handle the receipt of a STUN request, I found I had to weave  
> back and forth
>     between the two documents and take some guesses as to which  
> paragraphs in
>     rfc3489bis to ignore. For example, section 9.1.1 of rfc3489bis  says 
> that a server
>     should include a NONCE attribute in certain error responses, but  I 
> am guessing
>     that statement does not apply for ICE.
>     Would it be possible to give somewhere, perhaps in an appendix,  an 
> integrated
>     description of the STUN procedures for ICE (that is, an  integration 
> of the procedures
>     specified in rfc3489bis, plus sections 7.7 and 7.8 for sending  and 
> receiving STUN requests
>     for ordinary candidates, and sections 7.10.1 and 7.10.2 for  sending 
> and receiving
>     STUN requests for peer-reflexive candidates)?

I don't want to repeat whats in rfc3489bis. The version of rfc3489bis 
you are reading is the first revision that defines the connectivity 
usage, and it will take another rev (which is next after I finish ICE) 
to get it better aligned. THe theory goes that you would read rfc3489bis 
and the connectivity usage and it would be clear that you would be using 
all of it.

> 
> 
> 2) In section 7.10.1, the document says
>         The comparison of the source IP and port of the Binding  Request 
> and
>         the IP address and port of the remote transport address in the
>         matching transport address pair may indicate inequality.  In  that
>         case, the source IP and port of the Binding Request (and  again, 
> for
>         relayed transport address, this refers to the source IP  address 
> and
>         port of the packet when it arrived at the relay) are  compared 
> to the
>         IP address and ports across the transport address pairs in  *all*
>         remote candidates.
>    When you say "*all*" here, do you mean all candidates for the  same 
> media stream
>    which have the same transport protocol?

Same media stream and transport protocol. Will clarify.

> 
> 
> 3)  In section 7.10.1, the document talks about passing a "Get Req"  
> event to the state machine
>     of the (local candidate, peer-reflexive candidate) pair.
>     Is this in addition to the event passed to the state machine of  the 
> (local candidate, generating candidate) pair,
>     or instead of?  The last paragraph of section 7.10 suggests that  
> this is in addition to,
>     but it is not clear to me why the state machine for (local  
> candidate, generating candidate) should get this event.

Good question. I have revised the state machine to allow for the 
optimizatiosn you have suggested in your draft. In doing so, the text is 
now clear on this. A "miss" event gets fed into the state machine for 
(local,generating), which moves it instantly to invalid.

> 
> 4)  In section 7.10.1, the document says
>       "The agent SHOULD select the candidate
>         pair corresponding to the combination of the alternate remote
>         candidate and the native candidate from the original matching
>         candidate pair."
>     When you say SHOULD here, do you mean that the agent might  select a 
> different candidate pair,
>     or that the agent might elect not to send the "Get Req" to this  pair?
>     Would you explain why agent might choose to do something different?

This is a good point. SHOULDs are confusing to implementors, to be 
honest. Over time I have made an increasingly concerted effort to use 
them less, and when I use them, explain why its a SHOULD. ICE has far 
fewer SHOULDs, and this one in particular is out of place. Its basically 
a MUST. The description here is more concise now and this SHOULD is gone.

> 
> 5)  Is the timer described in section 7.13 "Sending Media" the same  as 
> the timer
>     for promoting a candidate to active (section 7.9)? The wording  used 
> is almost identical.

They're not identical, in fact, though very similar. The one in 7.9 is 
only used by offerers, the one in 7.13 for answerers. I'll clarify.

> 
> 6) In section 7.6, the document says
>           "If, while in the Testing state, the agent receives a  Binding 
> Request
>            matching that transport address pair, and this Binding  Request
>            generates a successful response, the transport address  pair 
> moves
>            into the Send-Valid state.  In addition, the agent  
> retransmits a
>            Binding Request for the transaction in progress."
>     How is this retransmission relate to the STUN client state  machine 
> for this address pair?

It doesn't impact the FSM in that section, if that is what you are 
asking. Its a forced retransmission, really, overriding the normal 
retransmit rules for STUN. I'll clarify that.

>     Section 7.1 of draft-ietf-behave-rfc3489bis-03 talks about  sending 
> a total of 9 requests
>     at exponentially increasing intervals. Does the above paragraph  
> mean that the retransmit
>     timer simply expires early? Or does this transmission have no  
> effect on the retransmit
>     timer and the retransmission count (thus potentially sending a  
> total of 10 requests)?

No effect, causing possibly 10 requests. I clarified that. THis is an 
optimization like so much of ICE; things will work without it, but ICE 
is faster if you do this.

> 
> 
> 
> Editorial comments
> ===============
> 
> Section 7.6:
> 
> -   Perhaps I am missing something, but aren't the names for the Send- 
> Valid and Recv-Valid states reversed?
>     That is:
>           - In Send-Valid, the local agent knows it can _receive_   on 
> that transport address pair
>           - In Recv-Valid, the local agent knows it can  _send_      on 
> that transport address pair

Its all a matter of perspective. Send-Valid also means that its peer can 
*send* to it. Per your other comment, I've added a sentence that 
describes each state and it expresses it in this way to make it clear.

> 
> -  Does an otherwise valid STUN request generate a success response  
> when received in any state?

yes.

>    As I stated in a previous message, I think it shouldn't in the  
> Invalid state, but whatever is decided,
>    perhaps a clear statement on this issue would be helpful?

I added a clear statement about this.

> 
> Section 7.7
> -     "ransport" should be "transport"?
> -     "reflesive" should be "reflexive"?
> -     "neccesarily" should be "necessarily"?
> -     "oferrer" should be "offerer"?

fixed. I'll do a full spell check before submitting the final rev.

> 
> 
> -    Specify processing of other error codes listed in draft-ietf- 
> behave-rfc3489bis?
>      Specifically: 300, 434, 435, 436, 437 are presumably all errors  
> because none of them are applicable
>      to this usage of STUN?

yes. rather than listing each response code I merely stated that its 
unrecoverable or inapplicable error responses.

> 
> -       " ... to launch DoS attacks Section 13.4.2"
>      Formatting:
>         "... to launch DoS attacks (see Section 13.4.2)."

fixed

> 
> -         "... contains a reflexive or relayed candidate derived from  a 
> local candidate with that local transport address."
>      This is true for any derived  candidate, not just reflexive or  
> relayed candidates.
>      Suggest  rewording as follows:
>               "... contains a  candidate derived from that local  
> transport address."

ok

> 
> -         "If the USERNAME was not valid, the agent generates a 430."
>    Do you perhaps mean 436 (Unknown Username) rather than 430 (Stale  
> Credentials)?

No - its 430. 436 was previously a turn-only error code, assocaited with 
digest authentication. We're not using digest here, so its not used.

>    Also, suggest changing "was" to "is" for consistency (in verb  tense) 
> with the surrounding sentences.
> 

done

> 
> Section 7.8:
> -    "The first is generation ..., and the second ICE-specific"
>       Suggest adding an "is" after "second" for consistency.

ok

> 
> -      "An agent will continue to receive periodic STUN connectivity  
> checks
>          on a local transport address as long as it had listed that  
> transport
>          address, or one derived from it, in an a=candidate  attribute 
> in its
>         most recent offer or answer, the state machine for that  transport
>         address is in the Recv-Valid or Valid states, and the transport
>         address is for UDP."
>     I think it is possible to continue to receive them even when the  
> local state machine
>     is in other states, for example, the Invalid state. See my  previous 
> message
>     on this subject.

Removed the bit about being state dependent.

> 
> 
> Section 7.9 "Promoting a Candidate to Active"
> 
> -  Since the retry interval for STUN is initially 100 milliseconds,  
> perhaps the default value for
>    timer Tws should be 120 milliseconds (rather than 100  milliseconds) 
> to allow time for a
>    retry to complete for the candidate pair that is two earlier in  the 
> check sequence?
>   Or perhaps even larger, if candidate pairs from different m/c  lines 
> are combined in a single
>   candidate pair check ordering.

I hadn't done much real analysis in coming up with this default. 
Considering it further, the problem actually goes away if the number of 
components is large. Say you have 20 components in a candidate pair, and 
you are trying all of the components in a higher priority pair before a 
lower one. Thus, 20*50ms after the LAST check on the higher priority 
candidate pair is the EARLIEST that a lower priority one can validate. 
Thats a full 1s after the completion of the last check for the higher 
priority one, enough for many retransmits.

So, if you want to allow for a single packet loss (the easier formula), 
you need:

Tws = max(0, 100ms + RTT - N*50ms)

where N is the number of components. Assuming a 100ms RTT and N=2 
actually gives you the 100ms figure, so my guesstimate seems OK ;)

The main thing though is you can decrease Tws to zero if you have lots 
of components, and thats worth adding. I'll add this formula in.

> 
> - Perhaps the document should specify some relationships that should  
> hold between the various timer intervals?

per above - done!

> 
> -     "When the agent behind such a NAT sends a Binding Request to  the 
> other agent (assuming it is reachable) ..."
>    For clarity, suggest replacing "it" by "the other agent".

> 
> 
> Section 7.10.1
> 
> -     " ... sees if a transport address with
>        that same component ID exists in the peer reflexive  candidate.  If
>        not (and it shouldn't),..."
>   There might be a remote transport address with the same tid if the
>   local agent had previously received a STUN Request for the same  
> USERNAME.

this has been fixed per another comment you made.

> 
> -      "   Newly created or not, the agent extracts the component ID  
> from the
>             matching transport address pair, and sees if a transport  
> address with
>             that same component ID exists in the peer reflexive  
> candidate.  If
>             not (and it shouldn't), the agent adds a transport  address 
> to the
>             peer reflexive candidate.  This transport address is  equal 
> to the
>             source IP address and port from the incoming STUN  Binding 
> Request
>            (and in the case of a relayed transport address, the one  
> seen by the
>            relay).  It is assigned the component ID equal to the  
> component ID in
>            the matching transport address pair.  This transport  address 
> will
>            have a tid, equal to the concatenation of the candidate  ID 
> for this
>            new candidate, and the component ID, separated by a colon."
>    Presumably, the transport protocol and qvalue of the peer  reflexive 
> candidate
>    are the same value as the corresponding values of the generating  
> candidate,
>    and the rules for setting the various optional (extension-attr-name,
>    extension-attr-value) pairs are specific to the transport protocol
>    (with none currently defined for UDP).

Correct on the transport protocol.
Q-value is derived from the candidate whose q-value processing is 
mentioned elsewhere.
I've specified rules for the three additional candidate attributes which 
are now defined in -09, and specified that extensiosn would need to 
define how other candidate attributes are inherited.

> 
> 
> 
> Section 7.11.1 Sending of a Subsequent Offer
> 
> -     "o  If the candidate in the m/c-line is valid, all other  candidates
>            SHOULD be removed.  This has the effect of stopping  
> connectivity
>            checks of other candidates.  This SHOULD would not be  
> followed if
>            an agent wanted to keep a candidate ready for usage  should, for
>            some reason, the active candidate later become invalid."
>    If the candidate in the m/c line is a low priority candidate  (e.g., 
> a STUN relay candidate)
>    and the connectivity checks for higher priority candidates have  not 
> yet finished,
>    then removing the other candidates would be bad.
>    This situation could occur if the subsequent offer was triggered  for 
> reasons
>    other than ICE processing.

Right. Added "lower priority" to this to fix it.

> 
> 
> Section 7.11.2  Receiving the Offer and Sending the Answer
> 
> -   When talking about removing candidate pairs, the spec says
>            "3.  If the agent receives a STUN Binding Request for  that 
> candidate
>                  pair, the agent SHOULD generate a 430 response."
>     The document currently states in section 7.8 that a STUN  response 
> is generated
>     based on just a prefix match on the USERNAME. The above sentence  seems
>     incompatible with this.
>     (I suggested in a previous message that the STUN Response should  be 
> based on an exact match
>     of the USERNAME, which would be consistent with this sentence).

Per my other note, I think the prefix match is needed. I've removed the 
bit about 430, and instead referenced the section on receiving stun 
requests. btw, if a candidate pair disappears its generally because a 
candidate disappeared, in which case the prefix match will in fact fail.

> 
> 
> 
> Section 8    Guidelines for Usage with  SIP
> 
> -       "Two latency of figures are of particular interest."
>     Perhaps you mean the following??
>           "Two latency values are of particular interest."

deleted extra 'of'

> 
> 
> Section 11.1
> -      "In this example, the NAT has the address and port independent  
> mapping property
>          and the address dependent permission property".
>     I believe the BEHAVE terminology is "endpoint-independent  mapping" and
>     "address-dependent filtering".

fixed.

> 
> - Is there is an error in the SDP for the first example?
>        v=0
>        o=jdoe 2890844526 2890842807 IN IP4 $L-PRIV-1.IP
>        s=
>        c=IN IP4 $STUN-PUB-1.IP
>        t=0 0
>        a=ice-pwd:$LPASS
>        m=audio $STUN-PUB-1.PORT RTP/AVP 0
>        a=rtpmap:0 PCMU/8000
>        a=candidate $L1 1 UDP 1.0 $L-PRIV-1.IP $L-PRIV-1.PORT
>        a=candidate $L2 1 UDP 0.7 $NAT-PUB-1.IP $NAT-PUB-1.PORT
>    Should the address and port in the m/c line be NAT-PUB-1.IP and  
> NAT-PUB-1.PORT?
> 

yes, this was pointed out by others also.

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