Subject: Re: [Perc] Request for decision review

From: Miguel París Díaz <[email-masked]>
Date: Wed, 20 Jul 2016 12:56:59 +0200

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

>
>
> On Wednesday, 25 May 2016, Eric Rescorla <[email-masked]> wrote:
>
>>
>>
>> On Wed, May 25, 2016 at 1:43 PM, Emil Ivov <[email-masked]> 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" <[email-masked]>
>>>> To: "Paul E. Jones" <[email-masked]>
>>>> Cc: "Adam Roach" <[email-masked]>; "Cullen Jennings" <[email-masked]>;
>>>> [email-masked]
>>>> 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
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/perc
>>>
>>
>>
>
> --
> sent from my mobile
>
> _______________________________________________
> Perc mailing list
> [email-masked]
> 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
------------------------------------------------------------------------

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 20 Jul 2016 12:34:26 +0000

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" <[email-masked]>
To: "Emil Ivov" <[email-masked]>
Cc: "Eric Rescorla" <[email-masked]>; "Paul E. Jones" 
<[email-masked]>; "Adam Roach" <[email-masked]>; 
"[email-masked]" <[email-masked]>; "Cullen Jennings" <[email-masked]>
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.
>
>   2 - Dominant Speaker switching is performed rewriting SSRCs, seqnums 
>andt timestams. Notice that it would be consider and attack [1] when it 
>is the best way (easy, efficient and
>I think so, but should be ensure that endpoints support that before 
>make SSRC immutable?
>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] 
>>>>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.
>>>>
>>>>I think at this point the answers that I've heard are for both 
>>>>browsers: we are not doing this now.
>>>
>>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.
>>>
>>>
>>>Is it even something that could be in WebRTC 1.0? I.e., does it 
>>>require changes?
>>
>>>>>>>The SFU has nothing to do with the E2E SSRC collision problem.  
>>>>>>>When an
>>>>>>>Of course it's SRTP.  It just happens to be two passes of SRTP, 
>>>>>>>but it's
>>>>>>>nonetheless SRTP.
>>>>>>
>>>>>>>reverse at the receiver).  The MDD doesn't have two steps: it 
>>>>>>>just does
>>>>>>>number, the original values have to be added to the packet inside 
>>>>>>>an RTP
>>>>>>>>>intent with Double is for this to be an autonomous operation, 
>>>>>>>>>it might
>>>>>>>HBH.  It really depends on what we want that FEC flow to look 
>>>>>>>like.  Do
>>>>>>>over the E2E packets.  (The latter would be parallel to the 
>>>>>>>current FEC
>>>>>>>So, thinking of how this might be implemented in an SRTP library, 
>>>>>>>if we
>>>>>>>application encrypts the packet, it would pass the packet into 
>>>>>>>the SRTP
>>>>>>>is used, then the only requirement is to ensure the second call 
>>>>>>>into the
>>>>>>>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
>>>>>>>stream_identifier is something that identifies the stream other 
>>>>>>>than the
>>>>>>>is self-identifying.  But, we lose that elegance when we modify 
>>>>>>>the SSRC
>>>>>>>At least we agree that it would be a good goal to find an 
>>>>>>>approach that
>>>>>>>I can only assume that proper handling of received simulcast 
>>>>>>>flows would

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 20 Jul 2016 14:48:59 +0200

On Jul 20, 2016, at 12:56 PM, Miguel París Díaz <[email-masked]> 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 
> This is working in the WebRTC context using endpoints like Chrome or Firefox. To implement them following current PERC status:
> 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
>>>> 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.
>>>> 
>>>> I think at this point the answers that I've heard are for both browsers: we are not doing this now.
>>> 
>> 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.
>>> 
>>> 
>>> Is it even something that could be in WebRTC 1.0? I.e., does it require changes?
>> 
>>>> 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
>>>>> 
>>>>>>> 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
>>>>>>> SFU can ensure that the HBH SSRCs do not collide, but it cannot control
>>>>>>> Of course it's SRTP.  It just happens to be two passes of SRTP, but it's
>>>>>>> nonetheless SRTP.
>>>>>> 
>>>>>>> reverse at the receiver).  The MDD doesn't have two steps: it just does
>>>>>>> number, the original values have to be added to the packet inside an RTP
>>>>>>>>> intent with Double is for this to be an autonomous operation, it might
>>>>>>>>> 1) If there is a desire to do HBH FEC, the process might be to encrypt
>>>>>>>>> that HBH SSRC passed in when doing these steps in reverse to introduce
>>>>>>>>> that 64-bit context ID.
>>>>>>>> 
>>>>>>> before sending a stream to a receiver.  In order to do that, the sender
>>>>>>> HBH.  It really depends on what we want that FEC flow to look like.  Do
>>>>>>> over the E2E packets.  (The latter would be parallel to the current FEC
>>>>>>> So, thinking of how this might be implemented in an SRTP library, if we
>>>>>>> application encrypts the packet, it would pass the packet into the SRTP
>>>>>>> pass (HBH pass).  It could be two entirely instances of the SRTP library
>>>>>>> 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
>>>>>>> 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
>>>>>>> packet, because it could not simply discover it by looking at the packet
>>>>>>> stream_identifier is something that identifies the stream other than the
>>>>>>> without the application having to pass in such identifiers.  The stream
>>>>>>> is self-identifying.  But, we lose that elegance when we modify the SSRC
>>>>>>>>> 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.)
>>>>>>>> 
>>>>>>>> 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
>>>>>>> receiving endpoints are not going to properly handle multiple simulcast
>>>>>>> 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

