RE: Genart last call review of draft-ietf-avtext-lrr-05
"Roni Even" <ron.even.tlv@gmail.com> Fri, 16 June 2017 04:53 UTC
Return-Path: <ron.even.tlv@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61E23126BF6; Thu, 15 Jun 2017 21:53:15 -0700 (PDT)
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, FREEMAIL_FROM=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 OQuJ5gqL7BYI; Thu, 15 Jun 2017 21:53:12 -0700 (PDT)
Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (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 371571200F3; Thu, 15 Jun 2017 21:53:11 -0700 (PDT)
Received: by mail-wr0-x230.google.com with SMTP id 77so32020014wrb.1; Thu, 15 Jun 2017 21:53:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=y2oxbJ1B5NvJHXpaG77l9kjVCZpYhleZHCj0B5pDUkM=; b=vJqYYdf9XWXBOrRmh8iRlVuvgPv9B0E0SaCEp2wWZrmPFX4RdXCPpMBmP3XqdCYF4y DgNpQmLuiMiFs2wRAd2nfCJMvtW1IenZVi7DcBxRIDsakMTATfSz0m4JhEtR7359nIN+ uza6h3sZ01uiVt8LFmLvebhi2rDjld77Xv/GKlYtBp33Po46AhGOuGU4u3AvGHEbutUV aGSmsOIeyu341k+gSOE9k7bIf8LrQOFRku4zR10jNp4x49sC09Q3eeuCUVc//vcIz/th ijBdhYVWIuqfl5gQECaWfdxBjNVXBSP8AA/8mcRO6Bu5nbWIyVZ6abj1yk9HO2GRPnhb OH0w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=y2oxbJ1B5NvJHXpaG77l9kjVCZpYhleZHCj0B5pDUkM=; b=NWN8mTI0k3yKNE4qb6u4nSLFX/EOAadQbI+0y+56X1BwJB8q8YMaMCIHpYXGGFysF3 3c2EizPoMFO0mCBvLzprwuRWfCkL+0+0oPFGHcGaDT/n2i1LVLxkyobBcyNlirU7DiaJ hjq9stBnUZabbW7KtcMG0Nm/xdB2niULlnCHphAEo0fz0D1G2YdpVb5q4TA7vgPinKEk oTxDia3GrmcuyshQKSHO7bi/HLZ6blxuJ4Uwj1PUTwb7vfeX/7EP+/MRxmdXpMqMNMns /GkYrX+L3fVKeISbWKKcbQ9GnmvxBNXDIKecrlBQmTSd4vCSgs1Jr3P6tl3bqeTyplHF aWgw==
X-Gm-Message-State: AKS2vOxp+w20GegSY4TQM/BDCJJuTuJmwZ5yzWeN2+TSnV7is4z+vO2K aA5lHEPFOkQNYncNoz0=
X-Received: by 10.223.161.220 with SMTP id v28mr5505308wrv.37.1497588790216; Thu, 15 Jun 2017 21:53:10 -0700 (PDT)
Received: from RoniPC (bzq-109-64-85-249.red.bezeqint.net. [109.64.85.249]) by smtp.gmail.com with ESMTPSA id 70sm2346488wmu.28.2017.06.15.21.53.07 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 15 Jun 2017 21:53:08 -0700 (PDT)
From: Roni Even <ron.even.tlv@gmail.com>
To: 'Jonathan Lennox' <jonathan@vidyo.com>, 'Roni Even' <roni.even@huawei.com>
Cc: draft-ietf-avtext-lrr.all@ietf.org, 'General Area Review Team' <gen-art@ietf.org>, avtext@ietf.org, ietf@ietf.org
References: <149629998360.19813.14889515687249184753@ietfa.amsl.com> <BAFC5C7C-466C-4756-9AF1-A803196E7D25@vidyo.com> <6E58094ECC8D8344914996DAD28F1CCD7CFF25@DGGEMM506-MBX.china.huawei.com> <B9294064-4F4E-4FA1-A864-4F9790767B5C@vidyo.com> <6E58094ECC8D8344914996DAD28F1CCD7D0641@DGGEMM506-MBX.china.huawei.com> <116D9947-414D-47EB-A0C7-8031999E5A89@vidyo.com> <01fe01d2e468$662f18e0$328d4aa0$@gmail.com> <D99B14A9-C6A4-456B-AEFA-8819B9EF6760@vidyo.com> <6E58094ECC8D8344914996DAD28F1CCD7D0DE0@DGGEMM506-MBX.china.huawei.com> <23DA0728-571B-4D1D-A567-6C4F3D245C03@vidyo.com>
In-Reply-To: <23DA0728-571B-4D1D-A567-6C4F3D245C03@vidyo.com>
Subject: RE: Genart last call review of draft-ietf-avtext-lrr-05
Date: Fri, 16 Jun 2017 07:52:00 +0300
Message-ID: <001e01d2e65c$4b2a9fb0$e17fdf10$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQEOBITKuJRO9nhiFivT7qoen86ZIALweQwbARran8oBJBqhhQNABGFpAZ6UghYByHOz5gHNftrUAX0ZIuQCRL/WiKMlgM2w
Content-Language: he
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/80poCln4EiEv3xX3U5i65V7W5rY>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Jun 2017 04:53:15 -0000
Hi Jonathan, In line Roni > -----Original Message----- > From: Jonathan Lennox [mailto:jonathan@vidyo.com] > Sent: Thursday, June 15, 2017 11:28 PM > To: Roni Even > Cc: Roni Even; draft-ietf-avtext-lrr.all@ietf.org; General Area Review Team; > avtext@ietf.org; ietf@ietf.org > Subject: Re: Genart last call review of draft-ietf-avtext-lrr-05 > > > > On Jun 14, 2017, at 1:37 AM, Roni Even <roni.even@huawei.com> wrote: > > > > Hi Jonathan, > > Probably part of my comment was based on the draft name , the message > > name and the abstract (all about refresh). I did not see any text about the > same usage limitation on FIR from RFC5104 "Using the FIR command to recover > from errors is explicitly disallowed, and instead the PLI message defined in AVPF > [RFC4585] should be used. The PLI message reports lost pictures and has been > included in AVPF for precisely that purpose." > > > > I am OK with similar approach as you suggested, so do you mean that PLI > should be used also in this case to recover from errors. > > Yes, either PLI itself or some future to-be-defined per-layer PLI equivalent. I’ll > add corresponding text for LRR. Would that satisfy your comments? [Roni Even] Yes this will be OK > > > Practically it will interesting to see if applications are using PLI and not FIR for > packet loss cases and what encoders do when receiving PLI. (-: > > I suspect PLI and FIR are actually handled identically by most applications, but in > low-bitrate scenarios it likely makes sense to treat them differently. > > > BTW: errors is a general term, I assume that for FIR it meant errors > > due to packet loss (congestion) > > Packet loss is the most likely, but packet corruption (in the absence of UDP > checksums), or encoder or decoder bugs, are also possible. > > > Roni > > > >> -----Original Message----- > >> From: Jonathan Lennox [mailto:jonathan@vidyo.com] > >> Sent: יום ד 14 יוני 2017 01:49 > >> To: Roni Even > >> Cc: Roni Even; draft-ietf-avtext-lrr.all@ietf.org; General Area > >> Review Team; avtext@ietf.org; ietf@ietf.org > >> Subject: Re: Genart last call review of draft-ietf-avtext-lrr-05 > >> > >> > >>> On Jun 13, 2017, at 1:13 PM, Roni Even <ron.even.tlv@gmail.com> wrote: > >>> > >>> Hi Jonathan, > >>> This will be good but maybe explain the upgrade means also refresh. > >> Because my poor understanding in English is that upgrade is adding a > >> new layer that was not available to the media receiver while refresh > >> is to restore existing layer (e.g. decoder synchronization loss). > >>> Roni > >> > >> Ah, I see. > >> > >> The design goal of LRR was for it to be used for upgrade, not for > >> synchronization loss, though of course now that you mention it, it > >> could certainly be used for the latter as well. (I.e. it was designed > >> to be analogous to FIR, not to PLI.) > >> > >> As with the difference between FIR and PLI, the congestion > >> considerations are somewhat different between upgrade and > >> synchronization loss. Do you think it's worth addressing the synchronization > loss cases explicitly? > >> > >>> > >>>> -----Original Message----- > >>>> From: Jonathan Lennox [mailto:jonathan@vidyo.com] > >>>> Sent: Tuesday, June 13, 2017 7:03 PM > >>>> To: Roni Even > >>>> Cc: Roni Even; draft-ietf-avtext-lrr.all@ietf.org; General Area > >>>> Review Team; avtext@ietf.org; ietf@ietf.org > >>>> Subject: Re: Genart last call review of draft-ietf-avtext-lrr-05 > >>>> > >>>> Hi, Roni — > >>>> > >>>> You seem to be assuming that a refresh and an upgrade are two > >>>> different actions. That’s not the intention — a refresh is a > >>>> characteristic of a stream that allows a decoder to upgrade. > >>>> > >>>> I’ll try to draft some text that makes it clear that it’s possible > >>>> either to independently upgrade temporal or spatial, or else > >>>> upgrade both > >> at once. > >>>> > >>>>> On Jun 11, 2017, at 7:20 AM, Roni Even <roni.even@huawei.com> > wrote: > >>>>> > >>>>> Hi Jonathan, > >>>>> I assume the new text you propose is > >>>>> > >>>>> "When C is 1, TTID MUST NOT be less than CTID, and TLID MUST NOT > >>>>> be less than CLID; at least one of TTID or TLID MUST be greater > >>>>> than CTID or CLID respectively. That is to say, the target layer > >>>>> index <TTID, TLID> MUST be a layer upgrade from the current layer > >>>>> index <CTID, CLID>. A sender MAY request an upgrade in both > >>>>> temporal and spatial/quality layers simultaneously." > >>>>> > >>>>> I think that this text still only implies the behavior, also the > >>>>> current text talks about upgrade but I assume it is also for a > >>>>> refresh not only to upgrade > >>>>> > >>>>> Maybe " A sender MAY request an upgrade or refresh in both > >>>>> temporal and spatial/quality layers simultaneously by either > >>>>> having C =1 or by having both > >>>> CLID and CTID with lower values then TTID and TLID. If the sender > >>>> want to upgrade or refresh only one layer then C MUST be equal to 1 > >>>> and only the CTID or the CLID of the layer to be upgraded or > >>>> refreshed should be lower than the TTID or TLID respectively " > >>>>> > >>>>> > >>>>> Roni > >>>>>> -----Original Message----- > >>>>>> From: Jonathan Lennox [mailto:jonathan@vidyo.com] > >>>>>> Sent: יום ד 07 יוני 2017 18:30 > >>>>>> To: Roni Even > >>>>>> Cc: Roni Even; draft-ietf-avtext-lrr.all@ietf.org; General Area > >>>>>> Review Team; avtext@ietf.org; ietf@ietf.org > >>>>>> Subject: Re: Genart last call review of draft-ietf-avtext-lrr-05 > >>>>>> > >>>>>> > >>>>>>> On Jun 7, 2017, at 1:15 AM, Roni Even <roni.even@huawei.com> > >> wrote: > >>>>>>> > >>>>>>> Hi Jonathan, > >>>>>>> I did not see the text you added yet as a response to my first > >>>>>>> question So to better clarify my question . If the FCI has > >>>>>>> TTID=0 and TLID=2 > >>>> . > >>>>>> does it mean that it is a request to update both? > >>>>>>> This was also the reason for the question about both TTID=0 and > >>>>>>> TLID=0, > >>>>>> which layer need update or is it both? > >>>>>>> Can you say that you want just to update temporal or spatial? > >>>>>> > >>>>>> Yes, if the FCI has TTID=0 and TLID=2, it’s a request to update > >>>>>> both layers — or more specifically, to make sure that you can > >>>>>> start decoding the substream with TTID=0 and TLID=2. (For most > >>>>>> scalability structures this would mean updating both, but exotic > >>>>>> structures are > >>>>>> possible.) > >>>>>> > >>>>>> If you want to just update one part of the stream, that’s what > >>>>>> CTID and CLID are for. If you sent TTID=0 and TLID=2, > >>>>>> accompanied by > >>>>>> CTID=0 and CLID=0, that means that you already have TID 0, and > >>>>>> you just want to increase the LID. > >>>>>> > >>>>>> The current text is at > >>>>>> https://github.com/juberti/draughts/tree/master/lrr , if you want > >>>>>> to take a look at the latest revisions, or suggest text that you > >>>>>> think would make > >>>> it cleaner. > >>>>>> > >>>>>> > >>>>>>> Roni > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Gen-art [mailto:gen-art-bounces@ietf.org] On Behalf Of > >>>>>>>> Jonathan Lennox > >>>>>>>> Sent: יום ד 07 יוני 2017 00:30 > >>>>>>>> To: Roni Even > >>>>>>>> Cc: draft-ietf-avtext-lrr.all@ietf.org; General Area Review > >>>>>>>> Team; avtext@ietf.org; ietf@ietf.org > >>>>>>>> Subject: Re: [Gen-art] Genart last call review of > >>>>>>>> draft-ietf-avtext-lrr-05 > >>>>>>>> > >>>>>>>> Hi, Roni — thanks for your review. Responses inline. > >>>>>>>> > >>>>>>>>> On Jun 1, 2017, at 2:53 AM, Roni Even <ron.even.tlv@gmail.com> > >>>> wrote: > >>>>>>>>> > >>>>>>>>> Reviewer: Roni Even > >>>>>>>>> Review result: Ready with Issues > >>>>>>>>> > >>>>>>>>> I am the assigned Gen-ART reviewer for this draft. The General > >>>>>>>>> Area Review Team (Gen-ART) reviews all IETF documents being > >>>>>>>>> processed by the IESG for the IETF Chair. Please treat these > >>>>>>>>> comments just like any other last call comments. > >>>>>>>>> > >>>>>>>>> For more information, please see the FAQ at > >>>>>>>>> > >>>>>>>>> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > >>>>>>>>> > >>>>>>>>> Document: draft-ietf-avtext-lrr-?? > >>>>>>>>> Reviewer: Roni Even > >>>>>>>>> Review Date: 2017-05-31 > >>>>>>>>> IETF LC End Date: 2017-06-08 > >>>>>>>>> IESG Telechat date: Not scheduled for a telechat > >>>>>>>>> > >>>>>>>>> Summary: > >>>>>>>>> The document is ready with issues for a standard track RFC > >>>>>>>>> Major > >>>>>>>>> issues: > >>>>>>>>> > >>>>>>>>> Minor issues: > >>>>>>>>> > >>>>>>>>> 1. Can you specify both TTID and TLID in the same FCI. > >>>>>>>> > >>>>>>>> Syntactically, they must both occur. > >>>>>>>> > >>>>>>>> If you mean can you request an upgrade in both at once, yes; > >>>>>>>> I’ve added text to clarify this. > >>>>>>>> > >>>>>>>>> 2. What is the meaning of value 0 for TTID and TLID - TID or > >>>>>>>>> LID > >>>>>>>>> =0 in frame marking draft means base layer if there is scalability. > >>>>>>>>> This relates to the previous question. > >>>>>>>> > >>>>>>>> I’m not sure I understand this question. > >>>>>>>> > >>>>>>>> I’ve added text that if C=1, at least one of <TTID, TLID> MUST > >>>>>>>> be greater than <CTID, CLID>, and both MUST be greater than or > >>>>>>>> equal to their counterpart, so the LRR is actually requesting a > >>>>>>>> layer > >> upgrade. > >>>>>>>> Is that what you were asking about? > >>>>>>>> > >>>>>>>>> 3. What would an FCI with both TTID and TLID equal 0 mean. > >>>>>>>> > >>>>>>>> It means you want a refresh of the base temporal/spatial layer, only. > >>>>>>>> > >>>>>>>>> Nits/editorial comments: > >>>>>>>>> > >>>>>>>>> 1. Section 3 "an Real-Time Transport Control Protocol" should > >>>>>>>>> be "a Real…". > >>>>>>>> > >>>>>>>> Colin pointed out that it should say “an RTP Control Protocol” > >> anyway. > >>>>>>>> > >>>>>>>>> 2. In section 3 " [RFC5104](Section 3.5.1)" there is a link to > >>>>>>>>> section > >>>>>>>>> 3.5.1 but it does not work. > >>>>>>>> > >>>>>>>> xml2rfc doesn’t have any way to link to sections of other > >>>>>>>> documents, so the “(Section 3.5.1)” part is just a comment. > >>>>>>>> > >>>>>>>> I think the internet-draft tooling may have thought I was > >>>>>>>> trying to link to a non-existent section 3.5.1 of this > >>>>>>>> document, but that’s outside > >>>>>> my control. > >>>>>>>> > >>>>>>>>> 3. In section 3.2 "(see section Section 2.1)" section appears twice. > >>>>>>>> > >>>>>>>> Fixed. > >>>>>>>> _______________________________________________ > >>>>>>>> Gen-art mailing list > >>>>>>>> Gen-art@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/gen-art > >>>>> > >>> > >>> > >
- Genart last call review of draft-ietf-avtext-lrr-… Roni Even
- Re: Genart last call review of draft-ietf-avtext-… Jonathan Lennox
- RE: Genart last call review of draft-ietf-avtext-… Roni Even
- RE: Genart last call review of draft-ietf-avtext-… Roni Even
- Re: Genart last call review of draft-ietf-avtext-… Jonathan Lennox
- Re: Genart last call review of draft-ietf-avtext-… Jonathan Lennox
- RE: Genart last call review of draft-ietf-avtext-… Roni Even
- Re: Genart last call review of draft-ietf-avtext-… Jonathan Lennox
- RE: Genart last call review of draft-ietf-avtext-… Roni Even
- Re: Genart last call review of draft-ietf-avtext-… Jonathan Lennox
- RE: Genart last call review of draft-ietf-avtext-… Roni Even
- Re: Genart last call review of draft-ietf-avtext-… Jonathan Lennox
- RE: Genart last call review of draft-ietf-avtext-… Roni Even