Subject: [avtext] Review of draft-ietf-avtext-splicing-notification-00

From: Stephen Botzko <[email-masked]>
Date: Mon, 10 Nov 2014 11:07:11 +0900

In general there are a few spots where the English needs to be improved.
One example is

But in RTP splicing
   scenario described in [RFC6828], the mixer has to decode the RTP
   packets, search and solve the Splicing Interval inside the payloads.

In addition to the missing "the" ("But in the RTP...", the meaning of
"solve the Splicing Inverval" is not obvious.

   The need for such processing enhances the workload of the mixer and
   limits the size of RTP sessions the mixer can support.

Presumably the processing i*ncreases* the workload, and limits the*
number* of RTP sessions.

   Most terminology defined in "Content Splicing for RTP Sessions"
   [RFC6828] applies to this document except the following one.

   Splicing Interval:

      A set of certain metadata that allows the mixer to know when to
      start and end the RTP splicing. The information consists of a
      couple of NTP-format timestamps on the splicing in point and on
      the splicing out point.

I think the intent is to say that the terminology in RFC 6828 applies,
and in addition...

The phrase "a couple of NTP-format timestamps" should not be used in a
formal definition.

I think the definition of slicing interval could be simplified
somewhat - defining it as the NTP timestamps for the Splicing-In Point
and Splicing-Out Point per RFC 6828.

 To enable
   the mixer to get the substitutive content before the splicing starts,
   the main RTP sender MUST send the Splicing Interval far enough in
   advance. Alternatively, the main RTP sender can estimate when to send
   the Splicing Interval based on the round-trip time (RTT) following
   the mechanisms in section 6.4.1 of [RFC3550] when the mixer sends
   RTCP RR to the main sender.

The normative MUST in the first sentence is problematic, since the
main RTP sender has no way of knowing how much lead time the mixer
needs.  So it is indefinite.

The "alternatively" sentence seems wrong to me - a mixer might well
need longer than the RTT to accomplish the splicing.  Although the
MUST is worded as applying, it also puts a constraint on the receiving
mixer.  In any event, you can't have an alternative to a MUST.

One approach is to establish a definitive bound (e.g., "send the
Splicing Interval at least N seconds before the Splice-In Time").
This is admittedly a bit arbitrary.  Or perhaps a second message can
be created to allow the mixer to tell the sender how much time it
needs.

The indefinite timing issue shows up in throughout this document.
Simply pointing out in multiple places that the splice interval
packets might be missed, and that they need to be received in time for
the mixer and the substitutive sender to process them seems weak.  It
would be better to ensure that the sender knows how much lead time it
needs to allow, and has some minimum guidance (SHOULDs) on how many
times the splice intervals should be sent via RTP and RTCP.

   The substitutive sender also needs to learn the Splicing Interval
   from the main RTP sender in advance, and thus estimates when to
   transfer the substitutive content to the mixer. The Splicing Interval
   could be transmitted from the main RTP sender to the substitutive
   content using some out-of-band mechanisms, the details how to achieve
   that are beyond the scope of this memo.

Why is this out-of-scope?  The substitutive sender also has an RTP
session established with the mixer.  Why can't the splicing interval
be sent to the substitutive sender by the mixer by using an RTP / RTCP
payload extension defined in this document.

It seems wrong not to provide the complete protocol.

   When the substitutive RTP sender gets the Splicing Interval, it must
   prepare the substitutive stream. The RTP timestamp of the first
   substitutive RTP packet that would be presented on the receivers MUST
   correspond to the same time instant as the former NTP timestamp in
   the Splicing Interval...

   When the splicing will end, the RTP timestamp of the first main RTP
   packet that would be presented on the receivers MUST correspond to
   the same time instant as the latter NTP timestamp in the Splicing
   Interval.

There should be some recognition here that these RTP packets could be lost.

Also, since the MUST statements are in the passive voice, it is not
clear which device is responsible for the implementing the two MUSTs.
Is it intended to be the substitutive sender or the mixer?  Please use
the active voice.

I am wondering if there are missing MUSTs or SHOULDs in this section:

-Are there any MUSTS that need to be imposed on the main sender and
the substitutive sender that related to decodability? (e.g., that the
start and end of the splice must be on frame boundaries?).

-Are there any SHOULDS that relate to RTP payloads that use
interleaved or overlapped payloads?

-Are there any MUSTS or SHOULDS related to scalable codecs?

   After the mixer intercepts the RTP header extension and derives the
   Splicing Interval, it will generate its own stream and could not
   include the RTP header extension in outgoing packets to reduce header
   overhead.

The meaning of "could not" is unclear.  "SHOULD NOT"?  However, since
there is a goal to make splicing undetectable to downstream receiver,
perhaps this should be a MUST NOT.

BR

Stephen Botzko

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Wed, 19 Nov 2014 09:46:53 +0000

Hi Stephen,

Thanks for your comments and sorry for the latency. Please see my answers inline.

BR,
Rachel

From: avtext [mailto:[email-masked]] On Behalf Of Stephen Botzko
Sent: Monday, November 10, 2014 10:07 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [avtext] Review of draft-ietf-avtext-splicing-notification-00

In general there are a few spots where the English needs to be improved.  One example is

But in RTP splicing

In addition to the missing "the" ("But in the RTP...", the meaning of "solve the Splicing Inverval" is not obvious.

[Rachel]: How about changing to “But in the RTP splicing scenario described in [RFC6828],  the mixer has to decode the RTP packets and search for the Splicing Interval inside the payloads.”?

Presumably the processing increases the workload, and limits the number of RTP sessions.

[Rachel]: Okay.

   Splicing Interval:

      the splicing out point.

I think the intent is to say that the terminology in RFC 6828 applies, and in addition...

[Rachel]: How about changing to “The terminology defined in ‘Content Splicing for RTP Sessions’ [RFC6828] applies to this document and in addition, we defines:”

The phrase "a couple of NTP-format timestamps" should not be used in a formal definition.

[Rachel]: How about using “a pair of ” instead?

I think the definition of slicing interval could be simplified somewhat - defining it as the NTP timestamps for the Splicing-In Point and Splicing-Out Point per RFC 6828.

[Rachel]: It works for me.

 To enable

[Rachel]: Will change “far enough in advance” to “far ahead”.

The normative MUST in the first sentence is problematic, since the main RTP sender has no way of knowing how much lead time the mixer needs.  So it is indefinite.

The "alternatively" sentence seems wrong to me - a mixer might well need longer than the RTT to accomplish the splicing.  Although the MUST is worded as applying, it also puts a constraint on the receiving mixer.  In any event, you can't have an alternative to a MUST.

[Rachel]: How about using “For example” instead?

One approach is to establish a definitive bound (e.g., "send the Splicing Interval at least N seconds before the Splice-In Time").  This is admittedly a bit arbitrary.  Or perhaps a second message can be created to allow the mixer to tell the sender how much time it needs.

[Rachel]: We couldn’t give a definitive second bound because it depends on the RTT between the main sender and the mixer, e.g., 1.5RTT. It varies in different implementations. And I think it may not be good to let mixer send an additional message with how much time it needs to the main sender. Because we want to keep mixer with as small as possible changes. Additional message sent from mixer to sender complicates the protocol. Besides, this information could also be obtained by the main sender with some out of scope methods.

The indefinite timing issue shows up in throughout this document. Simply pointing out in multiple places that the splice interval packets might be missed, and that they need to be received in time for the mixer and the substitutive sender to process them seems weak.  It would be better to ensure that the sender knows how much lead time it needs to allow, and has some minimum guidance (SHOULDs) on how many times the splice intervals should be sent via RTP and RTCP.

Why is this out-of-scope?  The substitutive sender also has an RTP session established with the mixer.  Why can't the splicing interval be sent to the substitutive sender by the mixer by using an RTP / RTCP payload extension defined in this document.

[Rachel]: Just as Colin said in his comments, there’s other things that should be coordinated between the main sender and the substitutive sender, like time synchronization, content negotiation, etc.  Most of these things are finished through out of band mechanisms. So the Splicing Interval notification could be also included in that way. Of course, the mixer can forward this message to the substitutive sender, but we don’t think it’s necessary. Because it will complicate the whole protocol while we want the mixer to be as simple as possible.

   the Splicing Interval...

   Interval.

[Rachel]: True. But mixer will not deal with the lost packets. When receivers find some packets lost, they will send NACK to the mixer. Then the mixer will decide whether the lost packets are from the main sender or the substitutive sender, and retrieve them for the receivers. Please see RFC 6828 section 4.4.

Also, since the MUST statements are in the passive voice, it is not clear which device is responsible for the implementing the two MUSTs.  Is it intended to be the substitutive sender or the mixer?  Please use the active voice.

[Rachel]: It’s the mixer. Will change it to the active sentence.

-Are there any MUSTS that need to be imposed on the main sender and the substitutive sender that related to decodability? (e.g., that the start and end of the splice must be on frame boundaries?).

-Are there any SHOULDS that relate to RTP payloads that use interleaved or overlapped payloads?

[Rachel]: It has been described in RFC6828, as “The original media content and substitutive media content will use the same time period but may contain different numbers of RTP packets due to different media codecs and entropy coding”. That means splicing does not happen arbitrarily. So the frame boundary problems could be solved when contents are prepared by service providers.  And the splicing only happens on the RTP level. So no payloads or codecs constraints.

   overhead.

The meaning of "could not" is unclear.  "SHOULD NOT"?  However, since there is a goal to make splicing undetectable to downstream receiver, perhaps this should be a MUST NOT.

[Rachel]: Will change to “MUST NOT”.

BR

Stephen Botzko