Subject: Re: [avtext] AD Evaluation of draft-ietf-avtext-rtp-stream-pause-07 (last call and editorial part)

From: Bo Burman <[email-masked]>
Date: Wed, 1 Jul 2015 09:26:03 +0000

Hi Ben!

Thank you for your thorough review and for good and constructive comments!
Please find my responses and update proposals below.

I have already implemented my proposed updates in my local copy and can issue a new version right away if they are all OK.

Cheers,
Bo 

> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]]
> Sent: den 16 juni 2015 05:19
> To: [email-masked]; [email-masked]
> Subject: 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.
> 
> *** Things to discuss before IETF Last Call:
[BoB] <snip> (handled in separate thread)

> *** 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?
[BoB] Yes. Suggest "...pause operation is arguably not as time critical as the resume operation...".

> 
> -- 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?
[BoB] That is possible, and it does not hurt anything. Trying to resume a non-existing SSRC is simply ignored by the receiver of the message, which is stated in section 5.4 ("Receiving RESUME requests for a stream that is not paused does not require any action and can be ignored"). The party that tried to resume such stale SSRC probably then also did not see the BYE for it. Such stale SSRC will of course eventually time out.

> 
> -- 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?
[BoB] That's a good point. Any stream receiver can resume at any point in time, assuming they know that the stream exists, which it may not do if there is no PAUSED (and that is an allowed condition). All receivers that saw the original PAUSE were obviously OK with it, but if there were undetected receivers added to the session during pause, and if those did not yet learn about the paused stream because there was no PAUSED or they did not support PAUSED, they will learn about the stream when the pausing party leaves. I'll add some clarifying text on that.

> 
> -- 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?
[BoB] Yes, that wording is unfortunate. Suggest changing it to "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."
> 
> This MUST NOT seems to be non-constraining.
[BoB] To try to re-phrase, TMMBR/TMMBN 0 MUST NOT be used for PAUSE/RESUME signaling purposes in case topology is not point-to-point, even for endpoints that only support TMMBR/TMMBN and not PAUSE/RESUME/REFUSED/PAUSED. Does the sentence fail to convey that?

> 
> -- 8.1, 3rd paragraph: "as indicated by PAUSED"
> 
> ... or REFUSED?
[BoB] Yes, that's another way to learn it. Will add.

> 
> -- 8.1, 4th from end:
> 
> Can you offer guidance on selecting an appropriate time?
[BoB] I expect this to vary from application to application and also to depend on the importance of achieving the bandwidth saving, but I'd say 2-5 regular RTCP intervals could be appropriate. With adding that, I also think "sending" should be changed to "scheduling" to highlight that the desirable RTCP send time randomization is kept.

> 
> -- 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?
[BoB] "Undesirable" is probably sufficient, but "impossible" was thought to go better with "...SHALL enter Pausing State..." and the text is by that trying to convey that there should be really good reasons not to pause.

> 
> Also, shouldn’t this mention the hold off?
[BoB] Hold off is the main property of Pausing State (before going to Paused State), so there is no hold off in entering Pausing State and I thus don't think it is necessary to mention it here.

> 
> -- 8.2, 2nd paragraph
> 
> Is this true for the locally paused state? If so, how is the PauseID value calculated for local pausing.
[BoB] Yes, it is true also for locally paused state. PauseID is then calculated as if the locally pausing RTP sender would have included it in a PAUSE sent to itself. I can add that clarification.

> 
> -- 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?
[BoB] Yes. The text already says it is 32 bits and goes into the Type Specific field. Is anything of that unclear? I can add that it is fixed-length.

> 
> --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.
[BoB] The 8.4 3rd paragraph text starts with scoping the sentence to receiving non-valid PauseID, which is why the valid PauseID case is omitted from the latter part of the sentence that describes the exception when not to send REFUSED.

> 
> --8.4, 6th paragraph:
> 
> Can you offer guidance on selecting an appropriate time?
[BoB] For PAUSE, I suggest referencing 8.1. For RESUME, I suggest adding such text to 8.3 and referencing it here. Given that RESUME is likely more time-critical than PAUSE, it is reasonable to suggest a shorter time, like 1-2 regular RTCP intervals.

> 
> 
> -- 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.
[BoB] OK. Will change.

> 
> *** Editorial Things:
> 
> -- section 1, paragraph 4, last sentence:
> 
> Long, convoluted sentence. Consider breaking into multiple, simpler sentences.
> 
> also, s/anyway/still
[BoB] OK

> 
> -- paragraph 5:
> 
> s/ "As the RTP streams..." / "As the set of RTP streams..."
> s/ "... using Extended RTP Profile..." / "... using the Extended RTP Profile..."
[BoB] OK

> 
> -- 2nd to last paragraph: "... it is proposed to define..."
> 
> I suggest "This document defines..."
[BoB] OK

> 
> -- 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.)
[BoB] OK. Suggest moving it directly under section 3, where it should be more clear that the optimization of transport usage that it mentions applies to all the subsequent use cases. Also added that "mute" is assumed to be applicable also for other media than audio, which I think is very reasonable.

