Subject: [MMUSIC] Minor comments on ICE-15

From: Philip Matthews <[email-masked]>
Date: Fri, 20 Apr 2007 11:41:50 -0400

Jonathan:

Below are some more comments on ICE-15. Most of them are minor  
editorial comments.
I have extracted text from ICE-15, and then put in comments marked  
with "PM:".

- Philip

----------------

    The basic idea behind ICE is as follows: each agent has a variety of
    candidate TRANSPORT ADDRESSES (combination of IP address and  
port) it
    could use to communicate with the other agent.  These might include:

    o  A transport address on a directly attached network interface or
       interfaces
PM: s/or interfaces//  (since a given transport address can only be  
on one interface)

----

    Next, the agent uses STUN to obtain additional candidates.  These
    come in two flavors: translated addresses on the public side of a  
NAT
    (SERVER REFLEXIVE CANDIDATES) and addresses of media relays (RELAYED
    CANDIDATES).  The relationship of these candidates to the host
    candidate is shown in Figure 2.  Both types of candidates are
PM: s/in Figure 2/in Figure 2 (here the notation "X:x" means IP  
address X and port x)./
    discovered using STUN.

----

    To find a server reflexive candidate, the agent sends a STUN Binding
    Request, using the Binding Discovery Usage [12] from each host
    candidate, to its STUN server.  It is assumed that the address of  
the
    STUN server is manually configured or learned in some unspecified
    way.  It is RECOMMENDED that when an agent has a choice of STUN
    servers (when, for example, they are learned through DNS records and
    multiple results are returned), an agent uses a single STUN server
    (based on its IP address) for all candidates for a particular
    session.  This improves the performance of ICE.
PM: First of all, I suggest NOT placing normative text in the  
Overview section.
More fundamentally, there are topologies where one absolutely wants  
to use
multiple STUN servers. After all, this is the main point of the draft  
that you
co-authored with Dan Wing on discovering STUN servers.

----

    Each candidate is associated with a property called its FOUNDATION.
    Two candidates have the same foundation when they are "similar" - of
    the same type and obtained from the same interfaces and STUN  
servers.
PM: s/interfaces/interface/  and s/servers/server/.
    Otherwise, their foundation is different.  A candidate pair has a
    foundation too, which is just the concatenation of the  
foundations of
    its two candidates.  Initially, only the candidate pairs with unique
    foundations are tested.  The other candidate pairs are marked
    "frozen".  When the connectivity checks for a candidate pair  
succeed,
    the candidate pairs with the same foundation are unfrozen.  This
PM: s/the candidate pairs/other candidate pairs/  ?
    avoids repeated checking of components which are superficially more
    attractive but in fact are likely to fail.

----

    With regular nomination, the controlling agent lets the checks
    continue until at least one valid candidate pair for each media
    stream is found.  Then, it picks amongst those that are valid, and
    sends a second STUN request on its NOMINATED candidate pair, but  
this
    time with a flag set to tell the peer that this pair has been
    nominated for use.  A This is shown in Figure 4.
PM: s/A This/This/

----

2.7.  Lite Implementations

    In order for ICE to be used in a call, both agents need to support
    it.  However, certain agents will always be connected to the public
    Internet and have a public IP address at which it can receive  
packets
    from any correspondent.  To make it easier for these devices to
    support ICE, ICE defines a special type of implementation called  
LITE
    (in contrast to the normal FULL implementation).  A lite
    implementation doesn't gather candidates; it includes only host
    candidates for any media stream.  When a lite implementation  
connects
    with a full implementation, the full agent takes the role of the
    controlling agent, and the lite agent takes on the controlled role.
    In addition, lite agents do not need to generate connectivity  
checks,
    run the state machines, or compute candidate pairs.  Additional
PM: s/Additional/For/
    guidance on when a lite implementation is appropriate, see the
    discussion in Appendix A.

----

    Default Destination/Candidate:  The default destination for a
       component of a media stream is the transport address that  
would be
       used by an agent that is not ICE aware.  For the RTP component,
       the default IP address is in the c line of the SDP, and the port
       in the m line.  For the RTCP component it is in the rtcp  
