[payload] TSVART telechat review of draft-ietf-payload-flexible-fec-scheme-16

Bernard Aboba <bernard.aboba@gmail.com> Mon, 04 February 2019 03:29 UTC

Return-Path: <bernard.aboba@gmail.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 69BAC130DE5; Sun, 3 Feb 2019 19:29:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 h9IY3OztFCqk; Sun, 3 Feb 2019 19:29:44 -0800 (PST)
Received: from mail-vk1-xa35.google.com (mail-vk1-xa35.google.com [IPv6:2607:f8b0:4864:20::a35]) (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 AAE1C1294FA; Sun, 3 Feb 2019 19:29:44 -0800 (PST)
Received: by mail-vk1-xa35.google.com with SMTP id v70so2868971vkv.7; Sun, 03 Feb 2019 19:29:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=BvW1WGrT1z/rNd4ARVLprjig3L/p7VSU6eVdQSMj0Y8=; b=lnyf8kp+OTvS8fnEGeEdqbH27jxqylcEt3zO5AOEJ4uioEmrKJYwajfnl6L+x0mMx1 AYRQmNGeLoU41jwDXs5rqDP1DeE59xQJGdP4klh4izuCSXzdY/YKUj6AwRSidqDct+wX OSRqXJJhmb063oqV0XMD6JFvboT6/6tCQGCZadfzJp0snWieL2XT6/djPS+yW+zSuVpc xwh2dvE+D2Y2tj22y+P/rYE9HagvOTEkTJNXk1y81+Xlucdbwv3JNc1Me3wralM3kSlE h9HBhOZ/VdMloufytmVecnWYj2d+VV+UUczQbHUwsHMrG+nOKCjDrPjC/6nq5QkDBsUm ZYwQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=BvW1WGrT1z/rNd4ARVLprjig3L/p7VSU6eVdQSMj0Y8=; b=CV+TsbR2XTNbp+3iAvi0Pa84EMnZ283EHa/4bDblBcA13QauA0akBx7SZPwCSoHIVo ygC4M8piCIGaoBmpTUU48t0KFMjzdTvikIfPg8VzaXMuWSSKI/Pcos4R0IFYt+sfDxU4 heaEk/Z3F3UQA4yhOvgyn0Zq6zQlnvxSo2IIIZK82IjdJ/zyDjHIX4jNsq+r33chBVNA GFcNIbqasWxJGc9A2T+4ax6Q8POXxSI6WWwqCjTCP2XlG7cy+HGkO/qEVlwgsMNbTvPt FHDvVI9u6JfCdzKfay0JMQfrY2b3sbCXW/omGI5AI/IaBtGBe2524dIkogIEoSZpJNPw GIpw==
X-Gm-Message-State: AJcUukfCGwzZBx6LDMkOIXV0RbxgT78sSvzd2Tg6dHl8f9LTyiE60QtM aEHvMz6XsSbOhHjxshmkxUfZCRP+XPVG3xnDzPIrpFSJ
X-Google-Smtp-Source: ALg8bN5Qy9pkAw/xfh+WHyyqAyVTHAyUE41S+fougQQW8D3L0753768Mu+QPswXUNpf2OFl9mf11MpFItUi1QHUDgsk=
X-Received: by 2002:a1f:2ed7:: with SMTP id u206mr20832650vku.72.1549250983072; Sun, 03 Feb 2019 19:29:43 -0800 (PST)
MIME-Version: 1.0
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Sun, 03 Feb 2019 22:29:31 -0500
Message-ID: <CAOW+2ds=yd__nhhVLVNuHFTcLPE6+Niw-aw06wpNX7QeN-p5Rw@mail.gmail.com>
To: tsv-art@ietf.org
Cc: payload@ietf.org, IETF discussion list <ietf@ietf.org>, draft-ietf-payload-flexible-fec-scheme@ietf.org
Content-Type: multipart/alternative; boundary="000000000000839b4e0581091a12"
Archived-At: <https://mailarchive.ietf.org/arch/msg/payload/EU8Dm9GZwt3w1WgUzRH7t8-zWek>
Subject: [payload] TSVART telechat review of draft-ietf-payload-flexible-fec-scheme-16
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: Mon, 04 Feb 2019 03:29:47 -0000

Reviewer:  Bernard Aboba
Review result:  Needs clarifications

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the
IETF discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

Document: draft-ietf-payload-flexible-fec-scheme-16

My reading of the document raised questions relating to implementation
requirements as well as the configuration and use of the Flexible Mask mode
(R=0, F=0).  Presumably, this mode can be used to choose arbitrary packets
to protect. There is not much discussion of flexible mode early in the
document, and no use cases are presented relating to this mode.  However,
it would appear to me that flexible mode can be used to implement scenarios
such as differential protection for Scalable Video Coding.

For example, the sender could use flexible mode to only protect base layer
packets by using a flexible mask to select only packets sent with TID = 0
and SID = 0.  Since with flexible mode the mask is not negotiated and thus
can be varied on the fly, it would appear to me that differential
protection can be provided even in situations where the number of layers
encoded (and even the temporal/spatial encoding mode) vary on the fly.

If this interpretation is correct, I would suggest adding a section after
1.1.4 covering the flexible mask mode and a differential protection use
case for it.
It also would appear to me that flexible mode could be used to implement
dynamic FEC, but I'll leave it to the authors to decide whether to mention
that use case.

With respect to SDP parameters (L, D, ToP) defined in Section 5.1.1, I was
unclear on several points:

1. Is it possible to configure a ToP value to indicate that the sender
desires to utilize both FEC and retransmission?  Or must the sender choose
to utilize this payload for one or the other but not both?

2. What happens if both RTX and flexible FEC with retransmission are
Offered in SDP?  Could this result in the sender being allowed to send both
types of retransmission (though presumably only one at a time)?  Are the
type(s) of retransmission used determined by which retransmission schemes
are provided in the Answer?

3. If L and D are not specified, does this imply that the sender will
operate in flexible mode?  Are implementations of the specification
required to support all of the modes except for the F=1, R=1 mode that is
forbidden?  If not, how does an Answerer indicate that it doesn't support
the mode that is Offered?

4. Does the negotiation of L, D and ToP in SDP imply that the sender cannot
switch to use of another configuration without renegotiation?  Since the
flexible FEC format is self-describing, it would appear to me that
switching should be possible as long as the implementation requirements are
clear.  For example, do all implementations needs to support all mask
sizes?