Subject: [avtext] Mirja Kühlewind's Discuss on draft-ietf-avtext-splicing-notification-07: (with DISCUSS and COMMENT)

From: "Mirja Kuehlewind" <[email-masked]>
Date: Mon, 13 Jun 2016 05:55:29 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-avtext-splicing-notification-07: Discuss

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-splicing-notification/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I have a few points which I would like to have answers for before moving
the doc forward (which may not even results in text changes). I happy to
clear my position when answered before the telechat:

- The following action does not seem to be appropriate for a
specification of an end-to-end protocol:
"And if the splicer wishes to prevent the downstream receivers from
detecting splicing, it MUST
   NOT forward the message."
I guess if a middlebox decides to drop the message, there is not much we
can do. But I definitely would prefer to not see this specified in an
RFC.

- Why is just having the RTCP message not sufficient? Why are the RTP
extensions needed as well?

- And is the RTCP message send only once or multiple time? This is not
specified.

- There is some discussion about the implementation of the slicer in
section 5 (where btw. the title "Failure Cases" seems inappropriate),
while there is one sentence saying: "If the splicer is implemented
following [RFC6828], it will have its
   own SSRC and will send its own RTCP reports, and will forward
   translated RTCP reports from the receivers."
Why are alternatives discussed here, if there is already a recommendation
given in RFC6828? And how would proper congestion handling be ensure in
the other setups not described in RFC6828?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- As a general comment, I found it quite hard to read this doc without
reading RFC6828 which is only listed as a informative reference as it is
informational only. I think it is wrong. Further, RFC6828 describes some
action that a slicers has to perform. However, all language in RFC6828 is
non normative. This is slightly confusing to me as well. I would further
recommend to briefly give an overview of the assumed scenario is this
document.

- Minor comment: The definition of the new SDP grouping semantic should
be mentioned in the abstract and RFC4566 should be referenced. And I
don't think the SDP grouping registry requires a contact.

- Quick question: Maybe I'm missing something here but why do you need a
splicer in a scenario where "the
   substitutive sender is implemented together with the main RTP sender
inside a single device" (as written in section 2)?

---

From: "Roni Even" <[email-masked]>
Date: Tue, 14 Jun 2016 13:09:05 +0300

Hi
Inline
Roni

> -----Original Message-----
> From: Mirja Kuehlewind [mailto:[email-masked]]
> Sent: Monday, June 13, 2016 3:55 PM
> To: The IESG
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Mirja Kühlewind's Discuss on draft-ietf-avtext-splicing-notification-
> 07: (with DISCUSS and COMMENT)
> 
> 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.)
> 
> 
> I have a few points which I would like to have answers for before moving the
> doc forward (which may not even results in text changes). I happy to clear
> my position when answered before the telechat:
> 
> - The following action does not seem to be appropriate for a specification of
> an end-to-end protocol:
> I guess if a middlebox decides to drop the message, there is not much we can
> do. But I definitely would prefer to not see this specified in an RFC.
[Roni Even] This is a requirement, the spliced information may be a commercial and the splicer may want to prevent the end user from identifying easily  that he is now receiving a commercial 
> extensions needed as well?
[Roni Even] RTP and RTCP are unreliable protocols, so if you want higher probability for getting the information you send both (this is done is other similar usages)
> - And is the RTCP message send only once or multiple time? This is not
[Roni Even] This is implementation, once.
> 
> - There is some discussion about the implementation of the slicer in section 5
> (where btw. the title "Failure Cases" seems inappropriate), while there is one
> sentence saying: "If the splicer is implemented following [RFC6828], it will
> have its
> given in RFC6828?
[Roni Even] Since these are message definition, RFC6828 is one option but people may use other models
 And how would proper congestion handling be ensure in
> the other setups not described in RFC6828?
[Roni Even] This is regular RTP so congestion is as in RTP
> action that a slicers has to perform. However, all language in RFC6828 is non
> normative. This is slightly confusing to me as well. I would further
[Roni Even] RFC6828 is an implementation example
> be mentioned in the abstract and RFC4566 should be referenced. And I don't
> think the SDP grouping registry requires a contact.
[Roni Even] Grouping is in RFC5888 and not in RFC4566 (RFC5888 references RFC4566)
You are right - contact is not needed according to RFC5888

