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
----------------------------------------------------------------------