Subject: Re: [MMUSIC] some comments on ice-12, part one

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 03 Mar 2007 14:31:06 -0500

Thanks for the comments, and as with Jason's and ekrs, sorry for the 
long delay in responding.

inline.

Jean-Francois Mule wrote:

>    Here are some comments on draft ice-12 for consideration.
> 
> Most of these are editorial, to help improve the clarity and
> 
> readability of the document.
> 
>  
> 
> Jean-Francois.
> 
>  
> 
> *--- general comments*
> 
>  - intended status of the RFC = Standard Track: should it appear on
> 
>    page 1?

added.

> 
>  - note that the new ID boilerplate may be effective when you
> 
>    release the next draft

yup

> 
>  - consider putting a descriptive label for the figure captions

done.

> 
>  - applicability of ICE beyond SDP offer/answer:
> 
>    would it be worthwhile in the document to indicate somewhere what
> 
>    is required for ICE to work in more general terms?
> 
>    that is, describe the properties of any protocol that can make use
> 
>    of ICE: two-phase exchange protocol like SDP offer/answer,
> 
>    syntax & semantics for the ICE grammar (username fragment, pword,
> 
>    candidate, etc.), assumption about a signaling protocol mechanism
> 
>    that does have a mechanism to traverse NAT like outbound, STUN
> 
>    usage...

Perhaps elsewhere, but not here.

This is text that would not be needed for developers implementing ICE; 
it would be for spec writers like us that wanted to write more specs. 
One of the reasons why ICE got so bloated is that there was a lot of 
this kind of text in ICE, and I worked hard to remove it, so that ICE 
was written for its audience - implementors.

> 
>  - need to address the "m/c line" langage. As previously note:
> 
>    clarify the use of "m/c-line" and may be expand it as you may have
> 
>    multiple c lines, one for the session level, one for each media
> 
>    description. This applies at several places in the document. It may
> 
>    help to clarify the definition of "in-use" in section 5.3 to say
> 
>    something like:
> 
>    A candidate is defined as an "in-use" candidate in a media
> 
>    description if its IP address appears in the associated c line and
> 
>    its port in the related m line...
> 

Yes, I have now fixed this. I think its MUCH better now. "m/c-line" is 
now gone as a terminology. ICE speaks of default destinations for media, 
which is the place media would go if the peer didn't speak ICE. THis 
would be the m and c lines for RTP, but the a=rtcp attribute for rtcp. A 
candidate is called the default candidate if it matches the default 
destination for media. So now, instead of "Setting the m/c-lines" in the 
SDP, the process is called "selecting the default candidates".

This term is a much better match for what the m/c-line now signifies for 
ICE - which is nothing. It is not used at all really, and has a role 
only for non-ICE components. Thats what makes it 'default' - the thing 
you use when ICE isnt around.

>  
> 
>  
> 
>  
> 
> *--- Abstract*
> 
>  - the first sentence of the abstract may be read as "ICE is for nat
> 
>    traversal of signaling protocols": it does not seem to capture
> 
>    that ICE is designed for the NAT traversal of *media streams*.
> 

good point. In fact its quite misleading. Now says:

             <t>This document describes a protocol for Network
             Address Translator (NAT) traversal for multimedia sessions
             established with the offer/answer model. This
	    protocol is called Interactive
             Connectivity Establishment (ICE). ICE makes use of the
             Session Traversal Utilities for NAT (STUN) protocol, 
applying its
             binding discovery and relay usages, in addition to
	    defining a new usage for checking connectivity between
	    peers. ICE can be used by any protocol utilizing the
	    offer/answer model, such as the Session Initiation
	    Protocol (SIP).</t>

>  
> 
>    Consider adding some text, something like this:
> 
>  | This document describes a protocol for Network Address Translator
> 
>  | (NAT) traversal for multimedia session signaling protocols based
> 
>  |                ^ of media streams established with ...
> 
>  | on the offer/answer model, such as the Session Initiation Protocol
> 
>  

