Subject: Re: [avtext] WGLC for draft-ietf-avtext-rtp-stream-pause-02

From: Christian Groves <[email-masked]>
Date: Mon, 18 Aug 2014 21:02:53 +1000

On reading the draft I didn't really see a discussion regarding the 
pause / resume point. E.g. an RTP receiver could request a pause in the 
transmission of RTP and then at a later point request a resumption of 
the stream. I assume there would be two options for the sender. (1) 
Continue sending RTP packets related to media from the time of the pause 
OR (2) send RTP packets from the time of the resumption. E.g. the RTP 
stream may relate to a movie, the initial pause point is 5min into the 
movie, a request for resumption occurs 2min after. The sender could send 
RTP related to the media from the 5min or 7min point in the movie. For a 
real time voice stream probably only (2) makes sense. Is the assumption 
of the draft that only option (2) is supported?

The other question is related to media sender pause/resume. Cl.5.3 of 
the draft indicates that the RTP sender can choose to pause a stream at 
any time. However cl.5.4 only mentions that the RTP receiver can request 
to resume a stream. Is this intentional? I would have thought the sender 
could also decide to resume at any time?

Regards, Christian

On 26/07/2014 2:36 AM, DRAGE, Keith (Keith) wrote:
> (As WG cochair)
>
> This is to announce a Working Group Last Call on
>
> https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-stream-pause/
>
> draft-ietf-avtext-rtp-stream-pause-02
>
> Please comment on the document by August 18th, 2014.
>
> Comments preferably to the AVTEXT list.
>
> It is helpful if you categorise your comments into Editorial, Minor technical, Major issue.
>
> The author has posed some open questions to the list. The chairs do not believe this should impact the appriateness of starting the WGLC now. However do please respond to those questions.
>
> The chairs realise this is a period when people will be disappearing on leave - if you intend commenting on the document but such leave means you need more time, please email the chairs with that information and when you think you might complete a WGLC review.
>
>
>
> Regards
>
> Keith
> _______________________________________________
> avtext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avtext
>

---

From: Bo Burman <[email-masked]>
Date: Tue, 19 Aug 2014 08:34:04 +0000

Thank you for the review!

Regarding your first question, the assumption was that the scope is real-time streams and thus only (2) makes sense, as you say. To maybe state the obvious, it does not make much sense to specify for a real-time (live) media source that pausing should start buffering data at the sender, where a resume would then start to play out data that may be several minutes old. I also assume that a movie-player type application would not have the real-time requirements on the signaling that motivates the use of this draft, but that it rather uses RTSP or some other media-player protocol that often has the possibility to explicitly specify resume points.

I think it makes sense to be clear and include a few sentences on pause / resume point at least in 4.1 "Real-time Nature", but maybe also point it out again in 5.4 "Requesting to Resume". Do you agree?

Regarding your second question, it sounds reasonable that a media sender can have some local considerations (not a RESUME request from someone else) that makes it decide to resume transmission. This local decision to resume a stream can be seen as the media sender sending RESUME to itself (internally), similar to that pausing a stream based on a local decision can be seen as the media sender sending PAUSE to itself (internally). I would however be interested to know if you have some concrete example scenario as to when this could happen?

I would expect such conditions making a media sender resume a stream based on local considerations include the ones described in the next-to-last paragraph of 5.2, where local considerations makes a media sender REFUSE to pause a stream.

I suggest including a sentence in 5.4 that a media sender MAY resume a paused stream at any point in time due to local considerations. It should then be pointed out (in line what is already described in next-to-last paragraph of 5.2) that for the case when the *media receiver* paused the stream using TMMBR 0, this "local resume" is not permitted, since it is incompatible with the TMMBR semantics! It would however be OK either when (only) the media sender paused the stream due to local considerations, or when using PAUSE/RESUME messages defined in this draft. OK?

