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

From: "Jean-Francois Mule" <[email-masked]>
Date: Tue, 14 Nov 2006 07:59:16 -0700

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?
 - note that the new ID boilerplate may be effective when you
   release the next draft
 - consider putting a descriptive label for the figure captions
 - 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...
 - 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...

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

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

--- 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.
 
 - nit
 | assumed to be provided via some other mechanism [31].  At the
                              ^^^^^^^^^^
 s/some other/another, or, s/mechanism/mechanisms
 
 - 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).
 
 - 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
 
 - 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).
 
 - 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).
 
 - 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]
 
 - 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.
 
 - 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)
 
 - 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).
 
  - 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?
_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 14 Nov 2006 09:32:11 -0700

>    that does have a mechanism to traverse NAT like outbound, STUN

I think that would be nice (though not necessary). As an example of a
non-SIP signalling protocol that can use ICE, consider XMPP and the
Jingle extensions we are working on. The ICE semantics can be delivered
over the XMPP signalling channel, resulting (we hope) in the same
outcome: successful NAT traversal. We've been specifying ICE semantics
in XMPP syntax here:

http://www.xmpp.org/extensions/xep-0176.html

Peter

-- 
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 14 Nov 2006 11:36:56 -0800

Peter Saint-Andre [mailto:[email-masked]] wrote;

> http://www.xmpp.org/extensions/xep-0176.html

It is anticipated that BEHAVE's "application" milestone will describe how
ICE's techniques can be used by non-SDP applications.  As of now,
draft-ford-behave-app-04.txt is the most likely candidate document to meet
BEHAVE's "application" milestone, but it hasn't yet been adopted as a
working group document.

-d