right

> 
>  
> 
> *--- Table of Contents*
> 
> This may be nit picking but for consistency of the ToC, consider
> 
> these comments:
> 
>  
> 
>  -
> 
> < 4.  Choosing a Mode  . . . . . . . . . . . . . . . . . . . . . . . 15
> 
>                  ^^^^
> 
> qualify "Mode" as the mode related to the ICE full/passive role, not
> 
> recvonly/sendrecv modes of SDP, for e.g.
> 
>> 4.  Choosing an ICE Mode  .  . . . . . . . . . . . . . . . . . . . 15
> 
>   or  Choosing between full and passive modes for ICE.
> 
> Note that this comment may apply in other places and finding another
> 
> term (role?) may help folks who tend to use this term in the SDP
> 
> context and may help when discussing some of the use cases for
> 
> ICE keepalive when no media is sent due to the SDP mode.

this was fixed anyway with the concept of a lite implementation

> 
>  
> 
>  - nit
> 
> < 8.  Connectivity Checks  . . . . . . . . . . . . . . . . . . . . . 27
> 
>      ^ add a verb
> 
>> 8.  Performing Connectivity Checks  . . . . . . . . . . . . . .  . 27
> 
>  
> 
>  - nit
> 
> < 9.  Concluding ICE . . . . . . . . . . . . . . . . . . . . . . . . 32
> 
>                      ^ noun
> 
>> 9.  Concluding ICE operations. . . . . . . . . . . . . . . . . . . 32
> 
>                    or process (you use process in section 2)?
> 
>  
> 
> *--- Introduction*
> 
>  
> 
> The intro spends more time describing the motivations for ICE
> 
> than saying what ICE is. This may be fine given the overview
> 
> section that follows but it might be helpful to state upfront more
> 
> clearly what ICE is about.
> 
> Consider moving the last paragraph of the intro up. This way folks
> 
> who want to skip the justifications for ICE can jump to the next
> 
> section.

Not sure I agree. THis section is just a few paragraphs. Generally, I 
think any document needs to start with "here is the problem" and then a 
brief summary of what the solution is. That is exactly what we have 
here, and this pattern exists in nearly every document I've written.

> 
>  
> 
>  - paragraph 2:
> 
>  | Protocols using offer/answer are difficult to operate through
> 
>  | Network Address Translators (NAT).  Because their purpose is to
> 
>  | establish a flow of media packets, they tend to carry IP addresses
> 
>                                                          ^^^^^^^^^^^^
> 
>  | within their messages, which is known to be problematic through
> 
>  | NAT [14].
> 
>    s/IP addresses/the IP addresses of media sources and sinks
> 
>    (this is again to clarify which IP adds matter to ICE)
> 
>  

ok

> 
>  - paragraph 4:
> 
>  | This specification provides that solution for media streams
> 
>  | established by signaling protocols based on the offer-answer model.
> 
>  | It is called Interactive Connectivity Establishment, or ICE.  ICE
> 
>  | makes use of STUN and its relay extension, commonly called TURN, but
> 
>  | uses them in a specific methodology which avoids many of the pitfalls
> 
>  | of using any one alone.
> 
>  
> 
> Whether or not you decide to move this paragraph up, it should
> 
> introduce more clearly *what* ICE is. The current text refers to
> 
> "that solution" which vaguely refers to something in the paragraph
> 
> above. It says *how* ICE partially works (usage of STUN, TURN) and
> 
> hints at a methodology but it stops short of saying what it is about.
> 
> Consider adding some text summarizing the steps of that ICE
> 
> methodology to give the reader a feel for what it is.
> 
> For example, ICE provides a methodology for discovering,
> 
> signaling and checking the various addresses that agents/devices
> 
> behind NATs may use for media streams. It also defines the means for
> 
> agents involved in an offer/answer exchange to signal the discovered
> 
> candidate addresses and specifies a deterministic mechanism to check
> 
> that, if selected, the pairs of candidate addresses will allow media
> 
> streams send from/to those address to traverse NATs. Then refer to
> 
> the overview for the details.
> 
> This is not well-worded but this is what I was expecting in intro.

