Re: [avtext] WGLC for draft-ietf-avtext-rtp-duplication-02

["Ali C. Begen (abegen)" <[e-mail]>]

Thanks for the review.

On Aug 20, 2013, at 11:09 AM, Magnus Westerlund <[e-mail]> wrote:

> Hi,
> 
> I have reivewed this draft and have a few comments.
> 
> 1. Section 5. Source and duplicate association.
> 
> Where the single RTP session association at least have one safe but
> signalling support dependent solution (using SDP and ssrc-group) the
> spatial separated one only has half a solution. As the source and
> duplication goes in different RTP sessions, in cases where each session
> contains multiple SSRCs that has the same SDES CNAME then explicit
> association is not provided. Instead heuristics needs to be applied.

We discussed this months ago. See my email dated march 19th summarizing the motivation for the current text.

> 
> My understanding is that these heuristics will look something like this.
> Look at RTP packets Seq and TS field and match those between the two RTP
> sessions. I agree this will work in the majority of the cases, but it is
> not fail-safe. If one starts two audio streams with the same codec and
> packetization parameters using a common starting point and the same TS
> and Seq they will not be possible to correctly separate. Having multiple
> audio streams may actually be common in environments where multiple
> audio tracks are provided. Having the same Seq and TS is unlikely in
> cases of good implementation, but can occur when randomization of Seq
> and TS start is not implemented.
> 
> First of all, if heuristics are expected to be used, I think some basic
> heuristics and its failure cases should be described in this document.

The current draft intends to address the foremost important use cases. Those use cases are already in deployment not like the ones that might get deployed in some future.

> 
> The SDP grouping mechanism as currently defined is not sufficient for
> this. The issue is that you want to group one SSRC in one RTP session
> with another SSRC in another RTP session. That is not supported by
> grouping framework that groups RTP sessions (m= blocks) and
> SSRC-grouping that groups SSRCs within the same RTP session (m= block).

We want two basic things and that is what the draft supports:

1) grouping the original and the dup stream in separate m lines (there would not be other streams in these m lines)
2) grouping two ssrc's carried in the same m line (there could be other ssrc's in the same m line)

> 
> I think the best solution for this problem would be to have a RTCP SDES
> item that identifies identical streams. However, we have clearly not yet
> reached a consensus for how the different type of grouping identifiers
> need is supposed to work. Should they be hierarchical or purpose
> specific. This is the discussion around SRCNAME.
> https://datatracker.ietf.org/doc/draft-westerlund-avtext-rtcp-sdes-srcname/

Unfortunately the above draft or other similar ideas have not progressed. We have been holding our draft to wait for this discussion to get into a shape but really it has already been a year and an immediate solution is not in the horizon. So, that's why in March, I wrote that email to the group and we moved forward. Lets not restart those discussions again.

> 
> It may not be necessary to have this document hold up for a solution be
> finished here. I think one or more will become available. However, I
> think it is essential that the issue, when it can arise and the
> requirement on a solution to be documented.

When/if a solution is agreed, we can always revise whatever has been specified in the current rtp dup draft. I strongly object to holding our draft any longer as I explained to the avtext and mmusic chairs a while ago.

> 
> 2. Congestion Considerations
> 
> I think this document do need a congestion consideration section. Yes,
> it can double or triple the bandwidth requirement and that is worth a
> bit more discussion. However the bigger issue is that spatial vs single
> RTP session usage has different ways a congestion control needs to act.
> That is definitely needing a discussion.
> 
> So lets consider the single RTP session duplication. As the duplicate
> stream has the same five tuple, and only SSRC differs it can be expected
> to share UDP flow and path through the network. Thus in this case the
> original and the duplicate must be expected to share bottlenecks. Thus
> any congestion control needs to operate on the aggregate of the two
> streams. Due to the tight coupling, even if only the source stream is
> congestion controlled end-to-end there will be reaction to a congestion
> situation in the shared bottleneck. However, if not taking the
> duplication into account the reaction will be less than for a single non
> duplicated stream with double the bandwidth from the original.