---

From: Colin Perkins <[email-masked]>
Date: Tue, 14 Jun 2016 12:19:38 +0100

> On 13 Jun 2016, at 13:55, Mirja Kuehlewind <[email-masked]> wrote:
> 

This isn’t an end-to-end protocol. It’s a protocol for a sender to communicate with an RTP middlebox that’s performing splicing. RTP middleboxes are expected to modify RTCP, and discarding or modifying RTCP packets that don’t make sense for some participants is normal behaviour for such middleboxes.

> extensions needed as well?

RTP and RTCP are unreliable. The usual practice for these types of extension is to send data both in RTCP, and in some number of RTP packets, to increase the chances of it arriving in a timely manner. The draft is following standard practice here.

> - And is the RTCP message send only once or multiple time? This is not

That’s implementation dependent, and based on the expected packet loss rate, the importance of the data, and the frequency with which updates need to be sent. 

> Why are alternatives discussed here, if there is already a recommendation

I assume because this is not normatively requiring RFC 6828.

> And how would proper congestion handling be ensure in the other setups not described in RFC6828?

If the splicer is implemented as an RTP mixer, as in RFC 6828, then there will be three congestion control loops: original sender to splicer, substitutive sender to splicer, and splicer to receiver. 

If the splicer is implemented as an RTP translator, then it will be invisible to the congestion control, and the control loops run between original sender and receiver, or between substitutive sender and receiver, depending which of the streams is passed by the splicer. 

If the splicer is implemented for unicast streaming, the congestion control loops could run the RMCAT algorithms. Perhaps more likely, though, is that the splicer acts on a multicast (SSM) RTP flow, and you have provisioned capacity. 

> _______________________________________________
> avtext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avtext

-- 
Colin Perkins
https://csperkins.org/

---

From: Mirja Kühlewind <[email-masked]>
Date: Tue, 14 Jun 2016 16:58:06 +0200

Hi,

thanks for the quick reply. See below.

> This isn’t an end-to-end protocol. It’s a protocol for a sender to communicate with an RTP middlebox that’s performing splicing. RTP middleboxes are expected to modify RTCP, and discarding or modif…

Okay, thanks for the clarification that this is excepted behavior. I still 
find the wording a little awkward. Shouldn't this be:

"The splicer MAY decide to not forward the message, e.g., if it wishes to 
prevent the downstream receivers from detecting splicing"?

Or maybe SHOULD if that is actually the recommend behavior (but then the if 
part makes basically no sense)...

> RTP and RTCP are unreliable. The usual practice for these types of extension is to send data both in RTCP, and in some number of RTP packets, to increase the chances of it arriving in a timely mann…

Thanks for clarification. That could be clarified in the text. Because the 
text says that RTCP is used because the RTP information might get lost. So I 
was wondering why you are not only using RTCP and make sure you send it 
sufficiently often. Saying that this is common practice would be helpful from 
my point of view. Is there a reference for this?

> That’s implementation dependent, and based on the expected packet loss rate, the importance of the data, and the frequency with which updates need to be sent.

A recommendation or discussion should be provided here.

> I assume because this is not normatively requiring RFC 6828.

As I said below, I find it hard to read this document without having read 
RFC6828; therefore I'd say it should be normative or more background 
information should be added to this doc about the assumed scenario(s).

> If the splicer is implemented as an RTP mixer, as in RFC 6828, then there will be three congestion control loops: original sender to splicer, substitutive sender to splicer, and splicer to receiver.
Yes, this one is find and discussed in RFC6828.
> If the splicer is implemented as an RTP translator, then it will be invisible to the congestion control, and the control loops run between original sender and receiver, or between substitutive send…
In this scenario, the RTCP feedback message MUST be passed to the right 
sender to make the congestion control work. This part is not clearly 
specified in the draft, as far as I can say.

And will the splicer then forward the packets unaltered to the receiver, or 
could it be possible that the splicer adds additional data?

---

