Re: [rtcweb] Benjamin Kaduk's No Objection on draft-ietf-rtcweb-fec-08: (with COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Mon, 25 February 2019 01:32 UTC

Return-Path: <kaduk@mit.edu>
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 2B4E0130EB0; Sun, 24 Feb 2019 17:32:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mit.edu
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 RHngWYePdObm; Sun, 24 Feb 2019 17:32:46 -0800 (PST)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-eopbgr800109.outbound.protection.outlook.com [40.107.80.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C324A130EAE; Sun, 24 Feb 2019 17:32:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TrtZzWiT6/fkVgZg8lf9Zx54dQBskrwLlsGXZW4XBm0=; b=s+f9TzgqYVigfm0bWyzguwyiadqo5gC7coc1zBlMAyz7OgQkYBbpXdDbac2IVIebDiam+0XFUqk8ljVm5AFWxGtv2CP05LhDH1nXxJ5sbaCdGTDVy2ETBqbOJjoqH3Dhf8D5Tdk8flerjmCCLvHY9dwos0aSnEfGgTjs4MbSwQs=
Received: from BYAPR01CA0058.prod.exchangelabs.com (2603:10b6:a03:94::35) by SN6PR01MB3998.prod.exchangelabs.com (2603:10b6:805:27::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.14; Mon, 25 Feb 2019 01:32:43 +0000
Received: from BY2NAM03FT063.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e4a::204) by BYAPR01CA0058.outlook.office365.com (2603:10b6:a03:94::35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1643.21 via Frontend Transport; Mon, 25 Feb 2019 01:32:43 +0000
Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu;
Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu;
Received: from outgoing.mit.edu (18.9.28.11) by BY2NAM03FT063.mail.protection.outlook.com (10.152.85.182) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1643.13 via Frontend Transport; Mon, 25 Feb 2019 01:32:43 +0000
Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x1P1WdYd015650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 24 Feb 2019 20:32:41 -0500
Date: Sun, 24 Feb 2019 19:32:39 -0600
From: Benjamin Kaduk <kaduk@mit.edu>
To: Justin Uberti <juberti@google.com>
CC: The IESG <iesg@ietf.org>, RTCWeb IETF <rtcweb@ietf.org>, rtcweb-chairs@ietf.org, draft-ietf-rtcweb-fec@ietf.org
Message-ID: <20190225013238.GE78133@kduck.mit.edu>
References: <155044278522.4109.16405267305237327974.idtracker@ietfa.amsl.com> <CAOJ7v-2FhqENy-fpj6mpFYSVJjp7DZ5MP=-TcP+sz-GTLDA1ow@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAOJ7v-2FhqENy-fpj6mpFYSVJjp7DZ5MP=-TcP+sz-GTLDA1ow@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(396003)(39860400002)(136003)(346002)(376002)(2980300002)(189003)(199004)(51914003)(246002)(5660300002)(46406003)(8676002)(54906003)(106466001)(76176011)(7696005)(11346002)(33656002)(956004)(1076003)(2906002)(106002)(126002)(486006)(356004)(14444005)(53416004)(476003)(97756001)(305945005)(88552002)(6246003)(4326008)(104016004)(53546011)(23726003)(426003)(446003)(336012)(186003)(26005)(50466002)(8936002)(26826003)(478600001)(75432002)(966005)(229853002)(47776003)(316002)(786003)(36906005)(86362001)(55016002)(6916009)(58126008)(6306002)(16586007)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR01MB3998; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; MX:1; A:1;
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 275cf920-11f3-4527-8f3a-08d69ac12385
X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605104)(4608103)(4709054)(2017052603328)(7153060); SRVR:SN6PR01MB3998;
X-MS-TrafficTypeDiagnostic: SN6PR01MB3998:
X-MS-Exchange-PUrlCount: 2
X-Microsoft-Exchange-Diagnostics: 1; SN6PR01MB3998; 20:QB48f6DxZNsrE1iRB/Td9Q6igf05q+BV90IhcEpCNe2kIxZIe6ShtPGlKE++LWF9diCi+UKPVScZx7Vsem1XvTX5Le+dL67NG3355R0oMI4GsOZqdiIpp0C9JuAW4WWpgwaNqsLXnUn9Hkb9XzNoNZIegPBkzyag8E9rfwnl884GKKPRcgDvc3EDM8hCKf4qWchux5Kr5n4OhVpN/Of0UytsIOjBJpM+VLwX0uuMHxLJKkgoPiF7mfmSa0efCat0sIlHa4/b0P4Uu8Ps12l1A2CWmLvisObQQ4vWH7x/GklDAFLcw/B9KPTNgV8Z4DJjO4xsC5v2sYbRb3PSVpyzZHF9Bz58Py1hBcaxpA2TUnPVc/y5jGTeHehwpbuO7pekD3OVDp/LW2ioOeIVfsJmfGZstyApjxniGblNbbwL15VVpcVMasbfPXyWcDWEGtqdeSziMcmswZjMVPB9NHxtervEwrhsAOuvc0MNbWPLPjDSo90hZeYcCuOSGJFNvt0EnS+5YcFVP5cTUOpZJWBDSFjduw9LGwXpav3gr8LZTh1jMPeko9ZFU5u8/TW3HPS/rsx1qFbmTfMDc1wrspMzpLCgVlMdkod3vT80K3c8yck=
X-Microsoft-Antispam-PRVS: <SN6PR01MB3998F6B9721A7BBC8CF8F9C7A07A0@SN6PR01MB3998.prod.exchangelabs.com>
X-Forefront-PRVS: 095972DF2F
X-Microsoft-Exchange-Diagnostics: 1; SN6PR01MB3998; 23:f7+4fzQhh6Ywelfq2gp1Z6pmUr5BvrWjapkHWnEsRhQJjWo9Gcr6hIW2Ne0wWQph0hB5mD8H5iG/RsJLQBdazVUEzmpBQBEUzj8h3+CXJIwlN4xFRmhnScuW0BVW2ff4AZIEjcab0U9M8kICo9JGf2vTZNPCRdZxiTNHNNmfanB/f+Iwoty21IA29ut+dIK6VjMu9kM1srdCc/j0oExq0A3pkQk9YYXousePORgLAbZyTAXEVqYUK5Ii0QVwEIfKOQqBUnYoRW319p7fCAFnvPwh7nDayBuL/AJL9/AZi96FaE7bO5pomUiuJIF+25WNX8KabZOV3lcqftPuG3b4tUpIEElwxKPtW+lm1P/L0WXifbGRDO0w+gVfnXlPaA1GnI2JIpwP4WwZOvW7xrLmo+AufVDmBi8bPygczCaUVxJmMAGQIleVls8Vf+auOabEql17zUHSyxvV1YkFyJ4cpKbhQW0y5sbFYWgKlMVrsPG5GPh73l1Ugz+jGZTQpxbhlDdFauaoUBudp16kdA9Vl9BTfZlOVg5ONVHMN11W0lqiodyJhgYy9YBBC4EcQ/kGKReuMQNFJ/okIYVjqeVfqVbe5+9NVoT0bVHNOvZfHM0oHWjbDbdA1BDpGgNVWDFv4HBNq+R3OH7C3kmlsJeOqNSNxrYjvW/NB335+qa8KxtVKmY8tEFfW/LGMIH91ry8Y7nxQmr/UAlqE1ERg44ioPvoVpPhEf7IQyK6H7MPGW8W5mVnmBoW3Mll7Jna+7BAA6x4kwNG6yYQcaJN4URLwEiAEHmXWVyXVhukfP9EnBvDY3L0nozc2T55tqNFK86hHuEyxK6ScHd58Jk7vU6b5OHHkTzyWWyj3RJo0eCQPB7XGcmPpdmuj/KuVXAeZiMc+78GqQOW1MH6ZD+/pwzXfvhRODE8icPi5M9udgJDGBREmEsncAjrE8Ttu2gbDb3FZ9ZJJSmSEUD7woizheXVUb9HHUkx/HeY5fgtgUJhXF9z4ZuCK60SH/FCDGLwhNUcon8U9uWPTD7AoPfyTxWLAjsYrajkD2oBSuWnR0NFJKFFJvne4WD+5TVPMwsl7SZxinhMtFwdDvmeHIKqtf4G0uWYiyQRUCrfHillyxAAoIjgSY1FeTJkBaUqPPvEhWEO80jKX4inPL2HZl6dmIyi+lTXRXAq6jqn5WHGBr2ZNYtWDt6b0oDl3njYA9IHIohLFiOpfTeMVWvll1yyBhDcaeLD9D+XC/IHfwXDQALpA5yEVzVqYFROI5dORzgxEaT8FnmP+GuomET9zbXFlY0jdUHpfnCPtw+pfEgsczvD2pg=
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Message-Info: DE6NpB++//XtY+mktI6tOIJdnJHN5eWOEcQ/ebs9RJHGeEVqC9hCtfJpONjS9e+ai+zKQuCi/IZgaqMaeW7SvJVePJpcXS8bDUChEkY1DpGC3T3VBO6nqYbFJd3HJjlj7s1NGsaodYOruE2PI39kla5gZdVir7outZP/nvXVOGhn38C3nab0nWPf7Z9wP0ysZKE3xvLb0+6wHUpqOehzWh5TS1dTT9BTSVci51uQ0qa5GJu5ScX6G53CGbBeMoLG1EpHVVECVd6/jP29wtFKs12LTrXnq9YvyTB7c9WFuMZqPpE3G+SW828yVjeLefdFQN9/rhrV7QUop1UZxfEmT676Hsxdfyh4qoegf8y8vCL4c5IGSP7UwglkHJcCnzN7sQjpXFdB8QSdntwF7uZqltVpAMpQySi424B68ucI2m0=
X-OriginatorOrg: mit.edu
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Feb 2019 01:32:43.0931 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 275cf920-11f3-4527-8f3a-08d69ac12385
X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR01MB3998
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/EOoSzgQAeCyTjd9EJEybQ2re1vg>
Subject: Re: [rtcweb] Benjamin Kaduk's No Objection 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: Mon, 25 Feb 2019 01:32:49 -0000

On Fri, Feb 22, 2019 at 05:10:35PM -0800, Justin Uberti wrote:
> Thanks for your comments. See below.
> 
> On Sun, Feb 17, 2019 at 2:33 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
> 
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-rtcweb-fec-08: No Objection
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> >
> >
> > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-fec/
> >
> >
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > Section 3
> >
> > nit: The subsequent discussion seems to indicate that at least some of
> > these mechanisms are already specified and not new in this document; (if
> > so) it would be nice to have the exposition reflect that.
> >
> > Section 3.3
> >
> >    For Opus, packets deemed as important are re-encoded at a lower
> >    bitrate and added to the subsequent packet, allowing partial recovery
> >
> > Is "added" supposed to be something other than "appended" (which strongly
> > resembles the "redundant encoding" of the previous section)?
> >
> 
> It's similar to the redundant encoding, but done within the Opus bitstream,
> rather than at the RTP level.
> 
> >
> > Section 4.1
> >
> > Does it make sense to give subsection backreferences when talking about
> > (e.g.) redundant encoding?
> >
> 
> Yes, this could be done easily.
> 
> >
> > Section 5.2
> >
> >    Support for a SSRC-multiplexed flexfec stream to protect a given RTP
> >    stream SHOULD be indicated by including one of the formats described
> >    in [I-D.ietf-payload-flexible-fec-scheme], Section 5.1, as an
> >
> > nit: Since this Section 5 is solely for video, is it more appropriate to
> > refer to Section 5.1.2 ("Registration of video/flexfec") of
> > draft-ietf-payload-flexible-fec-scheme?
> >
> 
> Agreed - earlier versions of flexfec were slightly different.
> 
> >
> > Section 7
> >
> >    To support the functionality recommended above, implementations MUST
> >    be able to receive and make use of the relevant FEC formats for their
> >    supported audio codecs, and MUST indicate this support, as described
> >    in Section 4.  Use of these formats when sending, as mentioned above,
> >    is RECOMMENDED.
> >
> > Just to double-check: this is explicitly only mandating FEC for audio and
> > ignoring video entirely?
> >
> 
> This para only applies to audio. The following para discusses video, but is
> SHOULD-strength given the relative newness of flexfec.
> 
> >
> > Section 8
> >
> >    Because use of FEC always causes redundant data to be transmitted,
> >    and the total amount of data must remain within any bandwidth limits
> >    indicated by congestion control and the receiver, this will lead to
> >    less bandwidth available for the primary encoding, even when the
> >    redundant data is not being used.  This is in contrast to methods
> >    like RTX [RFC4588] or flexfec [I-D.ietf-payload-flexible-fec-scheme]
> >    retransmissions, which only transmit redundant data when necessary,
> >    at the cost of an extra roundtrip.
> >
> > This seems to imply that "FEC" is a specific usage and that flexfec is not
> > a subset of generic FEC.  If so, this could probably be reworded to be
> > less confusing to the reader (though my suspicion is that the "always
> > causes redundant data to be transmitted" is only intended to apply to
> > specific mechanisms from Section 3).
> >
> 
> flexfec is not quite a subset of generic FEC, since it also has a
> retransmission format. Thoughts on how this could be reworded?

I think it would need to be "Because use of FEC in the form of <something>
always causes [...]", but I'm not entirely sure what <something> is.  Is it
just "this document" or is there a broader framework or structure to which
this document adheres?

> >
> > Section 9
> >
> > This document seems to be agnostic on the question of RTP vs. SRTP; I would
> > consider referencing their respective security considerations as well as
> > what is already covered here.
> >
> >    As described in [RFC3711], Section 10, the default processing when
> >    using FEC with SRTP is to perform FEC followed by SRTP at the sender,
> >    and SRTP followed by FEC at the receiver.  This ordering is used for
> >    all the SRTP Protection Profiles used in DTLS-SRTP [RFC5763], as
> >    described in [RFC5764], Section 4.1.2.
> >
> > I was going to comment about the lack of clarity here, but I see that Ekr
> > has already gotten the core points, and that the secdir review has already
> > resulted in some chanegs in the editor's copy.  It would be nice to have
> > the result of the (merged) edits available to look at, though.
> >
> >  Here's the latest text. Let me know if this needs to be further clarified.
> 
>       In the WebRTC context, FEC is specifically concerned with recovering
>       data from lost packets; any corrupted packets will be discarded by the
>       SRTP <xref target="RFC3711" /> decryption process. Therefore, as described
>       in <xref target="RFC3711" />, Section 10, the default processing when
>       using FEC with SRTP is to perform FEC followed by SRTP at the sender, and
>       SRTP followed by FEC at the receiver. This ordering is used for all the
>       SRTP Protection Profiles used in DTLS-SRTP
>       <xref target="RFC5763" />, which are enumerated in
>       <xref target="RFC5764" />, Section 4.1.2.

This is a lot better; the only thing that I might wonder about is whether
the "this ordering is used for all the SRTP protection profiles used in
DTLS-SRTP" is a new requirement imposed by this document or if that's
supposed to be something that is stated in one of the references.

Thanks for the updates and confirmations of my understanding,

Benjamin