Subject: [Perc] Double PERC draft 5 and webrtc audio FEC

From: Sergio Garcia Murillo <[email-masked]>
Date: Thu, 29 Jun 2017 21:46:56 +0200

Hi all,

In the new double encryption draft that Cullen has just submitted, it is 
says:

7.3.  FEC

    The algorithms recommended in [I-D.ietf-rtcweb-fec] for audio work
    with no additional considerations.

But in ietf-rtcweb-fec it recommends to use rfc 2198 RTP payload for 
redundant audio data. The problem is that RED only protects the payload, 
and any RTP header extension will not be protected. That will prevent 
RED to work HBH as the receiver end will not be able to recover the OHB 
and perform the inner crypto on the recovered packet.

Best regards

Sergop

---

From: Alexandre GOUAILLARD <[email-masked]>
Date: Thu, 29 Jun 2017 13:11:50 -0700

Dear all,

The new double document is great and propose a lot of improvements. Thanks
for its author for the hard work (*).

I like the fact that a new section for RTX, DMTF, and other RTCP mechanisms
has been added to reflect the recent discussion on the mailing list. The
relaxing of the end- to end constraints and OHB usage to include and
accommodate cases where end-to-end RTP header extensions are not needed is
a welcome improvement.

I am not sure that I want one big key with two half, each being used as a
separate key. Maybe we could propose this as one way to do it, to
accommodate the other drafts on key management and retrieval, but not
mandatory to implement perc-compliant double encryption not to restrict
people who would want to use double with their own key management and
retrieval. I do not feel too strongly about this, and could live with the
current text as is.

As the document states, the proposed solution does not propose a solution
for supporting RTX, and has Sergio pointed out, would not support RED (for
the same reasons it does not support RTX) and in turn, FEC. We believe that
it would be unlikely for an SFU to provide the same quality of service
without those mechanisms. We believe we also have a potential solution to
this problem with only a small twist around how to, and to what, apply the
end-to-end encryption.

Instead of going ahead and rewriting the document Sergio provided before on
the mailing list as a separate draft, we would prefer to speak with the
authors of the double draft and see if the solution we propose for the
inner encryption would be acceptable since it would allow support of
RTX/FEC/RED at, we believe, no cost and no tradeoff compared to the current
solution.

Cullen, Adam, P. Jones, would you be open to a quick chat this week? I am
on Pacific time right now, and Sergio is CET.

If us 5 could reach consensus here, and present a common document, from my
point of view, that would remove any remaining discussion point for the WG.

Best regards,

Dr Alex.

(*) Some typos left e.g.:

"
5.2. Relaying a Packet
The Media Distributor does not have a notion of outer or inner The Media
Distributor *does has*
*"*

On Thu, Jun 29, 2017 at 12:46 PM, Sergio Garcia Murillo <
[email-masked]> wrote:

> and any RTP header extension will not be protected. That will prevent RED
> to work HBH as the receiver end will not be able to recover the OHB and
> perform the inner crypto on the recovered packet.
>
> Best regards
>
> Sergop
>
>
>
> _______________________________________________
> Perc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perc
>
>

-- 
Alex. Gouaillard, PhD, PhD, MBA
------------------------------------------------------------------------------------
President - CoSMo Software Consulting, Singapore
------------------------------------------------------------------------------------
sg.linkedin.com/agouaillard

   -

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Thu, 29 Jun 2017 22:00:50 +0000

> On Jun 29, 2017, at 2:11 PM, Alexandre GOUAILLARD <[email-masked]> wrote:
> 
> Cullen, Adam, P. Jones, would you be open to a quick chat this week? I am on Pacific time right now, and Sergio is CET.

Totally agree that a call would be the best way to make some progress. Unfortunately I am traveling all next week and it is booked pretty solid but If we could pick a time on July 10, 11, or 12, I think I could make just about any time work on those days.

---

From: Dr Alex Gouaillard <[email-masked]>
Date: Thu, 29 Jun 2017 15:13:08 -0700

I m flying back to Singapore on 10, but will find a slot to make it happen.

Calendar invite to come soon.

Sent from my iPhone

> On 29 Jun 2017, at 3:00 pm, Cullen Jennings (fluffy) <[email-masked]> wrote:
> 
>

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 29 Jun 2017 16:43:44 -0600

