Subject: [avtext] Spencer Dawkins' Yes on draft-ietf-avtext-rtp-stream-pause-08: (with COMMENT)

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 18 Aug 2015 20:16:36 -0700

Spencer Dawkins has entered the following ballot position for
draft-ietf-avtext-rtp-stream-pause-08: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-stream-pause/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

This draft was really easy for me to read (with some background in
RTP/RTCP, but I'm no expert on the topic). Thank you for the work on it -
the results show.

I have some questions, but nothing is a show-stopper.

In this text:

3.3.  RTP Mixer to Media Sender in Point-to-Multipoint

   In this use case there are several receivers of a stream and special
   care must be taken as not to pause a stream that is still wanted by
   some receivers.
   
I'm assuming that the Mixer is taking special care, but this is passive
enough that I'm filling in blanks. If you like passive voice, perhaps
something like

   In this use case there are several receivers of a stream and special
   care must be taken by the Mixer so as not to pause a stream that is 
                      ^^^^^^^^^^^^^^^
   still wanted by some receivers.
   
would be easier to parse.

If you can do active voice, perhaps 

   In this use case there are several receivers of a stream and the 
   Mixer must take special care so as not to pause a stream that is still

   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   wanted by some receivers.
   
In this text:

8.  Message Details

   Any references to PAUSE, PAUSED, RESUME and REFUSED in this section
   SHALL be taken to apply to the extent possible also when TMMBR/TMMBN
   are used (Section 5.6) for this functionality.  TMMBR/TMMBN MAY be
                                                               ^^^
   used instead of the messages defined in this specification when the
   effective topology is point-to-point.  If either sender or receiver
   learns that the topology is not point-to-point, TMMBR/TMMBN MUST NOT
   be used for pause/resume functionality.  If the messages defined in
   this specification are supported in addition to TMMBR/TMMBN by all
   involved parties, pause/resume signaling MUST use messages from this
   specification.  If the topology is not point-to-point and the
   messages defined in this specification are not supported, pause/
   resume functionality with TMMBR/TMMBN MUST NOT be used.
   
All of this makes sense to me, except that I'm not understanding why
TMMBR/TMMBN is a MAY. There's a lot of text that says you really need to
use the messages from this specification in this case, and in that case,
and ... but here, you MAY do something else.

I understand that TMMBR/TMMBN works in a point-to-point topology, but is
there a reason to prefer TMMBR/TMMBN in that topology? If so, it would
probably be good to explain why.

And as I read futher, I see this, in section 9:

      Note: When TMMBR 0 / TMMBN 0 are used to implement pause and
      resume functionality (with the restrictions described in this
      specification), signaling rtcp-fb attribute with ccm tmmbr
      parameter is sufficient and no further signaling is necessary.
      There is however no guarantee that TMMBR/TMMBN implementations
                       ^^^^^^^^^^^^
      pre-dating this specification work exactly as described here when
      used with a bitrate value of 0.
      
and that really makes me wonder why this specification is also describing
TMMBR/TMMBN. I'm sure there's a good reason, but can you understand my
confusion?

Finally, I see this, in section 9.1,

   If both "pause" and "tmmbr" are present in the offer, both MAY be
   included also in the answer, in which case TMMBR/TMMBN MUST NOT be
   used for pause/resume purposes (with a bitrate value of 0), to avoid
   signaling ambiguity.
   
and in section 9.2,

   If both "pause" and "tmmbr" are present in the SDP, TMMBR/TMMBN MUST
   NOT be used for pause/resume purposes (with a bitrate value of 0), to
   avoid signaling ambiguity.
   
I'm now wondering if the description of TMMBR/TMMBN in this specification
just for interworking with older implementations that don't support
PAUSE/RESUME but figured out how to get a similar effect with
TMMBR/TMMBN? 

I'm guessing, of course :-)

In this text:

8.5.  Transmission Rules

   o  PAUSE SHOULD use Early or Immediate timing, except for
      retransmissions that SHOULD use Regular timing.
      
^ I understand this one.

   o  The first transmission of PAUSED for each (non-wrapped) PauseID
      SHOULD be sent with Immediate or Early timing, while subsequent
      PAUSED for that PauseID SHOULD use Regular timing.  Unsolicited
      PAUSED (sent when entering Local Paused State (Section 6.4))
      SHOULD always use Immediate or Early timing, until PAUSED for that
      PauseID is considered delivered at least once to all receivers of
      the paused RTP stream, after which it SHOULD use Regular timing.

^ I'm wondering why these are SHOULDs. Are they MUSTs except that some
implementations don't do it, or recommendations but nothing breaks if you
don't do them, or something else?

   o  RESUME SHOULD always use Immediate or Early timing.

^ I wonder why this is SHOULD. Is there any guidance you can provide
about why RESUME would use Regular timing?

   o  The first transmission of REFUSED for each (non-wrapped) PauseID
      SHOULD be sent with Immediate or Early timing, while subsequent
      REFUSED for that PauseID SHOULD use Regular timing.

^ I am, of course, wondering about the corresponding SHOULDs for
REFUSED.

In this text:

9.  Signaling

   When signaling a config value other than 1, an implementation MUST
   ignore non-supported messages on reception, and MAY omit sending non-
   supported messages.
   
is this saying that an implementation might send non-supported messages?
I'm confused here.

---

From: Bo Burman <[email-masked]>
Date: Thu, 27 Aug 2015 11:28:39 +0000

Thank you for good and constructive comments. Please find responses to your questions inline below.
Cheers,
Bo

> -----Original Message-----
> From: Spencer Dawkins [mailto:[email-masked]]
> Sent: den 19 augusti 2015 05:17
> To: The IESG
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: Spencer Dawkins' Yes on draft-ietf-avtext-rtp-stream-pause-08: (with COMMENT)
> 
> When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines.
> (Feel free to cut this introductory paragraph, however.)
> 
> 
> This draft was really easy for me to read (with some background in RTP/RTCP, but I'm no expert on the topic). Thank you
> for the work on it - the results show.
> 
> I'm assuming that the Mixer is taking special care, but this is passive enough that I'm filling in blanks. If you like passive
> voice, perhaps something like
> 
[BoB] Thanks, your assumption is correct, and I think this active voice is easier to read.

> All of this makes sense to me, except that I'm not understanding why TMMBR/TMMBN is a MAY. There's a lot of text that
> says you really need to use the messages from this specification in this case, and in that case, and ... but here, you MAY
> do something else.
> 
> I understand that TMMBR/TMMBN works in a point-to-point topology, but is there a reason to prefer TMMBR/TMMBN
> in that topology? If so, it would probably be good to explain why.
> 
> and that really makes me wonder why this specification is also describing TMMBR/TMMBN. I'm sure there's a good
> reason, but can you understand my confusion?
> 
> I'm now wondering if the description of TMMBR/TMMBN in this specification just for interworking with older
> implementations that don't support PAUSE/RESUME but figured out how to get a similar effect with TMMBR/TMMBN?
> 
[BoB] Your guess is correct. This is hinted already with the last two sentences in the Introduction section "The Temporary Maximum Media Bitrate Request (TMMBR) message of CCM is used by video conferencing systems for flow control. It is desirable to be able to use that method with a bitrate value of zero for pause, whenever possible". Do you think this needs to be more explicitly stated, maybe in section 5.6 on TMMBR/TMMBN considerations? Say, something similar to what you said above: "This use is expected to be mainly for interworking with implementations that don't support PAUSE/RESUME, but make use of TMMBR/TMMBN to achieve a similar effect". Do you think something needs to be said in section 8 too?

> ^ I'm wondering why these are SHOULDs. Are they MUSTs except that some implementations don't do it, or
> recommendations but nothing breaks if you don't do them, or something else?
[BoB] It is recommendations, meaning that if you don't follow them, nothing will really break, but you'll get worse performance in one way or the other. The SHOULDs for Early or Immediate is to provide good timeliness and responsiveness of the application making use of the messages, while the SHOULDs for Regular are to avoid excessive bandwidth consumption.

> ^ I wonder why this is SHOULD. Is there any guidance you can provide about why RESUME would use Regular timing?
[BoB] The only case I can come to think of is when other RTCP messages used by the application layer (not PAUSE/RESUME) are somehow considered more important than resuming media streams in that specific application context. Again, nothing would really break with regular timing, but performance would certainly suffer badly. Maybe such application-level consideration is sufficiently "extreme" that it is motivated changing to a MUST, forcing such situations to break compliance?

> ^ I am, of course, wondering about the corresponding SHOULDs for REFUSED.
[BoB] Timely transmission of REFUSED can stop unnecessary repetitions of PAUSE or RESUME, which I believe motivates recommending Immediate or Early for the first transmission to save some RTCP bandwidth. That is however not considered critical enough to motivate recommending repetitions of the same indication to be sent with other than Regular timing. Nothing would break if repetitions are sent with Early or Immediate timing, but it would potentially waste some transmission opportunities for other RTCP (FB) messages. Do you think it motivated to add more text on such considerations?

> is this saying that an implementation might send non-supported messages?
[BoB] That should have been "... MAY omit sending messages not supported by the remote peer". I realize that further down it is said "... SHOULD NOT be used towards receivers that did not declare capability to receive those messages", so I guess that MAY should be changed to a SHOULD to be consistent. In any case, not having MUSTs here allows a mix of different capabilities among receivers in a multi-receiver case without letting the least capable receiver set the level of P/R functionality for all the others. With that in mind, do you think "SHOULD omit" is a too strong wording?

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 27 Aug 2015 07:36:44 -0500

Hi, Bo,

On Thu, Aug 27, 2015 at 6:28 AM, Bo Burman <[email-masked]> wrote:

> > Cc: [email-masked];
> [email-masked]; [email-masked];
> email addresses included in the To and CC lines.
> > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> RTP/RTCP, but I'm no expert on the topic). Thank you
> enough that I'm filling in blanks. If you like passive

Great.

> TMMBR/TMMBN is a MAY. There's a lot of text that
> > says you really need to use the messages from this specification in this
> case, and in that case, and ... but here, you MAY
> > do something else.
> >
> there a reason to prefer TMMBR/TMMBN
> > and that really makes me wonder why this specification is also
> describing TMMBR/TMMBN. I'm sure there's a good
> > I'm now wondering if the description of TMMBR/TMMBN in this
> specification just for interworking with older
> [BoB] Your guess is correct. This is hinted already with the last two
> sentences in the Introduction section "The Temporary Maximum Media Bitrate
> Request (TMMBR) message of CCM is used by video conferencing systems for
> flow control. It is desirable to be able to use that method with a bitrate
> value of zero for pause, whenever possible". Do you think this needs to be
> more explicitly stated, maybe in section 5.6 on TMMBR/TMMBN considerations?
> Say, something similar to what you said above: "This use is expected to be
> mainly for interworking with implementations that don't support
> PAUSE/RESUME, but make use of TMMBR/TMMBN to achieve a similar effect". Do
> you think something needs to be said in section 8 too?

I do think that short explanations about motivation are helpful.

> implementations don't do it, or
> [BoB] It is recommendations, meaning that if you don't follow them,
> nothing will really break, but you'll get worse performance in one way or
> the other. The SHOULDs for Early or Immediate is to provide good timeliness
> and responsiveness of the application making use of the messages, while the
> SHOULDs for Regular are to avoid excessive bandwidth consumption.
>
> >
> [BoB] The only case I can come to think of is when other RTCP messages
> used by the application layer (not PAUSE/RESUME) are somehow considered
> more important than resuming media streams in that specific application
> context. Again, nothing would really break with regular timing, but
> performance would certainly suffer badly. Maybe such application-level
> consideration is sufficiently "extreme" that it is motivated changing to a
> MUST, forcing such situations to break compliance?
>
> >
> [BoB] Timely transmission of REFUSED can stop unnecessary repetitions of
> PAUSE or RESUME, which I believe motivates recommending Immediate or Early
> for the first transmission to save some RTCP bandwidth. That is however not
> considered critical enough to motivate recommending repetitions of the same
> indication to be sent with other than Regular timing. Nothing would break
> if repetitions are sent with Early or Immediate timing, but it would
> potentially waste some transmission opportunities for other RTCP (FB)
> messages. Do you think it motivated to add more text on such considerations?

I'd have a preference for text that explains the strategy, rather than
using RFC 2119 language when this isn't actually about interworking.

> [BoB] That should have been "... MAY omit sending messages not supported
> by the remote peer". I realize that further down it is said "... SHOULD NOT
> be used towards receivers that did not declare capability to receive those
> messages", so I guess that MAY should be changed to a SHOULD to be
> consistent. In any case, not having MUSTs here allows a mix of different
> capabilities among receivers in a multi-receiver case without letting the
> least capable receiver set the level of P/R functionality for all the
> others. With that in mind, do you think "SHOULD omit" is a too strong
> wording?
>

Making it clear who isn't supporting the non-supported messages seems
helpful.

I'd be OK with either MAY or SHOULD in both places (you guys are the
experts), but it sounds like they should match.

Thanks!

Spencer