From: Colin Perkins <[email-masked]>
Date: Tue, 14 Jun 2016 21:46:57 +0100

Hi Mirja,

Some comments in line, but mostly I think this now needs a response from the authors. 

Colin

> On 14 Jun 2016, at 15:58, Mirja Kühlewind <[email-masked]> wrote:
> 
> Hi,
> 
> Okay, thanks for the clarification that this is excepted behavior. I still find the wording a little awkward. Shouldn't this be:
> 
> "The splicer MAY decide to not forward the message, e.g., if it wishes to prevent the downstream receivers from detecting splicing"?
> 
> Or maybe SHOULD if that is actually the recommend behavior (but then the if part makes basically no sense)…

I’m not sure it needs to use normative language for either of the points in that paragraph, but I don’t see that it hurts. Essentially, if the splicing notification message is forwarded, it wastes a trivial amount of bandwidth, and tells the downstream receivers exactly when the splicing occurred. The latter is visible from looking at the video content anyway, but I suppose that not giving the hint might make things slightly harder for devices that are trying to block adverts inserted via splicing. 

> Thanks for clarification. That could be clarified in the text. Because the text says that RTCP is used because the RTP information might get lost. So I was wondering why you are not only using RTCP and make sure you send it sufficiently often. Saying that this is common practice would be helpful from my point of view. Is there a reference for this?

It should be easy to clarify, but I’m not sure there’s a reference. It’s a practice that’s evolved over time, but I’m not sure it’s well documented. 

> As I said below, I find it hard to read this document without having read RFC6828; therefore I’d say it should be normative or more background information should be added to this doc about the assumed scenario(s).

I’ll let the authors respond to this. 

> In this scenario, the RTCP feedback message MUST be passed to the right sender to make the congestion control work. This part is not clearly specified in the draft, as far as I can say.

I agree that the RTCP needs to be passed to the right place, and that draft should be clarified if that’s not clear.

> And will the splicer then forward the packets unaltered to the receiver, or could it be possible that the splicer adds additional data?

It’s certainly possible that the splicer could rewrite the RTP headers, or even transcode the media. That’s true of any RTP middlebox, and if done, the middlebox needs to be careful to rewrite RTCP to match, to ensure that it’s done transparently. The RTP spec has some words about this, and drafts like draft-ietf-straw-b2bua-rtcp-12 give additional recommendations (although that’s not an appropriate reference to add to this document, since it’s unlikely that splicing will be done with SIP).

-- 
Colin Perkins
https://csperkins.org/

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Wed, 15 Jun 2016 07:22:28 +0000

Hi Mirja,

As one of the authors, please see my replies inline.

BR,
Rachel 

-----邮件原件-----
发件人: Mirja Kühlewind [mailto:[email-masked]]
发送时间: 2016年6月14日 22:58
收件人: Colin Perkins
抄送: The IESG; [email-masked]; [email-masked]; [email-masked]; [email-masked]
主题: Re: [avtext] Mirja Kühlewind's Discuss on draft-ietf-avtext-splicing-notification-07: (with DISCUSS and COMMENT)

Hi,

On 14.06.2016 13:19, Colin Perkins wrote:
>> 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
>> I have a few points which I would like to have answers for before 
>> moving the doc forward (which may not even results in text changes).
>> I happy to clear my position when answered before the telechat:
>>
>> I guess if a middlebox decides to drop the message, there is not much 
>> we can do. But I definitely would prefer to not see this specified in 
>> an RFC.
>

Or maybe SHOULD if that is actually the recommend behavior (but then the if part makes basically no sense)...

[Rachel]: Okay. I think it can be modified like this in this case. 

[Rachel]: It's more like conventional method to increase robustness. As far as I know, there's no formal document to record this. Maybe we can address this like this

OLD
"

   To increase robustness against such case, the document also defines a
   complementary RTCP packet type to carry the same Splicing Interval to
   the splicer.

"

NEW
"
   To increase robustness against such case, the document also defines a
   new RTCP packet type to carry the same Splicing Interval to
   the splicer. Since RTCP is also unreliable and may not so immediate as the in-band way, it's only considered as a complement to RTP header extension.
