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

[Mirja Kühlewind <[e-mail]>]

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


On 15.06.2016 09:22, Huangyihong (Rachel) wrote:
> Hi Mirja,
>
> As one of the authors, please see my replies inline.
>
> BR,
> Rachel
>
> -----邮件原件-----
> 发件人: Mirja Kühlewind [mailto:[e-mail]]
> 发送时间: 2016年6月14日 22:58
> 收件人: Colin Perkins
> 抄送: The IESG; [e-mail]; [e-mail]; [e-mail]; [e-mail]
> 主题: Re: [avtext] Mirja Kühlewind's Discuss on draft-ietf-avtext-splicing-notification-07: (with DISCUSS and COMMENT)
>
> Hi,
>
> thanks for the quick reply. See below.
>
> On 14.06.2016 13:19, Colin Perkins wrote:
>>> On 13 Jun 2016, at 13:55, Mirja Kuehlewind <[e-mail]> wrote:
>>>
>>> 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-notificat
>>> ion/
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> -
>>> 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.
>>
>> 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.
>
> 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)...
>
> [Rachel]: Okay. I think it can be modified like this in this case.
>
>
>>> - 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.
>
> A recommendation or discussion should be provided here.
>
> [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.
>
>>
>>> - 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?
>>
>> 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).
>
> [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.
>
>
>>
>>> 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.
> 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 sender and receiver, depending which of the streams is passed by the splicer.
> 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.
>
> [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."
>
> And will the splicer then forward the packets unaltered to the receiver, or could it be possible that the splicer adds additional data?
>
> [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.
>
>>
>> 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.
>>
>>> ---------------------------------------------------------------------
>>> -
>>> 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.
>
> [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.
>
>>>
>>>
>>> _______________________________________________
>>> avtext mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/avtext
>>
>>
>>