Subject: [avtext] AD Evaluation of draft-ietf-avtext-rtp-stream-pause-07

From: "Ben Campbell" <[email-masked]>
Date: Mon, 15 Jun 2015 22:18:50 -0500

Hi,

Here's my AD Evaluation of draft-ietf-avtext-rtp-stream-pause-07. I've 
broken it down between things I'd like to see discussed prior to IETF 
last call, things I think can be worked in parallel to the last call, 
and things that are just editorial.

Thanks!

Ben.

*** Things to discuss before IETF Last Call:

-- Partial Support Configuration

I concur with Paul's SDP review that the current method of configuring 
partial support is confusing and error prone. I will go further and say 
I am concerned that the whole idea of partial support can really impact 
interoperability. It seems like there are many combinations where 
participants can simply fail to work (where failing to work means they 
cannot use this extension at all.) Have you had people say they are 
willing to implement some but not all features of this spec? Do the 
features cause harm if a participant tries to send them to a peer that 
doesn't understand them? (This is a bit of RTCP CCM esoterica that I do 
not know off-hand: Are recipients expected to ignore things they don't 
understand?)

I can see a switch or mixer declaring that it will never send PAUSE or 
RESUME. But it seems like encouraging (or even allowing) partial support 
for “endpoint” participants will hurt interoperability. For example, 
you have reason why a mixer or switch might choose to send pause—but 
that will never work if the endpoints don’t support receiving it.

So, when section 9 says " 'config' allows for partial implementation of 
this specification according to the different roles in the use cases 
section", do you mean to constrain the use of "config" to only those 
roles where it is needed? Would it make sense to say that 
mixers/switches that support pause must support at least certain 
configs, where endpoints must support other minimums?

-- "Available PauseID"

I find the specification of "Available PauseID" to be very confusing. 
Section 8.1 (third paragraph) seems to say that the PauseID in the PAUSE 
request should be taken from the most recently received PAUSED 
indication. But the next paragraph says the value from PAUSED should be 
incremented by one.

I think the confusion comes from two things. First, the name "Available 
PauseID" is a confusing choice. To me, "available" means I can use it. 
But if I understand correctly, I can't use that one for a "new" PAUSE 
request. Perhaps a better term would be "Current PauseID". That would 
make more sense if I refer to the "current" value to act on a current 
pause (or most recent) condition, and then have the concept of a "next" 
PauseID which would be the current one plus 1.

I also think it would help to have one section that describes 
(non-normatively) all the semantics of PauseID early in section 5 
(before the concept is first referenced.)

-- 2.2: Are the definitions in the RTP Taxonomy document necessary to 
understand/implement this draft? If so, this should be a normative 
reference, which we would need to call out in the last call. (I'm not 
saying they are required to understand this one--I'm not sure one way or 
another.)

-- 5.3, 3rd paragraph:

Does this mean the stream receiver may see a PAUSED indication prior to 
the stream actually being paused? (That is, see a paused indication, but 
continue to receive the stream?) I don't think that's the intent, but 
seeing this after the paragraphs on the PAUSED indication makes me 
wonder.

*** Things that can be treated as part of IETF Last Call:

-- I'm not going to push on this, since I assume this was a 
well-discussed compromise in the WG. But it seems to me that having two 
independent mechanisms to accomplish the same thing, with one only 
working in limited conditions (TMMBR/TMMBN) adds more complexity that 
value, and is likely to reduce interoperability.

-- 4.1: "The pause operation is arguably not very time critical"

This seems to contradict the previous sentence. I assume the point is 
that both are time sensitive, but pause is less so than resume?

-- 4.3:

Is it possible for the sender to change the SSRC between the pause and 
resume requests, so that the resume request refers to a stale SSRC 
value? Does it hurt anything if it happens?

-- 6.3.1, 2nd bullet:"the sender MUST keep
       record of which receiver that caused the RTP stream to pause.  If
       that receiver sends an RTCP BYE message observed by the sender,
       the sender SHALL resume the RTP stream."

If no other participant objected to the pause in the first place, why do 
we assume that exit of the original pause requestor means the other 
participants want the stream to resume? Why put the burden on the sender 
to track this?

-- 8: "If the messages defined in
    this specification are supported in addition to TMMBR/TMMBN, pause/
    resume signaling MUST use messages from this specification."

