Re: [Perc] Request for decision review

[Miguel París Díaz <[e-mail]>]

Hello Paul,
we rewrite the SSRC because currently it is the way to associate a
MediaStreamTrack to an RTP stream.

Analysing the case of video quality switching (simulcast):

   - Rewriting SSRCs at the SFU side improves the QoE a lot due the switch
   is transparent for the endpoint which receives the RTP stream, applies the
   JitterBuffer, decrypts it, creates encoded frames, decodes frames, applies
   sync-buffer (for interstream synchronization (typically audio and video))
   and renders the video. So the logic in the client is quite easier and
   smooth when switchings.


   - If we do NOT do that, the another possibility (I didn't found others)
   is negotiating with the receiver N SSRCs (each one per quality) performing
   ON/OFF at the SFU side and doing the switching in the receiver. For doing
   that:
      - You have N MediaStreamTracks.
      - You have to detect at application layer when a MediaStreamTrack
      stops receiving media using getUserMedia API's events (which
takes at least
      500ms)
      - You have to detect the the new enabled MediaStreamTrack, which can
      take a lot of times due to JitterBuffer restarting, decoder
restarting, etc.
      - You have to deal with audio-video synchronization that may be quite
      difficult.
      - The endpoint uses more resources (CPU and memory)
      - etc.
      - In conclusion it is a pain for the users because they see freeze
      video time to time (the QoE is very bad)


   - Rewriting timestamps is needed because there are usually some offsets
   between different qualities.


2016-07-20 14:34 GMT+02:00 Paul E. Jones <[e-mail]>:

> Miguel,
>
> The current design of PERC is one where there is an E2E encryption step
> using regular SRTP.  An intermediary does not have the E2E keys and,
> therefore, cannot change anything about the packet.  Then, that packet is
> encrypted HBH using a different key that the next hop device will have.
> Assuming the next hop device is an MDD (nor "Media Distributor"), that
> device could have the liberty of changing the sequence numbers and, in
> fact, it will be obliged to do so if it does not always forward all of the
> streams (since not forwarding some streams will mean the cryptographic
> context gets out of sync).
>
> So in the typical case, the MDD will change the sequence number and might
> insert a new header extension to carry the original value.  It might also
> change the payload type value.
>
> How, as the endpoint receives a packet, it will decrypt the HBH packet and
> reconstruct the E2E packet using the OHB field.  But what is there?  Well,
> it's the original packet as created by the sending endpoint.  Even if we
> change the SSRC or sequence number, the original values are there and
> preserved.  So, other than out of necessity (sequence number changed to
> keep crypto context in sync and PT changed to ensure the right PT value is
> received as expected), I'm still not convinced that changing the SSRC
> really buys us anything.  Sure, we could change it.  We actually has space
> in the OHB originally to allow that.  But for what purpose?  Changing or
> not changing an SSRC value should not have any affect whatsoever on the
> QoE.   (I'm not saying the SSRC has no importance, but I question the need
> to rewrite them.)
>
> I'm not sure how the other identifiers you mention might help improve
> QoE.  Maybe expand on that little?
>
> One important point to consider in all of this is that WebRTC browsers
> MUST be PERC-aware, else they cannot participate in conferences.  If
> they're not PERC-aware, then there would have to be a middlebox that
> "downgrades" for those older browsers and it can rewrite whatever it wants,
> since it would be in possession of keys and would strip off one layer of
> encryption to produce a legacy SRTP flow (or no SRTP at all).
>
> Paul
>
> ------ Original Message ------
> From: "Miguel París Díaz" <[e-mail]>
> To: "Emil Ivov" <[e-mail]>
> Cc: "Eric Rescorla" <[e-mail]>; "Paul E. Jones" <[e-mail]>;
> "Adam Roach" <[e-mail]>; "[e-mail]" <[e-mail]>; "Cullen
> Jennings" <[e-mail]>
> Sent: 7/20/2016 6:56:59 AM
> Subject: Re: [Perc] Request for decision review
>
>
> Hello everybody,
> I understand the point of Emil because as implementer I am worried about
> having hard restrictions which avoid or hinder the implementation of
> features requested by the market, and this could make PERC unusable.
>
> So I think that firstly we should reach consensus about which features or
> uses cases must be allowed to be implemented and then discuss the low level
> details taking into account that we won't can add restrictions which avoid
> these features.
> This may also apply to others WGs and not only to PERC. Even having
> support for rid, mid, etc. could ease the design of PERC.
>
> Ones of the features affected with the current status are:
>   1 - Video quality switching (simulcast)
>   2 - Dominant Speaker switching
>
> 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 rewriting SSRCs,
> seqnums and timestams
>   2 - Dominant Speaker switching is performed rewriting SSRCs, seqnums
> andt timestams. Notice that it would be consider and attack [1]
> <https://tools.ietf.org/html/draft-mattsson-perc-srtp-cloud-01#section-7.2.4>
> 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]
> <https://www.ietf.org/mail-archive/web/mmusic/current/msg16611.html>?
> 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
> ------------------------------------------------------------------------
>
>


-- 
Miguel París Díaz
------------------------------------------------------------------------
Computer/Software engineer.
Researcher and architect in http://www.kurento.org
http://twitter.com/mparisdiaz
------------------------------------------------------------------------