attribute
       when present, and when not present, the IP address in the c line
       and 1 plus the port in the m line.  A default candidate for a
       component is one whose transport address matches the default
       destination for that component.
PM: The term "default" doesn't work very well when you talk about a
re-offer that specifies a new "default" value.

----

    The agent will receive a STUN Binding or Allocate response.  A
    successful Allocate Response will provide the agent with a server
    reflexive candidate (obtained from the mapped address) and a relayed
    candidate in the RELAY-ADDRESS attribute.  If the Allocate  
request is
    rejected because the server lacks resources to fulfill it, the agent
    SHOULD instead send a Binding Request to obtain a server reflexive
    candidate.  A Binding Response will provide the agent with only a
    server reflexive candidate (also obtained from the mapped address).
    The base of the server reflexive candidate is the host candidate  
from
    which the Allocate or Binding request was sent.  The base of a
    relayed candidate is that candidate itself.  If a relayed candidate
    is identical to a host candidate (which can happen in rare cases),
    the relayed candidate MUST be discarded.  Proper operation of ICE
    depends on candidate having a unique base when their transport
    addresses are identical.
PM: You are mixing singular and plural in this sentence.
PM: The operation implied by the last two sentences seems to be the same
     as that described in the next section.

----

4.1.1.3.  Eliminating Redundant Candidates

    Next, the agent eliminates redundant candidates.  A candidate is
    redundant if its transport address equals another candidate, and its
    base equals the base of that other candidate.  Note that two
    candidates can have the same transport address yet have different
    bases, and these would not be considered redundant.

PM: Which candidate should be kept? The highest priority candidate?

4.1.1.4.  Computing Foundations

    Finally, the agent assigns each candidate a foundation.  The
    foundation is an identifier, scoped within a session.  Two  
candidates
    MUST have the same foundation ID when all of the following are true:

    o  they are of the same type (host, relayed, server reflexive, peer
       reflexive or relayed)
PM: "relayed" appears twice

----

    Each candidate is assigned a foundation.  The foundation MUST be
    different for two candidates from different interfaces, and MUST be
    the same otherwise.  A simple integer that increments for each
    interface will suffice.  In addition, each candidate MUST be  
assigned
    a unique priority amongst all candidates for the same media stream.
PM: s/all candidates/all local candidates/
    This priority SHOULD be equal to 2^24*(126) + 2^8*(65535) + 256  
minus
    the component ID, which is 2130706432 minus the component ID.

    If an agent has included two candidates for a component, the v4
    candidate SHOULD be selected as the default.  Since a lite
PM:  How can a lite agent include two candidates for a component. ???
    implementation has a single candidate for a component, each of these
    candidates is considered to be default.

----

    STUN connectivity checks between agents make use of a short term
    credential that is exchanged in the offer/answer process.  The
    username part of this credential is formed by concatenating a
    username fragment from each agent, separated by a colon.  Each agent
    also provides a password, used to compute the message integrity for
    requests it receives.  The username fragment and password are
PM: s/receives/sends/
    exchanged in the ice-ufrag and ice-pwd attributes, respectively.  In
    addition to providing security, the username provides disambiguation
    and correlation of checks to media streams.  See Appendix B.4 for
    motivation.

----

        v=0
        o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1
        s=
        c=IN IP4 192.0.2.3
        t=0 0
        a=ice-pwd:asd88fgpdd777uzjYhagZg
        a=ice-ufrag:8hhY
        m=audio 45664 RTP/AVP 0
        b=RS:0
        b=RR:0
        a=rtpmap:0 PCMU/8000
        a=candidate:1 1 UDP 2130706178 10.0.1.1 8998 typ host
        a=candidate:2 1 UDP 1694498562 192.0.2.3 45664 typ srflx raddr
    10.0.1.1 rport 8998
PM: How are these priority value computed? I would have expected a  
value of 2,130,706,431 and 1,694,498,815 respectively.

----

    o  For each media stream, the default destination for at least one
       component of the media stream appears in a candidate attribute.
       For example, in the case of RTP, the IP address and port in the c
       and m line, respectively, appears in a candidate attribute, or  
the
       value in the rtcp attribute appears in a candidate attribute.
PM: Why just "at least one component"? Why not all components?