---

From: Miguel París Díaz <[email-masked]>
Date: Wed, 20 Jul 2016 16:35:15 +0200

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

> 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.)
>
> "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
>
> Cc: "Eric Rescorla" <[email-masked]>; "Paul E. Jones" <[email-masked]>;
> "Adam Roach" <[email-masked]>; "[email-masked]" <[email-masked]>; "Cullen
> Jennings" <[email-masked]>
> andt timestams. Notice that it would be consider and attack [1]
>>>> 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.
>>>>
>>>>> Cc: "Adam Roach" <[email-masked]>; "Cullen Jennings" <[email-masked]
>>>>> >;
>>>>> [email-masked]

---

From: Emil Ivov <[email-masked]>
Date: Wed, 20 Jul 2016 17:08:05 +0200

It is probably worth reminding there IS a middle ground that allows
PERC to function with both SSRC rewriting and use of RID. We simply
need to convey the original SSRC to the receiver and have PERC code
use that for verification. That's all.

We've been through this before. The only meaningful argument against
this is Paul's: "The code wouldn't be as pretty as I want it to be
because PERC would no longer be implementable as a double standard
SRTP unprotect".

As a result we are going toward something incompatible with most
popular SFU implementations, mandating support for receiver-side
RID-based simulcast that NO ONE implements today, that will not be
part of WebRTC 1.0 and that is not even fully specified on the IETF.

Chairs, ADs, ... please, please, please, let's get back to a state of sanity.

Emil

On Wed, Jul 20, 2016 at 4:35 PM, Miguel París Díaz <[email-masked]> wrote:
> 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
> 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
> 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
>> 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).
>>
>> 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?
>>
>> 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
>>
>> <[email-masked]>; "Adam Roach" <[email-masked]>; "[email-masked]"
>> <[email-masked]>; "Cullen Jennings" <[email-masked]>
>> andt timestams. Notice that it would be consider and attack [1] when it is
>> the best way (easy, efficient and
>> idea [2]?
>>> implement  receiver-side simulcast support ... but a minor optimization to
>>> PERC is ...
>>>

-- 
https://jitsi.org

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 20 Jul 2016 17:11:01 +0200

On Jul 20, 2016, at 16:35, Miguel París Díaz <[email-masked]> wrote:
> 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 to detect at application layer when a MediaStreamTrack stops receiving media using getUserMedia API's events (which takes at least 500ms)
[BA] I do not believe those events provide a useful way to support reception of simulcast in WebRTC 1.0. That is why simulcast reception is not supported.

In ORTC it is supported (2 implementations) but experience shows that without an explicit switching indication (like PAUSED or SEI layer drop) it is quite difficult to perform well in the face of reordering. Without a drop indication or RFC 6051 support, a single stream approach typically works much better.

---

From: "David Benham (dbenham)" <[email-masked]>
Date: Thu, 21 Jul 2016 12:37:14 +0000

Despite giving an additional answer below, I am also calling for +1s from this list in favor of ...
   a) not do this mapping to 7667 topologies now while still so much more PERC design work to do
          and
   b) do this mapping to 7667 topologies on the AVT-Core mail list and/or (joint) agenda time in future if needed

