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

["Roni Even" <[e-mail]>]

Hi Jonathan,
In line
Roni

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