Subject: [Rum] AD Review of draft-ietf-rum-rue

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 5 Oct 2021 20:59:08 -0700

This is my AD review for the above document.  Once these points are
resolved, we can proceed to IETF Last Call.

Overall this looks to be in pretty good shape.  Nice work.  I've only got a
few things that should be relatively easy to resolve.

Section 3:

* Suggest dropping "in this memo" at the end.  Two reasons: (1) You don't
really need it, and (2) the current preference is use "document" rather
than "memo" (and earlier in this section, you used "document" as part of
the BCP14 boilerplate).

Section 4:

* HTTP/HTTPS needs a reference.

Section 5:

* "In addition, implementation ..." -- should be "implementations"

Section 5.1

* "... and SHOULD inform the RUE User of the problem." -- why the SHOULD
here?  "SHOULD" implies a choice, preferably an informed one, so why might
an implementation not indicate the problem to the user?

Section 5.4

* "visual-separator" is also defined in RFC 3966, so the reference right
before it needs to be inclusive.

Section 6.8:

* Same issue with the two SHOULDs here.

Section 8:

* s/NOT/not/

* Same issue with the SHOULD here; why might I not do what it says?

-MSK

---

From: Brian Rosen <[email-masked]>
Date: Wed, 6 Oct 2021 10:34:09 -0400

I have fixed all but one of these in my working copy.  I need some help from providers on Section 6.8.  This text is, I believe, copied from the provider profile.  Under what conditions would you not use NACK/FIR/PLI?

Brian

> On Oct 5, 2021, at 11:59 PM, Murray S. Kucherawy <[email-masked]> wrote:
> 
> This is my AD review for the above document.  Once these points are resolved, we can proceed to IETF Last Call.
> 
> Overall this looks to be in pretty good shape.  Nice work.  I've only got a few things that should be relatively easy to resolve.
> 
> Section 3:
> 
> * Suggest dropping "in this memo" at the end.  Two reasons: (1) You don't really need it, and (2) the current preference is use "document" rather than "memo" (and earlier in this section, you used "document" as part of the BCP14 boilerplate).
> 
> Section 4:
> 
> * "... and SHOULD inform the RUE User of the problem." -- why the SHOULD here?  "SHOULD" implies a choice, preferably an informed one, so why might an implementation not indicate the problem to the user?
> 
> Section 5.4
> 
> * "visual-separator" is also defined in RFC 3966, so the reference right before it needs to be inclusive.
> 
> Section 6.8:
> 
> -- 
> Rum mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rum

---

From: Ed Sayers <[email-masked]>
Date: Wed, 6 Oct 2021 14:49:41 +0000

Hi Brian,

* NACK (Negative ACKnowledgement) Requests are used to fix up small amounts of packets loss when a tmmbr/remb/transport-wide-cc congestion adjustment is not yet needed.
* PLI is used to request a full frame refresh from the remote Encoder due to "picture loss", i.e. the Decoder cannot keep decoding the stream.
* An FIR might be used at the start of VideoMail recording, where there is no actual picture loss, but a full-frame refresh is needed as a start point for the recording.

Note also that the Provider Profile only makes mention of tmmbr, not remb or transport-wide-cc at this time.
This is because remb and transport-wide-cc are geared towards SFUs and multiple video streams in WebRTC and is not applicable on the Inter-Provider interface.

Ed Sayers
Endpoint SDK Team Lead
Purple, a Division of ZP Better Together, LLC
purplevrs.com

The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message.

-----Original Message-----
From: Rum <[email-masked]> On Behalf Of Brian Rosen
Sent: 06 October 2021 15:34
To: Murray S. Kucherawy <[email-masked]>
Cc: [email-masked]
Subject: Re: [Rum] AD Review of draft-ietf-rum-rue

Brian

---

From: Brian Rosen <[email-masked]>
Date: Wed, 6 Oct 2021 10:52:18 -0400

Ed

