Duplicating RTP Streams
draft-ietf-avtext-rtp-duplication-06

   This loss might be due to congestion,
   it might also be a result of an unplanned outage caused by a flapping
   link, link or interface failure, a software bug

I just have an amusing image of Martian packets on a flapping link.  Don't mind me....

Not a DISCUSS, but I would appreciate of this one would be solved.
I believe the abstract is misleading:

   Packet loss is undesirable for real-time multimedia sessions, but can
   occur due to congestion, or other unplanned network outages.  This is
   especially true for IP multicast networks, where packet loss patterns
   can vary greatly between receivers.  One technique that can be used
   to recover from packet loss without incurring unbounded delay for all
   the receivers is to duplicate the packets and send them in separate
   redundant streams.  This document explains how Real-time Transport
   Protocol (RTP) streams can be duplicated without breaking RTP or RTP
   Control Protocol (RTCP) rules.

The abstract tells me: here is mechanism to avoid packet loss, 
which can occur due to congestion of other unplanned network outage
However, from section 7:

   First of all, RTP duplication MUST NOT be used
   in cases where the primary cause of packet loss is congestion since
   duplication can make congestion only worse. 

So this spec. only applies to "other unplanned network outage". 
This should be clear from the beginning, i.e. the abstract.

Interestingly, this is in line with my DISCUSS on draft-ietf-mmusic-delayed-duplication-02.
At least, I'm consistent with myself.


Thank for addressing Linda's and David's OPS-DIR reviews

I want to talk about this on the call on Thursday.

Like others (incl. Suresh) I am concerned about Section 7 language. It is important that the section indicates who the MUST/SHOULD requirements are placed at, and how those entities know the situation.

One interpretation is that the requirements are placed on operator (the human). In that case, maybe some language such as "The network operator MUST NOT …" should be used. 

On the other hand, if you are talking about things that devices should do, they have no knowledge of congestion, as Suresh pointed out in his Gen-ART review. In this case I'd recommend a change along the following lines:

OLD:
   Duplication is RECOMMENDED only to
   be used for protection against network outages due to a temporary
   link or network element failure and where it is known that there is
   sufficient network capacity to carry the duplicated traffic. 
NEW:
   Duplication is RECOMMENDED only to
   be used for protection against network outages due to a temporary
   link or network element failure and where it is known (e.g., through explicit
   operator configuration) that there is
   sufficient network capacity to carry the duplicated traffic.

thank you for the considerations on congestion control!

I agree with Benoit that the Abstract (and I think second paragraph of the intro) should be rewritten to indicate that this technique is only applicable to non-congestive packet loss.

In the intro, one additional sentence would have helped me. After this:

   One technique to recover from packet loss without incurring unbounded
   delay for all the receivers is to duplicate the packets and send them
   in separate redundant streams.
   
Add:

   As described later in this document, the probability that two copies
   of the same packet are lost in cases of non-congestive packet loss is
   quite small.

In fact, nowhere in the document do you actually say something along the lines of "the techniques we describe actually address the kinds of non-congestive losses we see in the field." When chatting with Richard, he suggested some text like:

   Time-delay duplication and spatial duplication deal with different
   patterns of loss.  Time-delay duplication helps with transient loss
   (within the duplication window), while spatial duplication can help
   with longer-term loss that affects only one of the two redundant
   paths.

Saying that, and saying, "Those are the kinds of losses we actually see, so these techniques will help" would be useful.

I was most worried about making sure the same security is used for the duplicate stream - that's covered so onward!

I'm supporting Benoit's Comment about being clear that the intended environment is managed/engineered networks, early in the document.

- Please see the additional security considerations text added
to [1] version -03 [2] after my discuss on that. I'm not sure
that text is prefect but isn't something similar warranted
here too? (And since we've common authors, this should be easy
enough:-) Doing that by reference is fine if that's easier.

- BTW: I thought I was reading the same document as [1] for a
while;-) 

[1] https://datatracker.ietf.org/doc/draft-ietf-mmusic-delayed-duplication/
[2] http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-delayed-duplication-03

I have a number of comments below, and an overarching concern.

The over arching concern is the assumption that using different flow
identifiers will cause the use of diverse paths, and this is by no means
assured. If you want diverse paths we should look at methods of
implementing that such as segment routing and MPLS TE.

=====

From a routing perspective, two streams are considered identical if
   the following two IP header fields are the same, since they will be
   both routed over the same path:

Not really, we look at the IP type and transport ports to determine
flow equivalence.

=====

 When two routing-plane identical streams are used, the two
       streams will have identical IP headers.  This makes it
       impractical to forward the packets onto different paths.  

Er well they could have different flow labels.

========
Due to the possible presence of network address and port
   translation (NAPT) devices, load balancers, or other middleboxes, use
   of anything other than an identical 5-tuple might also cause spatial
   redundancy 

... and flow label

========

When using spatial redundancy, the duplicate RTP stream is sent using
   a different source and/or destination address/port pair. 

This does not guarantee spacial redundancy of course.

From section 4.2:
   As specified in Section 3.2 of [RFC7104], it is advisable that the
   SSRC listed first in the "a=ssrc-group:" line (i.e., SSRC of 1000) is
   sent first, with the other SSRC (i.e., SSRC of 1010) being the time-
   delayed duplicate.

This is a rather odd thing to say, given that the text goes on to say that it doesn't really matter.   Either it matters or it doesn't.   If it doesn't, you might want to say this instead:

   Section 3.2 of [RFC7104] states that it is advisable that the
   SSRC listed first in the "a=ssrc-group:" line (i.e., SSRC of 1000) is
   sent first, with the other SSRC (i.e., SSRC of 1010) being the time-
   delayed duplicate.

If this is stated in anticipation that some implementations will erroneously take the order from the ordering of the two SSRC lines, then you might as well just require them to be specified in the intended order.