Re: [payload] Benjamin Kaduk's Discuss on draft-ietf-payload-flexible-fec-scheme-17: (with DISCUSS and COMMENT)
Magnus Westerlund <magnus.westerlund@ericsson.com> Thu, 21 February 2019 15:09 UTC
Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C93812F1A2 for <payload@ietfa.amsl.com>; Thu, 21 Feb 2019 07:09:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.699
X-Spam-Level:
X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_SUMOF=5, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=PvyvUte7; dkim=pass (1024-bit key) header.d=ericsson.com header.b=dL9mQTGF
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 6RYe7NDJFjqM for <payload@ietfa.amsl.com>; Thu, 21 Feb 2019 07:09:22 -0800 (PST)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2513D130DE3 for <payload@ietf.org>; Thu, 21 Feb 2019 07:09:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1550761757; x=1553353757; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=lswRbin0KTOWo4h5FWC3IRgN/77zCY/+xVVKeTjy/nk=; b=PvyvUte71WW1PXWP/WvTcnVL2Pe2CNGerc0T81MZWyC/0mQzTLuCbL+ZshHQGKKA JUyZF24IW0t9glVEKfoX5AKLLUFyAZjf5+3/vawTdzVKXSuigAejAjwNH/Iy8BtU PF5qzMOGgR72ZOhN1voWwq48/SvEYutfpmAJXnaGulI=;
X-AuditID: c1b4fb3a-5c9c29e00000672c-0e-5c6ebf1d099f
Received: from ESESBMB504.ericsson.se (Unknown_Domain [153.88.183.117]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id D3.3C.26412.D1FBE6C5; Thu, 21 Feb 2019 16:09:17 +0100 (CET)
Received: from ESESSMB502.ericsson.se (153.88.183.163) by ESESBMB504.ericsson.se (153.88.183.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 21 Feb 2019 16:09:16 +0100
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Thu, 21 Feb 2019 16:09:16 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lswRbin0KTOWo4h5FWC3IRgN/77zCY/+xVVKeTjy/nk=; b=dL9mQTGFGjDKzMdsk4UAeYF/VelKA2ZafU/JEIZsesPFA9io9OEk8WSJwnM6gMjZBwQjGcqCGzsiDl20+0ET3m0svX+FsiivX8q7aRg2yATkP3iN64zz1l2aiQVhP6pQa7L5G1sKSaqNos2T+exCT29in7doNxuYTTVKNgqmG0U=
Received: from DB6PR0701MB2517.eurprd07.prod.outlook.com (10.168.76.146) by DB6PR0701MB2917.eurprd07.prod.outlook.com (10.168.82.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.11; Thu, 21 Feb 2019 15:09:15 +0000
Received: from DB6PR0701MB2517.eurprd07.prod.outlook.com ([fe80::c12a:38ba:dd6:fc1b]) by DB6PR0701MB2517.eurprd07.prod.outlook.com ([fe80::c12a:38ba:dd6:fc1b%3]) with mapi id 15.20.1643.014; Thu, 21 Feb 2019 15:09:15 +0000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
To: Benjamin Kaduk <kaduk@mit.edu>, The IESG <iesg@ietf.org>
CC: "roni.even@mail01.huawei.com" <roni.even@mail01.huawei.com>, "payload-chairs@ietf.org" <payload-chairs@ietf.org>, "payload@ietf.org" <payload@ietf.org>, "draft-ietf-payload-flexible-fec-scheme@ietf.org" <draft-ietf-payload-flexible-fec-scheme@ietf.org>
Thread-Topic: [payload] Benjamin Kaduk's Discuss on draft-ietf-payload-flexible-fec-scheme-17: (with DISCUSS and COMMENT)
Thread-Index: AQHUx9RrE+qo8a/ki06DNNe3BRLJCQ==
Date: Thu, 21 Feb 2019 15:09:15 +0000
Message-ID: <DB6PR0701MB2517037171DD3C796EC0655F957E0@DB6PR0701MB2517.eurprd07.prod.outlook.com>
References: <155052681367.25946.18116200153523550938.idtracker@ietfa.amsl.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.176.1.93]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 8d3cda7c-2309-4a00-4888-08d6980e8b61
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:DB6PR0701MB2917;
x-ms-traffictypediagnostic: DB6PR0701MB2917:
x-ms-exchange-purlcount: 3
x-microsoft-exchange-diagnostics: 1; DB6PR0701MB2917; 23:Io+5eYfSJ7dFZTcj7Rbwu1/gWCoXdThIZy2uBiOS/TugRSgjDY/E4auL7X6Mxk1ZaobQSFaLwhHVzMciBpGbpFk+wPt2vy0t30cFDtswY0GSQQxs4myFH9jraCukY6pgSdrrM+nK3BvzCCpD2LdDccOSva9Jgh7V+jvQktDUeiI9DJd4rB7IUMzoZZcKQQLrijbI+T38hX5BWXWriN85MHELDm9v11F74O+AOKgls1NkcS2dgEYMo2CtRlGEddhjadev127qMRqqRsBZaukiE8ngBeZTW4ZCb9dxSLNYfJ/DM5alwqrY5lYK7Y1GX3IlReIbI+6qnDTxJsW5OF8dNNXOjCH0HzinWX1Oo1FJf+AjNzzOVjYnlW09gA/XGbwZZdRjkxZFbmxBLe8DLlny5JOdJkD+2T91xcL4w6ux4o9jt9xhzcqA8qN57jmrYr+8UUWeBC1ljV7xnID1a97/6zVNVgI7jKcdpBqawAwwf7NfzWHqitskCrxiMR2nl/gxupBKWnDAN7k2KM9qoHJgDG/xLNgGJaan+r9SkUSQwy/JvnKKeXwbGKywdRVMIhG+IngPpmR1TxY8Cer9hqkPdJy5+kpicBI09idmiyStG+PzcfVeV2mmVrxL1qR+e1wm2bwj/CEJm0FXAFb4c9DgRAj1KxUz8KwgZIwLxUW9T5Fp8/PA/B/VhFF3LAIHIhWrH0hnDXfNk6DTSWidaJNJwibXGaCH0Ve7i7++Y53coZwcfDedopG69kvLbyU9ZuHKdFNzrw2xCPEkrED3kqbmZgJWVqMrOqUEvdY105NILuGzJkx9UtRR/FZYzTJLeNDuPTESbfbVv6r/Av/CTAhQFrISY1H2SiU5RH1NYQLnhufGayCy8mQN0Jf7wXSc1rsFjuBgpBEDAhl150ltHPwXXP/bcxR+4+A/tZ5CGWI/qMdzOKys5Cuar4FJXXQ/v1aBRhN/H7QoXeC9YsC3YteXDQPgI9sEuAr/MFcunOgerTURjF3NzqRoSjne+93GRaVqvYHAtfsy6qC4Kvm/ow/jFdK1smQ1vlQqmHXVeAK685RljlaNjIjbZji30o9CWXL7Z26BbAt2fAq1E6rMcicjK5GIbYyZjhdBe160BWVL+j6WnnK0UAv9uUFVO6weHB8jDj21x6hhWexd+qoIY6dnQq0jzDAr4RvUJzzCV2X7ch4MeHLs+Qj/kO2kjKklUfbbbe8OZmPItm/qOjXPnhqzKyLSWRHxQwHDNSDXgdI6s5+BUYxBlfaLr00QBeeunDBbiXmgbktbnfJDrwlaZdvthu1rorXDVo1LeQGMZfuJOafdfavFJEKaLw7b+okeft9F
x-microsoft-antispam-prvs: <DB6PR0701MB291793D92F94C2E2FC9EC510957E0@DB6PR0701MB2917.eurprd07.prod.outlook.com>
x-forefront-prvs: 09555FB1AD
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(136003)(39860400002)(346002)(366004)(396003)(199004)(189003)(55016002)(9686003)(53936002)(7736002)(305945005)(4326008)(3846002)(6436002)(99286004)(76176011)(30864003)(74316002)(6306002)(446003)(7696005)(476003)(71200400001)(71190400001)(6116002)(44832011)(66066001)(229853002)(486006)(86362001)(54906003)(68736007)(102836004)(186003)(14444005)(110136005)(316002)(6346003)(478600001)(8676002)(6506007)(53546011)(2906002)(33656002)(26005)(256004)(5660300002)(25786009)(81166006)(2171002)(6246003)(97736004)(81156014)(8936002)(14454004)(106356001)(105586002)(966005); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR0701MB2917; H:DB6PR0701MB2517.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: DSY0WFt0OLg0evw4b1ub791PVtjwl0/YMfRFWVUB37PrGxSZ8bG44X4w6PuBB9xC5pLE/85fh+cx7B3ol44owYxg46kTzDl2BNRfpRWYVpN2deSGET2N4uukMJoq4tnOXb+SnN4am/CeWU567sTXn2/9zeNzEUUguFxRLnoJQ6bsF0ZUCqBUIMocMDw1xiAJgHDBhUKxeu9gOgHogzko1zeuHUsHvr+0EYjUSHFLBW1YELWBg2d2JWnBakyYLO+h2IkHPUPWTO2EezvL7Ccs4Ra1fQg3LnKhm48SrJ9Gc8AGBHWG0jUsShsm5ykDG/yB1n3+YFuDKebIA/MMBOa1InrapYcNIpVFlirDiUrD9CNIIx15P32Or2MrO+OFY24vEhDMYQ/VVvudxodySqijTZ1MRSPSw1b1efmLwOMh6mc=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 8d3cda7c-2309-4a00-4888-08d6980e8b61
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Feb 2019 15:09:15.3525 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2917
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02SfUhTURjGOfdju64mx6X4Yg1k6D85zTRplEiB2QiVirQQIYdedKRT7lVJ Iz9rmBqtgsxFpTnTVlam5qBC1BRkhqUWmthmrkQUivCz5sjtGvTf732f5z3neQ+HIWV36QBG q8tnOZ0mWyGSUPVnugtC5T261PCZbi/VxhSnuu28Tqpa2usJlcW+JlaNfnhHqByX1shDIrXJ tE6oLR12Wl0xPEAeJ1Mk0RlstraQ5fbEpEmyrLWJea0l5weGnGQZWk+vRl4M4H0w5loiq5GE keG3CJ6u6reKFQT3zDcJt0uGTQS0NHkEChtIMIx3igRXHQFda4+2CgcCp6VW5B4RYRVMrpV7 2BdHQ9P0G884ifUEdK620W5hBy4Go36WFEwXoL/qIy1wGDRbb3mYwsFgtpg9B0lxGtQsdm9m YjZvS4QrP4PcbYTlYFv9QrmZxP7w2XGfEJbDYHo9QgrsB/OzLto9CjgQbJMpQlsOo/drkMAJ 8OD7IHLHBDyFYLzVtiUoYWakTCxwADSOLIkF0w1vWBnrogUhF4zXBrdMu+DlQiMhmH7TUFG3 JBYekoWWtstISK2BifJvhAGFGv8LLrASGl79EgkcAg8bF0ijZ38fGKp3UA2IMiM/nuX5nMyI iDCW06bzfK4uTMfmv0Cbn6a3888BC+qdO9yHMIMU26XB7bpUGa0p5Ity+hAwpMJXGvR8syXN 0BQVs1zuWa4gm+X70E6GUvhLnTKfVBnO1OSz51g2j+X+qQTjFVCGvJ/MP/6Krx4MtQ/6pJWd sumz4iYWjzUti6tccYuUKcnREWQvFVnZyJMTXXOVP0wNFYbmUvWSn/RZzImeRWdEYUISVb5/ TmVopWN1MZVR3EX50dnIWmV6YE2/+f22DavjdAn3KXxYHh8V0tZjz5uO1ycna+/EKY+4Ypc1 4hkFxWdp9u4mOV7zF1MsmqUwAwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/payload/sy9NZwzBjS54vTpgmmXbeFZ2CGk>
Subject: Re: [payload] Benjamin Kaduk's Discuss on draft-ietf-payload-flexible-fec-scheme-17: (with DISCUSS and COMMENT)
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/payload/>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Feb 2019 15:09:25 -0000
Hi Benjamin, I am not one of the authors, but one that have helped beating on this document in the WG, so I think I can answer your questions. I think the authors should check what I say and check the last part of the comments. On 2019-02-18 22:53, Benjamin Kaduk wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-payload-flexible-fec-scheme-17: Discuss > > 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-payload-flexible-fec-scheme/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I'm confused about some parts of how I'd implement this. > It's quite possible this is just my error, but I'm including this point in > the Discuss section in case it's not. This basically relates to how > multiple recovery packets from a given FEC block get encoded and identified > on the wire, but also how to populate the source block when multiple SSRCs > are included. > > In short: suppose that I have D=3 and L=2. I should expect 5 repair > packets for the six source packets in a block; the scheme for determining > what order to generate them in and what their contents are is fairly clear > to me. But how do I identify them on the wire? I'm assuming that the D > and L on the wire are fixed values, since there's the possibility to only > send zero on the wire and negotiate their values out of band. It's a > little less clear whether the "SN base" fields are expected to be the same > for all 5 recovery packets based on a given block, but if they do change > then I'm not sure how I tell whether a given recovery packet is for a row > or a column. Is this supposed to be using the sequence number from the > outer RTP header for packet ordering, and the implicit order for row/column > FEC packets? (It seems that in case of very bad packet loss and dynamic > L+D, the receiver could then get out of sync as to what the sequence number > is that corresponds to the start of a new batch of recovery blocks.) So, if one are going to do a 2-D FEC code and have indicated that in the signaling, each repair packet is still either a row or column FEC. So a Row packet for your D=3 and L=2 2-D FEC configurations are going to say: Sn base= i, L=2 D=1 The rest of the Row packets for this block are going to have: Sn base=i+2, L=2 D=1 Sn base= i+4, L=2 D=1 Then the column packets Sn base=i, L=2 D=3 Sn base=i+1, L=2 D=3 >From a receiver perspective you are not actually not caring about what block structures the sender uses. You anyway only can store received FEC packet in a receiver buffer for the stipulated time. When a repair packet comes in one checks if that repairs any loss, otherwise stores it in the buffer. > I also don't see how, for the case when there are multiple SSRCs, I know > how many source packets to include from each SSRC in order to make up the > D x L source block -- since Section 6.2's discussion lumps all the "source > packets" together into a single set that get mutually xor'd, that seems to > imply that the encoding is not "do recovery for SSRC1, do recovery for > SSRC2, ..., concatenate them all". Well, for each SSRC one follows the SN base and L and D parameters. This results in a number of packets that the XOR is performed over. Does this help? Cheers Magnus > There are perhaps some other scenarios to worry about, such as interleaved > recovery within a single block, but I'm happy to focus on the single 2-D > case for purposes of illustration. > > Any insight into what I'm missing would be appreciated. > > > A couple other points to check on: > > I'm not sure I'm following the procedures in Section 6.3.2 properly (see > COMMENT) -- is the text correct as written? > > I also think there are a couple more factors worth mentioning in the > security considerations (see COMMENT). > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > It's a little odd to see so much content in Section 1.1 before we get to > requirements notation and defintions/notations. > > I think I'm a bit confused about current best practices for multiplexing, > as RFC 3550 Section 5.2 says "separate audio and video streams SHOULD NOT > be carried in a single RTP session and demultiplexed based on the payload > type or SSRC fields", but we seem to be not only recommending using SSRC > for demultiplexing repair packets, but also suggesting that the FEC can > cover multiple different audio and/or video streams with different SSRCs. > I guess RFC 8108 is supposed to clarify when it's okay to use multiple > SSRCs in the same RTP session, so maybe the answer is just "3550 was overly > cautious and we don't worry about that anymore". > > Section 4.2.1 > > Version (V) 2 bits: This MUST be set to 2 (binary 10), as this > specification requires all source RTP packets and all FEC repair > packets to use RTP version 2. The reason for this restriction is > the first 2 bits of the FEC header contain other information (R > and F bits) rather than recovering the RTP version field. > > nit: is it better to say that the FEC mechanism does not recover this > value, rather than talking about how the first 2 bits of the FEC header are > used for something else? (The FEC header's structure need not bear any > relation to the 12-byte RTP header, AFAICT.) > > Payload Type: The (dynamic) payload type for the FEC repair > packets is determined through out-of-band means. [...] > > Is "(e.g., SDP)" applicable here? > > Sequence Number (SN): The sequence number follows the standard > definition provided in [RFC3550]. definition. Therefore it must > > nit: drop separate "definition." > > multiplex multiple repair streams in an RTP session. The repair > streams' SSRC's CNAME SHOULD be identical to the CNAME of the > source RTP stream(s) that this repair stream protects. An FEC > stream that protects multiple source RTP streams with different > CNAME's uses the CNAME associated with the entity generating the > FEC stream or the CNAME of the entity on whose behalf it performs > the protection operation. In cases when the repair stream covers > packets from multiple source RTP streams with different CNAME > values, any of these CNAME values MAY be used. > > I'm not sure I'm parsing this properly; the penultimate sentence says that > the CNAME to use is determined by nature of the entity producing the repair > stream, but the last sentence says that there is a nondeterministic choice. > > Section 4.2.2 > > Any reason not to include "retransmit" and "fixed block" mnemonics for the > 'R' and 'F' bits? > > Please include a note here that several fields (e.g., P, PT, etc.) in the > FEC header are not meant to be interpreted directly but are instead actual > FEC parity data akin to the following "payload". (Absent such an > indication, the reader could see that these fields are "used to determine" > values when they appear to contain values directly, and get confused.) > > I would suggest adding a forward-reference to Section 6 since that > describes how the Repair Payload is calculated. > > Section 4.2.2.2 > > Should implementations set bounds on L and D that are smaller than the > maximum encodable value (255)? > > If L=0, D=0, use the optional payload format parameters for L and D. > > What is the behavior when those payload format parameters were not > provided? > > The L=1 case seems to imply that some full packet retransmission will be used; > is it worth calling that out as a consequence of such a parameter choice? > > Section 4.2.2.3 > > nit: The "P|X" bits in Figure 15 seem indented by one too many spaces. > > Section 5.1 (all subsections) > > Having the ToP values for interleaved and non-interleaved 1-D protection > presented in a different order than virtually all of the body text (that > presents non-interleaved first) is needlessly hard on the reader. > > What is the interaction between rate, repair-window, and the L and D > values? That is, if we set L and D to be large, and rate to be small, can > we end up claiming a repair window that is too small to accumulate the > necessary L*D source packets and compute recovery packets? > > Section 5.2.1 > > o The value for the repair-window parameter depends on the L and D > values and cannot be chosen arbitrarily. More specifically, L and > D values determine the lower limit for the repair-window size. > The upper limit of the repair-window size does not depend on the L > and D values. > > Per my above remark, this consideration seems generally applicable and not > limited to SDP Offer/Answer. > > o Any unknown option in the offer MUST be ignored and deleted from > the answer. If FEC is not desired by the receiver, it can be > deleted from the answer. > > This sounds like it is restating an existing normative requirement (in > which case a reference and descriptive, non-normative, text seems > appropriate). > > Section 6.2 > > o The first 16 bits of the RTP header (16 bits). > > Maybe note here that we'll actually ignore the first 2 bits? > > Section 6.3.2 > > 2. For the repair packet in T, compute the FEC bit string from the > first 80 bits of the FEC header. > > I'm scratching my head a bit at this. Is this operation something other > than "take the first 80 bits of the FEC header"? (If not, the length and > sequence number base seem to be in different places in the source packets > and FEC bit string, if I'm reading things right.) > > 11. Set the SN field in the new packet to SEQNUM. Skip the next 16 > bits in the recovered bit string. > > To be clear, we're skipping over the xor of the reconstructed length field > with the seqnum field of the source packets? > > 13. Take the next 16 bits of the recovered bit string and set the > new variable Y to whatever unsigned integer this represents > (assuming network order). Convert Y to host order. Y > represents the length of the new packet in bytes minus 12 (for > the fixed RTP header), i.e., the sum of the lengths of all the > following if present: the CSRC list, header extension, RTP > payload and RTP padding. > > I don't see how this matches up with the bit string construction in Section > 6.2. > > Section 6.3.3 > > 1. Append Y bytes to the new packet. > [...] > 5. Append the recovered bit string (Y octets) to the new packet > generated in Section 6.3.2. > > I think a different verb than "append" should be used in step 1, perhaps > "allocate Y additional bytes for the new packet", as the text as-written > has us appending 2*Y bytes, only Y of which have a value specified. > > Section 9 > > The main > security considerations for the RTP packet carrying the RTP payload > format defined within this memo are confidentiality, integrity and > source authenticity. Confidentiality is achieved by encrypting the > RTP payload. Integrity of the RTP packets is achieved through a > suitable cryptographic integrity protection mechanism. [...] > > This phrasing of "is achieved by" implies that the mechanisms for doing so > are defined in this document, but that's not the case. Don't we really > mean things like "Confidentiality can be provided by encrypting the RTP > payload"? > > Given that FLEX FEC enables the protection of multiple source > streams, there exists the possibility that multiple source buffers > may be created that may not be used. An attacker could leverage > unused source buffers to as a means of occupying memory in a FLEX FEC > endpoint. Moreover the application source data may not be perfectly > matched with FLEX FEC source partitioning. If this is the case, > there is a possibility for unprotected source data if, for instance, > the FLEX FEC implementation discards data that does not fit perfectly > into its source processing requirements. > > I don't think this text quite covers the risks when interacting with an > adversarial endpoint -- an attacker could try to advertise FEC schemes with > large D and L and/or large repair windows, that cause the receiver to > consume a lot of resources buffering packets that may be used as repair > inputs. Endpoints need to be aware of the risk when deciding whether to > accept FEC streams, e.g., via SDP Offer/Answer. > > Similarly, a network attacker could modify the recovery fields > corresponding to packet lengths (when integrity protection is not in play), > to force large allocations on the receiver. It's fairly likely that this > doesn't even require knowing which source packet(s) will be lost, since > length is a 16-bit field and the expected input values are not likely to > have the high bit(s) set. > > The need for integrity protection on the SDP Offer/Answer exchange is > probably sufficiently well-documented elsewhere that we don't need to > reiterate it here. > > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > -- Magnus Westerlund ---------------------------------------------------------------------- Network Architecture & Protocols, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ----------------------------------------------------------------------
- [payload] Benjamin Kaduk's Discuss on draft-ietf-… Benjamin Kaduk
- Re: [payload] Benjamin Kaduk's Discuss on draft-i… Magnus Westerlund
- Re: [payload] Benjamin Kaduk's Discuss on draft-i… Giridhar Mandyam
- Re: [payload] Benjamin Kaduk's Discuss on draft-i… Ali C. Begen
- Re: [payload] Benjamin Kaduk's Discuss on draft-i… Benjamin Kaduk
- Re: [payload] Benjamin Kaduk's Discuss on draft-i… Giridhar Mandyam
- Re: [payload] Benjamin Kaduk's Discuss on draft-i… Magnus Westerlund
- Re: [payload] Benjamin Kaduk's Discuss on draft-i… Giridhar Mandyam
- Re: [payload] Benjamin Kaduk's Discuss on draft-i… Benjamin Kaduk