Subject: [MMUSIC] SDP Directorate: Review of draft-boucadair-mmusic-altc-07

From: Flemming Andreasen <[email-masked]>
Date: Mon, 07 Jan 2013 22:23:49 -0500

Hi

I am the assigned SDP directorate reviewer for 
draft-boucadair-mmusic-altc-07

For background on the SDP directorate, please see the FAQ at

     http://www.ietf.org/iesg/directorate/sdp.html

Please wait for direction from your document shepherd or AD before 
posting a new version of the draft.

Summary:
---------
- The document does not adequately cover how it relates to the existing 
Standards Track mechanism for solving the similar problem in a different 
and more general way (namely ICE [RFC 5245])
- The document has technical issues
- The document has a few minor editorial issues

New SDP Information Elements:
---------------------------
The draft defines a new "a=altc" attribute

Technical Comments:
------------------
1) The Abstract positions the document as an alternative to ANAT, but 
without certain problems experienced by ANAT. The abstract fails to 
mention that a general Standards Track solution in the form of ICE (RFC 
5245) has been defined whereas the solution defined in this document has 
a narrower scope and various limitations.

2) Section 1.1, third paragraph. The document states that ICE is 
processing intensive and has seen limited deployment. While this is 
perhaps a matter of debate, it would be helpful if the document would 
point out the limitations of using instead of ICE. Areas that come to 
mind here are
- lack of NAT traversal (without network/SBC support),
- no connectivity verification (verifying functioning path as well as 
authenticating/correlating initial incoming media packets with signaling),
- support for non-contiguous RTP/RTCP port pairs in alternatives
There are probably others and it would be helpful to point those out to 
potential implementers (the simplicity comes with trade-offs).

3) Section 1.1, third paragraph: The document claims that ICE is not 
usable in closed networks. This is incorrect (it is however correct that 
there are scenarios where ICE does not work, however those scenarios 
should then be explained instead).

4) Section 1.1, fourth paragraph: The document claims to be compliant 
with RFC 6157 because RFC 6157 includes the sentence
<quote>
The use of ICE can be avoided for signaling messages that stay within 
such managed networks
</quote>
The quote is taken out of context however as it applies to a scenario in 
RFC 6157 where the entire network is IPv6 based, whereas the mechanism 
defined here is for scenarios where it is not.

5) Section 3.2, first paragraph
<quote>
A compliant SDP parser will ignore any session description that contains 
attribute lines it does not support.
<quote>
No - only the unsupported attribute lines will be ignored (which is also 
what the rest of the draft implies)

6) Section 4.1, attribute definition
The optional trailing integer part is not defined.

7) Section 4.1, Bullet list, "port"
This does not seem to work with the "a=rtcp" attribute [RFC 4566], and 
hence there may be issues with non-contiguous RTP/RTCP port pair support 
in alternatives.

8) Section 4.1, 4th last paragraph
The mechanism relies on implicit ordering of attribute lines. If an 
intermediary changes the order, it would have unintended side-effects. 
It would be much better to have an explicit ordering mechanism. In the 
absence of that, the potential reordering issue should be called out.

Editorial Comments:
-----------------
1) Section 1.1, second paragraph. Add reference after "DS-Lite"

2) sdp-cap-neg should be SDPCapNeg (multiple occurrences)

3) Section 1.3, first paragraph: Add reference to RFC 4091.

4) Section 1.3, second paragraph: Add text and reference to RFC 6157 for 
a solution to "SIP layer address family interworking"

5) Section 4.2.3
Add RFC reference after "ICE"

6) Section 4.2.4
Add RFC reference after "SDPCapNeg"

Thanks

-- Flemming

---

From: <[email-masked]>
Date: Tue, 8 Jan 2013 10:59:15 +0100

Dear Flemming,

Thank you for the review. 

Please see inline. 

Cheers,
Med 

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] 
>De la part de Flemming Andreasen
>Envoyé : mardi 8 janvier 2013 04:24
>À : [email-masked]
>Cc : mmusic; Gonzalo Camarillo
>Objet : [MMUSIC] SDP Directorate: Review of 

Med: I updated the abstract as follows: 

OLD:

   This document proposes a mechanism which allows to carry multiple IP
   addresses, of different address families (e.g., IPv4, IPv6), in the
   same SDP offer.  The proposed attribute solves the backward
   compatibility problem which plagued ANAT, due to its syntax.

NEW:

   This document proposes a mechanism which allows to carry multiple IP
   addresses, of different address families (e.g., IPv4, IPv6), in the
   same SDP offer.  The proposed attribute solves the backward
   compatibility problem which plagued ANAT, due to its syntax.

   The proposed solution is applicable to scenarios where connectivity
   checks are not required.

>potential implementers (the simplicity comes with trade-offs).

Med: The scope of ALTC is very clear: scenarios where there is no need for connectivity checks. This is already mentioned in Section 2 and I tried to make it clear in the new proposed abstract text.  

>should then be explained instead).

Med: closed networks are provided only as an example. Anyway, I updated the text as follows: 

OLD:

(e.g., closed networks)

NEW:

(e.g., closed networks making use of SBCs)

>defined here is for scenarios where it is not.

Med: The text from RFC6157 is:

      Implementations are encouraged to use ICE; however, the normative
      strength of the text above is left at a SHOULD since in some
      managed networks (such as a closed enterprise network) it is
      possible for the administrator to have control over the IP version
      utilized in all nodes and thus deploy an IPv6-only network, for
      example.  The use of ICE can be avoided for signaling messages
      that stay within such managed networks.

