Duplication Grouping Semantics in the Session Description Protocol
draft-ietf-mmusic-duplication-grouping-04
Yes
(Gonzalo Camarillo)
(Richard Barnes)
No Objection
(Brian Haberman)
(Jari Arkko)
(Martin Stiemerling)
(Sean Turner)
(Spencer Dawkins)
(Stephen Farrell)
(Stewart Bryant)
(Ted Lemon)
Note: This ballot was opened for revision 03 and is now closed.
Gonzalo Camarillo Former IESG member
Yes
Yes
(for -03)
Unknown
Richard Barnes Former IESG member
(was Discuss)
Yes
Yes
(for -03)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(2013-11-15 for -03)
Unknown
-- 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"?
Benoît Claise Former IESG member
No Objection
No Objection
(2013-11-19 for -03)
Unknown
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.
Brian Haberman Former IESG member
No Objection
No Objection
(for -03)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -03)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -03)
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
(2013-11-20 for -03)
Unknown
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?
Sean Turner Former IESG member
No Objection
No Objection
(for -03)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -03)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(for -03)
Unknown
Stewart Bryant Former IESG member
No Objection
No Objection
(for -03)
Unknown
Ted Lemon Former IESG member
No Objection
No Objection
(for -03)
Unknown