Thanks for this info, but it doesn’t help me :(

The text says SHOULD use them, not MUST.  Why SHOULD?

Should (!) I add text on tmmbr?  If so, what should it say?

Brian

> On Oct 6, 2021, at 10:49 AM, Ed Sayers <[email-masked]> wrote:
> 
> Hi Brian,
>

---

From: Ed Sayers <[email-masked]>
Date: Wed, 6 Oct 2021 15:26:13 +0000

Hi Brian,

The initial Provider Profile was really an agreed migration path from ITU-T H.323, with a common set of destination rules, over 6 years ago.

Some things in the framework were a 'must' because they were needed at the most fundamental level to interoperate (SIP over TCP).
But, some elements like tmmbr/nack/pli were defined to be optional because they are not fundamentally required for inter-operability, but can be used to improve quality over time.
In other words, setting a hard deadline and large set of required features would have caused significant and detrimental impact to customers, and been contrary to the Providers' goal of continuous steady improvement.

For example:
* If tmmbr is not supported, then a re-INVITE is permitted to adapt bandwidth.
* if PLI/FIR is not supported then SIP INFO RFC-5168 MUST be used.
* NACKing was optional with no required fallback substitute.

Ed Sayers
Endpoint SDK Team Lead

-----Original Message-----
From: Brian Rosen <[email-masked]> 
Sent: 06 October 2021 15:52
To: Ed Sayers <[email-masked]>
Cc: Murray S. Kucherawy <[email-masked]>; [email-masked]
Subject: Re: [Rum] AD Review of draft-ietf-rum-rue

Ed

Brian

> Purple, a Division of ZP Better Together, LLC purplevrs.com
>

---

From: Brian Rosen <[email-masked]>
Date: Wed, 6 Oct 2021 11:40:18 -0400

Thanks

Looking at the text again, I think the intention is that you use FIR/PLI/NACK unless the other end only supports 5168.  

Is that reasonable?  Do I need to add the tmmbr/re-INVITE text?  Should I change the NACK SHOULD to MAY?

Brian

> On Oct 6, 2021, at 11:26 AM, Ed Sayers <[email-masked]> wrote:
> 
> Hi Brian,
>

---

From: Ed Sayers <[email-masked]>
Date: Wed, 6 Oct 2021 15:57:17 +0000

Hi Brian,

I would say you are correct about FIR/PLI.

But, keep the comment about NACK separate, and I think MAY makes sense for that.

I would say it is probably worth adding an item mentioning tmmbr, and the option to use re-INVITE as fallback.

Ed Sayers
Endpoint SDK Team Lead

-----Original Message-----
From: Brian Rosen <[email-masked]> 
Sent: 06 October 2021 16:40
To: Ed Sayers <[email-masked]>
Cc: Murray S. Kucherawy <[email-masked]>; [email-masked]
Subject: Re: [Rum] AD Review of draft-ietf-rum-rue

Thanks

Brian

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 6 Oct 2021 12:29:40 -0400

I'm having trouble distinguishing what is best practice from 
accommodations in case the other end doesn't support one or the other of 
these.

Is the goal that all of these mechanisms be optional? IMO there should 
be one or more MUST implement, and then the rest can be SHOULD or MAY 
implement. And then a suggested best practice for deciding which to use 
among those supported at both ends. That can be SHOULD or MAY.

	Thanks,
	Paul

---

From: Brian Rosen <[email-masked]>
Date: Wed, 6 Oct 2021 13:39:41 -0400

I’ve rewritten this text to read:

   The NACK, FIR and PLI features as described in [RFC5104] MUST be
   implemented.  Availability of these features MUST be announced with
   the "ccm" feedback value.  NACK should be used when negotiated and
   conditions warrant its use and the other end supports it.  Signaling
   picture losses as Packet Loss Indicator (PLI) should be preferred.
   FIR should be used only in situations where not sending a decoder
   refresh point would render the video unusable for the users, as per
   RFC5104 subsection 4.3.1.2.

   For backwards compatibility with calling devices that do not support
   the foregoing methods, implementations MUST implement SIP INFO
   messages to send and receive XML encoded Picture Fast Update messages
   according to [RFC5168].
Is this acceptable?

Brian

> On Oct 6, 2021, at 12:29 PM, Paul Kyzivat <[email-masked]> wrote:
> 
> I'm having trouble distinguishing what is best practice from accommodations in case the other end doesn't support one or the other of these.
> 
> Is the goal that all of these mechanisms be optional? IMO there should be one or more MUST implement, and then the rest can be SHOULD or MAY implement. And then a suggested best practice for deciding which to use among those supported at both ends. That can be SHOULD or MAY.
> 
> 	Thanks,
> 	Paul
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 6 Oct 2021 15:25:48 -0400

>     RFC5104 subsection 4.3.1.2.

You are using "should" rather than SHOULD above. Is that intended? Why?

Since all of these are MUST implement, it will only be when 
interoperating with non-compliant devices that the fallbacks apply. That 
could be stated more clearly. And I'm confused about when to choose 
between NACK and PLI. (Is there any time when conditions warrant NACK 
but PLI is preferred?

	Thanks,
	Paul

---

From: Brian Rosen <[email-masked]>
Date: Wed, 6 Oct 2021 15:40:32 -0400

Lower case should because it is advice rather than mandatory with exception.  This stuff is quite complicated and absolutes are hard to come by.  It’s not “use 5104 unless the other end doesn’t support it”, it’s “use this features this way unless you have some unusual conditions”.

I don’t know enough to answer your question about NACK and PLI.  One hitch I see is that NACK is not defined in 5104, it’s defined in 4585.

Brian

> On Oct 6, 2021, at 3:25 PM, Paul Kyzivat <[email-masked]> wrote:
> 
> Since all of these are MUST implement, it will only be when interoperating with non-compliant devices that the fallbacks apply. That could be stated more clearly. And I'm confused about when to choose between NACK and PLI. (Is there any time when conditions warrant NACK but PLI is preferred?
> 
> 	Thanks,
> 	Paul
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rum <https://www.ietf.org/mailman/listinfo/rum>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 6 Oct 2021 16:05:14 -0400

On 10/6/21 3:40 PM, Brian Rosen wrote:
> Lower case should because it is advice rather than mandatory with 
> exception.  This stuff is quite complicated and absolutes are hard to 
> come by.  It’s not “use 5104 unless the other end doesn’t support it”, 
> it’s “use this features this way unless you have some unusual conditions”.
> 
> I don’t know enough to answer your question about NACK and PLI.  One 
> hitch I see is that NACK is not defined in 5104, it’s defined in 4585.

And I'm also at the limits of my knowledge.

PROVIDERS!!! Can you suggest replacement text for Brian to swap into the 
document that has the correct balance of normative text and 
non-normative suggestions to properly cover this subject?

	Thanks,
	Paul

> Brian
> 
> 
>> On Oct 6, 2021, at 3:25 PM, Paul Kyzivat <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> interoperating with non-compliant devices that the fallbacks apply. 
>> That could be stated more clearly. And I'm confused about when to 
>> choose between NACK and PLI. (Is there any time when conditions 
>> warrant NACK but PLI is preferred?
>>
>> Thanks,
>> Paul
>>
>>>> On Oct 6, 2021, at 12:29 PM, Paul Kyzivat <[email-masked] 
>>>> <mailto:[email-masked]>> wrote:
>>>>
>>>> accommodations in case the other end doesn't support one or the 
>>>> other of these.
>>>>
>>>> Is the goal that all of these mechanisms be optional? IMO there 
>>>> should be one or more MUST implement, and then the rest can be 
>>>> SHOULD or MAY implement. And then a suggested best practice for 
>>>> deciding which to use among those supported at both ends. That can 
>>>> be SHOULD or MAY.
>>>>
>>>> Thanks,
>>>> Paul
>>>>
>>>>> I would say it is probably worth adding an item mentioning tmmbr, 
>>>>> and the option to use re-INVITE as fallback.
>>>>> Ed Sayers
>>>>> Endpoint SDK Team Lead
>>>>> purplevrs.com <http://purplevrs.com>
>>>>> The information contained in this e-mail message is intended only 
>>>>> for the personal and confidential use of the recipient(s) named 
>>>>> above. If you have received this communication in error, please 
>>>>> notify us immediately by e-mail, and delete the original message.
>>>>> Looking at the text again, I think the intention is that you use 
>>>>> FIR/PLI/NACK unless the other end only supports 5168.
>>>>>> The initial Provider Profile was really an agreed migration path 
>>>>>> from ITU-T H.323, with a common set of destination rules, over 6 
>>>>>> years ago.
>>>>>>
>>>>>> Some things in the framework were a 'must' because they were 
>>>>>> needed at the most fundamental level to interoperate (SIP over TCP).
>>>>>> But, some elements like tmmbr/nack/pli were defined to be optional 
>>>>>> because they are not fundamentally required for inter-operability, 
>>>>>> but can be used to improve quality over time.
>>>>>> In other words, setting a hard deadline and large set of required 
>>>>>> features would have caused significant and detrimental impact to 
>>>>>> customers, and been contrary to the Providers' goal of continuous 
>>>>>> steady improvement.
>>>>>>
>>>>>> For example:
>>>>>> The information contained in this e-mail message is intended only 
>>>>>> for the personal and confidential use of the recipient(s) named 
>>>>>> above. If you have received this communication in error, please 
>>>>>> notify us immediately by e-mail, and delete the original message.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> * NACK (Negative ACKnowledgement) Requests are used to fix up 
>>>>>>> small amounts of packets loss when a tmmbr/remb/transport-wide-cc 
>>>>>>> congestion adjustment is not yet needed.
>>>>>>> * PLI is used to request a full frame refresh from the remote 
>>>>>>> Encoder due to "picture loss", i.e. the Decoder cannot keep 
>>>>>>> decoding the stream.
>>>>>>> * An FIR might be used at the start of VideoMail recording, where 
>>>>>>> there is no actual picture loss, but a full-frame refresh is 
>>>>>>> needed as a start point for the recording.
>>>>>>>
>>>>>>> Note also that the Provider Profile only makes mention of tmmbr, 
>>>>>>> not remb or transport-wide-cc at this time.
>>>>>>> This is because remb and transport-wide-cc are geared towards 
>>>>>>> SFUs and multiple video streams in WebRTC and is not applicable 
>>>>>>> on the Inter-Provider interface.
>>>>>>>
>>>>>>>
>>>>>>> Ed Sayers
>>>>>>> Endpoint SDK Team Lead
>>>>>>> The information contained in this e-mail message is intended only 
>>>>>>> for the personal and confidential use of the recipient(s) named 
>>>>>>> above. If you have received this communication in error, please 
>>>>>>> notify us immediately by e-mail, and delete the original message.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I have fixed all but one of these in my working copy.  I need 
>>>>>>> some help from providers on Section 6.8.  This text is, I 
>>>>>>> believe, copied from the provider profile.  Under what conditions 
>>>>>>> would you not use NACK/FIR/PLI?
>>>>>>>
>>>>>>> Brian
>>>>>>>
>>>>>>>
>>>>>>>> This is my AD review for the above document.  Once these points 
>>>>>>>> are resolved, we can proceed to IETF Last Call.
>>>>>>>>
>>>>>>>> Overall this looks to be in pretty good shape.  Nice work.  I've 
>>>>>>>> only got a few things that should be relatively easy to resolve.
>>>>>>>>
>>>>>>>> Section 3:
>>>>>>>>
>>>>>>>> * Suggest dropping "in this memo" at the end.  Two reasons: (1) 
>>>>>>>> You don't really need it, and (2) the current preference is use 
>>>>>>>> "document" rather than "memo" (and earlier in this section, you 
>>>>>>>> used "document" as part of the BCP14 boilerplate).
>>>>>>>>
>>>>>>>> Section 4:
>>>>>>>>
>>>>>>>> * "... and SHOULD inform the RUE User of the problem." -- why 
>>>>>>>> the SHOULD here?  "SHOULD" implies a choice, preferably an 
>>>>>>>> informed one, so why might an implementation not indicate the 
>>>>>>>> problem to the user?
>>>>>>>>
>>>>>>>> Section 5.4
>>>>>>>>
>>>>>>>> * "visual-separator" is also defined in RFC 3966, so the 
>>>>>>>> reference right before it needs to be inclusive.
>>>>>>>>
>>>>>>>> Section 6.8:
>>>>>>>>
>> <https://www.ietf.org/mailman/listinfo/rum>
>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 7 Oct 2021 08:27:25 +0200

> 6 okt. 2021 kl. 19:39 skrev Brian Rosen <[email-masked]>:
> 
>   the "ccm" feedback value.
I don’t get why we have to announce a MUST. There’s some explanation missing here. What is the purpose of the announcement if implementation is a must?

> NACK should be used when negotiated and
>   conditions warrant its use and the other end supports it.
How is it negotiated? Reference?

>  Signaling
Reference?

>   messages to send and receive XML encoded Picture Fast Update messages
Adding a MUST to something that is not declared as a SIP INFO framework
- is that a good thing? See RFC 6086

” Any new usage MUST use the Info Package mechanism defined in this
       specification, since it does not share the issues associated with
       legacy INFO usage, and since Info Packages can be registered with
       IANA.”

I wonder how to parse this. If we’re adding a MUST in a *NEW* RFC that points to a legacy INFO usage RFC, I think we’re in trouble. Modern SIP stacks that implement INFO packages the right way may have a problem with this MUST. RFC 6086 doesn’t really guide here. It clearly says any new usage of INFO has to follow RFC 6086, but new SIP RFCs - what do we do here?

Just something to consider before adding a MUST here. I would change it to a recommendation, an option for the implementor that wants to be backwards compatible. ”Backwards compatible” here does not point to any RFC-compliant implementation of an older version of RUE as specified by the IETF.

/O

---

From: Ed Sayers <[email-masked]>
Date: Thu, 7 Oct 2021 12:19:59 +0000

Hi,

ACKing is used to request resending any specified lost packets, with the aim of continuing to decode without stopping or needing a full frame refresh.

In contrast, an FIR or PLI signals that the decoder does need a full frame refresh. The semantics in the RFC mean that PLI is defined for use when packet loss (or errors) cause a Decoder to need a full frame to continue decoding per 5104-s:3.5.1.

However, An FIR could be used as a refresh point at the start of a VideoMail recording - Where the full frame is needed as a sync point rather than for error recovery.

Ed Sayers
Endpoint SDK Team Lead
Purple, a Division of ZP Better Together, LLC
purplevrs.com<https://purplevrs.com/>

[Purple is DEI certified!]
The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message.

From: Rum <[email-masked]> On Behalf Of Olle E. Johansson
Sent: 07 October 2021 07:27
To: Brian Rosen <[email-masked]>
Cc: [email-masked]; Paul Kyzivat <[email-masked]>
Subject: Re: [Rum] AD Review of draft-ietf-rum-rue

6 okt. 2021 kl. 19:39 skrev Brian Rosen <[email-masked]<mailto:[email-masked]>>:

 Signaling

       IANA.”

/O

Is this acceptable?

Brian

On Oct 6, 2021, at 12:29 PM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:

                Thanks,
                Paul

Hi Brian,
purplevrs.com<http://purplevrs.com>
-----Original Message-----
From: Brian Rosen <[email-masked]<mailto:[email-masked]>>
Sent: 06 October 2021 16:40
To: Ed Sayers <[email-masked]<mailto:[email-masked]>>
Cc: Murray S. Kucherawy <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Rum] AD Review of draft-ietf-rum-rue
Thanks

On Oct 6, 2021, at 11:26 AM, Ed Sayers <[email-masked]<mailto:[email-masked]>> wrote:

Hi Brian,

For example:

Ed Sayers
Endpoint SDK Team Lead

-----Original Message-----
From: Brian Rosen <[email-masked]<mailto:[email-masked]>>
Sent: 06 October 2021 15:52
To: Ed Sayers <[email-masked]<mailto:[email-masked]>>
Cc: Murray S. Kucherawy <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Rum] AD Review of draft-ietf-rum-rue

Ed

Brian

On Oct 6, 2021, at 10:49 AM, Ed Sayers <[email-masked]<mailto:[email-masked]>> wrote:

Hi Brian,

Ed Sayers
Endpoint SDK Team Lead

-----Original Message-----
From: Rum <[email-masked]<mailto:[email-masked]>> On Behalf Of Brian Rosen
Sent: 06 October 2021 15:34
To: Murray S. Kucherawy <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Rum] AD Review of draft-ietf-rum-rue