To elaborate further, for the case of TMMBR/TMMBN signaling and assuming that the media sender has paused the stream due to local considerations, the PAUSED indication would be a TMMBR 0 containing the media sender itself (SSRC) as owning the bitrate (0) restriction. A media receiver that does not need to receive the (already paused) RTP stream could also send a TMMBR 0, and the restriction would then be jointly owned by both RTP end points. Assume that the local restrictions at the media sender that made it pause the stream in the first place are lifted, and following CCM [RFC 5104] rules, a new TMMBR 0 would be sent out where the media sender SSRC is no longer in the bounding set, only the media receiver. Even though the media sender is OK with not having the stream paused any longer, the media receiver still desires it to be paused and TMMBR semantics requires the bitrate to be kept at 0. 

Cheers,
Bo

> -----Original Message-----
> From: avtext [mailto:[email-masked]] On Behalf Of Christian Groves
> Sent: den 18 augusti 2014 13:03
> To: [email-masked]
> Subject: Re: [avtext] WGLC for draft-ietf-avtext-rtp-stream-pause-02
> 
> On reading the draft I didn't really see a discussion regarding the pause / resume point. E.g. an RTP receiver could request
> a pause in the transmission of RTP and then at a later point request a resumption of the stream. I assume there would be
> two options for the sender. (1) Continue sending RTP packets related to media from the time of the pause OR (2) send
> RTP packets from the time of the resumption. E.g. the RTP stream may relate to a movie, the initial pause point is 5min
> into the movie, a request for resumption occurs 2min after. The sender could send RTP related to the media from the
> 5min or 7min point in the movie. For a real time voice stream probably only (2) makes sense. Is the assumption of the
> draft that only option (2) is supported?
> 
> The other question is related to media sender pause/resume. Cl.5.3 of the draft indicates that the RTP sender can choose
> to pause a stream at any time. However cl.5.4 only mentions that the RTP receiver can request to resume a stream. Is this
> intentional? I would have thought the sender could also decide to resume at any time?
> 
> Regards, Christian
> 
> > The author has posed some open questions to the list. The chairs do not believe this should impact the appriateness of
> starting the WGLC now. However do please respond to those questions.
> >
> > The chairs realise this is a period when people will be disappearing on leave - if you intend commenting on the
> document but such leave means you need more time, please email the chairs with that information and when you think
> you might complete a WGLC review.
> >
> >
> >
> > Regards
> >
> > Keith

---

From: Christian Groves <[email-masked]>
Date: Wed, 20 Aug 2014 16:35:47 +1000

Hello Bo,

Thanks for your response. Please see my responses below and some further 
comments:

1) A minor nit: The headings titles for 4.5 and 12 are the same. Maybe 
change 4.5 to "Message acknowledgements".

2) Clause 9: Use of PAUSE and PAUSED: I must admit I find the 
distinction between these two parameters really confusing. Especially 
when the draft says that they are different functions but that "pause" 
encompasses "paused". It is really necessary to have two parameters? It 
seems that a node can do the following with respect to the messages:
a) Both send and receive PAUSE, RESUME, PAUSED and REFUSE
b) Send PAUSE, RESUME and receive PAUSED and REFUSE only
c) Receive PAUSE, RESUME and send PAUSED and REFUSE only
d) Do not receive messages but send a PAUSED only.

The issue seems to come when considering the local PAUSE functionality. 
As the draft notes that "pause" contains the full "paused" 
functionality", I could assume that a) b) and c) contain the local PAUSE 
functionality. d) would also have to contain the local PAUSE 
functionality. However I'm not sure b) would be valid because the node 
would have to be able to send PAUSED as a result of clause 5.3. Whilst 
the intent is that 'pause' and 'paused' are different functions there 
would appear to be interactions. e.g. It would be strange to set 
'pause=recvonly' and 'paused=recvonly'.

I think the usage at least needs to be clarified as there appears to be 
some overlap and inconsistencies with other sections. Preferably it 
would be good to try to use one parameter.

3) Clause 5.1 indicates "/<The> Capability to understand PAUSED 
indication is defined separately from the others to support partial 
implementation, which is specifically believed to be feasible for the 
RTP Mixer to Media Sender use case (Section 3.2)./" I guess the 
important thing is that its the media sender that must at least support 
the PAUSED indication, the mixer needs to support PAUSE.

