Subject: Re: [Perc] Consensus call: SSRCs are immutable

From: Bernard Aboba <[email-masked]>
Date: Sun, 15 Nov 2015 15:09:29 -0800

Mo said:

"Specifically, even without simulcast, the MSM and SFU RTP topologies which
rewrite SSRC would not be allowed in PERC per the proposed rule on E2E
SSRC.

"

[BA] Given the popularity of the MSM and SFU RTP topologies,
disallowing them in PERC is not very practical.  As Emil has noted,
even simple use cases (like simulcast) are implemented with these
topologies today.

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 15 Nov 2015 19:33:07 -0500

Bernard,

While I think it's possible to allow these devices to change the SSRC or sequence number, I still think it is worth revisiting whether we need to allow that for perc.

The middle box will have very little visibility into what it's forwarding.  For whatever purpose a legacy device had for changing these values, do they still apply?

If we really do go forward with allowing these changes, do we also want to make these middle boxes responsible for preserving the original value? Or, do we want to insert that into the payload?

Given that perc changes what middle boxes can even see in the packet, I think it's reasonable to question what limited set or new set of topologies we allow.

Paul

-------- Original Message --------
From: Bernard Aboba <[email-masked]>
Sent: November 15, 2015 6:09:29 PM EST
To: [email-masked]
Subject: Re: [Perc] Consensus call: SSRCs are immutable

Mo said:

"

------------------------------------------------------------------------

_______________________________________________
Perc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/perc

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 15 Nov 2015 18:08:16 -0800

> While I think it's possible to allow these devices to change the SSRC or sequence number, I still think it is worth revisiting whether we need to allow that for perc.

[BA] PERC is talking about limiting the operation of a device (the MDD) whose operation has no definition.

Since the MDD presumably has no access to the payload, it is not a mixer. It also apparently is not an SFU or MSM.  So what is left? Is it an RTP translator? 

> The middle box will have very little visibility into what it's forwarding. For whatever purpose a legacy device had for changing these values, do they still apply?

[BA] The modification of the SSRC field is an operation that is intrinsic to a number of RTP topologies and middle box types.  From what I can tell, SSRC modification is growing more prevalent, not less - it is now being done by SBCs as well as the vast majority of SFU implementations. 

If those RTP topologies are prohibited, the question is which ones remain and what audio and video conferencing scenarios can be carried out with them. 

The considerations may differ between audio and video scenarios. As an example, in PERC audio mixing would be replaced by forwarding. Since mixing of Opus is not widely implemented anyway, for Opus audio conferencing it may be ok to not modify the SSRC as long as the SFU has the information it needs to drop audio frames (such as the client-mixer header extension?)

> If we really do go forward with allowing these changes, do we also want to make these middle boxes responsible for preserving the original value? Or, do we want to insert that into the payload?

[BA] It is possible to add fields to the payload without restricting the applicable RTP topologies, but of course there are disadvantages -  a PERC middle box cannot adjust for differing path MTUs as a MANE can, so this could lead to IP fragmentation, unless there is a way for end points to determine the appropriate MTU, either on their own or with assistance from the middle box.

> Given that perc changes what middle boxes can even see in the packet, I think it's reasonable to question what limited set or new set of topologies we allow.

[BA] It is indeed a reasonable question, but one that requires substantial analysis to understand.