OK, fair point on this paragraph. Here's what I put in:

<t> This specification defines Interactive Connectivity Establishment
(ICE) as a technique for NAT traversal for media streams established
by the offer/answer model. ICE is an extension to the offer/answer
model, and works by including a multiplicity of IP addresses and ports
in SDP offers and answers, which are then tested for connectivity by
peer-to-peer STUN exchanges. The IP addresses and ports included in
the SDP are gathered using the STUN binding acquisition
techniques in <xref target="I-D.ietf-behave-rfc3489bis"/> and relay
allocation procedures in <xref target="I-D.ietf-behave-turn"/>.
</t>

> 
>  
> 
>    - given the length of the document, should the introduction
> 
>      contain a paragraph describing the document outline and
> 
>      highlight the key sections?
> 
>      ... a detailed overview of ICE in section 2, terminology
> 
>      and definitions in section 3, etc.

I sometimes do that for shorter documents, but for longer documents the 
ToC does a much better job.

> 
>  
> 
>  
> 
> *--- Section 2, Overview of ICE*
> 
>  
> 
>  - nit
> 
>  | in RFC 3264 terminology) which want to communicate.  They are able
> 
>  | to communicate indirectly via some signaling system such as SIP, by
> 
>                                                 ^^^^^^         ^^^
> 
>   s/system/protocol or else s/SIP/SIP server; given the need for
> 
>   outbound, both seem equivalent.
> 
>  

s/system/protocol

> 
>  - nit
> 
>  | assumed to be provided via some other mechanism [31].  At the
> 
>                               ^^^^^^^^^^
> 
>  s/some other/another, or, s/mechanism/mechanisms
> 
>  

s/some other/another

> 
>  - nit
> 
>  | (or multiple tiers of NATs).  ICE allows the agents to discover
> 
>  | enough information about their topologies to find a path or paths
> 
>                                                 ^^^^^^^^^^^^^^^^^^^^
> 
>  | by which they can communicate.
> 
>  s/find a path or paths/potentially find one or more path(s)
> 
>  ("potentially" is suggested to cover for the rare cases where ICE
> 
>   stops and no path may be found).

ok

> 
>  
> 
>  - nit
> 
>   consider replacing
> 
> < visualize call flows).  Both L and R are behind NATs -- though as
> 
> < mentioned before, they don't know that.  The type of NAT and its
> 
>   with
> 
>> visualize call flows).  Both L and R are behind NATs though they
> 
>> may not be aware of it.  The type of NAT and its

ok

> 
>  
> 
>  - consider rewording this:
> 
>  | These might include:
> 
>  |
> 
>  |  o  It's directly attached network interface (or interfaces in the
> 
>  |      case of a multihomed machine
> 
>  |
> 
>  |   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.
> 
>  
> 
> into something like:
> 
>   These might include:
> 
>  
> 
>    o  candidate addresses derived from the agent's attached
> 
>       network interface(s) (agents running on multihomed hosts may
> 
>       have multiple interfaces),
> 
>  
> 
>    o  a translated transport address on the public side of a NAT,
> 
>  
> 
>    o  The transport address of a media relay the agent is using.
> 
>  
> 
> notes: a network interface address offer refers to the IP only, hence
> 
> the use of "derived from" and the suggestion to add "transport" in
> 
> front of address. Also, if you decide to keep the terms
> 
> like "server reflexive" in this list, consider doing it for all the
> 
> bullet points (but you do that later).

ok, done

> 
>  
> 
>  - consider rewording this:
> 
> < For instance, if L and R are both behind NATs then their
> 
> < directly interface addresses are unlikely to be able to
> 
> < communicate directly (this is why ICE is needed, after all!).
> 
>  
> 
> into something like:
> 
>> For instance, if L and R are both behind NATs, the candidate
> 
>> addresses associated with their directly attached network
> 
>> interface are unlikely to be able to communicate directly (this is
> 
>> why ICE is needed).

Jason F. suggested similar text though not quite the same. But its been 
fixed.

> 
>  
> 
>  - section 2.1:
> 
>    In the first sentence, consider making it clear and even
> 
>    repeating it later that a candidate address is a *transport*
> 
>    address (a combination of IP and port).
> 
>  
> 
>    e.g., in paragraph 1, suggested new txt:
> 
>    In order to execute ICE, an agent must identify all of its address
> 
>    candidates. A candidate is a transport address, a combination of
> 
>    an IP address and port. This document defines three types of
> 
>    candidates, some derived from physical or logical network
> 
>    interfaces, others discoverable via STUN.
> 
>    Naturally, a viable candidate address is one for which the
> 
>    candidate IP address is obtained directly from a local interface
> 
>    the client has towards the network, and the candidate port where
> 
>    the client expects to receive media. [snip]

fixed

> 
>  
> 
>  - nit:
> 
>   consider rewording this:
> 
> < 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.
> 
>         ^^^^^^^^^^^^^^^^^^^^^^                   ^
> 
> into something like:
> 
>> as a Virtual Private Network (VPN) or Mobile IP (MIP).  In all
> 
>> cases, such a network interface appears to the agent as a local
> 
>> interface from which the OS networking API allows a port to be
> 
>> allocated to create a transport address as a host candidate.
> 
>  

ok

> 
>  - section 2.1, paragraph 2:
> 
>  | If an agent is multihomed, it can obtain a candidate from each
> 
>  | interface.
> 
>  s/can/should
> 
>  (even if this entire overview is informative in nature, i'd recommend
> 
>   changing all instances of "can" into lowercase "should"'s/"may"'s)

"obtains" is fine here. I stay aware from normative text in intros.

> 
>  
> 
>  - section 2.1, paragraph 3, figure 2:
> 
>  
> 
> As done in draft-ietf-behave-nat-udp-08, it may help the reader to
> 
> add the (IP add, port) tuples in the diagram in order to visualise
> 
> that the other 2 candidate types are derived from each host
> 
> candidate. E.g. X:x for host candidate, X1':x1' for server reflexive,
> 
> etc. and pointing to those in the paragraph following the figure:
> 
>  
> 
>> When the agent sends the Binding Request from a host candidate,
> 
>> the NAT will allocate a binding, mapping a server reflexive
> 
>> candidate (X1':x1') to the host candidate (X:x).
> 
>  

done

> 
>   - section 2.1, page 9, Note:
> 
> | Note
> 
> | "Base" refers to the address you'd send from for a particular
> 
> | candidate.  Thus, as a degenerate case host candidates also have a
> 
> | base, but it's the same as the host candidate.
> 
>  
> 
>   s/you'd/an agent
> 
>   s/degenerate/degenerated?
> 

de·gen·er·ate       (dĭ-jěn'ər-ĭt)  Pronunciation Key
adj.

    1. Having declined, as in function or nature, from a former or 
original state: a degenerate form of an ancient folk art.

-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

---

From: Philip Matthews <[email-masked]>
Date: Wed, 14 Mar 2007 18:58:39 -0400

>>  | on the offer/answer model, such as the Session Initiation Protocol

The only problem with this proposal is that P2PSIP is now considering
using ICE to signal control connections -- what P2PSIP is currently
calling Peer Protocol Connections.  See, for example:
             draft-matthews-p2psip-bootstrap-mechanisms       and
             draft-matthews-p2psip-dsip-nat-traversal
The latter document uses SIP with ICE to signal new SIP connections.

I think ICE should be described as a protocol for setting up  
transport connections through
NATs using the Offer/Answer model. The connections can be TCP, UDP,
or some other transport protocol. What protocol runs over these  
transport connections
is immaterial to ICE.
For clarity, it could be mentioned that a one example is multimedia  
sessions signaled
using SIP.

- Philip