Subject: [MMUSIC] editorial comments on draft-ietf-mmusic-ice-12

From: "Jason Fischl" <[email-masked]>
Date: Mon, 6 Nov 2006 23:30:12 -0800

General Comments:
- The draft is in really good shape.
  - I like the passive mode but I think that by interspersing the
description of how passive-only mode differs from full mode requires an
implementor of a passive-only mode device to fully understand ICE. I think
it would be better to either move all of the passive-only mode description
into a separate section or even a separate document.
- I really like the new Overview of ICE

Otherwise, here are a number of proposed edits to the text.

2. Overview of ICE

- typo: "figure figure"
   Figure 1 shows a typical environment for ICE deployment.  The
   two endpoints are labeled L and R (for left and right, which helps

- simplified language in bullet point
   The basic idea behind ICE is as follows: each agent has a variety of
   candidate transport addresses it could use to communicate with the
   other agent.  These might include:

   o directly attached network interface or interfaces

   o  A translated address on the public side of a NAT (a "server
      reflexive" address)

   o  The address of a media relay the agent is using.

- reworded highlighted text
   Potentially, any of L's candidate transport addresses can be used to
   communicate with any of R's transport addresses.  In practice,
   however, many combinations will not work.  For instance, if L and R
   are both behind NATs, their directly attached interface addresses are
   unlikely to be able to communicate directly (this is why ICE is
   needed, after all!).  The purpose of ICE is to discover which pairs
   of addresses will work.  The way that ICE does this is to
   systematically try all possible pairs (in a carefully sorted order)
   until it finds one or more that works.

2.1.  Gathering Candidate Addresses

- removed some text
   In order to execute ICE, an agent has to identify all of its address
   candidates.  Naturally, one viable candidate is obtained directly
   from a local interface.  Such a
   candidate is called a HOST CANDIDATE.  The local interface could be
   ethernet or WiFi,
   or it could be one that is obtained through a tunnel mechanism, such
   as a Virtual Private Network (VPN) or Mobile IP (MIP).  In all cases,
   these appear to the agent as a local interface from which ports (and
   thus a candidate) can be allocated.

- reworded text
   If an agent is multihomed, it can obtain a candidate from each
   interface.  Depending on the location of the peer on the IP network
   relative to the agent, the agent may be reachable by the peer through
   one or more of those interfaces.  Consider, for example,
   an agent which has a local interface to a private net 10 network (I1),
and
   a second connected to the public Internet (I2).  A candidate from I1
   will be directly reachable when communicating with a peer on the same
   private net 10 network, while a candidate from I2
   will be directly reachable when communicating with a peer on the
   public Internet.  Rather than trying to guess which interface will
   work prior to sending an offer, the offering agent includes both
   candidates in its offer.

- reworded text
   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 discovered using STUN.

- punctuation
   To find a server reflexive candidate, the agent sends a STUN Binding
   Request, using the Binding Discovery Usage [11] from each host
   candidate, to its STUN server.  It is assumed that the address of
   the STUN server is configured, or learned in some way.  When the
   agent sends the Binding Request, the NAT (assuming there is one) will
   allocate a binding, mapping this server reflexive candidate to the
   host candidate.  Outgoing packets sent from the host candidate will

- removed text
Note
   "Base" refers to the address you'd send from for a particular
   candidate.

- not sure this paragraph is needed since RELAYED candidate is defined in
the previous paragraph. I think it doesn't help the reader.
   Traffic from L to R has its addresses rewritten twice: first by the
   NAT and second by the STUN relay server.  Thus, the address that R
   knows about and the one that it wants to send to is the one on the
   STUN relay server.  This address is the final kind of candidate,
   which we call a RELAYED CANDIDATE.

- removed he
   As an optimization, as soon as R gets L's check message R
   immediately sends a check message to L on the same candidate
   pair.  This accelerates the process of finding a valid candidate.

2.4.  Frozen Candidates
- reworded
   The previous description only addresses the case where the agents
   wish to establish a single media component. i.e., a single flow with
   a single host-port quartet.  Typically, ( e.g. with RTP and RTCP)
   the agents need to establish connectivity for more than one flow.

- removed and reworded text
   The network properties are likely to be
   very similar for each component (especially because RTP and RTCP are
   typically run on adjacent ports).  It is usually possible to
   leverage information from one media component in order to determine
   the best candidates for another.  ICE does this with a mechanism
   called "frozen candidates."

- removed text
   Initially, only
   the candidates for a single media component are tested.  The other
   media components are marked "frozen".  When the connectivity checks
   for the first component succeed, the corresponding candidates for the
   other components are unfrozen and checked immediately.  This avoids
   repeated checking of components which are superficially more
   attractive but in fact are likely to fail.

4.  Choosing a Mode
- reworded from negative to positive. more readable.
   The first step in ICE processing is selection of a mode.  An ICE
   agent can operate in either full mode or passive-only mode.  An agent
   MAY only act in passive-only mode if the following are all true:

5.  Sending the Initial Offer
- fixed spelling mistake
   In order to send the initial offer in an offer/answer exchange, an
   agent must gather candidates, prioritize them, choose candidates for
   inclusion in the m/c-line, and then formulate and send the SDP.  Each
   of these steps is described in the subsections below.

5.1 Gathering Candidates
- changed amount to number
   The value of Ta SHOULD be configurable, and SHOULD have a default of
   20ms.  Note that this pacing applies only to starting STUN
   transactions with source and destination transport addresses ( i.e.,
   the host candidate and STUN server respectively) for which a STUN
   transaction has not previously been sent.  Consequently,
   retransmissions of a STUN request are governed entirely by the
   retransmission rules defined in [11].  Similarly, retries of a
   request due to recoverable errors (such as an authentication
   challenge) happen immediately and are not paced by timer Ta.  Because
   of this pacing, it will take a certain amount of time to obtain all
   of the server reflexive and relayed candidates.  Implementations
   should be aware of the time required to do this, and if the
   application requires a time budget, limit the number of candidates
   which are gathered.

- minor tweaks
   An Allocate Response will provide the client with a server reflexive
   candidate (obtained from the mapped address) and a relayed candidate
   in the RELAY-ADDRESS attribute.  A Binding Response will provide the
   client 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.  A server
   reflexive candidate obtained from an Allocate response is called
   the "translation" of the relayed candidate obtained from the same
   response.  The agent will need to remember the translation for the
   relayed candidate, since it is placed into the SDP.  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 each base being unique.

5.2.  Prioritizing Candidates

- reworded
   One criteria for selection of the type and local preference values is
   the use of an intermediary.  With an intermediary, if media is sent to
that
   candidate, it will first transit an intermediate server before
   being received.  Relayed candidates are one type of
   candidate that involves an intermediary.  Another are host candidates
   obtained from a VPN interface.  When media is transited through an
   intermediary, it can increase the latency and/or packet loss and/or cost.

5.3.  Choosing In-Use Candidates
- that to those
   It is RECOMMENDED that in-use candidates be chosen based on the
   likelihood of those candidates to work with the peer that is being
   contacted.  Unfortunately, it is difficult to ascertain which
   candidates those might be.  As an example, consider a user within an
   enterprise.  To reach non-ICE capable agents within the enterprise,
   host candidates have to be used, since the enterprise policies may
   prevent communication between elements using a relay on the public
   network.  However, when communicating to peers outside of the
   enterprise, relayed candidates from a publically accessible STUN
   server are needed.

5.4.  Encoding the SDP
- why not use H, S, P, R for "host", "srflx", "prflx", and "relay"
respectively? This would save bytes and up the chance that this will work
when MTU issues.
- I also felt that a simple example of what these would look like might be
helpful here - even if there is a more detailed and full example later on.

6.3.  Gathering Candidates

- simplified wording
   The process for gathering candidates at the answerer is identical to
   the process for the offerer as described in Section 5.1.  It is
   RECOMMENDED that this process begin immediately on receipt of the
   offer, prior to user acceptance of a session.  Such gathering MAY
   begin when an agent starts.

6.7.  Forming the Check Lists
- removed text
   A full-mode agent MUST form the check lists as described in this
   section.

- suggest renaming O-P to be OP or O, A-P to AP or A - will make it more
readable. e.g.

   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)

- would a state transition diagram help for the check list state?

6.8.  Performing Periodic Checks

   An agent performs two types of checks.
   Periodic checks occur periodically for each media stream, and
   involve choosing the highest priority check in the Waiting state from
   each check list, and performing it.  Triggered checks are performed on
   receipt of a connectivity check from the peer.  Full mode agents MUST
   generate periodic checks, and all agents MUST generate triggered
   checks.  This section describes how periodic checks are performed,
   and thus applies only to full mode agents.

8.1.1.  Sending the Request
- removed some text.
   The Binding Request by an agent MUST include the USERNAME and
   MESSAGE-INTEGRITY attributes.  That is, an agent MUST NOT wait to be
   challenged for short term credentials.  Rather, it MUST provide them
   in the Binding Request.

Appendix A.  Passive-Only ICE
- fixed typo "intervending"
- fixed "it gateway" to "the gateway"

   First, doing so greatly facilitates NAT traversal for clients that
   connect to it.  Consider a PC softphone behind a NAT whose mapping
   policy is address and port dependent.  The softphone initiates a call
   through a gateway that implements ICE.  The gateway doesn't obtain
   any server reflexive or relayed candidates, but it implements ICE,
   and consequently, is prepared to receive STUN connectivity checks on
   its host candidates.  The softphone will send a STUN connectivity
   check to the gateway, which passes through the intervening NAT.
   This causes the NAT to allocate a new binding for the softphone.  The
   connectivity is received by the gateway, and will cause the gateway to
   send a check back to the softphone, at this newly created candidate.
   A successful response confirms that this candidate is usable, and the
   gateway can send media immediately to the softphone.  This allows
   direct media transmission between the gateway and softphone, without
   the need for relays, even though the softphone was behind a 'bad'
   NAT.
_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic