Re: [payload] TSVART telechat review of draft-ietf-payload-flexible-fec-scheme-16
Bernard Aboba <bernard.aboba@gmail.com> Mon, 04 February 2019 05:36 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 1AE7E130E09; Sun, 3 Feb 2019 21:36:05 -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 9IOgLUhr0P8Z; Sun, 3 Feb 2019 21:36:02 -0800 (PST)
Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (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 80D601294FA; Sun, 3 Feb 2019 21:36:02 -0800 (PST)
Received: by mail-ua1-x934.google.com with SMTP id e16so4056934uam.12; Sun, 03 Feb 2019 21:36:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lmD6+ScDbQg9s6yLJukrRJDzjrYgdfTKCONf7TRpmc8=; b=eTC2rfU4Lbx9NFFo0BleRQggoF9BUUTn5stTI6qNG9ACJrp032bZqNqxOHQDoTSsEx 8FsN/wkv5/3cX/bSWDDvTeFoxYGsSN+KT9/86vD0gUlBw74KWLH/K76jl7pub5aiyUL0 ZJRZT1bHBLPFQmU3FO/KDO0G3rKi3VDJ+s/qP1UIOeAm7mlryo35rLb0mUPAswzmPLZ/ CVzhiDMBBugIOr/ey8YrmVWcKnXIKphuXMwRSGONoPIA2yZVW5PrdPHUYQnn9+yz8wC6 r+U2ddhlXgj6itZ8BZCGXD7apqYv2HB0rMWXL5lP2TCOvEVcQOrCuU7xb8InsYBthE/X V0Bg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lmD6+ScDbQg9s6yLJukrRJDzjrYgdfTKCONf7TRpmc8=; b=TTSzBMaKNYwhRxkJpEMvpgvCb+B1ozStzmc5U1cUX5RARiuhplwwkFPTzktOMbhn3S 9mcGObzig0w8RWu4d3sYc8pJHfZPw+YJi3pqEGROWXwu3LhvM9QLNutsGiSfNkQuNtWW XaPkPxwo0bD4Ycs/BMEoSEISo/P6fqzGLyB025bnrlAr8f+EFtb+Ao/Mk35JlFUcQ9En DJBY6l5xhyBGbDdwAEYMajSCf0TgBEhPXtRx7nGaPnr6bhaBraPR0SXSN0UqaaKAkbkc k1rgijk3kCtFoWEKpA8j7G76P4MyC9ZvXye1VBRJ+4+fLodGU64ujcJE2uJ1YoE9ysis +Suw==
X-Gm-Message-State: AJcUukexPLI+H7E9o/wkLEvzOHpFUmY2xWUI/HLv2+zH1bHvacDgmeSE yqFDhveV+FkG2K2JQxJHpOLp1WbXyWxqHi60qdhzpw==
X-Google-Smtp-Source: ALg8bN7u2y2fNAbSUFC4iqJ9ln4a6D/k+GBvR5PgIKLIMJQPMAeUAeml6O1v4xT+K73Z3SZFJO8spxjGsOIjWrc+Wa4=
X-Received: by 2002:ab0:498d:: with SMTP id e13mr21021609uad.134.1549258561186; Sun, 03 Feb 2019 21:36:01 -0800 (PST)
MIME-Version: 1.0
References: <CAOW+2ds=yd__nhhVLVNuHFTcLPE6+Niw-aw06wpNX7QeN-p5Rw@mail.gmail.com> <CAOW+2du5Ov8+38Jt1CECpShsG-9s=-Y1yigO9tmvF274Hnhn-A@mail.gmail.com> <60f081439d6945298288ba5841f48a34@NASANEXM01C.na.qualcomm.com>
In-Reply-To: <60f081439d6945298288ba5841f48a34@NASANEXM01C.na.qualcomm.com>
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Mon, 04 Feb 2019 00:35:50 -0500
Message-ID: <CAOW+2dsLy0dO3bK38WVpfQr7f6oU297eKdqvG6M8D0j4UqkkpA@mail.gmail.com>
To: Giridhar Mandyam <mandyam@qti.qualcomm.com>
Cc: IETF discussion list <ietf@ietf.org>, "draft-ietf-payload-flexible-fec-scheme@ietf.org" <draft-ietf-payload-flexible-fec-scheme@ietf.org>, "payload@ietf.org" <payload@ietf.org>, "tsv-art@ietf.org" <tsv-art@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000034707905810adeb5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/payload/CL_Fl1dh86w_UhQ24vLCdzo0yLw>
Subject: Re: [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 05:36:05 -0000
Meant very different. For example, in a conferencing scenario a participant sends SVC with differential protection via flexible mode and the conferencing server sends a single layer with 2D. On Mon, Feb 4, 2019 at 12:31 AM Giridhar Mandyam <mandyam@qti.qualcomm.com> wrote: > > What if the Answerer wants to utilize a very configuration from what is in the Offer? > > > > What is “a very configuration” actually meant to convey? Did you mean > “every configuration”? > > > > Thanks, > > > > -Giri Mandyam > > > > *From:* Bernard Aboba <bernard.aboba@gmail.com> > *Sent:* Sunday, February 3, 2019 7:48 PM > *To:* tsv-art@ietf.org > *Cc:* payload@ietf.org; IETF discussion list <ietf@ietf.org>; > draft-ietf-payload-flexible-fec-scheme@ietf.org > *Subject:* Re: TSVART telechat review of > draft-ietf-payload-flexible-fec-scheme-16 > > > > *CAUTION*: This email originated from outside of the organization. > > Some additional notes: > > > > 1. The spec says that absence of a ToP value means that any ToP is > allowable, but it doesn't explicitly say that implementations needs to > support all ToP types. So I was unclear whether it might be necessary to > Offer multiple potential flexible FEC configurations so as to be able to > negotiate what ToP values each side can handle, and if so, how this would > work. Personally, things would be simpler if the spec were to mandate > support for as many features as possible so as to avoid the need to put > multiple potential configurations into an Offer. > > > > 2. With respect to Offer/Answer, Section 5.2.1 strikes me as potentially > quite complex: > > Each combination of the L and D parameters produces a different > > FEC data and is not compatible with any other combination. A > > sender application may desire to offer multiple offers with > > different sets of L and D values as long as the parameter values > > are valid. The receiver SHOULD choose the offer that has a > > sufficient amount of interleaving. If multiple such offers exist, > > the receiver may choose the offer that has the lowest overhead or > > the one that requires the smallest amount of buffering. The > > selection depends on the application requirements. > > [BA] By "multiple Offers" I presume you are not talking about multiple rounds of O/A or multiple Offers sent at once, > > but rather multiple SDP lines describing potential configurations. In this paragraph, "choosing" the offer > > presumably refers to the configurations that are provided in the Answer? What if the Answerer wants to utilize a very > > configuration from what is in the Offer? > > > > > > > > > > > > On Sun, Feb 3, 2019 at 10:29 PM Bernard Aboba <bernard.aboba@gmail.com> > wrote: > > 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? > > > > > >
- [payload] TSVART telechat review of draft-ietf-pa… Bernard Aboba
- Re: [payload] TSVART telechat review of draft-iet… Bernard Aboba
- Re: [payload] TSVART telechat review of draft-iet… Giridhar Mandyam
- Re: [payload] TSVART telechat review of draft-iet… Bernard Aboba
- Re: [payload] TSVART telechat review of draft-iet… Giridhar Mandyam
- Re: [payload] TSVART telechat review of draft-iet… Giridhar Mandyam
- Re: [payload] TSVART telechat review of draft-iet… Bernard Aboba