4) Clause 10.1 paragraph below the figure. Indicates "/includes the 
"nowait" sub-parameter for both "pause" and "paused" parameters/" 
however the nowait parameter is only specified in the example offer for 
pause + nowait is not defined for paused in the ABNF syntax. The last 
paragraph in clause 9.1 also indicates that possibility to support 
"nowait" for "paused" i.e. "/The answerer MUST NOT add "nowait" on the 
"pause" line in the answer unless it is present on the "paused" line in 
the offer./" This isn't possible due to the syntax.

5) Clause 9.1 paragraph 2: "/In other words, an offer for "paused 
dir=sendonly" means that the offerer intends to send PAUSED indications 
whenever it pauses RTP stream delivery in any of its streams./" Would a 
pause in one stream require sending a PAUSED indication in multiple streams?

6) Clause 9.1 para.1 nit: "...functionality if the answer<er>.."

7) Clause 9.2 first paragraph: The third sentence indicates that it is 
normally only necessary to include either "pause" or "paused" however 
clause 9 indicates "SHOULD" for including both and clause 9.1 indicates 
"is RECOMMENDED" to include both. It seems the reasoning to use both is 
the same for O/A and declarative use, i.e. implementations may have 
different support levels.

Regards, Christian

> I think it makes sense to be clear and include a few sentences on pause / resume point at least in 4.1 "Real-time Nature", but maybe also point it out again in 5.4 "Requesting to Resume". Do you ag…
[CNG] I agree with your reasoning. I think it would be good to add some 
sentences to clarify this. Perhaps it would also be worth adding a 
formal definition for the term "pause"? I think naturally people assume 
the media player usage of the term as to expected behaviour as that's 
what they are used to.

> Regarding your second question, it sounds reasonable that a media sender can have some local considerations (not a RESUME request from someone else) that makes it decide to resume transmission. Thi…
[CNG] I don't have a particular scenario in mind. The question was 
largely triggered by the ability in 5.3 to have a local PAUSE. It seemed 
that if there were local conditions that triggered a PAUSE that the 
clearing of those conditions may result in a resumption of RTP flow.
> I would expect such conditions making a media sender resume a stream based on local considerations include the ones described in the next-to-last paragraph of 5.2, where local considerations makes…
[CNG] Not sure. "local conditions" are really enumerated by the draft. 
There could be media processing reasons e.g. para 2 clause 5.3. It could 
be related to a service e.g. hold etc.
> I suggest including a sentence in 5.4 that a media sender MAY resume a paused stream at any point in time due to local considerations. It should then be pointed out (in line what is already describ…
[CNG] Yes this sounds OK. I agree that the resume doesn't apply when 
TMMBR 0 is used.

---

From: Bo Burman <[email-masked]>
Date: Fri, 22 Aug 2014 12:35:11 +0000

Hi Christian,

Thank you again for comments! See my responses inline, including comments to your comments.

> From: Christian Groves [mailto:[email-masked]]
> Sent: den 20 augusti 2014 08:36
> To: Bo Burman; [email-masked]
> 1) A minor nit: The headings titles for 4.5 and 12 are the same. Maybe change 4.5 to "Message acknowledgements".
[BoB]: Good suggestion. Will do.

> 
> 2) Clause 9: Use of PAUSE and PAUSED: I must admit I find the distinction between these two parameters really
> confusing. Especially when the draft says that they are different functions but that "pause"
> encompasses "paused". It is really necessary to have two parameters? It seems that a node can do the following with
> respect to the messages:
> functionality", I could assume that a) b) and c) contain the local PAUSE functionality. d) would also have to contain the
> local PAUSE functionality. However I'm not sure b) would be valid because the node would have to be able to send
> PAUSED as a result of clause 5.3. Whilst the intent is that 'pause' and 'paused' are different functions there would appear
> to be interactions. e.g. It would be strange to set 'pause=recvonly' and 'paused=recvonly'.
> 
> I think the usage at least needs to be clarified as there appears to be some overlap and inconsistencies with other
> sections. Preferably it would be good to try to use one parameter.
[BoB]: Good catch and good analysis!

