Re: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-fec-08: (with COMMENT)

Ben Campbell <> Sat, 23 February 2019 00:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 149BE130ED1; Fri, 22 Feb 2019 16:57:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bfRgEKgVAUDy; Fri, 22 Feb 2019 16:57:16 -0800 (PST)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3B99112D4ED; Fri, 22 Feb 2019 16:57:16 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id x1N0v7Ol025418 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 22 Feb 2019 18:57:09 -0600 (CST) (envelope-from
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=default; t=1550883430; bh=Z2aRgokIl0/7f0N7HOZNw69+Pw7EOBVJ8cOkM4KOyj8=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=X5UA1IAwlxqQjpT76w/G/FLx7yXt+C8/Qby7lkZGtAP/tzx1ZO6x7fqp9kXVAza3O 3H1TOvmbDyqMNnGWOUVc63kRx4QP1Dcsi3Epe4gQbLtr/NZvm7fJJzFHGcHbJPUsWk vJ1qSMrAzNSgH4WPRN6PlM4jJmx7fPUkNGRWZshE=
X-Authentication-Warning: Host [] claimed to be []
From: Ben Campbell <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_606450F9-7D0E-430A-BF0F-CA08D0DA20E9"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Fri, 22 Feb 2019 18:57:05 -0600
In-Reply-To: <>
Cc: The IESG <>, RTCWeb IETF <>,,
To: Justin Uberti <>
References: <> <>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <>
Subject: Re: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-fec-08: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 23 Feb 2019 00:57:18 -0000

Thanks for the response. Comments below:

> On Feb 22, 2019, at 6:31 PM, Justin Uberti <> wrote:
> Thanks for your comments. See below:
> On Wed, Feb 20, 2019 at 9:56 AM Ben Campbell < <>> wrote:


> ----------------------------------------------------------------------
> Thanks for this effort. I am balloting "yes", but have some minor comments:
> §8:
> - "Given this, WebRTC implementations SHOULD consider using RTX or
> flexfec retransmissions instead of FEC when RTT is low,"
> "consider" seems vague for a normative requirement. Can you describe concrete
> requirements? Otherwise I suggest descriptive language.
> Perhaps "prefer" rather than "consider" would be less squishy.

Prefer is better, thanks.

> Can you give guidance on what RTT would be reasonable to consider as "low"?
> This is somewhat application-dependent, but ~100 ms would be a reasonable threshold.

Would it make sense to say that the threshold for “low” is application dependent, but that would be a reasonable number for “typical” applications?

> - "Note that when probing bandwidth, i.e., speculatively sending extra
> data to determine if additional link capacity exists, FEC SHOULD be
> used in all cases."
> I assume the point of this is the redundant FEC data should _be_ that extra
> data. But one could read this to mean that, if you are already sending extra
> data, you should also use FEC.
> I see what you mean, agree this could be clarified.


> §9, 2nd paragraph:
> I'm by no means an expert in this, and leave it to the crypto experts to know
> if this matters, but does the additional redundancy of FEC have any impact on
> SRTP encryption?
> My understanding is that the fact that FEC is sent as its own stream with its own IV means that even if the data was identical to the primary payload, there would be no issue.

Is that true for the case of in-band FEC at the codec level?

> But given that no new mechanisms are being proposed in this document, it's probably covered elsewhere.

I can accept that argument.