----

    Once roles are determined for a session, they persist unless ICE is
    restarted.  A ICE restart (Section 9.1 causes a new selection of
    roles and tie-breakers.
PM: s/9.1/9.1)/

----

5.7.2.  Computing Pair Priority and Ordering Pairs

    Once the pairs are formed, a candidate pair priority is computed.
    Let O be the priority for the candidate provided by the offerer.   
Let
    A be the priority for the candidate provided by the answerer.  The
    priority for a pair is computed as:

       pair priority = 2^32*MIN(O,A) + 2*MAX(O,A) + (O>A?1:0)

    Where O-P>A-P?1:0 is an expression whose value is 1 if O-P is  
greater
    than A-P, and 0 otherwise.  This formula ensures a unique priority
PM: Do you mean "O" rather than "O-P" and "A" rather than "A-P"?

    for each pair in most cases.  Once the priority is assigned, the
    agent sorts the candidate pairs in decreasing order of priority.  If
    two pairs have identical priority, the ordering amongst them is
    arbitrary.

----

5.7.3.  Pruning the Pairs

    This sorted list of candidate pairs is used to determine a sequence
    of connectivity checks that will be performed.  Each check involves
    sending a request from a local candidate to a remote candidate.
    Since an agent cannot send requests directly from a reflexive
    candidate, but only from its base, the agent next goes through the
    sorted list of candidate pairs.  For each pair where the local
    candidate is server reflexive, the server reflexive candidate  
MUST be
    replaced by its base.  Once this has been done, the agent MUST prune
PM: A candidate is replaced by its corresponding base candidate. In  
other words, all the associated information about the candidate  
(e.g., its foundation) is replaced by the associated information for  
its base.

    the list.  This is done by removing a pair if its local and remote
    candidates are identical to the local and remote candidates of a  
pair
    higher up on the priority list.  The result is a sequence of ordered
    candidate pairs, called the check list for that media stream.
PM: Do we need to talk about what happens when the default candidate  
pair
gets pruned?

    In addition, in order to limit the attacks described in
    Section 17.4.2, an agent SHOULD limit the total number of
    connectivity checks they perform across all check lists to 100, by
    discarding the lower priority candidate pairs until there are less
    than 100.

----

    The initial states for each pair in the check list are computed by
PM: s/the check list/a check list/
    performing the following sequence of steps:

----

    One of the check lists will have some number of pairs in the Waiting
    state, and the other check lists will have all of their pairs in the
    Frozen state.  A check list with at least one pair that is  
Waiting is
    called an active check list, and a check list with all pairs frozen
    is called a frozen check list.
PM: "active" and "frozen" look like check list states to me. Could we  
make them explicit states?

    The check list itself is associated with a state, which captures the
    state of ICE checks for that media stream.  There are two states:
PM: s/two states/three states/

    Running:  In this state, ICE checks are still in progress for this
       media stream.

    Completed:  In this state, ICE checks have completed successfully  
for
       this media stream.

    Failed:  In this state, the ICE checks have not completed
       successfully for this media stream.

----

    Once the agent has computed the check lists as described in
    Section 5.7, it sets a timer for each active check list.  The timer
    fires every Ta*N seconds, where N is the number of active check  
lists
    (initially, there is only one active check list).  Implementations
    MAY set the timer to fire less frequently than this.  Ta is the same
    value used to pace the gathering of candidates, as described in
    Section 4.1.1.  Multiplying by N allows this aggregate check
    throughput to be split between all active check lists.  The first
    timer for each active check list fires immediately, so that the  
agent
    performs a connectivity check the moment the offer/answer exchange
    has been done, followed by the next periodic check Ta seconds later.
PM: There is nothing here that requires all these timers to be spaced  
out.
As it stands, once every Ta*N seconds, all the timers could fire at  
once.
I am wondering if it is better to have just one timer and round-robin  
between
the check lists?

    When the timer fires, the agent MUST:

    o  Find the highest priority pair in that check list that is in the
       Waiting state.

    o  If there is such a pair:

       *  Send a STUN check from the local candidate of that pair to the
          remote candidate of that pair.  The procedures for forming the
          STUN request for this purpose are described in Section 7.1.1.
PM: Move state of pair to "In-Progress"?

