Duplication Grouping Semantics in the Session Description Protocol
draft-ietf-mmusic-duplication-grouping-04

-- Section 3.3 --

   (1) with an answer that ignores the grouping attribute or (2) with a
   refusal to the request (e.g., 488 Not Acceptable Here or 606 Not
   Acceptable in SIP).

SIP?  Or should that be "SDP"?

In his OPS-DIR review, Fred summarizes pretty well the operational impacts stemmed from this specification.
I would be worth the extra couple of paragraphs IMHO. A new section "operational impact" would be ideal.
For completeness, Fred's review is included below:

The operational impacts of the duplication mechanism (which is in use operationally, if I'm not mistaken) are three-fold:
 - impact on total traffic load
 - impact on routing
 - impact on receiving system

The impact on traffic load is obvious: if I duplicate every packet among a set of packets, I double its total traffic load. 

The impact on routing is somewhat glossed over by the document, although it is hinted at in comments about using different addresses and so preferring different routes in at least parts of the path. Sending separate packet streams that use the same route subjects all of the traffic streams to the same set of potential failures; if a packet from stream 1 is subject to loss at a congested interface or a place where routing is unstable, so will its counterpart in stream 2. If a given interface en route is heavily loaded, doubling a component of its service load won't reduce that. An important characteristic of these separate streams, therefore, is disjoint routing, and ideally routing along paths unlikely to experience simultaneous failures (e.g., using different lambdas in the same fiber doesn't help if the fiber is cut).

The impact on the receiving system is that something one might consider architecturally unusual, such as duplication or reordering of packets and the implied processing, suddenly becomes normal. Duplication is obvious. Reordering would happen when traffic on one stream consistently arrives earlier than that another, and a packet is lost on the first. The arriving packet on the second stream will be perceived as a packet out of order. One can hopefully expect RTP's application to recognize the matter and resolve it, but it would be nice if that could happen as early in packet processing as possible. So one has an increased interrupt and processing load on the receiving system, and the algorithms used to deal with duplicated or reordered traffic may need tuning.

I don't know that I would request any changes to the document. If I did, it would be to highlight these issues and point to other RFCs or operational procedures that could be used to mitigate them.

3.1:


   The "a=group:DUP" semantics MUST be used to group the redundant
   streams except when the streams are specified in the same media
   description, i.e., in the same "m" line (See Section 3.2).

Don't you mean "is" instead of "MUST be"? I don't understand what the MUST means in this context other than "is".

3.1 & 3.2:

   ...the order of the listed redundant streams does
   not strictly indicate the order of transmission, although it is
   RECOMMENDED that the stream listed first is sent first, with the
   other stream(s) being the (time-delayed) duplicate(s).

Is there any downside to doing them out of order (or any upside to doing them in order)? If yes, why isn't it a MUST? If no, why the RECOMMENDation?