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

[Flemming Andreasen <[e-mail]>]

On 1/8/13 4:59 AM, [e-mail] wrote:
> Dear Flemming,
>
> Thank you for the review.
>
> Please see inline.
>
> Cheers,
> Med
>
>> -----Message d'origine-----
>> De : [e-mail] [mailto:[e-mail]]
>> De la part de Flemming Andreasen
>> Envoyé : mardi 8 janvier 2013 04:24
>> À : [e-mail]
>> Cc : mmusic; Gonzalo Camarillo
>> Objet : [MMUSIC] SDP Directorate: Review of
>> draft-boucadair-mmusic-altc-07
>>
>> 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.
> 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.
I'd suggest adding "If connectivity checks are required, ICE (RFC 5245) 
provides such a solution".

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

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

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

>> 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)
> Med: OK. I updated the text.
Ok
>> 6) Section 4.1, attribute definition
>> The optional trailing integer part is not defined.
> Med: Thanks for catching this. I updated section 4.1.
Ok.
>> 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.
> 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.
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).

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

>>
>> 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"
> Med: I implemented all the proposed changed. Thanks.
Ok - thanks

-- Flemming


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