RE: Genart last call review of draft-ietf-avtext-lrr-05

Hi Jonathan,
In line
Roni

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