Re: [Perc] Request for decision review

[Bernard Aboba <[e-mail]>]

On Jul 20, 2016, at 12:56 PM, Miguel París Díaz <[e-mail]> wrote:
> 
> These features must also offer an high QoE for the users. For that, the experience tells me that it should be performed in the SFU side.

> In our current implementation:
>   1 - Video quality switching (simulcast) is performed by rewriting SSRCs, seqnums and timestamps

[BA] I assume you are talking about an SFU that provides a single stream per participant to the receiver. Most existing SFU implementations operate that way. Possible exception is SFUs supporting SVC with MRST which provide multiple streams and may not have to rewrite seqnums.

>   2 - Dominant Speaker switching is performed rewriting SSRCs, seqnums and timestamps. Notice that it would be considered an attack [1] when it is the best way (easy, efficient and 
> with high QoE) we found to implement this feature.
> 
> This is working in the WebRTC context using endpoints like Chrome or Firefox. To implement them following current PERC status:
> Could (1) be implemented without SSRCs rewriting and using RID instead?
> I think so, but should be ensure that endpoints support that before make SSRC immutable?
> Could (2) be implemented without SSRCs rewriting and using MID instead? Could (2) be implemented even without adding a specific RTP stream using idea [2]?
> I think so, but should be ensure that endpoints support that before make SSRC immutable?
> 
> These questions tell me that if endpoints does not support them, features requested by the market and PERC will be incompatible :S.
> 
> Best regards!!
> 
> Refs
> [1] https://tools.ietf.org/html/draft-mattsson-perc-srtp-cloud-01#section-7.2.4
> [2] https://www.ietf.org/mail-archive/web/mmusic/current/msg16611.html
> 
> 2016-05-26 1:12 GMT+02:00 Emil Ivov <[e-mail]>:
>> 
>> 
>>> On Wednesday, 25 May 2016, Eric Rescorla <[e-mail]> wrote:
>>> 
>>> 
>>>> On Wed, May 25, 2016 at 1:43 PM, Emil Ivov <[e-mail]> wrote:
>>>> 
>>>> 
>>>>> On 25.05.16 г. 15:20, Paul E. Jones wrote:
>>>>> Emil,
>>>>> 
>>>>> You are saying that endpoints would negotiate via signaling which SSRC
>>>>> value(s) to use before actually joining the conference?
>>>> 
>>>> It's awesome how you would always attribute to me the least appealing of all possible interpretations :).
>>>> 
>>>> Whether or not we negotiate SSRCs should not be within PERC's scope. For the record this is how WebRTC works anyway (courtesy of some of the people on this list) but the matter is completely orthogonal to PERC.
>>>> 
>>>> What I was suggesting is the possibility for PERC endpoints and MDD to negotiate whether or not they will be dealing with a single end-to-end SSRC space, or whether they will have separate HBH and E2E SSRC spaces.
>>>> 
>>>> This way you get to only implement the single end-to-end option in your endpoints and to not support the other one.
>>>> 
>>>> Does this make more sense?
>>>> 
>>>>> That doesn't strike me as terribly appealing, honestly.  Between that
>>>>> and the pain of dealing with conflicting SSRCs, I might favor the
>>>>> latter.  What I'd prefer most, though, is neither and just let endpoints
>>>>> do their thing.
>>>>> 
>>>>> I'd still like to hear confirmation that receiving browsers will
>>>>> definitely be doing the right thing w.r.t. receiving simulcast streams.
>>>>> Adam seemed to suggest Firefox will be doing the right thing (probably
>>>>> before PERC is done). What about popular browsers?
>>>> 
>>>> I think at this point the answers that I've heard are for both browsers: we are not doing this now.
>>> 
>>> As far as Firefox goes, we're not doing this now because PERC isn't ready.
>>  
>> So you are saying that simulcast itself is not a good enough reason to implement  receiver-side simulcast support ... but a minor optimization to PERC is ...
>> 
>> Obviously I don't need to be explained the reasoning. I am glad you have this plan.
>> 
>> I only wish we would have a clearer view of everyone's intended delivery dates since we are about to block PERC on them.
>> 
>> 
>>> We're looking at it soon and plan to try to implement it pretty much as soon as it's baked enough to do.
>>> 
>>> 
>>>> it's not part of webrtc 1.0.
>>> 
>>> Is it even something that could be in WebRTC 1.0? I.e., does it require changes?
>> 
>> How would you tell FF what group an RID corresponds to?
>> 
>> Emil 
>>> 
>>> 
>>>  
>>>> we'd like to do it in the future.
>>> 
>>> Yes.
>>> 
>>> -Ekr
>>>  
>>> 
>>> 
>>>> 
>>>> What I'd like to avoid is PERC having a firm dependence on this last statement and for it to only be usable when it comes true.
>>>> 
>>>> Emil
>>>> 
>>>>> 
>>>>> Paul
>>>>> 
>>>>> ------ Original Message ------
>>>>> From: "Emil Ivov" <[e-mail]>
>>>>> To: "Paul E. Jones" <[e-mail]>
>>>>> Cc: "Adam Roach" <[e-mail]>; "Cullen Jennings" <[e-mail]>;
>>>>> [e-mail]
>>>>> Sent: 5/25/2016 2:23:43 PM
>>>>> Subject: Re: [Perc] Request for decision review
>>>>> 
>>>>>> Paul,
>>>>>> 
>>>>>> I have answered your points below but we did gloss over the suggestion
>>>>>> I made and I consider it important:
>>>>>> 
>>>>>> We can allow SSRC rewriting and make it negotiable by signalling. This
>>>>>> way SFUs can state they support rewriting/immutability/both and
>>>>>> endpoints can choose to use what's available or reject the session as
>>>>>> unsupported.
>>>>>> 
>>>>>> I believe this should address the concerns that have been expressed so
>>>>>> far.
>>>>>> 
>>>>>> Now for the rest of the points:
>>>>>> 
>>>>>>> On 25.05.16 г. 7:22, Paul E. Jones wrote:
>>>>>>> Emil,
>>>>>>> 
>>>>>>>>> Since we are not enforcing a requirement that endpoints select a
>>>>>>>>> distinct SSRC per media flow, there is a potential conflict in the
>>>>>>>>> number space used E2E.
>>>>>>>> 
>>>>>>>> As I have been insisting many times already: We have the option to
>>>>>>>> mandate that SFUs preserve the SSRC space. That's not hard to
>>>>>>>> implement. It's not a great option but it is a possibility.
>>>>>>>> 
>>>>>>>> We can also say that whether or not SFUs do that rewrite is a feature
>>>>>>>> that has to be signalled so clients can choose whether to support it
>>>>>>>> or not. This should address your concern.
>>>>>>> 
>>>>>>> The SFU has nothing to do with the E2E SSRC collision problem.  When an
>>>>>>> endpoints sends out an RTP packet and it goes though an SFU that changes
>>>>>>> the SSRC, there is a HBH SSRC and an E2E SSRC.  I fully agree that the
>>>>>>> SFU can ensure that the HBH SSRCs do not collide, but it cannot control
>>>>>>> the fact that the E2E SSRCs collide.
>>>>>> 
>>>>>> The SFU has everytihng to do with the E2E collision problem and it's
>>>>>> potential solutions. What you describe is one way to handle things.
>>>>>> Another one would be to just make SSRC conflicts obvious to senders so
>>>>>> that they would apply 3550 resolution. That's pretty easy to implement.
>>>>>> 
>>>>>>>>> The 64 bit identifier is just a hack to work
>>>>>>>>> around that problem. If the problem didn't exist, we could use SSRC
>>>>>>>>> values to look up the context as it was I intended in SRTP.
>>>>>>>> 
>>>>>>>> E2E PERC is NOT SRTP. We may choose to make it look like it is and I
>>>>>>>> see why that is appealing but not doing it is by no means "a hack".
>>>>>>> 
>>>>>>> Of course it's SRTP.  It just happens to be two passes of SRTP, but it's
>>>>>>> nonetheless SRTP.
>>>>>> 
>>>>>> Exactly! And two passes of SRTP happen to NOT be SRTP as in: no stock
>>>>>> SRTP endpoint would do anything meaningful with them. So what you are
>>>>>> looking is to just optimize implementations, which is relevant but not
>>>>>> the primary concern.
>>>>>> 
>>>>>>> What PERC is adding are some additional steps between
>>>>>>> each pass for HBH authentication of packets at the sender (and the
>>>>>>> reverse at the receiver).  The MDD doesn't have two steps: it just does
>>>>>>> one normal SRTP decryption for the packet received and one SRTP
>>>>>>> encryption step sending the packet.  The only special requirement PERC
>>>>>>> introduces is that if the MDD changes either the PT field or sequence
>>>>>>> number, the original values have to be added to the packet inside an RTP
>>>>>>> header extension called OHB (if not already present).
>>>>>>> 
>>>>>>> 
>>>>>>>>> The problem with using a 64 bit value is that any existing SRTP
>>>>>>>>> library
>>>>>>>>> would have to change to associate the context that way.
>>>>>>>> 
>>>>>>>> So just to be clear ... we are lamenting about changing an int to a
>>>>>>>> long?
>>>>>>> 
>>>>>>> No, lamenting that this would not align with what RFC 3711 says to use
>>>>>>> to identify the context.
>>>>>> 
>>>>>> Again, 3711 applies to HBH. We are trying to reuse as much of it for
>>>>>> E2E as possible and that's admirable but it's not a reason why we
>>>>>> should significantly disrupt existing implementations.
>>>>>> 
>>>>>>>>> Further, if we
>>>>>>>>> wish to break up the PERC processing into two steps, that HBH SSRC
>>>>>>>>> would
>>>>>>>>> have to be extracted and passed in by the application. While I
>>>>>>>>> think the
>>>>>>>>> intent with Double is for this to be an autonomous operation, it might
>>>>>>>>> not be implemented that way for two reasons:
>>>>>>>>> 1) If there is a desire to do HBH FEC, the process might be to encrypt
>>>>>>>>> E2E -> FEC -> HBH. So the second call to the SRTP library would need
>>>>>>>>> that HBH SSRC passed in when doing these steps in reverse to introduce
>>>>>>>>> that 64-bit context ID.
>>>>>>>> 
>>>>>>>> Em ... you'd have to explain this in a bit more detail because I fail
>>>>>>>> to see how FEC is any different than regular media. As you say it
>>>>>>>> yourself, it all just works out properly as long as you do your FEC
>>>>>>>> after E2E and before HBH as that way the SFU would be able to de- or
>>>>>>>> re-FEC.
>>>>>>> 
>>>>>>> Historically, there were two options for FEC.  Either we do FEC first
>>>>>>> and then SRTP, or SRTP first then FEC.  The order has to match at both
>>>>>>> the sender and receiver.  Either way, it generally makes very little
>>>>>>> difference.
>>>>>>> 
>>>>>>> An MDD might want to be a good citizen and reconstruct lost packets
>>>>>>> before sending a stream to a receiver.  In order to do that, the sender
>>>>>>> will either need to do SRTP (both passes) then FEC or it could do the
>>>>>>> first SRTP pass (the E2E encryption pass) then FEC then SRTP for the
>>>>>>> HBH.  It really depends on what we want that FEC flow to look like.  Do
>>>>>>> we want it to be FEC over a bunch of E2E+HBH encrypted packets or just
>>>>>>> over the E2E packets.  (The latter would be parallel to the current FEC
>>>>>>> order of "FEC then SRTP".
>>>>>>> 
>>>>>>> So, thinking of how this might be implemented in an SRTP library, if we
>>>>>>> allow the SRTP(E2E)+FEC+SRTP(HBH) option for FEC order, then when the
>>>>>>> application encrypts the packet, it would pass the packet into the SRTP
>>>>>>> libtary once to encrypt HBH.
>>>>>> 
>>>>>> You mean E2E here.
>>>>>> 
>>>>>>>  It then does whatever FEC processing it
>>>>>>> wants, then it calls into the SRTP library again to encrypt the second
>>>>>>> pass (HBH pass).  It could be two entirely instances of the SRTP library
>>>>>>> that handles each pass.  On the MDD, it decrypts the flow and does
>>>>>>> whatevever FEC magic it wants to do.  There is only one SRTP operation
>>>>>>> at the MDD, so no problem.  At the receiver, it decrypts the packet
>>>>>>> received using HBH decryption. It then does whatever FEC processing it
>>>>>>> needs to do.  Next, it would call into the SRTP library to decrypt for
>>>>>>> E2E.  If the SSRCs never change, this works fine.  One could implement
>>>>>>> this using two instances of an SRTP library today.  If a single library
>>>>>>> is used, then the only requirement is to ensure the second call into the
>>>>>>> library does not encounter issues with the replay database (since it
>>>>>>> might otherwise think it's a replayed packet).  In either case, the
>>>>>>> crypto context would be looked up as per RFC 3711 using SSRC.  If,
>>>>>>> however, the SSRC value is allowed to change, then the second call into
>>>>>>> the SRTP library (same or different instance of the library) would be a
>>>>>>> problem since Alice and Bob both used SSRC 1.  The collision is going to
>>>>>>> prevent the library from working properly.
>>>>>> 
>>>>>> I still fail to see how FEC changes any of this (for better or worse).
>>>>>> The problem you describe here is exactly the same with or without FEC
>>>>>> and it's what we are having the argument about.
>>>>>> 
>>>>>>> If we take the approach of using a 64-bit identifier (in contradiction
>>>>>>> to RFC 3711)
>>>>>> 
>>>>>> :) ... It is NOT in contradiction with 3711 because layers of
>>>>>> encryptions are not part of 3711. We simply need to set the
>>>>>> expectations right for implementers.
>>>>>> 
>>>>>>>  to identify the crypto context, then we would need to pass
>>>>>>> that identifier into the SRTP library when attempting to decrypt the
>>>>>>> packet, because it could not simply discover it by looking at the packet
>>>>>>> (which it could do normally since the SSRC value is right there in the
>>>>>>> packet).  It would be necessary to make a call like
>>>>>>> srtp_unprotect(context, packet, stream_identifiier) (where
>>>>>>> stream_identifier is something that identifies the stream other than the
>>>>>>> SSRC per 3711, like E2E_SSRC || HBH_SSRC).
>>>>>>> 
>>>>>>> A beautiful thing about SRTP today
>>>>>> 
>>>>>> You mean PERC here and not SRTP (even if PERC does simply apply a
>>>>>> second srtp unprotect it is still not stock 3711).
>>>>>> 
>>>>>>> is the library can operate on streams
>>>>>>> without the application having to pass in such identifiers.  The stream
>>>>>>> is self-identifying.  But, we lose that elegance when we modify the SSRC
>>>>>>> in the MDD when we break the operation into two passes to handle this
>>>>>>> FEC order.
>>>>>> 
>>>>>> So we have an aesthetic concern because we have to change int-s to
>>>>>> long-s and that's why we are having a 100 mail thread. I am speechless.
>>>>>> 
>>>>>>>>> 2) It might be desirable to implement the PERC logic by just having a
>>>>>>>>> two-step wrapper around the existing SRTP library to avoid making
>>>>>>>>> changes to the core library. (I'd prefer built-in support for Double,
>>>>>>>>> but I can appreciate how some might prefer to not change an otherwise
>>>>>>>>> working library.)
>>>>>>>> 
>>>>>>>> As I said, being able to reuse SRTP libraries with no change is a
>>>>>>>> great optimization if we get it but I really don't think the
>>>>>>>> alternative is anywhere near the complexity that would justify banning
>>>>>>>> SSRC re-writing.
>>>>>>> 
>>>>>>> At least we agree that it would be a good goal to find an approach that
>>>>>>> would eliminate or minimize changes to the SRTP logic. :)
>>>>>>> 
>>>>>>> Now to the complexity part... that's in the thread you're having with
>>>>>>> Cullen which, as I understand, is an expression of a concern that
>>>>>>> receiving endpoints are not going to properly handle multiple simulcast
>>>>>>> streams coming toward them.
>>>>>>> 
>>>>>>> Since I don't work for a browser vendor, I cannot speak to their plans.
>>>>>>> I can only assume that proper handling of received simulcast flows would
>>>>>>> be implemented per the current drafts.  And if that's the case, then I
>>>>>>> don't think changing the SSRC would be needed.  If receiving endpoints
>>>>>>> fail to do that, then you're right that this could be a problem.
>>>>>> 
>>>>>> Let's be clear on this. There is absolutely nothing wrong or standard
>>>>>> breaking in the way browsers handle simulcast reception today. They
>>>>>> are simply not simulcast aware and the SFU hides it from them.
>>>>>> 
>>>>>> There is no reason why that would be labelled a bad practice even when
>>>>>> RID does go through all of the IETF process.
>>>>>> 
>>>>>> Also, the availability of this option (simulcast unaware receivers)
>>>>>> and its existence today make the motivation for RID support on the
>>>>>> receiving end pretty low. It does not give you anything extra in terms
>>>>>> of functionality. There are no substantial benefits from doing it (and
>>>>>> no it doesn't allow for significantly simpler SFUs ... those would
>>>>>> still have to keep 95% of their existing logic). We can decide to make
>>>>>> PERC dependent on it and hope that this would sway all browser vendors
>>>>>> ... or we could also try to lower the burden on PERC adoption.
>>>>>> 
>>>>>> Again, as stated in the beginning of this mail: it sounds like a
>>>>>> compromise may lie in the option for PERC to allow an SSRC rewriting
>>>>>> mode combined with the option for endpoints to not support it. In
>>>>>> other words we can have part of the PERC signalling indicate whether
>>>>>> the client and the server support these modes and whether they use
>>>>>> them. This is not beautiful (by any means) but it wouldn't prevent
>>>>>> either of us to do things their way.
>>>>>> 
>>>>>> Emil
>>>>>> -- https://jitsi.org
>>>> 
>>>> -- 
>>>> https://jitsi.org
>>>> 
>>>> _______________________________________________
>>>> Perc mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/perc
>> 
>> 
>> -- 
>> sent from my mobile
>> 
>> _______________________________________________
>> Perc mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/perc
> 
> 
> 
> -- 
> Miguel París Díaz
> ------------------------------------------------------------------------
> Computer/Software engineer.
> Researcher and architect in http://www.kurento.org
> http://twitter.com/mparisdiaz
> ------------------------------------------------------------------------
> _______________________________________________
> Perc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/perc