Last Call Review of draft-ietf-avtext-rtp-duplication-04
review-ietf-avtext-rtp-duplication-04-opsdir-lc-dunbar-2014-02-06-00

As a directorate of Ops Area, I have been asked to review
“draft-ietf-avtext-rtp-duplication-04”.

Here are my comments:



-



Section 3.2 Spatial Redundancy:

The section describes that a source uses two different IP addresses for
duplicated streams. But it fails to describe

how the receiving end know if the packets with different Source Addresses are
from the same source?

In later session, it is described to use SSRC to merge two sessions. But

How to prevent two different sources using the same SSRC?



The last sentence:

I don’t think that you mean sending streams to different destinations, do you?

Suggest: “Alternatively, destination host could also have multiple IP addresses
for an RTP source to send the redundant streams to.”



-



Section 3.3

This section is really for analyzing the two methods (3.1 Temporal Redundancy
and 3.2 Spatial Redundancy), correct?



Suggest to reference 3.1 and 3.2. For example

1.



Analysis of Temporal Redundancy:

2.



Analysis of Spatial Redundancy:



-



Section 3.4

Suggest to spell out SDP (is it “

Session Description Protocol”?)



-



Section 7 Congestion Control Considerations

I don’t think this recommendation is realistic:





The source hosts don’t know the congestion status of the network. Most likely
those duplications are used for sources/destinations to get better results for
themselves in congested network.





For the following: most network has its protection for link/interface failure.
More likely, duplications of sources/destinations are not for protecting hard
failure.





I suggest to emphasize that duplication can only make the overall network
congest more.





Linda