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

From: Jonathan Lennox <[email-masked]>
Date: Tue, 6 Jun 2017 21:29:46 +0000

Hi, Roni — thanks for your review.  Responses inline.

> On Jun 1, 2017, at 2:53 AM, Roni Even <[email-masked]> 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.

---

From: Roni Even <[email-masked]>
Date: Wed, 7 Jun 2017 05:15:49 +0000

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?

Roni

> -----Original Message-----
> From: Gen-art [mailto:[email-masked]] On Behalf Of Jonathan
> Lennox
> Sent: יום ד 07 יוני 2017 00:30
> To: Roni Even
> Cc: [email-masked]; General Area Review Team;
> [email-masked]; [email-masked]
> Subject: Re: [Gen-art] Genart last call review of draft-ietf-avtext-lrr-05
> 
> > 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.
> >
> > The document is ready with issues for a standard track RFC Major
> > issues:
> >
> > Minor issues:
> >
> 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?
> 
> 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.
> 
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: Roni Even <[email-masked]>
Date: Wed, 7 Jun 2017 07:38:10 +0000

Hi Jonathan,
Just another clarification for both TTID=0 and TLID=0 , I understand that there is one base layer, but does this case have any special meaning?
Roni

> From: Gen-art [mailto:[email-masked]] On Behalf Of Roni Even
> Sent: יום ד 07 יוני 2017 08:16
> To: Jonathan Lennox; Roni Even
> Cc: [email-masked]; General Area Review Team; draft-ietf-avtext-
> [email-masked]; [email-masked]
> 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?
> > > 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.
> > 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?
> >
> > 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.
> >

---

From: Jonathan Lennox <[email-masked]>
Date: Wed, 7 Jun 2017 15:29:49 +0000

> On Jun 7, 2017, at 1:15 AM, Roni Even <[email-masked]> wrote:
> 
> Hi Jonathan,

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.

---

From: Jonathan Lennox <[email-masked]>
Date: Wed, 7 Jun 2017 15:32:46 +0000

It’s not a special meaning — this would mean a request to break the dependency chain for the base temporal and spatial layer, while allowing higher layers to continue using reference pictures across this break.  Figure 2 is a rough approximation of what’s desired, if you imagine it for temporal and spatial simultaneously.

> On Jun 7, 2017, at 3:38 AM, Roni Even <[email-masked]> wrote:
> 
> Hi Jonathan,

---

From: Roni Even <[email-masked]>
Date: Sun, 11 Jun 2017 11:20:13 +0000

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
> From: Jonathan Lennox [mailto:[email-masked]]
> Sent: יום ד 07 יוני 2017 18:30
> To: Roni Even
> Cc: Roni Even; [email-masked]; General Area Review Team;
> Subject: Re: Genart last call review of draft-ietf-avtext-lrr-05
> 
> 
> > 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?
> 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
> >
> >> link to a non-existent section 3.5.1 of this document, but that’s outside
> my control.
> >>

---

From: Jonathan Lennox <[email-masked]>
Date: Tue, 13 Jun 2017 16:03:24 +0000

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 <[email-masked]> wrote:
> 
> Hi Jonathan,

---

From: "Roni Even" <[email-masked]>
Date: Tue, 13 Jun 2017 20:13:37 +0300

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

> Sent: Tuesday, June 13, 2017 7:03 PM
> To: Roni Even
> 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.
> 
> > 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
> >
> >   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
> >> Cc: Roni Even; [email-masked]; General Area
> >> Review Team; [email-masked]; [email-masked]
> >>> This was also the reason for the question about both TTID=0 and
> >>> TLID=0,
> >> which layer need update or is it both?
> >> 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
> >>>
> >>>> From: Gen-art [mailto:[email-masked]] On Behalf Of
> >>>> Jonathan Lennox
> >>>>> 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.
> >>>>>
> >>>>> 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.
> >>>> greater than <CTID, CLID>, and both MUST be greater than or equal
> >>>> to their counterpart, so the LRR is actually requesting a layer upgrade.
> >>>>> 1. Section 3 "an Real-Time Transport Control Protocol" should be
> >>>>> "a Real…".
> >>>>
> >>>> xml2rfc doesn’t have any way to link to sections of other
> >>>> documents, so the “(Section 3.5.1)” part is just a comment.
> >>>>

---

From: Jonathan Lennox <[email-masked]>
Date: Tue, 13 Jun 2017 22:48:34 +0000

> On Jun 13, 2017, at 1:13 PM, Roni Even <[email-masked]> wrote:
> 
> Hi Jonathan,

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?

---

From: Roni Even <[email-masked]>
Date: Wed, 14 Jun 2017 05:37:52 +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

> Sent: יום ד 14 יוני 2017 01:49
> To: Roni Even
> > 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?
> 
> >
> >> 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.
> >>
> >>> 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
> >>>>> question So to better clarify my question . If the FCI has TTID=0
> >>>>> and TLID=2
> >> .
> >>>> 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.)
> >>>>
> >>>> 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
> >>>>>
> >>>>>> 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.
> >>>>>>

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 15 Jun 2017 20:28:11 +0000

> On Jun 14, 2017, at 1:37 AM, Roni Even <[email-masked]> wrote:
> 
> Hi Jonathan,

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?

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

---

From: "Roni Even" <[email-masked]>
Date: Fri, 16 Jun 2017 07:52:00 +0300

Hi Jonathan,
In line
Roni

> Sent: Thursday, June 15, 2017 11:28 PM
> To: Roni Even
> > 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.
> 
> Packet loss is the most likely, but packet corruption (in the absence of UDP
> checksums), or encoder or decoder bugs, are also possible.
> 
> > Roni
> >
> >> 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.
> >>
> >> 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?
> >>
> >>>
> >>>>> "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."
> >>>>>
> >>>>> 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
> >>>>>>> question So to better clarify my question . If the FCI has
> >>>>>>> TTID=0 and TLID=2
> >>>> .
> >>>>>> both layers — or more specifically, to make sure that you can
> >>>>>> start decoding the substream with TTID=0 and TLID=2. (For most
> >>>>>> 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
> >>>>>>>> Cc: [email-masked]; General Area Review
> >>>>>>>> Team; [email-masked]; [email-masked]
> >>>>>>>>> Major
> >>>>>>>> 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.
> >>>>>>>>> 1. Section 3 "an Real-Time Transport Control Protocol" should
> >>>>>>>>> be "a Real…".
> >>>>>>>>
> >>>>>>>> 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.
> >>>>>>>>

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 21 Jun 2017 08:46:27 -0400

Roni, thanks for your review. Jonathan, thanks for addressing Roni’s comments. I have entered a No Objection ballot position on this document.

Alissa

> Real...".