To go back to the design intent of "paused" and if I remember correctly, I believe it was to allow for a very restricted implementation that supports/knows _only_ "local pause" functionality, and additionally (with the dir= parameter) allow for just a) sending the indication, b) just receiving it, or c) both. This is however not motivated or required by any of the currently included use cases. It seems that some parts of the current text, for example clause 5.1, confuses the use of "paused" with what is actually solved by the direction parameter of "pause".

I think the following two main options are reasonable ways forward:

1) Remove the "paused" SDP parameter entirely, and with it the possibility to implement support of only the local pause indication

2) Make the text consistently express that "paused" refers to capability for that limited functionality. For SDP offer/answer, we then have a few more choices regarding the relation between "pause" and "paused":

	a)  an offer expressing support for this specification MUST contain only one of "pause" or "paused", and an offer with "pause" is possible to restrict by answering with "paused", but an offer with the limited "paused" cannot be upgraded to "pause" in the answer. May possibly cause problems with declarative use; guidance appreciated.

	b) "pause" and "paused" are kept separate (what current text mostly does, except for some confusion that must be corrected throughout if this option is chosen); the offer MAY contain either or both, while the answer MUST choose one and MUST NOT add anything that was not in the offer

> 
> 
> 3) Clause 5.1 indicates "/<The> Capability to understand PAUSED indication is defined separately from the others to
> support partial implementation, which is specifically believed to be feasible for the RTP Mixer to Media Sender use case
> (Section 3.2)./" I guess the important thing is that its the media sender that must at least support the PAUSED indication,
> the mixer needs to support PAUSE.
[BoB]: As said above, signaling for the mixer case is a bit confused in 5.1, and better dealt with (and covered) by having either dir=sendonly or dir=recvonly to pause parameter, depending on desired functionality restriction. Only supporting local PAUSED, indicated by "paused" SDP parameter, is a separate issue and should be made clearer, if not removed (see above).

> 
> 4) Clause 10.1 paragraph below the figure. Indicates "/includes the "nowait" sub-parameter for both "pause" and
> "paused" parameters/"
> however the nowait parameter is only specified in the example offer for pause + nowait is not defined for paused in the
> ABNF syntax. 
[BoB]: Correct. Only "pause" should be in the sentence above.

> The last paragraph in clause 9.1 also indicates that possibility to support "nowait" for "paused" i.e. "/The
> answerer MUST NOT add "nowait" on the "pause" line in the answer unless it is present on the "paused" line in the
> offer./" This isn't possible due to the syntax.
[BoB]: Correct. Probably a typo; "paused" -> "pause".

> 
> 5) Clause 9.1 paragraph 2: "/In other words, an offer for "paused dir=sendonly" means that the offerer intends to send
> PAUSED indications whenever it pauses RTP stream delivery in any of its streams./" Would a pause in one stream require
> sending a PAUSED indication in multiple streams?
[BoB]: No, only for the actually paused stream; unclear wording. What about simply "...intends to send PAUSED indications for paused RTP streams"?

> 6) Clause 9.1 para.1 nit: "...functionality if the answer<er>.."
[BoB]: OK

> 
> 7) Clause 9.2 first paragraph: The third sentence indicates that it is normally only necessary to include either "pause" or
> "paused" however clause 9 indicates "SHOULD" for including both and clause 9.1 indicates "is RECOMMENDED" to include
> both. It seems the reasoning to use both is the same for O/A and declarative use, i.e. implementations may have
[BoB]: I believe 9.2 should be changed to be aligned with 9.1 and RECOMMEND to include both (as long as option 2b from above is chosen/kept, otherwise that text has to be re-written accordingly) 

