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

Ben Campbell <ben@nostrum.com> Sat, 23 February 2019 03:51 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D41F113103F; Fri, 22 Feb 2019 19:51:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2Jmy5wTEfZY; Fri, 22 Feb 2019 19:51:34 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5512D130EE8; Fri, 22 Feb 2019 19:51:34 -0800 (PST)
Received: from [10.0.1.29] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x1N3pSVh052957 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 22 Feb 2019 21:51:31 -0600 (CST) (envelope-from ben@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1550893893; bh=Y9VN/aPX4CSzx9611QLFycOQO8JzBjNvVIs3YqUkYTA=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=GUV9JKzGF2WP3yapIkAN7I5UFP57RDSgShrRqwnugmA3otRj3HeLohzHNTZlasZA6 Jt9biYpFjnUFmeUHqtkWCi5F2HnOQwa5+do0HiMsYq7bd7/SEwmJGAUrb32eAV5C3A ZP+scKJCDecvdvmexOT/36LduxzAij5WS8L/NooY=
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.29]
From: Ben Campbell <ben@nostrum.com>
Message-Id: <ABA28F15-4C23-4326-90A8-BD70E352165E@nostrum.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_A948554D-568E-41CB-BAF4-23F15CC50C17"; 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 21:51:23 -0600
In-Reply-To: <CAOJ7v-3=fsMzcg24FbDyRs6MC=w9jXqysoKxYEoAUpxHGRZ1tw@mail.gmail.com>
Cc: RTCWeb IETF <rtcweb@ietf.org>, The IESG <iesg@ietf.org>, rtcweb-chairs@ietf.org, draft-ietf-rtcweb-fec@ietf.org
To: Justin Uberti <juberti=40google.com@dmarc.ietf.org>
References: <155068537927.31452.11334457138991637471.idtracker@ietfa.amsl.com> <CAOJ7v-2HFn1uEYxqBp2ZyvbgwbDavOr8u9CNYo2bXdEeGeQggg@mail.gmail.com> <4C5C447B-3CAA-436C-A60D-432B4374C39A@nostrum.com> <CAOJ7v-3=fsMzcg24FbDyRs6MC=w9jXqysoKxYEoAUpxHGRZ1tw@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/cvdgs3LCnphxPpvPKCzaWNGcIEo>
Subject: Re: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-fec-08: (with COMMENT)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 23 Feb 2019 03:51:37 -0000


> On Feb 22, 2019, at 7:17 PM, Justin Uberti <juberti=40google.com@dmarc.ietf.org>; wrote:
> 
> 
> 
> On Fri, Feb 22, 2019 at 4:57 PM Ben Campbell <ben@nostrum.com <mailto:ben@nostrum.com>> wrote:
> Thanks for the response. Comments below:
> 
>> On Feb 22, 2019, at 6:31 PM, Justin Uberti <juberti@google.com <mailto:juberti@google.com>> wrote:
>> 
>> Thanks for your comments. See below:
>> 
>> On Wed, Feb 20, 2019 at 9:56 AM Ben Campbell <ben@nostrum.com <mailto:ben@nostrum.com>> 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.
> 
> Thanks
> 
>> 
>> §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?
> 
> In the RFC 2198 case, SRTP is once again run over a new packet, again with a new IV (from a new sequence number), and a new primary payload, so the cipher state will be entirely different when the previous data is re-encrypted. In the codec in-band case, you have a new bitstream, so there are no repeated bytes.

Okay, I’m convinced. Thanks!

Ben.