Selective Forwarding Middlebox (sect 3.7 of RFC7667) accommodates either SSRC termination/rewrites (separate space) or SSRC non-termination/no-rewrite (common space).

I checked with Magnus over a year ago that indeed SSRC termination/rewrites was not the only mode for 3.7 SFM's.
He did some rewording to sect 3.7 make that (mildly) clearer after our exchange.
https://www.ietf.org/mail-archive/web/avt/current/msg16699.html
https://www.ietf.org/mail-archive/web/avt/current/msg16700.html

-----Original Message-----
The framework document defines the MD as
"Media Distributor (MD): An RTP middlebox that is not allowed to to
   have access to E2E encryption keys.  It may operate according to any
   of the RTP topologies [I-D.ietf-avtcore-rtp-topologies-update] per
   the constraints defined by the PERC system, which includes, but not
   limited to, having no access to RTP media unencrypted and having
   limits on what RTP header field it can alter."

If we do not allow changing SSRC by the middle box then as far as I can see
this means that only Topo-PtP-Translator from RFC7667 is applicable for PERC
and not any other topology

Roni Even

---

From: "Roni Even" <[email-masked]>
Date: Thu, 21 Jul 2016 15:45:03 +0300

Hi,
What confuses me is that the framework document reference RFC7667 but does not say what is the PEWRC topology at all. So we are trying to define a solution to an undefined topology. This should be a PERC issue, not AVTcore, this is why PERC was formed

As for SFM it can have one RTP session to all participants but I assume it will still need some way to indicate the mapping of incoming streams to outgoing stream from the SFM otherwise the receiver does not know if there is one or multiple RTP sessions. This is what Emil suggested for identifying if SSRC are mutable or not.

Roni

> From: David Benham (dbenham) [mailto:[email-masked]]
> Sent: Thursday, July 21, 2016 3:37 PM
> To: [email-masked]; [email-masked]
> Subject: RE: [Perc] Request for decision review
> 
> Selective Forwarding Middlebox (sect 3.7 of RFC7667) accommodates either
> SSRC termination/rewrites (separate space) or SSRC non-termination/no-
> rewrite (common space).
> 
> I checked with Magnus over a year ago that indeed SSRC
> termination/rewrites was not the only mode for 3.7 SFM's.
> The framework document defines the MD as "Media Distributor (MD): An
> RTP middlebox that is not allowed to to
> this means that only Topo-PtP-Translator from RFC7667 is applicable for
> PERC and not any other topology
> 
> Roni Even
> 
> 
> 
>

---

From: "David Benham (dbenham)" <[email-masked]>
Date: Thu, 21 Jul 2016 13:01:29 +0000

Need to start an RFC7667bis to elaborate further on how an SFM works in SSRC non-termination/no-rewrite (common space) case?

-----Original Message-----
From: Roni Even [mailto:[email-masked]] 
Sent: Thursday, July 21, 2016 5:45 AM
To: David Benham (dbenham) <[email-masked]>; [email-masked]
Subject: RE: [Perc] Request for decision review
Importance: High

Hi,

Roni

---

From: "Roni Even" <[email-masked]>
Date: Thu, 21 Jul 2016 16:12:08 +0300

You do not need to change RFC7667 since to know if it is a SSRC terminating or not is not an RTP issue, it may be signaling issue and this is not AVTcore charter.
The PERC framework document must have clear text about what is in MD. It is too vague now in order to see if the solution addresses the specified MD.
The framework is the only architecture document
Roni