> > Regarding your first question, the assumption was that the scope is real-time streams and thus only (2) makes sense, as
> you say. To maybe state the obvious, it does not make much sense to specify for a real-time (live) media source that
> pausing should start buffering data at the sender, where a resume would then start to play out data that may be several
> minutes old. I also assume that a movie-player type application would not have the real-time requirements on the
> signaling that motivates the use of this draft, but that it rather uses RTSP or some other media-player protocol that often
> has the possibility to explicitly specify resume points.
> >
> > I think it makes sense to be clear and include a few sentences on pause / resume point at least in 4.1 "Real-time
> Nature", but maybe also point it out again in 5.4 "Requesting to Resume". Do you agree?
> [CNG] I agree with your reasoning. I think it would be good to add some sentences to clarify this. Perhaps it would also be
> worth adding a formal definition for the term "pause"? I think naturally people assume the media player usage of the
> term as to expected behaviour as that's what they are used to.
[BoB]: OK. Will change both 4.1, 5.4 and add a definition of "pause".

> 
> >
> > Regarding your second question, it sounds reasonable that a media sender can have some local considerations (not a
> RESUME request from someone else) that makes it decide to resume transmission. This local decision to resume a
> stream can be seen as the media sender sending RESUME to itself (internally), similar to that pausing a stream based on a
> local decision can be seen as the media sender sending PAUSE to itself (internally). I would however be interested to
> know if you have some concrete example scenario as to when this could happen?
> [CNG] I don't have a particular scenario in mind. The question was largely triggered by the ability in 5.3 to have a local
> PAUSE. It seemed that if there were local conditions that triggered a PAUSE that the clearing of those conditions may
> result in a resumption of RTP flow.
[BoB]: OK.

> >
> > I would expect such conditions making a media sender resume a stream based on local considerations include the ones
> described in the next-to-last paragraph of 5.2, where local considerations makes a media sender REFUSE to pause a
> stream.
> There could be media processing reasons e.g. para 2 clause 5.3. It could be related to a service e.g. hold etc.
> >
> > I suggest including a sentence in 5.4 that a media sender MAY resume a paused stream at any point in time due to local
> considerations. It should then be pointed out (in line what is already described in next-to-last paragraph of 5.2) that for
> the case when the *media receiver* paused the stream using TMMBR 0, this "local resume" is not permitted, since it is
> incompatible with the TMMBR semantics! It would however be OK either when (only) the media sender paused the
> stream due to local considerations, or when using PAUSE/RESUME messages defined in this draft. OK?
> [CNG] Yes this sounds OK. I agree that the resume doesn't apply when TMMBR 0 is used.
[BoB]: OK. Will add a short text for that into 5.4, as suggested.

> >
> > To elaborate further, for the case of TMMBR/TMMBN signaling and assuming that the media sender has paused the
> stream due to local considerations, the PAUSED indication would be a TMMBR 0 containing the media sender itself (SSRC)
> as owning the bitrate (0) restriction. A media receiver that does not need to receive the (already paused) RTP stream
> could also send a TMMBR 0, and the restriction would then be jointly owned by both RTP end points. Assume that the
> local restrictions at the media sender that made it pause the stream in the first place are lifted, and following CCM [RFC
> 5104] rules, a new TMMBR 0 would be sent out where the media sender SSRC is no longer in the bounding set, only the
> media receiver. Even though the media sender is OK with not having the stream paused any longer, the media receiver
> still desires it to be paused and TMMBR semantics requires the bitrate to be kept at 0.
> > Cheers,
> > Bo
> >
> >> pause / resume point. E.g. an RTP receiver could request a pause in
> >> the transmission of RTP and then at a later point request a
> >> resumption of the stream. I assume there would be two options for the
> >> sender. (1) Continue sending RTP packets related to media from the
> >> time of the pause OR (2) send RTP packets from the time of the
> >> resumption. E.g. the RTP stream may relate to a movie, the initial pause point is 5min into the movie, a request for
> resumption occurs 2min after. The sender could send RTP related to the media from the 5min or 7min point in the movie.
> For a real time voice stream probably only (2) makes sense. Is the assumption of the draft that only option (2) is
> supported?
> >>
> >> the draft indicates that the RTP sender can choose to pause a stream
> >> at any time. However cl.5.4 only mentions that the RTP receiver can request to resume a stream. Is this intentional? I
> would have thought the sender could also decide to resume at any time?
> >>
> >> Regards, Christian
> >>
> >>> The author has posed some open questions to the list. The chairs do
> >>> not believe this should impact the appriateness of
> >>> The chairs realise this is a period when people will be disappearing
> >>> on leave - if you intend commenting on the
> >> document but such leave means you need more time, please email the
> >> chairs with that information and when you think you might complete a WGLC review.
> >>>
> >>>
> >>> Regards
> >>>
> >>> Keith