> 
> 
> -- 3.2, First paragraph:
> 
> "That is accomplished
>     through the Mixer originating its’ own streams, identified by SSRC..."
> 
> s/its'/its
[BoB] OK

> 
> Also, I seem you mean "identified by _distinct_ SSRC values"?
[BoB] Yes. Thanks.

> 
> -- 3rd paragraph: "request to pause a particular stream"
> 
> request that a particular stream be paused, or request the sender to pause a particular stream.
[BoB] OK. Will re-phrase both that and the next sentence in a similar way.

> 
> -- 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?
[BoB] I meant "for". Will change.

> 
> -- Figure 3:
> 
> Do B and D ever get mentioned? If not, it would be simpler without them.
[BoB] You are correct that they are not mentioned, but the use case is intended to describe a multi-party scenario, not only a Mixer intercepting a point-to-point call, and also (implicitly) providing a the reader with a mind-set that the need for pausing some streams typically increase when there are multiple streams available in the scenario. I will add some minor text mentioning B, C and D.

> 
> -- 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.
[BoB] I disagree. The point here is that the direction of the pause request is different, Media Receiver to RTP Mixer, compared to the other way around in the other use cases. I instead suggest pointing this out more clearly.

> 
> -- 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.
[BoB] OK, suggest "in a timely fashion" in 4.1. You don't suggest to replace all occurrences "real-time" in the document, do you?

> -- 4.2:
> s/who/that  (both times)
> s/likes/needs (or wants)
[BoB] OK

> 
> -- 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.)
[BoB] OK. Will re-phrase. I believe also the next sentence would benefit from being broken down, so I'll do that too.

> 
> -- 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…"
[BoB] Agree that the sentence is strange, probably due to some editing mishap. I think your interpretation and proposal is good.

> 
> -- 4.8, first paragraph:
> 
> Any reason to cite 4566 but not 3261? (Both have been cited earlier in the draft.)
[BoB] There's no particular reason. Probably due to move-text-around. I'll remove the 4566 citation here.

> 
> -- 5, 2nd paragraph: "It is proposed..."
> 
> Unless that proposal has not been accepted, consider saying "This solution re-uses..."
[BoB] It has been accepted, so I'll  change.

> 
> -- 5.4, 1st paragraph: "can request to resume... "
> 
> request the sender to resume, or request the resumption of...
[BoB] OK.

> 
> -- 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.
[BoB] True. I'll clarify that.

> 
> -- 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?
[BoB] Yes. Will clarify.

> 
>     "temporal dependency to before the pause"
> 
> dependency on samples from before the pause?
[BoB] Yes. Will add "sample"-wording whenever needed for added clarity.

> 
> -- 6.4, 4th paragraph from end:
> 
> s/"responsible to leave"/"responsible for leaving"
[BoB] OK.

> 
> 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?
[BoB] Good catch! There are two figures in the document source, where the first had no caption. Will add.

> 
> -- 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?
[BoB] No, there are no other ways to enter those states. I'll simplify the sentence according to your suggestion.

> 
> -- 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.
[BoB] It means from using TMMBR/TMMBN instead of the new messages defined in section 8. Suggest clarifying with a reference to section 5.5 and deleting "coming from such usage".

> 
> -- 9, 2nd paragraph after figure 7:
> 
> s/independent/independently
> s/likes/needs (or wants)
[BoB] OK

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 02 Jul 2015 18:03:55 -0500

Hi Bo,

One quick comment. I will followup on on the rest of your email as soon 
as I can.

> [BoB] <snip> (handled in separate thread)

My original evaluation had 4 points in this section. I've seen 
discussion of the first, but not the rest. It's entirely possibly I 
missed something in the thread--that happens more than I'd like to admit 
:-)

The first point was about interoperability considerations for the 
various configuration. I gathered you planned to add some text for this?

Here are the others for reference:

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

---

From: Bo Burman <[email-masked]>
Date: Fri, 3 Jul 2015 07:32:33 +0000

Hi Ben,

You are entirely right, there were four points in the pre-LC section of your original mail, and I've been working on a response for the latter three but did not complete it yet. I already have text for the first, the "config" interoperability considerations, in my local copy.

Cheers,
Bo

> Sent: den 3 juli 2015 01:04
> To: Bo Burman
> Cc: [email-masked]; [email-masked]
> Subject: Re: AD Evaluation of draft-ietf-avtext-rtp-stream-pause-07 (last call and editorial part)
> 
> Hi Bo,
> 
> One quick comment. I will followup on on the rest of your email as soon as I can.
> 
> My original evaluation had 4 points in this section. I've seen discussion of the first, but not the rest. It's entirely possibly I
> The first point was about interoperability considerations for the various configuration. I gathered you planned to add
> some text for this?
>

---

From: "Ben Campbell" <[email-masked]>
Date: Fri, 03 Jul 2015 08:14:11 -0500

Ah, understood, thanks!

On 3 Jul 2015, at 2:32, Bo Burman wrote:

> Hi Ben,
>
> You are entirely right, there were four points in the pre-LC section 
> of your original mail, and I've been working on a response for the 
> latter three but did not complete it yet. I already have text for the 
> first, the "config" interoperability considerations, in my local copy.
>
> Cheers,
> Bo
>