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

Benjamin Kaduk <kaduk@mit.edu> Mon, 25 February 2019 02:37 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 E854C129619; Sun, 24 Feb 2019 18:37:27 -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 8LjuoEhgwveA; Sun, 24 Feb 2019 18:37:24 -0800 (PST)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on071b.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe46::71b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E333E130EA1; Sun, 24 Feb 2019 18:37:23 -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=NpbJsoZzlSEKEn/4mPIDSgXL+Ae3JGWYlArv9eMjzFQ=; b=RRTvN+osbX3b59aBG9vAcJVGZ4Q02GpTmtts+T6BVuWj4aPr+bLn+q4QxGRTus73k17Xdn8rAnatEL3UIdlG3ELngrQk9CBn2IJa6iY/sNe1PpJhMa82RXnVI3Iww8UResUnmWH5dxJdw3+DNvOCHQXpLsuVG+s+g+Jhp1cshQo=
Received: from MWHPR01CA0034.prod.exchangelabs.com (2603:10b6:300:101::20) by MWHPR01MB3295.prod.exchangelabs.com (2603:10b6:300:fd::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.16; Mon, 25 Feb 2019 02:37:21 +0000
Received: from CO1NAM03FT046.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e48::202) by MWHPR01CA0034.outlook.office365.com (2603:10b6:300:101::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1643.15 via Frontend Transport; Mon, 25 Feb 2019 02:37:21 +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 CO1NAM03FT046.mail.protection.outlook.com (10.152.81.15) 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 02:37:20 +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 x1P2bGNo032482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 24 Feb 2019 21:37:18 -0500
Date: Sun, 24 Feb 2019 20:37:16 -0600
From: Benjamin Kaduk <kaduk@mit.edu>
To: Justin Uberti <justin@uberti.name>
CC: Justin Uberti <juberti@google.com>, The IESG <iesg@ietf.org>, RTCWeb IETF <rtcweb@ietf.org>, <rtcweb-chairs@ietf.org>, <draft-ietf-rtcweb-fec@ietf.org>
Message-ID: <20190225023716.GG78133@kduck.mit.edu>
References: <155044278522.4109.16405267305237327974.idtracker@ietfa.amsl.com> <CAOJ7v-2FhqENy-fpj6mpFYSVJjp7DZ5MP=-TcP+sz-GTLDA1ow@mail.gmail.com> <20190225013238.GE78133@kduck.mit.edu> <CALe60zCyNUpP-ROwX9L1GYAJW-R2M3rUmGZYW02ujRoxwmJXsQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CALe60zCyNUpP-ROwX9L1GYAJW-R2M3rUmGZYW02ujRoxwmJXsQ@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)(346002)(376002)(136003)(2980300002)(199004)(189003)(51914003)(4326008)(478600001)(97756001)(75432002)(6916009)(106002)(26826003)(6246003)(966005)(1076003)(50466002)(47776003)(14444005)(6306002)(33656002)(956004)(126002)(16586007)(86362001)(486006)(316002)(476003)(93886005)(786003)(55016002)(36906005)(446003)(336012)(54906003)(229853002)(426003)(23726003)(11346002)(104016004)(58126008)(46406003)(305945005)(246002)(26005)(5660300002)(106466001)(88552002)(8676002)(2906002)(186003)(356004)(8936002)(53416004)(53546011)(76176011)(7696005)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR01MB3295; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; A:1; MX:1;
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: f81579d7-352f-44ee-0df4-08d69aca2ac2
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:MWHPR01MB3295;
X-MS-TrafficTypeDiagnostic: MWHPR01MB3295:
X-MS-Exchange-PUrlCount: 2
X-Microsoft-Exchange-Diagnostics: 1; MWHPR01MB3295; 20:o1tL9S2ZuUrSjXY/GU3qlnJ7Y6CyNG8mV7fpsxqaJFiQCGTdgqsuzUcmqtb4ghINi2i4RIjrUK+HMchS1/ixUHh5BAIDBPrJ0YVkoitlbgYo7mmJ+zhpnolqJQ6UkYrtdJOUJxFWLW11l/Tweo5fz7524ouvXsVthhxxkSqIZ1yztrPVbCMuEDTdlEqXsUD7yXIjrbRwPNydlVBhRAO3mPM1i3uxD08CzeBuC+sKmcpdMRgOB0qcZFYZjwRkTGNeAIY02J2AcqYNlcnELDDnJd1mnGp1vUdyrReoF0qWvW26+nunqZDJh6jci5sct06OjFC4l5kAHuwk9jRnXPzeJX/4BY61OA6DQRYZH8GCLm7WbEE7QMHsYy/bnlc0XoK963YVhFtpmeIKK4jQB+8u1bgqczCn8ki2CLdxQamfL3iQVxu+GZzdTni568jW8tCxuWZYdQnZwIpT+VBUEN9X7Dw7QD7PKC4HopNi5HoAexquYcCl5xecCPr2nlAi3ZxRqrHPFgl4Wx433jq287E79LlwEMOwQe9SMKI8IQ1FQOpnFkbnllIxy0cXXRar3J6yASwo5fxru8oN9Bx2CnkgH9H/7IM5CnPDb8tK6fscixQ=
X-Microsoft-Antispam-PRVS: <MWHPR01MB3295DBC9F5B9D1B54E84E601A07A0@MWHPR01MB3295.prod.exchangelabs.com>
X-Forefront-PRVS: 095972DF2F
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; MWHPR01MB3295; 23:fikkKQ5RLB9oL8QskPUXazeoEk2dbCdVwDR7gSdHg?= =?us-ascii?Q?pfdvoH/1fkJDZzGK0I5CW0Th0nQ8QIiDuwV2pmuueiq5mkjpWSJf2CHagHJ/?= =?us-ascii?Q?Uyd/UduvP/iDpqWzM0zF7zYHMTzam56i7n+m/VPfdrYsNezaqBThBvbDQcQW?= =?us-ascii?Q?mMrxMX3rV5fSyJMnXC3Bi+YbrSUsDwHFZOfkxIphSWk4idgJuuATfqtkeXAM?= =?us-ascii?Q?AfUjDlxl8CBwjnSyk224pylWbqjAV/UUxuDivL37fdg5n4Xp4jdVmUS1YUY3?= =?us-ascii?Q?akO2b2Ybsb8vYMu5SadCrUXSEwVoqma9y7LyamnWagTrYZR6QHxaxJH08hb6?= =?us-ascii?Q?bAnaYT7wyO4BjtN1Ek2K4+JgTL7lTeSCfTCjGwx2DXU3FqyaYcvPQVcPnVhW?= =?us-ascii?Q?8gFnTqBVKVx+i/IMJs2mRLbwp/hHQEoWg55JndBwgh9R8KAHQ+20dhVFgZP2?= =?us-ascii?Q?BUP6F9FYR6/KnCnE8w61CtUBmnTAqRwU+2onvG7lf+lu3apASU7IlgiBSMKS?= =?us-ascii?Q?rFQntZ2fbotV+BxWCFu9VnJUn9uHEZ8AGfaxmKEwx9F0u8ikGSioZbkL/aIr?= =?us-ascii?Q?ihWLMmild6u7F9k2RDwL6djWDTx3vzjDKXxdCqX6EVXRdHzgfQmV8maiv6hi?= =?us-ascii?Q?e93AK+c2xQ0AUPioqT5SmVFV40S1Ii7qdpbdAQPs5/u4R1cE5HAKICR8yNkN?= =?us-ascii?Q?fRNZBF2+MyD+3keQPr/bqWQ0y1W45vDwU4D28Uvvk5p8d7LXkCXYN6FK3850?= =?us-ascii?Q?m39Tyy6tj8hepa/HBufssbriuBQnhJa0uunHT5OZZFDtpj5kLT4xgPGSod6z?= =?us-ascii?Q?msw9Dj9ocWPajqcJW7AvSBV36miI7POwsx2HKUXFlgkx1DiDuY1HLlXAL7ry?= =?us-ascii?Q?9q6V4L6vooo+YKsfpqAKGeePxWBPC9dx17TEENJaNNdFieEuaITewXGZkevq?= =?us-ascii?Q?YmsihtK+PpR324TuewwXbT3FO4LaQQUd1p6GBIe3tHVvCLxBYCl7kaH9TYHB?= =?us-ascii?Q?ggrYAM4BRumHaEfRUk9NAkxwkQOydVNWHmDXijkDK/HW0Jzt2DwfszqKgCIM?= =?us-ascii?Q?tUDfoO+OzQ/Ylnvasolr8rkLjZ66r/8JKFUzNcSOToksk3wnCPkZZdx8FzPs?= =?us-ascii?Q?7AqoYIst21d+3Z84j2IYHSehGJzCr5mAr09RfNgwF0Qvjg9ob9+VNM3k/Le3?= =?us-ascii?Q?sGLkgiChxvA5RWJw4Ol5Z9k9vT09VZ31ENxYTTxtm4tBhB76cqi1rEkHLPop?= =?us-ascii?Q?9UBY/hX8r7TXd53vE4GadPJEcks6bCSclME5NMMO5kgmGiKRiGF+6IQ/IxzT?= =?us-ascii?Q?LXCBtiNMJdlgZDycAED1olkZTvyYO5PsCoN+nrw0h6z?=
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Message-Info: XH+RTsvUmr+AodNop4hfsxRemUsrVTP5YpGN3y/Dl+wkdZiVVOpLOFhA4UMAibOMoaXn6ZOsqr+6j9gojscyp9ErsEkNe6DSb/uMHEUDNrcbb1oUFwVSW7am08a5kJmNpPaOyzcu1O0WEc0wTTaMSLCE58WXhUAxAQV/D0dJwtaruOWkFqwsCDU6xC66mMEx7GWS7p6AjUEPGMCspKXjUBdubFEQ3Z243Wyh1dZk3H/NkMtQKa0T1BVPYQx8gJh3SKccefddsAaZtMN0KauOaQlxjQ87PLV+Hlx8y+XoBTy0DxL7hYo1nsXWHxjzJ7WS0hD0RepKkn2e6AH0syS7TWh2GxrW23iSo4hB0H+XrazbyosXJKwWQBniWd3vQLFScABDRDQj653Gb8TcHeiuB4cm6bAEu+Hcb2i3YJxdnaM=
X-OriginatorOrg: mit.edu
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Feb 2019 02:37:20.4985 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: f81579d7-352f-44ee-0df4-08d69aca2ac2
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: MWHPR01MB3295
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/5AzODAyIA__wan7kds-CO5r0wDQ>
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 02:37:28 -0000

On Sun, Feb 24, 2019 at 06:16:06PM -0800, Justin Uberti wrote:
> On Sun, Feb 24, 2019 at 5:32 PM Benjamin Kaduk <kaduk@mit.edu>; wrote:
> 
> > 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?
> >
> 
> This document incorporates multiple FEC schemes, so there isn't another
> overarching document (to my knowledge) that captures all of the mechanisms.
> 
> The intent here was to say "Because FEC, in general, always causes...", but
> open to other phrasings.

Ah, I see now.  I think what would help is "in contrast to methods like RTX
or flexfec (when retransmissions are used) [I-D.<...>]"

> 
> > > >
> > > > 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.
> >
> 
> It's really just a reiteration of an existing point from RFC 3711 to head
> off common questions about the interaction of FEC and encryption.

Okay.  Thanks for confirming!

-Benjamin

> >
> > Thanks for the updates and confirmations of my understanding,
> >
> > Benjamin
> >