"

>> - And is the RTCP message send only once or multiple time? This is 
>> not specified.
>

[Rachel]: I think in Section 2, we have already provided some guidance on how often the Splicing Interval to be sent, which is not just limited to RTP header extension, also includes RTCP message.

>> Why are alternatives discussed here, if there is already a 
>> recommendation given in RFC6828?
>

As I said below, I find it hard to read this document without having read RFC6828; therefore I'd say it should be normative or more background information should be added to this doc about the assumed scenario(s).

[Rachel]: So you're suggesting that we propose some texts to briefly introduce the RFC6828? If that's the case, we'll provide some text later.

[Rachel]: Okay. I think this can be clarified in the draft, adding a sentence like this:

"When the splicer works as an RTP translator, the congestion control runs between original sender and receiver, or between substitutive sender and receiver, so the RTCP feedback message MUST be passed to the right sender to let the congestion control work."

[Rachel]: When it's not splicing time, it will forward the packets untouched. No additional data. When it's in the splicing interval, the splicer will use the substitutive content instead of the original content and modify the RTP header.

>> - As a general comment, I found it quite hard to read this doc 
>> without reading RFC6828 which is only listed as a informative 
>> reference as it is informational only. I think it is wrong. Further, 
>> RFC6828 describes some action that a slicers has to perform. However, 
>> all language in RFC6828 is non normative. This is slightly confusing 
>> to me as well. I would further recommend to briefly give an overview 
>> of the assumed scenario is this document.
>>
>> - Minor comment: The definition of the new SDP grouping semantic 
>> should be mentioned in the abstract and RFC4566 should be referenced. 
>> And I don't think the SDP grouping registry requires a contact.

[Rachel]: Yes. I'll remove the contact.
>>
>> - Quick question: Maybe I'm missing something here but why do you 
>> need a splicer in a scenario where "the
>>    substitutive sender is implemented together with the main RTP 
>> sender inside a single device" (as written in section 2)?

[Rachel]: In implementations, servers may not quite be close to end users. For advertisement splicing case, sometimes it's the splicer's decision to choose which kind of users to forward the spliced content, which means different users may get different spliced content.

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 15 Jun 2016 09:54:02 +0200

Hi,
(As individual)

I think we stumbled on one thing that maybe should be included in the 
update of RFC5285.

Namely the discussion and reasoning why a sender may need to repeat a 
RTP header extension. See below excerpt from the discussion:

Den 2016-06-15 kl. 09:22, skrev Huangyihong (Rachel):
> BR, Rachel
> -----邮件原件----- 发件人: Mirja Kühlewind [mailto:[email-masked]] 发送时

>
>>> - Why is just having the RTCP message not sufficient? Why are the
>>> RTP extensions needed as well?
>>
>> RTP and RTCP are unreliable. The usual practice for these types of
>> extension is to send data both in RTCP, and in some number of RTP
>> packets, to increase the chances of it arriving in a timely manner.
>> The draft is following standard practice here.
>
> Thanks for clarification. That could be clarified in the text.
> Because the text says that RTCP is used because the RTP information
> might get lost. So I was wondering why you are not only using RTCP
> and make sure you send it sufficiently often. Saying that this is
> common practice would be helpful from my point of view. Is there a
> reference for this?
>
> [Rachel]: It's more like conventional method to increase robustness.
> As far as I know, there's no formal document to record this. Maybe we
> can address this like this
>
> OLD "
>
> To increase robustness against such case, the document also defines
> a complementary RTCP packet type to carry the same Splicing Interval
> to the splicer.
>
> "
>
> NEW " To increase robustness against such case, the document also
> defines a new RTCP packet type to carry the same Splicing Interval
> to the splicer. Since RTCP is also unreliable and may not so
> immediate as the in-band way, it's only considered as a complement to
> RTP header extension. "
>
>
>>> - And is the RTCP message send only once or multiple time? This
>>> is not specified.
>>
>> That’s implementation dependent, and based on the expected packet
>> loss rate, the importance of the data, and the frequency with which
>> updates need to be sent.
>
> [Rachel]: I think in Section 2, we have already provided some
> guidance on how often the Splicing Interval to be sent, which is not
> just limited to RTP header extension, also includes RTCP message.
>

