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

[Magnus Westerlund <[e-mail]>]

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





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