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

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Bo,

This all seems fine to me. Thank you for catching me up!

Spencer

On Tue, Sep 1, 2015 at 4:39 AM, Bo Burman <[e-mail]> wrote:

> 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]> 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]]
> > Sent: den 19 augusti 2015 05:17
> > To: The IESG
> > Cc: [e-mail];
> [e-mail]; [e-mail];
> > [e-mail];
> [e-mail]; [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
>