----

    2.  If there is a pair in the valid list for every component of this
        media stream (where this is the actual number of components  
being
        used, in cases where the number of components signaled in the  
SDP
        differs from offerer to answerer), the success of this check may
        unfreeze checks for other media streams.  Note that this step is
PM: Following the procedures as laid out here, the pair which has just
transitioned to Succeeded is NOT YET on the valid list, because that  
step
doesn't happen until the next section.
        followed not just the first time the valid list under
        consideration has a pair for every component, but every
        subsequent time a check succeeds and adds yet another pair to
        that valid list.  The agent examines the check list for each
        other media stream in turn:

----

    If the agent is the controlled agent, the response may result in the
    valid pair having its nominated flag set.  See Section 7.2.1.5 for
    the procedure.
PM: I don't see how this could be the case, since this is a binding  
response.

----

    Section 7.2.1.4, and Section 7.2.1.5 for full implementations.  In
    cases where multiple STUN requests are received before the answer,
    this may cause several triggered notifications to all be sent at the
    same time,
PM: s/,/./ ?
PM: Can the response include a NONCE, as the STUN spec says it can?

----

7.2.1.1.  Detecting and Repairing Role Conflicts

    Normally, the rules for selection of a role in Section 5.2 will
    result in each agent selecting a different role - one controlling,
    and one controlled.  However, in unusual call flows, typically
    utilizing third party call control, it is possible for both  
agents to
    select the same role.  This section describes procedures for  
checking
    for this case and repairing it.
PM: Can we see examples of 3PCC cases where this problem comes up?
I am worried that no one but Jonathan understands these cases.

    An agent MUST examine the Binding Request for either the ICE-
    CONTROLLING or ICE-CONTROLLED attribute.  It MUST follow these
    procedures:

    o  If neither ICE-CONTROLLING or ICE-CONTROLLED are present in the
       request, there is no conflict.

PM: Isn't this a malformed binding request, since 7.1.1.2. requires
one of these to be included?

----

7.2.1.4.  Triggered Checks

    Next, the agent constructs a pair whose local candidate is equal to

PM: This is a transport address pair, not a candidate pair. Then we  
are trying to match this transport address pair to a candidate pair  
on a check list. We use the local and remote UFRAGs to do this. In  
fact, I claim all this processing happens just before section 7.2.1.3.

----

    If a triggered check is to be generated, it is constructed and
    processed as described in Section 7.1.1.  These procedures require
    the agent to know the transport address, username fragment and
    password for the peer.  The username fragment for the remote
    candidate is equal to the part after the colon of the USERNAME in  
the
    Binding Request that was just received.  Using that username
PM: Why do I have to extract the username fragment in this manner?
I know the local and remote candidate pair -- why can't I just used  
the username fragment and password associated with it?
    fragment, the agent can check the SDP messages received from its  
peer

Rosenberg              Expires September 27, 2007              [Page 46]
Internet-Draft                     ICE                        March 2007

    (there may be more than one in cases of forking), and find this
    username fragment.  The corresponding password is then selected.  If
    agent has not yet received the username in an SDP (a likely case for
    the offerer in the initial offer/answer exchange), it MUST wait for
    the SDP to be received (since it won't have its peer's ICE password
    without it), and then proceed with the triggered check.
PM: You already said this above.

----
    o  If there is at least one nominated pair in the valid list for a
       media stream and the state of the check list is Running:

       *  The agent MUST remove all Waiting and Frozen pairs in the  
check
          list for the same component as the nominated pairs for that
          media stream
PM: Do we remove ALL, or only those of lower priority?

----

    o  Once there is at least one nominated pair in the valid list for
       every component of at least one media stream and the state of the
       check list is Running:

       *  The agent MUST change the state of processing for its check
          list for that media stream to Completed.

PM: What about checks that are "In-Progress"? Do these continue to  
run? If they do, then the stuff below about changing the state of ICE  
processing overall to Completed seems wrong. (Or is this why it is  
possible in Aggressive Nomination, for the default candidate to  
change multiple times?)

       *  The agent MUST continue to respond to any checks it may still
          receive for that media stream, and MUST perform triggered
          checks if required by the processing of Section 7.2.