IPv6-only is mentioned as an example. The key word IMHO in the above text is "managed networks". 

>what the rest of the draft implies)

Med: OK. I updated the text.

>The optional trailing integer part is not defined.

Med: Thanks for catching this. I updated section 4.1.

>hence there may be issues with non-contiguous RTP/RTCP port 

Med: We updated the text as follows:

OLD:

   Note that for RTCP, if applicable for the given media types, each
   side would act as if the chosen "altc" attribute's port number was in
   the 'm=' media line.  Typically, this would mean RTCP is sent to the
   odd +1 of the port number, unless some other attribute determines
   otherwise.

NEW:

   Note that for RTCP, if applicable for the given media types, each
   side would act as if the chosen "altc" attribute's port number was in
   the 'm=' media line.  Typically, this would mean RTCP is sent to the
   odd +1 of the port number, unless some other attribute determines
   otherwise.

   For example the RTP/RTCP multiplexing mechanism defined in [RFC5761]
   can still be used with ALTC, such that if both sides support
   multiplexing they will indicate so using the 'a=rtcp-mux' attribute
   as defined in [RFC5761]; but the IP connection address and port they
   use may be chosen using the ALTC mechanism.

   If the SDP offerer wishes to use the RTCP attribute defined in
   [RFC3605], a complication can arise since it may not be clear which
   address choice the 'a=rtcp' attribute applies to, relative the
   choices offered by ALTC.  Technically RFC 3605 allows indicating the
   address for RTCP explicitly in the 'a=rtcp' attribute itself, but
   this is optional and rarely used.  Since RFC 3605 did not prevent
   encoding multiple 'a=rtcp' attributes per media description, this
   document recommends encoding the first 'a=rtcp' attribute to be for
   the address choice encoded in the "m=" line, and a second 'a=rtcp'
   attribute for the alternate address provided by the 'a=altc'
   attribute.  In other words, if the 'a=rtcp' attribute explicitly
   encodes an address in its attribute, then that applies for ALTC as
   per [RFC3605]; if it does not, then ALTC assumes the first one is for
   the address in the "m=" line, and the second is for the alternate.

>absence of that, the potential reordering issue should be called out.

Med: Is this harmful? If an intermediary entity change the order, this does not impact the session establishment. Note the document already specify how a remote UA can detect the presence of an intermediary entity changing the "c" line is present in the path. 

>Editorial Comments:

Med: I implemented all the proposed changed. Thanks. 

>
>
>Thanks
>
>-- Flemming
>
>_______________________________________________
>mmusic mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 08 Jan 2013 16:44:24 -0500

>     The proposed solution is applicable to scenarios where connectivity
I'd suggest adding "If connectivity checks are required, ICE (RFC 5245) 
provides such a solution".

> Med: The scope of ALTC is very clear: scenarios where there is no need for connectivity checks. This is already mentioned in Section 2 and I tried to make it clear in the new proposed abstract text.

I don't think it will be obvious to people looking at the document what 
the trade-offs with the Standards Track solution (ICE) are, and hence I 
think it's advisable to call them out explicitly so people can make an 
informed decision as to which solution they want to use.

> (e.g., closed networks making use of SBCs)
The statement is still not entirely correct (the SBC can for example 
support ICE or it could be doing signaling processing only).

My understanding of where ICE does not work is in a scenario where an 
intermediay (proxy, SBC, or whatever) inserts a media relay of some sort 
in the m= line without updating/supporting ICE as part of that. This 
will lead to ice-mismatch (detected by ICE by design) and hence 
abandoning the ICE procedures.
a) Is this the scenario you were thinking of, and/or are there others ?
b) How does altc work and/or work better in that case (compared to ICE) ?
c) Whether using ICE or altc in the above scenario, you still have an 
issue with NAT traversal that may require some form of latching to work 
(or do you see altc somehow avoiding this ?)

The above should be clarified (or the overly broad statement should be 
removed instead).

> IPv6-only is mentioned as an example. The key word IMHO in the above text is "managed networks".
I think the key in the above is

"it is possible for the administrator to have control over the IP 
version utilized in all nodes"

and thus you know it's safe to use only one particular IP version and 
hence can avoid using ICE to actually pick a version that works. In any 
case, I don't think this reference to RFC 6157 compliance is critical 
for this document and hence it may be easier to simply remove it.

> Med: OK. I updated the text.
Ok
> Med: Thanks for catching this. I updated section 4.1.
Ok.
>     the address in the "m=" line, and the second is for the alternate.
I don't think this is a good idea (multiple instances with different 
values, and also ordering specific). While RFC 3605 may not explicitly 
disallow the above, it's also not part of it's overall defined 
semantics, and it's unlikely to produce interoperable implementations if 
used this way IMO.

Rather than having multiple instances with some altc-specific 
interpretation associated with those, you could extend the altc 
attribute itself to include the information. Alternatively, you could 
limit the solution to not support non-contiguous RTP/RTCP ports for 
anything but the default value provided in the m= line (then add a rule 
that a=rtcp is to be ignored if another address family is used).

> Med: Is this harmful? If an intermediary entity change the order, this does not impact the session establishment. Note the document already specify how a remote UA can detect the presence of an int…
It doesn't produce the intended operation. I thought part of the draft 
motivation was to enable a preferential selection of the address family 
in a backwards compatible manner, especially for IPv4-only peers. If the 
attributes get reordered, the preference no longer works.

Since the document is Informational, I guess it's up to you whether this 
is problematic, but if left as-is, I think you should at least point out 
this potential issue.

> Med: I implemented all the proposed changed. Thanks.
Ok - thanks

-- Flemming

>> .