---

From: Christian Groves <[email-masked]>
Date: Wed, 27 Aug 2014 16:49:46 +1000

Hello Bo,

Please see below.

Regards, Christian

On 22/08/2014 10:35 PM, Bo Burman wrote:
> ..snip..
[CNG] I wasn't following this closely when 'paused' was added so I'm not 
sure about removing it. It would simplify things if it was removed.
I think what would need to be added if local pause was supported without 
signalling is that a node supporting this draft must at minimum support 
the reception of a 'paused' indication and the sending of 'paused' if 
the node supports a paused state. There would probably need to be an 
extra value in direction indicating that PAUSE/RESUME is not sent or 
received.

Maybe an option 2c: If local pause is kept and it needs to be supported 
by signalling there actually appears to be 8 combinations of sent and 
received messages. I assume a node supporting the sending and/or 
reception of PAUSE must also support RESUME. A node supporting the 
reception of PAUSE/RESUME must also support sending PAUSED and REFUSED. 
The combinations a Node can support are:

1) Send(PAUSE,RESUMED,PAUSED,REFUSE) Receive (PAUSED,RESUMED,PAUSED,REFUSED)
2) Send(PAUSE, RESUME, PAUSED) Receive (PAUSED, REFUSED)
3) Send(PAUSED,REFUSED) Receive (PAUSE, RESUME, PAUSED)
4) Send(PAUSED,REFUSED) Receive (PAUSE, RESUME)
5) Send(PAUSE, RESUME) Receive (PAUSED, REFUSED)
6) Send(PAUSED) Receive(PAUSED)
7) Send() Receive(PAUSED)
8) Send(PAUSED) Receive()

Would it be easier to simply signal the messages that are supported 
rather than two parameters with a direction parameters? e.g. the draft 
could have the above list of values. If a node supported both the 
sending and reception of PAUSE/RESUME/PAUSED/REFUSED then it could 
signal e.g. a=rtcp-fb:98 ccm pause config=1 . Part of the confusion 
comes from the interaction between the parameters. This would remove the 
interaction.

It might make describing the SDP O/A procedures easier.
e.g.
On receiving an Offer with:
config=1 the answerer may reply with config=1, 2, 3, 4, 5, 6, 7 or 8.
config=2 the answerer may reply with config=3, 4, 5, 6, 7 or 8.
config=3 the answerer may reply with config=2, 4, 5, 6, 7 or 8.
config=4 the answerer may reply with config=5, 6, 7 or 8.
config=5 the answerer may reply with config=4, 6, 7 or 8.
config=6 the answerer may reply with config=6, 7 or 8.
config=7 the answerer may reply with config=8
config=8 the answerer may reply with config=7
In all cases the answerer may reply with a completely removed "pause" 
parameter.

An answerer cannot add extra messages to what is provided in the Offer. 
For example: If an Offer indicates config=6 an Answer cannot reply with 
config=3 indicating that it has the capability to receive PAUSE and 
RESUME. An answerer may remove messages that it does not support. For 
example: if an Offer indicates config=6 an Answer may reply with 
config=7 indicating that it can only receive PAUSED.

> [BoB]: No, only for the actually paused stream; unclear wording. What about simply "...intends to send PAUSED indications for paused RTP streams"?
[CNG] OK