----

    <connection-address>:  is taken from RFC 4566 [10].  It is the IP
       address of the candidate, allowing for IPv4 addresses, IPv6
       addresses and FQDNs.  An IP address SHOULD be used, but an FQDN
       MAY be used in place of an IP address.  In that case, when
       receiving an offer or answer containing an FQDN in an a=candidate
       attribute, the FQDN is looked up in the DNS using an A or AAAA
       record, and the resulting IP address is used for the remainder of
       ICE processing.
PM: What is the motivation for allowing an FQDN in this position? I  
think this just makes the implementation more complex, for no good  
reason.

----

15.5.  "ice-options> Attribute
PM: s/>/"/

----

17.5.  Interactions with Application Layer Gateways and SIP

    Application Layer Gateways (ALGs) are functions present in a NAT
    device which inspect the contents of packets and modify them, in
    order to facilitate NAT traversal for application protocols.   
Session
    Border Controllers (SBC) are close cousins of ALGs, but are less
    transparent since they actually exist as application layer SIP
    intermediaries.  ICE has interactions with SBCs and ALGs.

    If an ALG is SIP aware but not ICE aware, ICE will work through  
it as
    long as the ALG correctly modifies the SDP.  In this case, correctly
    means that the ALG does not modify the m and c lines or the rtcp
    attribute if they contain external addresses.  If they contain
    internal addresses, the modification depends on the state of the  
ALG.
    If the ALG already has a binding established that maps an external
    port to an internal IP address and port in m and c lines or rtcp
    attribute , the ALG uses that binding instead of creating a new one.
PM: I think these last two sentences are meant to be descriptions of
a correctly operating ALG, but this is not obvious from the wording.

----

B.1.  Pacing of STUN Transactions

    STUN transactions used to gather candidates and to verify
    connectivity are paced out at an approximate rate of one new
    transaction every Ta milliseconds, where Ta has a default of 20ms.
    Why are these transactions paced, and why was 20ms chosen as  
default?
PM: Below you describe why transactions are paced, but do not explain  
why 20ms was chosen as the default. Perhaps add a sentence that says  
that 20ms was chosen after an experiments with a number of NATs  
showed that they could all handle 20ms but could not handle  
significantly higher rates?

----

B.2.  Candidates with Multiple Bases

    Section 4.1.1 talks about merging together candidates that are
    identical but have different bases.  When can an agent have two
    candidates that have the same IP address and port, but different
    bases?  Consider the topology of Figure 23:

PM: There is no discussion in section 4.1.1 about "merging"  
candidates. Are you referring here to section 4.1.1.3 on eliminating  
duplicate candidates, and in particular to the last sentence? If so,  
perhaps reword this as follows:
"Section 4.1.1.3 talks about eliminating duplicate candidates, and  
states that a candidate can be eliminated only if there is another  
candidate with the same transport address and base. This leads to the  
question: How two candidates can have the same transport addresses,  
but different bases? Consider the topology of Figure 23:".

PM: Also, I think it would be useful to add a paragraph motivating  
why one wants to eliminate duplicate candidates. I suggest mentioning  
the common case of obtaining a server reflexive candidate for a host  
candidate, and discovering that the two candidates are the same.  
Perhaps you can think of other common cases?

---
B.5.  The Candidate Pair Sequence Number Formula

    The sequence number for a candidate pair has an odd form.  It is:

       pair priority = 2^32*MIN(O-P,A-P) + 2*MAX(O-P,A-P) + (O-P>A-P? 
1:0)

    Why is this?  When the candidate pairs are sorted based on this
    value, the resulting sorting has the MAX/MIN property.  This means
    that the pairs are first sorted based on decreasing value of the
    maximum of the two sequence numbers.  For pairs that have the same
    value of the maximum sequence number, the minimum sequence number is
    used to sort amongst them.  If the max and the min sequence numbers
    are the same, the offerers priority is used as the tie breaker in  
the
    last part of the expression.  The factor of 2*32 is used since the
    priority of a single candidate is always less than 2*32,  
resulting in
    the pair priority being a "concatenation" of the two component
    priorities.  This creates the desired sorting property.

PM: Perhaps add a paragraph on why this particular sorting algorithm  
was chosen?

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