Brian

On Oct 5, 2021, at 11:59 PM, Murray S. Kucherawy <[email-masked]<mailto:[email-masked]>> wrote:

Section 3:

Section 4:

Section 5:

Section 5.1

Section 5.4

Section 6.8:

Section 8:

* s/NOT/not/

-MSK
--
Rum mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rum

--
Rum mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rum

--
Rum mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rum

--
Rum mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rum

---

From: Brian Rosen <[email-masked]>
Date: Thu, 7 Oct 2021 10:20:21 -0400

Inline

> On Oct 7, 2021, at 2:27 AM, Olle E. Johansson <[email-masked]> wrote:
> 
> 
> 
>> 6 okt. 2021 kl. 19:39 skrev Brian Rosen <[email-masked] <mailto:[email-masked]>>:
>> 
You could implement it, but not announce it.  That would fall back to the INFO package.

> How is it negotiated? Reference?
I will put the reference to RFC4585 for NACK
>>   picture losses as Packet Loss Indicator (PLI) should be preferred.
Not sure what you want here.  PLI is defined in 5104.  There are other ways to use RTCP to indicate loss.  Do we really need to say what those are and provide references?

> Just something to consider before adding a MUST here. I would change it to a recommendation, an option for the implementor that wants to be backwards compatible. ”Backwards compatible” here does no…
I disagree.  There are lots of existing devices that conform to 5168.  We want to be backwards compatible with them.  This is not a new usage that 6068 contemplates: it’s backwards compatibility to a prior INFO use.

> 
> /O
> 
> 
> 
>> Is this acceptable?
>> 
>> Brian
>> 
>> 
>> 
>>> On Oct 6, 2021, at 12:29 PM, Paul Kyzivat <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>>> purplevrs.com <http://purplevrs.com/>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 12 Oct 2021 11:34:14 -0400

Murray,

I believe the -09 version addresses your comments. Please let us know if 
you see anything else that needs changing.

	Thanks,
	Paul

On 10/5/21 11:59 PM, Murray S. Kucherawy wrote:
> Overall this looks to be in pretty good shape.  Nice work.  I've only 
> got a few things that should be relatively easy to resolve.
> 
> Section 3:
> 
> * Suggest dropping "in this memo" at the end.  Two reasons: (1) You 
> don't really need it, and (2) the current preference is use "document" 
> rather than "memo" (and earlier in this section, you used "document" as 
> part of the BCP14 boilerplate).
> 
> Section 4:
> 
> here?  "SHOULD" implies a choice, preferably an informed one, so why 
> might an implementation not indicate the problem to the user?
> 
> Section 5.4
>