> Sent: Thursday, July 21, 2016 4:01 PM
> To: Roni Even; [email-masked]
> Need to start an RFC7667bis to elaborate further on how an SFM works in
> SSRC non-termination/no-rewrite (common space) case?
> 
> 
> What confuses me is that the framework document reference RFC7667 but
> does not say what is the PEWRC topology at all. So we are trying to define a
> solution to an undefined topology. This should be a PERC issue, not AVTcore,
> this is why PERC was formed
> 
> As for SFM it can have one RTP session to all participants but I assume it will
> still need some way to indicate the mapping of incoming streams to outgoing
> stream from the SFM otherwise the receiver does not know if there is one or
> multiple RTP sessions. This is what Emil suggested for identifying if SSRC are
> mutable or not.
> 
> Roni
> 
> >    b) do this mapping to 7667 topologies on the AVT-Core mail list
> > and/or
> > (joint) agenda time in future if needed
> >
> >
> >
> > Selective Forwarding Middlebox (sect 3.7 of RFC7667) accommodates
> > either SSRC termination/rewrites (separate space) or SSRC
> > non-termination/no- rewrite (common space).
> >
> > If we do not allow changing SSRC by the middle box then as far as I
> > can see this means that only Topo-PtP-Translator from RFC7667 is
> > applicable for PERC and not any other topology
> >
> > Roni Even
> >
> >
> >
> >
>

---

From: "David Benham (dbenham)" <[email-masked]>
Date: Thu, 21 Jul 2016 13:19:45 +0000

Sounds like knowing if an SFM is a SSRC terminating or not is already an issue ... perhaps something in signaling/RTCP.   
Seems incomplete interop for existing RFC7667 adopters before this PERC discussion came along.

Why didn't AVT Core already ask for this from another WG?

---

From: "Roni Even" <[email-masked]>
Date: Thu, 21 Jul 2016 16:46:29 +0300

Again, RFC7667 describes RTP level entities not how you signal functionality of the application on top of it. Using single or multiple RTP sessions in an implementation if both can be used in an RTP topology  is not AVT topic.

As for PERC, I am not arguing for changing or not changing SSRC in the MD. I am arguing that the PERC topology need to be clear.
Having a solution and then having the architecture is one way to design solutions (not my preferred mode) but it MUST also include the architecture and the framework definition of MD must reflect it.

The text for MD should be changed if SSRC cannot be overwritten to say that only the TOPO-PtP-translator and single session SFM are supported when signaling PERC support.

Roni

> Sent: Thursday, July 21, 2016 4:20 PM
> You do not need to change RFC7667 since to know if it is a SSRC terminating
> or not is not an RTP issue, it may be signaling issue and this is not AVTcore
> charter.
> The PERC framework document must have clear text about what is in MD. It
> is too vague now in order to see if the solution addresses the specified MD.
> The framework is the only architecture document Roni
> 
> > Need to start an RFC7667bis to elaborate further on how an SFM works
> > in SSRC non-termination/no-rewrite (common space) case?
> >
> >
> > does not say what is the PEWRC topology at all. So we are trying to
> > define a solution to an undefined topology. This should be a PERC
> > issue, not AVTcore, this is why PERC was formed
> >
> > As for SFM it can have one RTP session to all participants but I
> > assume it will still need some way to indicate the mapping of incoming
> > streams to outgoing stream from the SFM otherwise the receiver does
> > not know if there is one or multiple RTP sessions. This is what Emil
> > suggested for identifying if SSRC are mutable or not.
> >
> > Roni
> >

---

From: Miguel París Díaz <[email-masked]>
Date: Fri, 22 Jul 2016 11:09:38 +0200

We should take into account that when a MediaStreamTrack will be associated
to an RTP stream using MID RTP Header Extension instead of the SSRC, PERC
should allow rewrite this header.
The purpose is the same that allow rewriting SSRC nowadays.

2016-07-21 15:46 GMT+02:00 Roni Even <[email-masked]>:

> Again, RFC7667 describes RTP level entities not how you signal
> functionality of the application on top of it. Using single or multiple RTP
> sessions in an implementation if both can be used in an RTP topology  is
> not AVT topic.
>
>
> As for PERC, I am not arguing for changing or not changing SSRC in the MD.
> I am arguing that the PERC topology need to be clear.
> Having a solution and then having the architecture is one way to design
> solutions (not my preferred mode) but it MUST also include the architecture
> and the framework definition of MD must reflect it.
>
> The text for MD should be changed if SSRC cannot be overwritten to say
> that only the TOPO-PtP-translator and single session SFM are supported when
> signaling PERC support.
>
>
>
> Roni
>
> > Sounds like knowing if an SFM is a SSRC terminating or not is already an
> issue
> > ... perhaps something in signaling/RTCP.