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

[Bo Burman <[e-mail]>]

Hi Spencer,

I think your proposals are good and will make changes accordingly. See more inline.

From: Spencer Dawkins at IETF [mailto:[e-mail]]
Sent: den 27 augusti 2015 14:37
To: Bo Burman
Cc: The IESG; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: Spencer Dawkins' Yes on draft-ietf-avtext-rtp-stream-pause-08: (with COMMENT)

Hi, Bo,

On Thu, Aug 27, 2015 at 6:28 AM, Bo Burman <[e-mail]<mailto:[e-mail]>> wrote:
Thank you for good and constructive comments. Please find responses to your questions inline below.
Cheers,
Bo

> -----Original Message-----
> From: Spencer Dawkins [mailto:[e-mail]<mailto:[e-mail]>]
> Sent: den 19 augusti 2015 05:17
> To: The IESG
> Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;
> [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
> Subject: Spencer Dawkins' Yes on draft-ietf-avtext-rtp-stream-pause-08: (with COMMENT)
>
> 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.
[BoB] Thanks, your assumption is correct, and I think this active voice is easier to read.

Great.

>
> 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 :-)
[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.
[BoB] OK. I’ll add a sentence on this in section 5.6 and in section 8.

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

>
>    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?
[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?

>
>    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.
[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] OK. I’ll demote the RFC 2119 language in that section to prose text and add brief descriptive motivations.
I also think that a clause on RTCP timing in section 8.4 (REFUSED) is both misplaced and redundant, and propose to remove it:
   If REFUSED containing a certain PauseID was already sent and yet more
   PAUSE or RESUME messages are received that require additional REFUSED
   with that specific PauseID to be scheduled, further REFUSED messages
   with that PauseID SHOULD be sent in regular RTCP reports.  An
   exception to the previous rule is when the stream was paused and
   resumed so many times that the PauseID number space has wrapped since
    REFUSED was last sent with that PauseID.
I think that clause should be fully covered by the last bullet in 8.5 (text copied from -08; will be changed):
   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.

>
> 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.
[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.
[BoB] Definitely :)

I'd be OK with either MAY or SHOULD in both places (you guys are the experts), but it sounds like they should match.
[BoB] OK. I suggest to go for SHOULD in both places, and also add a sentence on when it can be motivated to violate that (multiple receivers with different config-capabilities, to avoid that the least capable receiver sets the functionality delivered to others).
I also received an offline comment suggesting to clarify that no partial message support is possible when using TMMBR/TMMBN, which should be obvious (since there is no such support in RFC 5104), but I anyway think that is a reasonable clarification to add.

Thanks!

Spencer