> On Jun 29, 2017, at 1:46 PM, Sergio Garcia Murillo <[email-masked]> wrote:
> 
> Hi all,
> 
> In the new double encryption draft that Cullen has just submitted, it is says:
> 
> 7.3.  FEC
> 
> But in ietf-rtcweb-fec it recommends to use rfc 2198 RTP payload for redundant audio data. The problem is that RED only protects the payload, and any RTP header extension will not be protected. That will prevent RED to work HBH as the receiver end will not be able to recover the OHB and perform the inner crypto on the recovered packet.
> Best regards
> 

Let me just ignore for a second that we disagree on best way to do RED when using SRTP (never mind PERC).  My read of draft-ietf-rtcweb-fec was that 2198 is a "MAY" be used but that the "RECOMMENDED" approach for opus in hybrid mode (which is preferred for WebRTC) was just to use the FEC that is build into Opus.  All the data I have seen suggests that opus FEC outperforms RED in pretty much all ways RED typically gets used so this seems somewhat reasonable. 

But that said, if you think the draft should mention RED, glad to add it. Plus the sentence in the draft probably needs to explain what works means in this context.

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 29 Jun 2017 16:45:07 -0700

Cullen said:

"Let me just ignore for a second that we disagree on best way to do RED
when using SRTP (never mind PERC).  My read of draft-ietf-rtcweb-fec was
that 2198 is a "MAY" be used but that the "RECOMMENDED" approach for opus
in hybrid mode (which is preferred for WebRTC) was just to use the FEC that
is build into Opus.  All the data I have seen suggests that opus FEC
outperforms RED in pretty much all ways RED typically gets used so this
seems somewhat reasonable."

[BA]  Opus FEC can't handle burst loss, but RED can.  So if you have burst
loss (quite likely on wireless networks), RED can substantially outperform
Opus FEC.  I realize this would involve use of RED in an *atypical* way,
though.

Also, it's important to compare Opus FEC against concealment.  When that is
done, its benefits do not stand out.

On Thu, Jun 29, 2017 at 3:43 PM, Cullen Jennings <[email-masked]> wrote:

> Let me just ignore for a second that we disagree on best way to do RED
> when using SRTP (never mind PERC).  My read of draft-ietf-rtcweb-fec was
> that 2198 is a "MAY" be used but that the "RECOMMENDED" approach for opus
> in hybrid mode (which is preferred for WebRTC) was just to use the FEC that
> is build into Opus.  All the data I have seen suggests that opus FEC
> outperforms RED in pretty much all ways RED typically gets used so this
> seems somewhat reasonable.
>
> But that said, if you think the draft should mention RED, glad to add it.
> Plus the sentence in the draft probably needs to explain what works means
> in this context.
>
>
> > Sergop
> >

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 29 Jun 2017 18:03:03 -0600

> On Jun 29, 2017, at 5:45 PM, Bernard Aboba <[email-masked]> wrote:
> 
> [BA]  Opus FEC can't handle burst loss, but RED can.  So if you have burst loss (quite likely on wireless networks), RED can substantially outperform Opus FEC.  I realize this would involve use of RED in an *atypical* way, though.

I realize some people want to use RED so I'm not arguing that we don't need to worry about it. It seems with RED for burst loss you have to decide how long a delay you want on the RED packets - more delay gives better burst loss protection but worse latency. When you implement FEC in opus, you have to decide more or less the same thing of how much delay to put in the redundant coding. So I see them somewhat similar to burst loss. But not sure it matters much because I'm fine with trying to have a solution that works for RED.

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Fri, 30 Jun 2017 10:17:39 +0200

> I realize some people want to use RED so I'm not arguing that we don't need to worry about it. It seems with RED for burst loss you have to decide how long a delay you want on the RED packets - mor…

Hi Cullen, Bernard,

I am not against or in favor on RED. My point was just that in the new 
draft when it addresses the FEC part, it says:

    The algorithms recommended in [I-D.ietf-rtcweb-fec 
<https://tools.ietf.org/html/draft-ietf-perc-double-05#ref-I-D.ietf-rtcweb-fec>] for audio work with no additional considerations.

which is incorrect as RED cannot be supported HBH for the reasons 
mentioned on my original mail, and the draft should be updated to 
reflect that fact.

Deciding if RED is a good FEC mechanism for webrtc or not, while being a 
very interesting topic, I think it is outside of the scope of this group.

Best regards

Sergio