Hi Jonathan, In line Roni > -----Original Message----- > From: Jonathan Lennox [mailto:jonathan@xxxxxxxxx] > Sent: Thursday, June 15, 2017 11:28 PM > To: Roni Even > Cc: Roni Even; draft-ietf-avtext-lrr.all@xxxxxxxx; General Area Review Team; > avtext@xxxxxxxx; ietf@xxxxxxxx > Subject: Re: Genart last call review of draft-ietf-avtext-lrr-05 > > > > On Jun 14, 2017, at 1:37 AM, Roni Even <roni.even@xxxxxxxxxx> 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@xxxxxxxxx] > >> Sent: יום ד 14 יוני 2017 01:49 > >> To: Roni Even > >> Cc: Roni Even; draft-ietf-avtext-lrr.all@xxxxxxxx; General Area > >> Review Team; avtext@xxxxxxxx; ietf@xxxxxxxx > >> 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@xxxxxxxxx> 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@xxxxxxxxx] > >>>> Sent: Tuesday, June 13, 2017 7:03 PM > >>>> To: Roni Even > >>>> Cc: Roni Even; draft-ietf-avtext-lrr.all@xxxxxxxx; General Area > >>>> Review Team; avtext@xxxxxxxx; ietf@xxxxxxxx > >>>> 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@xxxxxxxxxx> > 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@xxxxxxxxx] > >>>>>> Sent: יום ד 07 יוני 2017 18:30 > >>>>>> To: Roni Even > >>>>>> Cc: Roni Even; draft-ietf-avtext-lrr.all@xxxxxxxx; General Area > >>>>>> Review Team; avtext@xxxxxxxx; ietf@xxxxxxxx > >>>>>> Subject: Re: Genart last call review of draft-ietf-avtext-lrr-05 > >>>>>> > >>>>>> > >>>>>>> On Jun 7, 2017, at 1:15 AM, Roni Even <roni.even@xxxxxxxxxx> > >> 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@xxxxxxxx] On Behalf Of > >>>>>>>> Jonathan Lennox > >>>>>>>> Sent: יום ד 07 יוני 2017 00:30 > >>>>>>>> To: Roni Even > >>>>>>>> Cc: draft-ietf-avtext-lrr.all@xxxxxxxx; General Area Review > >>>>>>>> Team; avtext@xxxxxxxx; ietf@xxxxxxxx > >>>>>>>> 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@xxxxxxxxx> > >>>> 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@xxxxxxxx > >>>>>>>> https://www.ietf.org/mailman/listinfo/gen-art > >>>>> > >>> > >>> > >