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

From: Jonathan Lennox <[email-masked]>
Date: Tue, 13 Aug 2013 12:14:04 -0400

(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
[email-masked]

---

From: Stephan Wenger <[email-masked]>
Date: Tue, 13 Aug 2013 16:25:54 +0000

Hi,
no congestion control section in something like this?  I would have
expected a big red warning label "don't do this unless you have no other
choice.  In most cases, doing something like this is a bad idea".
Especially with respect to singe pass.
Confused,
Stephan

On 8.13.2013 18:14 , "Jonathan Lennox" <[email-masked]> wrote:

>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
>[email-masked]
>
>
>_______________________________________________
>avtext mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/avtext

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 14 Aug 2013 12:33:45 +0000

On Aug 13, 2013, at 7:25 PM, Stephan Wenger <[email-masked]> wrote:

> Hi,
> no congestion control section in something like this?  

Last paragraph of section 1 has a text, which summarizes the issue well enough IMO. One can certainly write a lot more detailed guidelines, but we will never be able to cover all the use or corner cases. The use of duplication has a lot of dependency on how the routing works and how the network topology is structured. 

> I would have

That is a strong statement and I dont agree with. Duplication methods are successfully deployed in many places today and it is not because we did not have another choice, but because it made a lot more sense in such environments.

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 20 Aug 2013 10:09:49 +0200

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.

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

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/

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.

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.

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.

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.

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.

Cheers

Magnus

-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 20 Aug 2013 11:12:02 +0000

Thanks for the review.

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

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

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

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

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

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

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

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

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 20 Aug 2013 15:42:49 +0200

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

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

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