I am not disagreeing with what you said above. But, what is there to specify or discuss in the document? If the streams are going thru the same route, duping will double your bw. this may or may not be a problem from a congestion viewpoint. Actually, it should not be for the cases this draft is supposed to be used. Remember duping is not a good idea when you are fighting with the congestion related losses. It is only useful when you are dealing with outage like problems. IOW, if someone is duping and that is causing congestion, it is a bad implementation. That is not how/when RTP duping is supposed to be used.
> 
> In spatial separation cases, the congestion control may not know if the
> congested part is a shared bottleneck or not. Thus independent
> congestion control loops are needed for the original and the duplicate.
> Then as they are tightly couple the actual used bandwidth needs to be
> the lower common denominator between the independent controllers.
> Otherwise if the bottleneck is not shared and on the duplicate path,
> then the original will go through fine, but not the duplicate.
> 
> Thirdly, the congestion state with end-to-end vs between the duplication
> point and re-assembly point needs to be discussed. This is the same
> issue that using FEC below the RTP stack has. As the end-receiver are
> not seeing the losses, except for losses in both streams, the receiver
> sees a more ideal path than reality. Thus injected RTCP reports from the
> re-assembly point or even congestion control messages to the media
> source from re-assembly needs to be considered to make the system work.

If the reassembly point is not the ultimate receiver (which is true most of the time), you are right. This does not have any relevance to the congestion control, however. The reassembly point's RTCP reports will be relevant to the sender in terms of adjusting the duplication interval, etc. the ultimate endpoint's RTCP reports are only relevant to determine the loss beyond the reassembly point. 

> 
> These issues I do expect to see discussed in a congestion control
> considerations section.
> 
> 3. Section 7.
> 
> I think the end-to-end usage of SRTP encryption and authentication with
> on the path duplication and de-duplication needs to be a bit more
> explicit about that this can be done, as long as the RTP headers
> entering the duplication node is identical after de-duplication. If not
> the end-receiver can not decrypt or authenticate the packets successfully.

That is my understanding, too. I will let SRTP folks to comment on this and I will be happy to add/change text if necessary.

> 
> Then the next issue is the protection of any such duplication system.
> The basic threat I see is that if I know a duplication service is
> running in a network and know which 5-tuple filters it is using, I could
> use that node to amplify my DDOS attack. Thus letting the target
> networks services be used against itself. If one believe this is a
> threat then one needs to authenticate the incomming traffic prior to
> duplication as being the traffic authorized for duplication. I think
> several solutions exist to that problem.

The stream properties defined in the SDP need to match to the stream(s) ingested by the attacker, right? So, if you  know your SDP is not hacked into, is there still a problem?

> 
> 
> Cheers
> 
> Magnus
> 
> 
> 
> 
> 
> On 2013-08-13 18:14, Jonathan Lennox wrote:
>> (As WG cochair)
>> 
>> This is to announce a working group last call for draft-ietf-avtext-rtp-duplication-02:
>> 
>> http://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-duplication/?include_text=1
>> 
>> Please respond to the list by Tuesday, September 3, 2013 (i.e. 3 weeks time) with any comments.
>> 
>> This is intended as a standards track RFC.
>> 
>> It is helpful to attempt to categorise the type of your comment (including severity) and also to assist to provide any replacement text you feel is necessary.
>> 
>> If you review the document and have no comments, please tell the chairs that you have reviewed it. This is always useful information in assessing the degree of WG review and consensus behind the document.
>> 
>> 
>> --
>> Jonathan Lennox
>> [e-mail]
>> 
>> 
>> _______________________________________________
>> avtext mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/avtext
>> 
>> 
> 
> 
> -- 
> 
> Magnus Westerlund
> 
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  [phone]
> Färögatan 6                | Mobile [phone]
> SE-164 80 Stockholm, Sweden| mailto: [e-mail]
> ----------------------------------------------------------------------
>