What if one (PTP) participant supports these formats, and the other only 
supports TMMBR/TMMBN? As worded that seems to mean that pause/resume 
cannot be used. (i.e. one MUST NOT use TMMBR/TMMBN because it supports 
the FCI messages, and the other only understands TMMBR/TMMBN?

"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."

This MUST NOT seems to be non-constraining.

-- 8.1, 3rd paragraph: "as indicated by PAUSED"

... or REFUSED?

-- 8.1, 4th from end:

Can you offer guidance on selecting an appropriate time?

-- 2nd paragraph from end:

This is a little confusing. Is the counter-indication really that local 
considerations make it _impossible_ to pause, or is simply _undesirable_ 
sufficient? Is pausing effectively optional?

Also, shouldn’t this mention the hold off?

-- 8.2, 2nd paragraph

Is this true for the locally paused state? If so, how is the PauseID 
value calculated for local pausing.

-- 3rd paragraph: "PAUSED SHALL contain..."

I assume this goes into the Type Specific field. If so, it would be 
worth explicitly mentioning that. Also, I assume that implies a 
fixed-length Type Specific in a PAUSED indication?

--8.4, 3rd paragraph:"receives a RESUME with a PauseID less than the 
valid one, in which case the RESUME SHALL be ignored."

This seems to conflict with the last sentence in 8.3. It says the resume 
is ignored if it contains a _valid_ PauseID or a value less than the 
valid one.

--8.4, 6th paragraph:

Can you offer guidance on selecting an appropriate time?

-- 15.2:

Seems like the references for RFCs 3264 and 4560 should be normative. 
This draft specified normative behavior for use with SDP and the 
offer/answer model.

*** Editorial Things:

-- section 1, paragraph 4, last sentence:

Long, convoluted sentence. Consider breaking into multiple, simpler 
sentences.

also, s/anyway/still

-- paragraph 5:

s/ "As the RTP streams..." / "As the set of RTP streams..."
s/ "... using Extended RTP Profile..." / "... using the Extended RTP 
Profile..."

-- 2nd to last paragraph: "... it is proposed to define..."

I suggest "This document defines..."

-- 3.1, three paragraphs starting with "RTCWEB WG's use case..."

These don't seem specific to this use case. Consider moving it out of 
the use case, or perhaps to the RTP Mixer to Media Sender use case 
(since that one mentions allowing the media sender to signal the 
receiver that it is pausing a stream.)

-- 3.2, First paragraph:

"That is accomplished
    through the Mixer originating its’ own streams, identified by 
SSRC..."

s/its'/its

Also, I seem you mean "identified by _distinct_ SSRC values"?

-- 3rd paragraph: "request to pause a particular stream"

request that a particular stream be paused, or request the sender to 
pause a particular stream.

-- 4th paragraph: "there may be situations that makes it desirable to 
the Mixer to pause some of its sent RTP streams"

do you mean "desirable _for_ the mixer…"? (Or do you mean to say the 
mixer desires that the streams be paused?

-- Figure 3:

Do B and D ever get mentioned? If not, it would be simpler without them.

-- 3.4

It’s kind of confusing to find that this section combines both the 
unicast and multicast cases, when the previous two sections separated 
them. I think it would be easier to understand if the information in 
this section were split between 3.2 and 3.3.

-- 4.1:

While I recognize that RAI has historically used real-time in this 
sense, it’s not the usual meaning of real-time in the field of 
computer science. Consider replacing “real-time” with 
“time-sensitive” or “time-sensitivity” depending on context.

-- 4.2:

s/who/that  (both times)
s/likes/needs (or wants)

-- 4.4, first paragraph, 2nd sentence:

Long, convoluted sentence. Please consider breaking it down into simpler 
sentences. (This is further confused by the presence of lots of commas, 
some of which separate list members, and some separate clauses.)

-- 4.5, last sentence:

I’m confused by this sentence. Do you mean to say, "In this error 
condition a negative acknowledgement may be needed…"

-- 4.8, first paragraph:

Any reason to cite 4566 but not 3261? (Both have been cited earlier in 
the draft.)

-- 5, 2nd paragraph: "It is proposed..."

Unless that proposal has not been accepted, consider saying "This 
solution re-uses..."

-- 5.4, 1st paragraph: "can request to resume... "

request the sender to resume, or request the resumption of...

-- paragraph 6: "it cannot be resumed due to local considerations"

This can be read to say that local considerations may prevent 
resumption, but I think you mean that resumption is prevented by 
protocol, even if the sender would like to resume due to local 
considerations.

-- 7th paragraph: "Should such temporal dependency between before and 
after
    the media was paused be used by the RTP stream sender, it requires
    the RTP stream receiver to have saved the sample from before the
    pause for successful continued decoding when resuming."

Do you mean temporal dependency between samples sent before and after 
the media was paused?

    "temporal dependency to before the pause"

dependency on samples from before the pause?

-- 6.4, 4th paragraph from end:

s/"responsible to leave"/"responsible for leaving"

Figure 5:

is all of the above (Both the common packet and the FCI formats and the 
intervening text) one figure, or should they be figure 5 and 6?

-- 8.2, first paragraph:

Are there other ways to get into those states? Wouldn’t it be simpler 
to say the indication MUST be sent whenever entering the paused or 
locally paused states?

-- 9, first paragraph after Figure 7: "but MAY use existing ccm tmmbr 
signaling [RFC5104] if the limitations in functionality as described in 
this specification coming from such usage are considered acceptable."

I don't understand what "coming from such usage" means in context.

-- 9, 2nd paragraph after figure 7:

s/independent/independently
s/likes/needs (or wants)

---

From: "Roni Even" <[email-masked]>
Date: Tue, 16 Jun 2015 09:01:37 +0300

Hi Ben,
With regards to 

> -- I'm not going to push on this, since I assume this was a well-discussed
> compromise in the WG. But it seems to me that having two independent
> mechanisms to accomplish the same thing, with one only working in limited
> conditions (TMMBR/TMMBN) adds more complexity that value, and is likely to
> reduce interoperability.

This has to do with the definition of TMMBR /TMMBN in RFC5104. The use case there support a group media session like multicast but since a lot of usage is by point to point video conferencing (even multipoint in these applications is doing media as point to point connection) allowed those usages to use TMMBR/TMMBN also for pause and resume since there are only two parties in each media session and it is used this way. As explained in the document TMMBR/TMMBN will not be efficient in multicast since the sender must look at what all participants wants and that is why we need this new messages. Still current system that use TMMBR/TMMBN for pausing are not contradicting RFC5104 and this is why we documented both methods
Roni

> -----Original Message-----
> From: avtext [mailto:[email-masked]] On Behalf Of Ben Campbell
> Sent: 16 June, 2015 6:19 AM
> To: [email-masked]; [email-masked]
> Subject: [avtext] AD Evaluation of draft-ietf-avtext-rtp-stream-pause-07
> 
> Hi,
> 
> Here's my AD Evaluation of draft-ietf-avtext-rtp-stream-pause-07. I've broken it
> down between things I'd like to see discussed prior to IETF last call, things I
> think can be worked in parallel to the last call, and things that are just editorial.
> 
> Thanks!
> 
> Ben.
> 
> I concur with Paul's SDP review that the current method of configuring partial
> support is confusing and error prone. I will go further and say I am concerned
> that the whole idea of partial support can really impact interoperability. It
> seems like there are many combinations where participants can simply fail to
> work (where failing to work means they cannot use this extension at all.) Have
> you had people say they are willing to implement some but not all features of
> this spec? Do the features cause harm if a participant tries to send them to a
> peer that doesn't understand them? (This is a bit of RTCP CCM esoterica that I
> do not know off-hand: Are recipients expected to ignore things they don't
> understand?)
> 
> I can see a switch or mixer declaring that it will never send PAUSE or RESUME.
> But it seems like encouraging (or even allowing) partial support for “endpoint”
> participants will hurt interoperability. For example, you have reason why a
> mixer or switch might choose to send pause—but that will never work if the
> endpoints don’t support receiving it.
> 
> So, when section 9 says " 'config' allows for partial implementation of this
> specification according to the different roles in the use cases section", do you
> mean to constrain the use of "config" to only those roles where it is needed?
> Would it make sense to say that mixers/switches that support pause must
> support at least certain configs, where endpoints must support other
> minimums?
> 
> -- "Available PauseID"
> 
> request should be taken from the most recently received PAUSED indication.
> But the next paragraph says the value from PAUSED should be incremented by
> one.
> 
> But if I understand correctly, I can't use that one for a "new" PAUSE request.
> Perhaps a better term would be "Current PauseID". That would make more
> sense if I refer to the "current" value to act on a current pause (or most recent)
> condition, and then have the concept of a "next"
> (non-normatively) all the semantics of PauseID early in section 5 (before the
> concept is first referenced.)
> 
> understand/implement this draft? If so, this should be a normative reference,
> which we would need to call out in the last call. (I'm not saying they are
> required to understand this one--I'm not sure one way or
> another.)
> 
> -- 5.3, 3rd paragraph:
> 
> Does this mean the stream receiver may see a PAUSED indication prior to the
> stream actually being paused? (That is, see a paused indication, but continue to
> receive the stream?) I don't think that's the intent, but seeing this after the
> paragraphs on the PAUSED indication makes me wonder.
> 
> -- I'm not going to push on this, since I assume this was a well-discussed
> compromise in the WG. But it seems to me that having two independent
> mechanisms to accomplish the same thing, with one only working in limited
> conditions (TMMBR/TMMBN) adds more complexity that value, and is likely to
> reduce interoperability.
> 
> This seems to contradict the previous sentence. I assume the point is that both
> are time sensitive, but pause is less so than resume?
> 
> -- 4.3:
> 
> Is it possible for the sender to change the SSRC between the pause and resume
> requests, so that the resume request refers to a stale SSRC value? Does it hurt
> anything if it happens?
> 
> If no other participant objected to the pause in the first place, why do we
> assume that exit of the original pause requestor means the other participants
> want the stream to resume? Why put the burden on the sender to track this?
> 
> Is this true for the locally paused state? If so, how is the PauseID value
> calculated for local pausing.
> 
> I assume this goes into the Type Specific field. If so, it would be worth explicitly
> mentioning that. Also, I assume that implies a fixed-length Type Specific in a
> PAUSED indication?
> 
> --8.4, 3rd paragraph:"receives a RESUME with a PauseID less than the valid
> one, in which case the RESUME SHALL be ignored."
> 
> This seems to conflict with the last sentence in 8.3. It says the resume is
> ignored if it contains a _valid_ PauseID or a value less than the valid one.
> 
> --8.4, 6th paragraph:
> 
> This draft specified normative behavior for use with SDP and the offer/answer
> model.
> 
> *** Editorial Things:
> 
> Long, convoluted sentence. Consider breaking into multiple, simpler sentences.
> 
> also, s/anyway/still
> 
> -- paragraph 5:
> 
> s/ "... using Extended RTP Profile..." / "... using the Extended RTP Profile..."
> 
> These don't seem specific to this use case. Consider moving it out of the use
> case, or perhaps to the RTP Mixer to Media Sender use case (since that one
> mentions allowing the media sender to signal the receiver that it is pausing a
> stream.)
> 
> 
> -- 3.2, First paragraph:
> 
> "That is accomplished
>     through the Mixer originating its’ own streams, identified by SSRC..."
> 
> s/its'/its
> 
> request that a particular stream be paused, or request the sender to pause a
> particular stream.
> 
> -- 4th paragraph: "there may be situations that makes it desirable to the Mixer
> to pause some of its sent RTP streams"
> 
> do you mean "desirable _for_ the mixer…"? (Or do you mean to say the mixer
> desires that the streams be paused?
> 
> -- Figure 3:
> 
> It’s kind of confusing to find that this section combines both the unicast and
> multicast cases, when the previous two sections separated them. I think it
> would be easier to understand if the information in this section were split
> between 3.2 and 3.3.
> 
> -- 4.1:
> 
> While I recognize that RAI has historically used real-time in this sense, it’s not
> the usual meaning of real-time in the field of computer science. Consider
> replacing “real-time” with “time-sensitive” or “time-sensitivity” depending on
> context.
> 
> -- 4.2:
> 
> s/who/that  (both times)
> s/likes/needs (or wants)
> 
> sentences. (This is further confused by the presence of lots of commas, some of
> which separate list members, and some separate clauses.)
> 
> -- 4.5, last sentence:
> 
> I’m confused by this sentence. Do you mean to say, "In this error condition a
> negative acknowledgement may be needed…"
> 
> -- 4.8, first paragraph:
> 
> Any reason to cite 4566 but not 3261? (Both have been cited earlier in the
> draft.)
> 
> Unless that proposal has not been accepted, consider saying "This solution re-
> uses..."
> 
> This can be read to say that local considerations may prevent resumption, but I
> think you mean that resumption is prevented by protocol, even if the sender
> would like to resume due to local considerations.
> 
> -- 7th paragraph: "Should such temporal dependency between before and after
> Do you mean temporal dependency between samples sent before and after the
> media was paused?
> 
> Are there other ways to get into those states? Wouldn’t it be simpler to say the
> indication MUST be sent whenever entering the paused or locally paused
> states?
> 
> -- 9, first paragraph after Figure 7: "but MAY use existing ccm tmmbr signaling
> [RFC5104] if the limitations in functionality as described in this specification
> coming from such usage are considered acceptable."
> 
> _______________________________________________
> avtext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avtext

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 18 Jun 2015 15:56:32 -0500

Hi,

I have a few comments on further reflection:

I notice that there are IPR declarations against the original version 
(prior to wg acceptance.) The license terms allow the possibility of 
royalties. I also see that the shepherd writeup mentions that avtext 
discussed these and are okay with them. However, this draft references 
some RTCWEB requirements as partial motivation. Have the IPR disclosures 
been discussed with RTCWEB, to confirm that they would be willing to use 
a mechanism with those disclosures?

On my comments about the "config" parameter:

The root of my concern is not the mechanism for negotiating partial 
support, but the number of config "profiles". It seems like this could 
encourage implementations that cannot use the mechanism interoperably. 
For example, the draft shows use cases where a conference bridge might 
need to ask an endpoint to pause. If people build endpoints that only 
support 2 or 3, then this would not be possible.

So my real question is, does the mechanism really need all 8 modes? Are 
there known situations where an implementer would choose not to 
implement this mechanism if one of the modes didn't exist? Some of them 
seem to have fairly subtle differences (e.g. whether the device may 
locally pause or not.)

Ben.

On 15 Jun 2015, at 22:18, Ben Campbell wrote:

> partial support is confusing and error prone. I will go further and 
> say I am concerned that the whole idea of partial support can really 
> impact interoperability. It seems like there are many combinations 
> where participants can simply fail to work (where failing to work 
> means they cannot use this extension at all.) Have you had people say 
> they are willing to implement some but not all features of this spec? 
> Do the features cause harm if a participant tries to send them to a 
> peer that doesn't understand them? (This is a bit of RTCP CCM 
> esoterica that I do not know off-hand: Are recipients expected to 
> ignore things they don't understand?)
>
> RESUME. But it seems like encouraging (or even allowing) partial 
> support for “endpoint” participants will hurt interoperability. 
> For example, you have reason why a mixer or switch might choose to 
> send pause—but that will never work if the endpoints don’t support 
> receiving it.
>
> So, when section 9 says " 'config' allows for partial implementation 
> of this specification according to the different roles in the use 
> cases section", do you mean to constrain the use of "config" to only 
> those roles where it is needed? Would it make sense to say that 
> Section 8.1 (third paragraph) seems to say that the PauseID in the 
> PAUSE request should be taken from the most recently received PAUSED 
> indication. But the next paragraph says the value from PAUSED should 
> be incremented by one.
>
> I think the confusion comes from two things. First, the name 
> "Available PauseID" is a confusing choice. To me, "available" means I 
> can use it. But if I understand correctly, I can't use that one for a 
> "new" PAUSE request. Perhaps a better term would be "Current PauseID". 
> That would make more sense if I refer to the "current" value to act on 
> a current pause (or most recent) condition, and then have the concept 
> of a "next" PauseID which would be the current one plus 1.
>
> saying they are required to understand this one--I'm not sure one way 
> or another.)
>
> -- 5.3, 3rd paragraph:
>
> Does this mean the stream receiver may see a PAUSED indication prior 
> to the stream actually being paused? (That is, see a paused 
> indication, but continue to receive the stream?) I don't think that's 
> the intent, but seeing this after the paragraphs on the PAUSED 
> indication makes me wonder.
>
> well-discussed compromise in the WG. But it seems to me that having 
> two independent mechanisms to accomplish the same thing, with one only 
> If no other participant objected to the pause in the first place, why 
> do we assume that exit of the original pause requestor means the other 
> participants want the stream to resume? Why put the burden on the 
> sender to track this?
>
> What if one (PTP) participant supports these formats, and the other 
> only supports TMMBR/TMMBN? As worded that seems to mean that 
> pause/resume cannot be used. (i.e. one MUST NOT use TMMBR/TMMBN 
> because it supports the FCI messages, and the other only understands 
> TMMBR/TMMBN?
>
> This is a little confusing. Is the counter-indication really that 
> local considerations make it _impossible_ to pause, or is simply 
> _undesirable_ sufficient? Is pausing effectively optional?
>
> This seems to conflict with the last sentence in 8.3. It says the 
> resume is ignored if it contains a _valid_ PauseID or a value less 
> than the valid one.
>
> --8.4, 6th paragraph:
>
> Long, convoluted sentence. Please consider breaking it down into 
> simpler sentences. (This is further confused by the presence of lots 
> of commas, some of which separate list members, and some separate 
> clauses.)
>
> -- 4.5, last sentence:
>
> is all of the above (Both the common packet and the FCI formats and 
> the intervening text) one figure, or should they be figure 5 and 6?
>
> -- 8.2, first paragraph:
>
> Are there other ways to get into those states? Wouldn’t it be 
> simpler to say the indication MUST be sent whenever entering the 
> paused or locally paused states?
>
> signaling [RFC5104] if the limitations in functionality as described 
> in this specification coming from such usage are considered 
> acceptable."
>

---

From: Bo Burman <[email-masked]>
Date: Mon, 22 Jun 2015 16:42:02 +0000

Ben, all,

Please see inline.

Cheers,
Bo

> From: Ben Campbell [mailto:[email-masked]]
> Sent: den 18 juni 2015 22:57
> Subject: Re: [avtext] AD Evaluation of draft-ietf-avtext-rtp-stream-pause-07
> 
> Hi,
> 
> I notice that there are IPR declarations against the original version (prior to wg acceptance.) The license terms allow the
> possibility of royalties. I also see that the shepherd writeup mentions that avtext discussed these and are okay with
> them. However, this draft references some RTCWEB requirements as partial motivation. Have the IPR disclosures been
> discussed with RTCWEB, to confirm that they would be willing to use a mechanism with those disclosures?
[BoB] Use of this draft in RTCWEB context has been discussed, e.g. in this thread https://mailarchive.ietf.org/arch/msg/rtcweb/d95AfR5YthE7O4he4yaTCOj8h1o, clarifying that use in RTCWEB would mainly target the RFC 5104-based TMMBR/TMMBN 0 mode, and one of the conclusions of the discussion was to keep the functionality out of v1.0. The draft is currently not referenced from any RTCWEB v1.0 specification. One of the alternatives mentioned in the thread above was to use an application-specific message in a DataChannel, but I cannot find that there was ever any consensus on what to do in v1.0, or if it should be specified at all.

> The root of my concern is not the mechanism for negotiating partial support, but the number of config "profiles". It
> seems like this could encourage implementations that cannot use the mechanism interoperably.
> For example, the draft shows use cases where a conference bridge might need to ask an endpoint to pause. If people
> build endpoints that only support 2 or 3, then this would not be possible.
[BoB] Let me try to answer by highlighting and summarizing the underlying reasons for those different config "profiles".

Config=1 is the "full" implementation.

Config=2 and 4 are intended for the RTP stream receiver that wants to pause/resume the remote sender's stream, but sees no use of letting anyone pause/resume its own sent RTP streams (if any). This may typically be implemented by a conference bridge. Config=4 differs from 2 only in that config=4 has no PAUSED support. To implement config=2 or 4 in an endpoint supposed to be connected to a conference bridge would obviously not work and would in my mind be a mistake or misunderstanding of the draft text rather than a deliberate design. Do you think that a clarification is needed in this respect?

Config=3 and 5 are intended for the RTP stream sender that wants to leave pause/resume control to a remote RTP stream receiver, but has no desire to control anyone else's RTP streams. This may typically be implemented by an endpoint participating in a group call through a conference bridge. 5 differs from 3 only in that it has no PAUSED support. Similar to above, implementing config=3 or 5 in a conference bridge could be a misunderstanding or mistake. Do you clarification is needed?

Config=6-8 all deal only with PAUSED (sendrecv/recvonly/sendonly capability, respectively). If I remember correctly, it was brought up during an IETF meeting (forgot which and by whom) that it could be a useful functionality in itself to indicate local pause. I then assumed that the it was not desirable to require the rest of pause/resume functionality to be able to use that, which is why config=6-8 are there in the draft. Implementations of config=6-8 are obviously not able to get any pause/resume functionality, but assumedly also don't wish to, and are in any case "interoperable" with other config supporting PAUSED.

Regarding config=4 and 5, not supporting PAUSED is not detrimental to pause/resume functionality and is in that sense "backwards compatible", but having explicit indication of PAUSED support allows to avoid some heuristics and delays in pause/resume implementation control logic, in addition to saving the bandwidth for sending unnecessary PAUSED.

As a side comment, use of pause/resume in a conference bridge cascading scenario would likely require config=1 between the conference bridges to provide sufficient functionality.

> 
> So my real question is, does the mechanism really need all 8 modes? Are there known situations where an implementer
> would choose not to implement this mechanism if one of the modes didn't exist? Some of them seem to have fairly
> subtle differences (e.g. whether the device may locally pause or not.)
[BoB] I'd rather say that if there were no configurations at all, there's a risk that implementations may anyway choose to implement a subset of the full functionality because it sees no use for the rest (correctly or not), like a conference bridge that sees no point in pausing its sent RTP streams. Is it not better from an interoperability perspective to specify how this subset restriction must be made to achieve a certain desirable functionality, instead of leaving it to individual implementations to decide what parts of the specification can and what cannot be omitted (admittedly in violation of the specification), to still have a reasonably working and interoperable implementation?

Are there too many configurations? I don't see how this can be determined with any certainty until there is a significant number of implementations in several different contexts. The number of config's _can_ certainly be reduced if you change the preconditions. If you for example were to require that all implementations must support PAUSED, _and_ that no implementations are allowed to _only_ support PAUSED, the number of configurations that are supported by any reasonable remaining use case would immediately drop to three (configurations 1-3).

> > "If the topology is not point-to-point and the messages defined in
> > this specification are not supported, pause/resume functionality with
> > computer science. Consider replacing “real-time” with “time-sensitive”
> > or “time-sensitivity” depending on context.
> >
> > -- 4.2:
> >
> > s/who/that  (both times)
> > s/likes/needs (or wants)
> >
> > after the media was paused be used by the RTP stream sender, it
> > requires the RTP stream receiver to have saved the sample from before
> > the pause for successful continued decoding when resuming."
> >

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 22 Jun 2015 15:44:40 -0500

On 22 Jun 2015, at 11:42, Bo Burman wrote:

>> (prior to wg acceptance.) The license terms allow the
>> possibility of royalties. I also see that the shepherd writeup 
>> mentions that avtext discussed these and are okay with
>> them. However, this draft references some RTCWEB requirements as 
>> partial motivation. Have the IPR disclosures been
> [BoB] Use of this draft in RTCWEB context has been discussed, e.g. in 
> this thread 
> https://mailarchive.ietf.org/arch/msg/rtcweb/d95AfR5YthE7O4he4yaTCOj8h1o, 
> clarifying that use in RTCWEB would mainly target the RFC 5104-based 
> TMMBR/TMMBN 0 mode, and one of the conclusions of the discussion was 
> to keep the functionality out of v1.0. The draft is currently not 
> referenced from any RTCWEB v1.0 specification. One of the alternatives 
> mentioned in the thread above was to use an application-specific 
> message in a DataChannel, but I cannot find that there was ever any 
> consensus on what to do in v1.0, or if it should be specified at all.

If this draft is not referenced by RTCWEB,  is the mention of RTCWEB use 
cases still relevant? (Unless I am reading it wrong, the quoted use 
cases really only support the "paused" semantic.)

>> support, but the number of config "profiles". It
>> For example, the draft shows use cases where a conference bridge 
>> might need to ask an endpoint to pause. If people
> [BoB] Let me try to answer by highlighting and summarizing the 
> underlying reasons for those different config "profiles".
>
> Config=2 and 4 are intended for the RTP stream receiver that wants to 
> pause/resume the remote sender's stream, but sees no use of letting 
> anyone pause/resume its own sent RTP streams (if any). This may 
> typically be implemented by a conference bridge. Config=4 differs from 
> 2 only in that config=4 has no PAUSED support. To implement config=2 
> or 4 in an endpoint supposed to be connected to a conference bridge 
> would obviously not work and would in my mind be a mistake or 
> misunderstanding of the draft text rather than a deliberate design. Do 
> you think that a clarification is needed in this respect?
>
> Config=3 and 5 are intended for the RTP stream sender that wants to 
> leave pause/resume control to a remote RTP stream receiver, but has no 
> desire to control anyone else's RTP streams. This may typically be 
> implemented by an endpoint participating in a group call through a 
> conference bridge. 5 differs from 3 only in that it has no PAUSED 
> support. Similar to above, implementing config=3 or 5 in a conference 
> bridge could be a misunderstanding or mistake. Do you clarification is 
> needed?

(In reference to the last sentence of each paragraph):  In general, I 
think this is an issue of balancing interoperability against the ability 
of implemntors that don't (think they) need to support all use cases to 
implement profiles. That's been a general issue for the IETF more than 
once, and I'm not sure we've ever gotten it right. A few paragraphs 
about the interoperability considerations among the various modes would 
be helpful.
>
> Config=6-8 all deal only with PAUSED (sendrecv/recvonly/sendonly 
> capability, respectively). If I remember correctly, it was brought up 
> during an IETF meeting (forgot which and by whom) that it could be a 
> useful functionality in itself to indicate local pause. I then assumed 
> that the it was not desirable to require the rest of pause/resume 
> functionality to be able to use that, which is why config=6-8 are 
> there in the draft. Implementations of config=6-8 are obviously not 
> able to get any pause/resume functionality, but assumedly also don't 
> wish to, and are in any case "interoperable" with other config 
> supporting PAUSED.

I'm skeptical about adding modes because they "might be useful", vs 
demonstrably needed. To some degree, the "might be useful" argument 
supports Paul's suggestion of indicating support on a per-method basis. 
But it's a bit late in the process to push on that (the "might be 
useful) part, so I will not do so further.

>
> Regarding config=4 and 5, not supporting PAUSED is not detrimental to 
> pause/resume functionality and is in that sense "backwards 
> compatible", but having explicit indication of PAUSED support allows 
> to avoid some heuristics and delays in pause/resume implementation 
> control logic, in addition to saving the bandwidth for sending 
> unnecessary PAUSED.
>
> As a side comment, use of pause/resume in a conference bridge 
> cascading scenario would likely require config=1 between the 
> conference bridges to provide sufficient functionality.

That would be worth a mention in the aforementioned interop 
considerations.

>
>>
>> So my real question is, does the mechanism really need all 8 modes? 
>> Are there known situations where an implementer
>> would choose not to implement this mechanism if one of the modes 
>> didn't exist? Some of them seem to have fairly
> [BoB] I'd rather say that if there were no configurations at all, 
> there's a risk that implementations may anyway choose to implement a 
> subset of the full functionality because it sees no use for the rest 
> (correctly or not), like a conference bridge that sees no point in 
> pausing its sent RTP streams. Is it not better from an 
> interoperability perspective to specify how this subset restriction 
> must be made to achieve a certain desirable functionality, instead of 
> leaving it to individual implementations to decide what parts of the 
> specification can and what cannot be omitted (admittedly in violation 
> of the specification), to still have a reasonably working and 
> interoperable implementation?

Have potential implementors indicated they would do that?

>
> Are there too many configurations? I don't see how this can be 
> determined with any certainty until there is a significant number of 
> implementations in several different contexts. The number of config's 
> _can_ certainly be reduced if you change the preconditions. If you for 
> example were to require that all implementations must support PAUSED, 
> _and_ that no implementations are allowed to _only_ support PAUSED, 
> the number of configurations that are supported by any reasonable 
> remaining use case would immediately drop to three (configurations 
> 1-3).

I guess I was thinking more in terms of whether all the modes are 
actually needed by use cases that people have thought about. But this 
also falls into the case of being too late in the process to push on it.

[...]

Thanks!

Ben.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 22 Jun 2015 23:42:36 +0000

I'd note there are drafts all over IETF that could potentially be used in RTCWEB implementations, even though they are not directly referenced. We could start with all PAYLOAD deliverables, all XRBLOCK deliverables, all CLUE deliverables ....

Your initial comment is effectively asking for RTCWEB to be included in the WGLC of all those documents.

Regards

Keith

> Sent: 22 June 2015 21:45
> To: Bo Burman
> Cc: [email-masked]; [email-masked]
> possibility of 
> >> discussed these and are okay with them. However, this draft 
> >> references some RTCWEB requirements as partial motivation. 
> Have the 
> >> IPR disclosures been discussed with RTCWEB, to confirm that they 
> >> would be willing to use a mechanism with those disclosures?
> https://mailarchive.ietf.org/arch/msg/rtcweb/d95AfR5YthE7O4he4yaTCOj8h
> > 1o, clarifying that use in RTCWEB would mainly target the RFC 
> > 5104-based TMMBR/TMMBN 0 mode, and one of the conclusions of the 
> > discussion was to keep the functionality out of v1.0. The draft is 
> > currently not referenced from any RTCWEB v1.0 specification. One of 
> > the alternatives mentioned in the thread above was to use an 
> > application-specific message in a DataChannel, but I cannot 
> find that 
> > there was ever any consensus on what to do in v1.0, or if 
> it should be 
> > specified at all.
> 
> If this draft is not referenced by RTCWEB,  is the mention of 
> RTCWEB use cases still relevant? (Unless I am reading it 
> wrong, the quoted use cases really only support the "paused" 
> semantic.)
> 
> >
> >>
> >> seems like this could encourage implementations that 
> cannot use the 
> >> mechanism interoperably.

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 22 Jun 2015 18:48:00 -0500

On 22 Jun 2015, at 18:42, DRAGE, Keith (Keith) wrote:

> I'd note there are drafts all over IETF that could potentially be used 
> in RTCWEB implementations, even though they are not directly 
> referenced. We could start with all PAYLOAD deliverables, all XRBLOCK 
> deliverables, all CLUE deliverables ....
>

That wasn't my intent. This document _explicitly_ lists RTCWEB use 
cases, and this document (actually its predecessor) has potentially 
non-royalty-free IPR disclosures. My question was, if RTCWEB had a 
dependency on the mechanism(s) in this draft, were they okay with the 
IPR. The answer seems to be that RTCWEB does not (at this time) have a 
dependency on this draft. So it's all good :-)

I followed up to question whether it still made sense to mention the 
RTCWEB use cases, but I'm okay either way there.

Ben.

---

From: Bo Burman <[email-masked]>
Date: Tue, 23 Jun 2015 10:51:43 +0000

Please find a few more comments inline.
Cheers,
Bo

> Sent: den 22 juni 2015 22:45
> To: Bo Burman
> >> references some RTCWEB requirements as partial motivation. Have the
> > application-specific message in a DataChannel, but I cannot find that
> > there was ever any consensus on what to do in v1.0, or if it should be
> > specified at all.
> 
> If this draft is not referenced by RTCWEB,  is the mention of RTCWEB use cases still relevant? (Unless I am reading it
> wrong, the quoted use cases really only support the "paused" semantic.)
[BoB] I think it is still relevant, especially since RTCWEB did not yet specify any solution, which perhaps should be stated. I think you are right that the listed mandatory RTCWEB use cases only support the "paused" semantic.

> about the interoperability considerations among the various modes would
[BoB] OK. I'll add that.

> That would be worth a mention in the aforementioned interop
[BoB] OK.

> Have potential implementors indicated they would do that?
[BoB] Not explicitly. This is more of a concern among the authors along the lines of your comment above, pro-actively trying to support finding a balance between interoperability and the need to support all use cases.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 23 Jun 2015 07:24:05 -0700

Agree with Keith here. As far as I know, there are no WebRTC implementations that support pause/resume, nor are any in progress, nor is the document referenced in any IETF RTCWEB or W3C specification. About the only link that I can find is a reference to TMMBR/TMMBN in the RTP usage document.

> On Jun 22, 2015, at 4:42 PM, DRAGE, Keith (Keith) <[email-masked]> wrote:
>