Re: [avtext] Genart last call review of draft-ietf-avtext-lrr-05

Roni Even <roni.even@huawei.com> Wed, 14 June 2017 05:38 UTC

Return-Path: <roni.even@huawei.com>
X-Original-To: avtext@ietfa.amsl.com
Delivered-To: avtext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5C571270A7; Tue, 13 Jun 2017 22:38:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.222
X-Spam-Level:
X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 3XY2CWP8nXaZ; Tue, 13 Jun 2017 22:38:03 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86CD51200F1; Tue, 13 Jun 2017 22:38:02 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DIL87550; Wed, 14 Jun 2017 05:38:00 +0000 (GMT)
Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 14 Jun 2017 06:37:59 +0100
Received: from DGGEMM404-HUB.china.huawei.com (10.3.20.212) by NKGEML413-HUB.china.huawei.com (10.98.56.74) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 14 Jun 2017 13:37:56 +0800
Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.49]) by DGGEMM404-HUB.china.huawei.com ([10.3.20.212]) with mapi id 14.03.0301.000; Wed, 14 Jun 2017 13:37:53 +0800
From: Roni Even <roni.even@huawei.com>
To: Jonathan Lennox <jonathan@vidyo.com>, Roni Even <ron.even.tlv@gmail.com>
CC: "draft-ietf-avtext-lrr.all@ietf.org" <draft-ietf-avtext-lrr.all@ietf.org>, General Area Review Team <gen-art@ietf.org>, "avtext@ietf.org" <avtext@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Thread-Topic: Genart last call review of draft-ietf-avtext-lrr-05
Thread-Index: AQHS2qO4IAQ0EK1qvUeY+IF4GawhgaIYtpMAgAAtEkCAAQCzAIAFrKRwgAPKzwD//zmbgIAAXZUAgADu7NA=
Date: Wed, 14 Jun 2017 05:37:52 +0000
Message-ID: <6E58094ECC8D8344914996DAD28F1CCD7D0DE0@DGGEMM506-MBX.china.huawei.com>
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>
In-Reply-To: <D99B14A9-C6A4-456B-AEFA-8819B9EF6760@vidyo.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.200.202.55]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.5940CBB9.004F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.49, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: e2a6e4c8b8332e96d28b21904c02d2cb
Archived-At: <https://mailarchive.ietf.org/arch/msg/avtext/AtazyrD4ZYpMvXCshQrl5PdBKSs>
Subject: Re: [avtext] Genart last call review of draft-ietf-avtext-lrr-05
X-BeenThere: avtext@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Audio/Video Transport Extensions working group discussion list <avtext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avtext>, <mailto:avtext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avtext/>
List-Post: <mailto:avtext@ietf.org>
List-Help: <mailto:avtext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avtext>, <mailto:avtext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Jun 2017 05:38:07 -0000

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. 

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. (-:

BTW: errors is a general term, I assume that for FIR it meant errors due to packet loss (congestion)
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
> >>>
> >
> >