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

[Magnus Westerlund <[e-mail]>]

On 2013-08-20 13:12, Ali C. Begen (abegen) wrote:
> 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.

Yes, my complaint is that you are not explicit enough on how you expect
the heuristics to work and what its limitations are.

> 
>> 
>> 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 understand that the common deployment for 1) is that there is only a
single stream. I just want the document to be clear that in cases where
there are multiple ones. Which they can be from a standards perspective
even if not commonly done today.

> 
>> 
>> 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.

I have no issue with this draft moving forward without any clear
reference to a solution today. What I am asking is for the draft to
acknowledge the shortcomming and be clear on what its requirements are.
> 
>> 
>> 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.

Yes, and I have no wish to hold it up any longer either. I just want you
to document the short commings of the current solution and warn any
users of it where the issues will arise.

> 
>> 
>> 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.

Yes, the issue I see is that people insert these in the middle of a
path, and thus prevent the congestion control to work. However, having
these node send RTCP to the original sender is not likely, especially
from a security perspective, thus some warning of the impact and the
responsibility of then the duplication.

>From my perspective if the duplication mechanism is injected in the
middle of e2e path and then improves the performance of that without
making the end nodes aware of its existence, then it the duplication
that are responsible for the congestion response and thus needs to have
a mechanism to detect and act on congestion in its paths. This is
clearly an issue with spatial duplication where one path can get
congested to hell and the other works fine and e2e it is fine. Only the
duplciation adder can really respond to dealing with the congestion on
that path.


> 
>> 
>> 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?

Yes, if the attacker also have the SDP. And the network is not source
address validating at its boundaries, then I can potentially inject
packets from the outside, that will then be duplicated. For multicast
cases it will be highly dependent on how the multicast routing is set up.

Cheers

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]
----------------------------------------------------------------------