This topic is also discussed in  	
draft-ietf-avtext-sdes-hdr-ext-07 Section 4.2.3.

 From my perspective I think the general transmission issues that needs 
to be considered with RTP header extension should be included in the 
update of RFC5285. That way each extension don't have to repeat it, only 
discuss additions or specific considerations for their formats.

To note I think that from SDES header Extension there should be included 
the topics of;

- MTU handling
- How many transmissions and if one can know it has reached the receiver
- Update handling, especially for extensions with data that can be sent 
using both RTCP and RTP header extension.

Note, this is my suggestion as an individual. Please discuss and comment.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Colin Perkins <[email-masked]>
Date: Wed, 15 Jun 2016 14:07:38 +0100

Hi Magnus,

I agree that this makes sense, and is probably better than having more general discussion in the splicing notification draft.

Colin

> On 15 Jun 2016, at 08:54, Magnus Westerlund <[email-masked]> wrote:
> 
> Hi,
> (As individual)
> 
> I think we stumbled on one thing that maybe should be included in the update of RFC5285.
> 
> Namely the discussion and reasoning why a sender may need to repeat a RTP header extension. See below excerpt from the discussion:
> 
> From my perspective I think the general transmission issues that needs to be considered with RTP header extension should be included in the update of RFC5285. That way each extension don't have to repeat it, only discuss additions or specific considerations for their formats.
> 
> To note I think that from SDES header Extension there should be included the topics of;
> 
> - MTU handling
> - Update handling, especially for extensions with data that can be sent using both RTCP and RTP header extension.
> 

-- 
Colin Perkins
https://csperkins.org/

---

From: David Singer <[email-masked]>
Date: Wed, 15 Jun 2016 09:48:52 -0700

Looks to me like we need to loot and pillage from at least the SDES draft, and update (and split into sub-sections, as it’s already long and a mix of topics) section 4.1 of 5285.  Yes, a section on repetition considerations and reliability seems reasonable to me.

> On Jun 15, 2016, at 6:07 , Colin Perkins <[email-masked]> wrote:
> 
> Hi Magnus,
> 
> https://csperkins.org/ <https://csperkins.org/>
David Singer
Manager, Software Standards, Apple Inc.

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Wed, 15 Jun 2016 19:24:06 +0000

I totally agree with this approach. We don’t need each specific RTP header extension draft to repeatedly discuss a common issue.

BR,
Rachel

-----邮件原件-----
发件人: Colin Perkins [mailto:[email-masked]] 
发送时间: 2016年6月15日 21:08
收件人: Magnus Westerlund
抄送: Huangyihong (Rachel); Mirja Kühlewind; [email-masked]; [email-masked]; [email-masked]; [email-masked]; IETF AVTCore WG; [email-masked]
主题: Re: Additions to RFC5285bis? was Re: [avtext] Mirja Kühlewind's Discuss on draft-ietf-avtext-splicing-notification-07: (with DISCUSS and COMMENT)

Hi Magnus,

Colin

>> defines a new RTCP packet type to carry the same Splicing Interval to 
>> the splicer. Since RTCP is also unreliable and may not so immediate 
>> as the in-band way, it's only considered as a complement to RTP 
>> header extension. "
>> 
>> 

--
Colin Perkins
https://csperkins.org/

---

From: Mirja Kühlewind <[email-masked]>
Date: Thu, 16 Jun 2016 15:10:53 +0200

Does this mean we wait with the final publication of the splicing draft until 
RFC5285bis is done (as this probably will be a normative reference then)?

Mirja

---

From: Mirja Kühlewind <[email-masked]>
Date: Thu, 16 Jun 2016 15:18:32 +0200

Hi Rachel,

please provide the suggested changes. I'll move to an no objection in my 
ballot position now, given that Alia still hold a discuss on the most 
important point. I agree here that more text to clarify the situation and 
assumed scenario(s) would be needed! I also would like to still review the 
next version (before final publication)!

Mirja