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

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 03 Mar 2007 11:58:57 -0500

Yes. I know. Its been almost FOUR MONTHS since you posted these. And I 
missed them for ice-13. And I should have put them in there. <hits head 
against wall - bad Dobby - bad Dobby>

responses inline.

Jason Fischl wrote:

> General Comments:
> - The draft is in really good shape.

Thanks.

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

See ekrs document. I believe the normative stuff has to be here or else 
we are in trouble. But you do need a separate document that helps 
understand it without having to poor through all of ice.

> - I really like the new Overview of ICE

Thanks to ekr - this was mostly his text.

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

fixed

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

ok

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

ok

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

ok

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

ok

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

ok

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

ok

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

I think its important to keep the text you removed, since the concept of 
base is hard to understand.

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

right, seems redundant. removed.

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

ok

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

ok

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

ok

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

ok

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

this is all nuked in -13

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

fixed, though don't sweat spelling since i'll run a check on the final rev

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

ok

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

i can't determine the diff in here, since other edits have been made to 
this paragraph since your comment - sorry

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

I think  the additional text that is there, which explains why, is 
important. Intermediaries are bad and we want folks to understand why.

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

ok

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

the trend in SDP extensions for some time has been relatively short 
(4-5) letter things so that they are understandable and likely to be 
unique. I think the current syntax meets that goal.

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

I copied the example SDP from the later example section here.

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

ok

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

text has changed in -13

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

good suggestion, changed

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

grumble grumble... i worked hard to remove such FSMs which were there in 
revisions up to -10. ALl of the 'states' are pretty simple and I don't 
think require a diagram.

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

ok

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

ok

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

this whole bit was nuked in -13.

Thanks for your comments,
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