Re: [AVTCORE] comment on draft-jones-avtcore-private-media-reqts-00

[Bernard Aboba <[e-mail]>]

The RTP header fields that need to be modified by an SFU depend on the architecture and transport mode used, but this can include the sequence number (if SST-SS transport is used), PT, SSRC (if the SFU allocates its own SSRCs), CSRC field (some SFUs do use this if the allocate their own SSRCs). Any of these changes result in the need to recalculate the MIC and can also require the SFU to decrypt and reencrypt, depending on the cipher suite in use. 

If the payload is encrypted end-to-end then the hop-by-hop cipher suite might only require authentication, but then we are presented with another set of issues the draft does not discuss:

1. The SFU no longer has access to the payload fields it needs to make a forwarding decision. This could be potentially solved by copying some or all of those fields to an RTP header extension, as advocated in the following drafts:
https://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext
https://tools.ietf.org/html/draft-avtext-berger-framemarking

Note however that these extensions may need to support not only forwarding but also robustness features beyond NACK/RTX or hop-by-hop FEC. As an example, it would be useful to consider how an SFU receiving an SLI, PLI or RPSI feedback message can respond.

2. The SFU no longer has the keys to generate payloads required to inform end points of layer drops and other codec configuration changes.  One could attempt to provide this functionality in RTCP (e.g. TMMBN = 0 for PAUSED) but this may only work for some transport modes (e.g. SST-MS so that an SSRC can be used to identify a paused layer) and may not be a good enough substitute. 

Looking at all the potential implications on the architecture it seems to me that we are looking at an iceberg here where there are a lot of issues hidden under the surface. There is also more than one potential goal that might be worth focussing on. For example, today SFUs are typically designed for only a single codec whereas SVC technology (or at least temporal scalability) is becoming mainstream so the ability to build generic multi-codec SFUs is desirable. So even if the SFU is trusted with the keys to decrypt the payload there are reasons why not having to parse the payload would be desirable.




> On Nov 8, 2014, at 11:52 PM, Roni Even <[e-mail]> wrote:
> 
> Hi guys,
> I read the document and was wondering which of the topologies in draft-ietf-avtcore-rtp-topologies-update-04 is used here (figure 3). Is it the selective forward middlebox. It will be good to either use the same terminology or if it is a different topology define it in the topology draft.
> 
> As for the sequence number, when using example in figure 3 , each RTP stream received (from the same SSRC) may have a gap in the sequence number or the receiver may report a loss for a stream switched out by the midlebox? Any requirement here?
> 
>  
> 
> Thanks
> 
> Roni Even
> 
>  
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt

_______________________________________________
Audio/Video Transport Core Maintenance
[e-mail]
https://www.ietf.org/mailman/listinfo/avt