Subject: Re: [avtext] Splicing: Confirmation of decisions at IETF#80

From: Roni Even <[email-masked]>
Date: Mon, 04 Apr 2011 09:38:22 +0300

Hi Dave,
I think it may be good to have the two use cases. The draft will be
informational so showing the flow for both cases may be good.
Regards
Roni

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of David R Oran
> Sent: Monday, March 28, 2011 9:58 PM
> To: DRAGE, Keith (Keith)
> Cc: [email-masked]
> Subject: Re: [avtext] Splicing: Confirmation of decisions at IETF#80
> 
> Sorry I wasn't there folks (still can't travel for another month or
> so).
> I have one question about the discussion and conclusion.
> 
> Was there consensus on the (I believe explicit) statement in the
> requirements that the splicing action be completely undetectable by the
> receiver?
> 
> The reason I ask is that from my perspective, the entire technical
> approach (including whether to model as a translator or mixer) is
> driven by this one requirement. In fact, I can see a number of MUCH
> simpler approaches if this requirement is dropped.
> 
> I just want to be clear when we adopt the milestone if we are a priori
> confining the solution space to solutions that satisfy this
> requirement.
> 
> I'm somewhat ambivalent about this, since the only use case I can think
> of where undetectability comes into play is advertisement insertion. We
> should be clear that everybody understands that this is the case.
> 
> Cheers, DaveO.
> 
> 
> On Mar 28, 2011, at 12:01 PM, DRAGE, Keith (Keith) wrote:
> 
> > (As WG chair)
> >
> > There was significant interest in the face-to-face meeting to
> creating a milestone in the WG. The essence of the milestone will be to
> address the use case of splicing using existing tools provided in RTP.
> It will therefore be an informational document.
> >
> > Unless the chairs hear contrary positions on the mailing list, the
> chairs will discussing such a milestone with the AD and adding it to
> our list of milestones in AVTEXT.
> >
> > Please respond by the end of this week (Friday).
> >
> > This does not adopt the current text as a working group item. The
> author will provide another revision of this document based on comments
> made, and other comments that people may wish to contribute now, and we
> will make a call to adopt text at that point. Please take this as an
> invitation to contribution other material either via the mailing list
> or via separate internet-drafts.
> >
> > Regards
> >
> > Keith
> > _______________________________________________
> > avtext mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/avtext
> 
> _______________________________________________
> avtext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avtext

---

From: Colin Perkins <[email-masked]>
Date: Mon, 4 Apr 2011 18:41:31 +0100

Roni,

I disagree, since the solutions for the two use cases are very different. The draft would be better to focus on addressing a single problem, rather than try to cover both. 

Colin

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

---

From: Roni Even <[email-masked]>
Date: Mon, 04 Apr 2011 22:54:24 +0300

Colin,
I think that the case with the requirement to undetectability is a simple
translator, is there something specific in this case. 

My view was that if we take undetectability away and use a translator or a
mixer it becomes an RFC3550 translator/mixer and we just point to RFC 3550.

I am still not sure why we made splicing using translator and not RTP mixer
which seemed to me a better fit.

Roni

> Behalf Of Colin Perkins
> Sent: Monday, April 04, 2011 8:42 PM
> To: Roni Even
> Cc: [email-masked]
> I disagree, since the solutions for the two use cases are very
> different. The draft would be better to focus on addressing a single
> problem, rather than try to cover both.
> 
> Colin
> 
> 
>

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 8 Apr 2011 17:27:54 +0200

Roni,

There is nothing simple about this splicing operation. Especially if you
attempt to do it undetectable. Even a regular translator that can be
detected with the purpose of splicing in content do needs some
significant consideration. I think the simplest is the mixer. But also
there the RFC 3550 isn't not a source of clarity on what you need to do
to maintain RTP correctness on the different sides.

When it comes to the mixer vs translator case, I think one reason was
this non-detectable requirement. Another aspect of it is has to do with
bit-rate adaptation to handle varying network conditions. A Mixer does
kind of cut off the feedback loop between the receiver and the sender.
To bridge that one needs additional RTCP messages.

In the context of a translator one can make this operate at least in the
following way. From primary perspective it can see the full path to the
receiver when the splicer is passing its content. And when the splicer
insert the alternative content it could get a report on the path up to
the splicer itself.

I think we need to discuss what our goals really are here.

Are they only to provide the receiver with a consistent media stream
despite the splicing? Or does one try to take additional steps to hide
the existence of the splicer from the receivers perspective?

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: David R Oran <[email-masked]>
Date: Fri, 8 Apr 2011 11:43:37 -0400

I tend to agree with Magnus' assessment.

There seems also to be an additional (only implicitly stated) requirement that people need to internalize (at least I think there is after a number of discussions with the proponents).

That is the ability of the translator to have minimal (or zero) overhead when content is not being actively spliced. I believe the system model the proponents have in their heads is one in which a system sitting in the middle of the network somewhere can have many RTP sessions flowing "through" , or "around" it, and only incur translator overhead during an actual splice operation, and possibly for a short period surrounding the splice. In other words, I'm presuming there's a scalability requirement of the form: "the overhead must scale with the number of active splices, not with the number of RTP sessions flowing through the intermediary".

I suspect this has substantial impact, perhaps not as great as the non-detectability requirement, but worth pondering for sure.

DaveO.

---

From: Jinwei Xia <[email-masked]>
Date: Sun, 10 Apr 2011 18:15:02 +0800

Magnus,

> to maintain RTP correctness on the different sides.

Undetectability requirement is specific for some ad insertion use cases (possibly not for all), but some other use cases using splicing operation do not cover the requirement such as those cited by Dave. Thus I will change this undetectability requirement to be optional. If undetectability is considered, IMO it is not easy either for  translator or mixer to consider upper layer operation.

If we use mixer, what's the value in CSRC field when the substitutive content comes from local media file?

> To bridge that one needs additional RTCP messages.

Mixer is simpler one for media adaptation, while translator is also smart enough to carry out adaptation since translator can intercept ECN feedbacks and modify them when congestion occurs during splice period. But I do not oppose that using mixer is a off-the-shelf approach.

> insert the alternative content it could get a report on the path up to

Right. It is the benefit by using translator.

> despite the splicing? 

It is not mandatory for all splicing use cases, but ad insertion may be a important splicing case in IPTV commercial deployment.

>Or does one try to take additional steps to hide

IMHO it is unnecessary to hide intermediate nodes from receiver.

I respect the preference of majority and more opinions are very appreciated!

Thank you.

Jinwei

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 11 Apr 2011 13:44:16 +0200

Hi,

Jinwei Xia skrev 2011-04-10 12:15:
>>> Colin, I think that the case with the requirement to
>>> undetectability is a simple translator, is there something
>>> specific in this case.
>>> 
>>> My view was that if we take undetectability away and use a
>>> translator or a mixer it becomes an RFC3550 translator/mixer and
>>> we just point to RFC 3550.
>>> 
>>> I am still not sure why we made splicing using translator and not
>>> RTP mixer which seemed to me a better fit.
>>> 
>> 
>> Roni,
>> 
>> There is nothing simple about this splicing operation. Especially
>> if you attempt to do it undetectable. Even a regular translator
>> that can be detected with the purpose of splicing in content do
>> needs some significant consideration. I think the simplest is the
>> mixer. But also there the RFC 3550 isn't not a source of clarity on
>> what you need to do to maintain RTP correctness on the different
>> sides.
> 
> Undetectability requirement is specific for some ad insertion use
> cases (possibly not for all), but some other use cases using splicing
> operation do not cover the requirement such as those cited by Dave.
> Thus I will change this undetectability requirement to be optional.
> If undetectability is considered, IMO it is not easy either for
> translator or mixer to consider upper layer operation.

Well, it will be detectable, unless one does transcoding in the splicer,
or force the two stream to be encoded by the same encoder. If any time
of media parameter are different between the two stream a downstream
client will be able to detect the switch.

> content comes from local media file?

Well, that could be assigned. I think we should get back the translator
vs mixer when we have arrived what the reasonable requirements really
are. It might in fact be that translator is the correct model and that
the other aspects overweights some other.

> 
>> 
>> When it comes to the mixer vs translator case, I think one reason
>> was this non-detectable requirement. Another aspect of it is has to
>> do with bit-rate adaptation to handle varying network conditions. A
>> Mixer does kind of cut off the feedback loop between the receiver
>> and the sender. To bridge that one needs additional RTCP messages.
> 
> Mixer is simpler one for media adaptation, while translator is also
> smart enough to carry out adaptation since translator can intercept
> ECN feedbacks and modify them when congestion occurs during splice
> period. But I do not oppose that using mixer is a off-the-shelf
> approach.

I wouldn't say off the shelf approach. Certain aspects are clearly more
straight forward. Other still needs considerations.

> 
>> 
>> In the context of a translator one can make this operate at least
>> in the following way. From primary perspective it can see the full
>> path to the receiver when the splicer is passing its content. And
>> when the splicer insert the alternative content it could get a
>> report on the path up to the splicer itself.
> 
>> Are they only to provide the receiver with a consistent media
>> stream despite the splicing?
> 
> It is not mandatory for all splicing use cases, but ad insertion may
> be a important splicing case in IPTV commercial deployment.
> 
>> Or does one try to take additional steps to hide the existence of
>> the splicer from the receivers perspective?
> 

Good, that makes things simpler.

> I respect the preference of majority and more opinions are very

Well, I want the opinion of a informed majority. Which do requires that
we work through the motivations.

Cheers

Magnus Westerlund

---

From: Colin Perkins <[email-masked]>
Date: Mon, 11 Apr 2011 21:12:22 +0100

> That is the ability of the translator to have minimal (or zero) overhead when content is not being actively spliced. I believe the system model the proponents have in their heads is one in which a…

I'm not sure there's any solution for the combination of non-detectable splicing and zero overhead when not actively splicing (at least, not without revising RTP). All the solutions I envisage have a per-stream overhead when not splicing in order to achieve non-detectable behaviour: they either need to continually rewrite RTP sequence numbers and RTCP, or act as a mixer and add a CSRC to the stream, and process RTCP packets. As such, they all scale with the number of RTP streams flowing through the intermediary. 

> I suspect this has substantial impact, perhaps not as great as the non-detectability requirement, but worth pondering for sure.

Agreed. It seems to me that the draft authors need to decide whether non-detectable behaviour or zero overhead when not splicing is their goal, as it doesn't look like both are possible.

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

---

From: Roni Even <[email-masked]>
Date: Wed, 13 Apr 2011 08:34:42 +0300

Colin,
I thought about the mixer based solution without listing the CSRCs.
According to RFC3550
"For some applications, it MAY be acceptable for a mixer not to identify
sources in the CSRC list.  However, this introduces the danger that loops
involving those sources could not be detected."

RTCP packets with RR from the receivers will need to be processed by the
mixers if the receivers cannot detect the inserted stream. Will probably
require the splicer to know which sequence numbers were the inserted stream

Roni

> Sent: Monday, April 11, 2011 11:12 PM
> To: David R Oran
> Cc: [email-masked]
> > There seems also to be an additional (only implicitly stated)
> requirement that people need to internalize (at least I think there is
> after a number of discussions with the proponents).
> >
> > That is the ability of the translator to have minimal (or zero)
> overhead when content is not being actively spliced. I believe the
> system model the proponents have in their heads is one in which a
> system sitting in the middle of the network somewhere can have many RTP
> sessions flowing "through" , or "around" it, and only incur translator
> overhead during an actual splice operation, and possibly for a short
> period surrounding the splice. In other words, I'm presuming there's a
> scalability requirement of the form: "the overhead must scale with the
> number of active splices, not with the number of RTP sessions flowing
> through the intermediary".
> 
> I'm not sure there's any solution for the combination of non-detectable
> splicing and zero overhead when not actively splicing (at least, not
> without revising RTP). All the solutions I envisage have a per-stream
> overhead when not splicing in order to achieve non-detectable
> behaviour: they either need to continually rewrite RTP sequence numbers
> and RTCP, or act as a mixer and add a CSRC to the stream, and process
> RTCP packets. As such, they all scale with the number of RTP streams
> flowing through the intermediary.
> 
> > I suspect this has substantial impact, perhaps not as great as the
> non-detectability requirement, but worth pondering for sure.
> 
> 
> Agreed. It seems to me that the draft authors need to decide whether
> non-detectable behaviour or zero overhead when not splicing is their
> goal, as it doesn't look like both are possible.
> 
> --
> Colin Perkins
> http://csperkins.org/
> 
> 
>

---

From: Jinwei Xia <[email-masked]>
Date: Wed, 13 Apr 2011 16:12:57 +0800

Magnus,

<snap>

> client will be able to detect the switch.

Right, in above analysis, translator and mixer both can realize splicing by changing different RTP parameters.

> Good, that makes things simpler.

Can we conclude that:     

Translator: 
    pros:  allow primary source know the situation of full path.
    cons: more considertaion for media adaptation; changing RTP SN and/or TS, and that RTCP.

Mixer:
    pros: straight forward approach for media adaptation.
    cons: primary source only know the situation between itself and mixer; changing RTP SN, TS, SSRC and CSRC, and that RTCP.

Is there any missing pros & cons of translator and mixer on splicing? 

Thank you.

Jinwei

---

From: Jinwei Xia <[email-masked]>
Date: Wed, 13 Apr 2011 21:09:03 +0800

----- Original Message ----- 
From: "Colin Perkins" <[email-masked]>
To: "David R Oran" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, April 12, 2011 4:12 AM
Subject: Re: [avtext] Splicing: Confirmation of decisions at IETF#80

> I'm not sure there's any solution for the combination of non-detectable splicing and zero overhead when not actively splicing (at least, not without revising RTP). All the solutions I envisage have…

Agree, even if we do not support non-detectability, translator or mixer still needs to rewrite related RTP parameters for main stream while not actively splicing. More RTP session, more overhead on translator or mixer.

> Agreed. It seems to me that the draft authors need to decide whether non-detectable behaviour or zero overhead when not splicing is their goal, as it doesn't look like both are possible.

Detectable seems to incur less impact and overhead compared to non-detectable. From such point of view, I prefer less overhead. 

Jinwei

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 13 Apr 2011 15:17:59 +0200

[As WG cochair]

In terms of the current direction forward, I'm not convinced any one particular solution has to be selected by the working group.

My understanding was that we wanted a document that described: "How do I use the existing RTP to perform splicing?" Such a document could have several solutions, followed by text that stated: "If you do it this way, then these are the implications." 

Naturally, when the solution document becomes a working group draft, the working group will have the say whether any particular solution, along with its corresponding implications, form an acceptable solution. That process could nail down the field to one, but I'm not currently convinced we have to start with one.

I'd welcome some views on this.

Essentially this would be saying about the current draft - this is one solution. The use of this mechanism has these implications. If you use it take into account these implications. And the way is free for the proposal of something else that does it differently, with different implications.

By the way the milestone has been created on the charter page - we elected to try and complete this work in December. Please focus the discussion on what we as a working group should be producing.

Regards

Keith

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Jinwei Xia
> Sent: 13 April 2011 09:13
> To: Magnus Westerlund
> Cc: [email-masked]
>     cons: primary source only know the situation between itself and mixer;
> changing RTP SN, TS, SSRC and CSRC, and that RTCP.
>

---

From: David R Oran <[email-masked]>
Date: Wed, 13 Apr 2011 09:55:50 -0400

> My understanding was that we wanted a document that described: "How do I use the existing RTP to perform splicing?" Such a document could have several solutions, followed by text that stated: "If y…
Yes, this makes sense to me, unless the work goes in the direction of adding protocol elements (e.g. header extensions), or modifying RTP algorithms/rules in ways that extend the protocol.

> Essentially this would be saying about the current draft - this is one solution. The use of this mechanism has these implications. If you use it take into account these implications. And the way is…
I'm not entirely comfortable with this, as part of our job is to pick one, or at least a small number of good designs in order to have maximum interoperability and generality. It is not to explore all parts of the design space and document them all.

Cheers, Dave.

---

From: Jinwei Xia <[email-masked]>
Date: Wed, 13 Apr 2011 22:49:23 +0800

Chair,

----- Original Message ----- 
From: "DRAGE, Keith (Keith)" <[email-masked]>
To: "Jinwei Xia" <[email-masked]>; "Magnus Westerlund" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, April 13, 2011 9:17 PM
Subject: RE: [avtext] Splicing: Confirmation of decisions at IETF#80

> My understanding was that we wanted a document that described: "How do I use the existing RTP to perform splicing?" Such a document could have several solutions, followed by text that stated: "If you > do it this way, then these are the implications." 
> 
> Naturally, when the solution document becomes a working group draft, the working group will have the say whether any particular solution, along with its corresponding implications, form an acceptable 
> solution. That process could nail down the field to one, but I'm not currently convinced we have to start with one.
> 
> Essentially this would be saying about the current draft - this is one solution. The use of this mechanism has these implications. If you use it take into account these implications. And the way is free for the  > proposal of something else that does it differently, with different implications.
> 

Thank you, your suggestion gives a reasonable direction. If we agree on this, I will add different solutions with their corresponding implications in further work. 

BR
Jinwei

---

From: Jinwei Xia <[email-masked]>
Date: Wed, 13 Apr 2011 23:08:38 +0800

----- Original Message ----- 
From: "David R Oran" <[email-masked]>
To: "DRAGE, Keith (Keith)" <[email-masked]>
Cc: "Jinwei Xia" <[email-masked]>; "Magnus Westerlund" <[email-masked]>; <[email-masked]>
Sent: Wednesday, April 13, 2011 9:55 PM
Subject: Re: [avtext] Splicing: Confirmation of decisions at IETF#80

> Yes, this makes sense to me, unless the work goes in the direction of adding protocol elements (e.g. header extensions), or modifying RTP algorithms/rules in ways that extend the protocol.

The current draft is informational intention without any protocol extension.

> I'm not entirely comfortable with this, as part of our job is to pick one, or at least a small number of good designs in order to have maximum interoperability and generality. It is not to explore…

Agree, we only consider the reasonable requirements, which are deeply discussed here, and their corresponding solution. Any margin case is out of scope unless it has convincing reason.

Thank you 

Jinwei

---

From: Colin Perkins <[email-masked]>
Date: Mon, 25 Apr 2011 13:02:19 +0100

> Agree, even if we do not support non-detectability, translator or mixer still needs to rewrite related RTP parameters for main stream while not actively splicing. More RTP session, more overhead on…

I don't think that's necessarily true. If you require non-detectability, I believe the splicer will need to rewrite RTP headers while not actively splicing. If you allow the splicer to be detectable, I think you can avoid that overhead. This, to me, seems one of the main design choices.

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

---

From: Xiajinwei <[email-masked]>
Date: Thu, 28 Apr 2011 14:42:27 +0800

Colin,

> From: Colin Perkins [mailto:[email-masked]] 
> Sent: Monday, April 25, 2011 8:02 PM
> To: Jinwei Xia
> Cc: David R Oran; [email-masked]
> >>> There seems also to be an additional (only implicitly 
> stated) requirement that people need to internalize (at least 
> I think there is after a number of discussions with the proponents).
> >>> 
> >>> That is the ability of the translator to have minimal (or 
> zero) overhead when content is not being actively spliced. I 
> believe the system model the proponents have in their heads 
> is one in which a system sitting in the middle of the network 
> somewhere can have many RTP sessions flowing "through" , or 
> "around" it, and only incur translator overhead during an 
> actual splice operation, and possibly for a short period 
> surrounding the splice. In other words, I'm presuming there's 
> a scalability requirement of the form: "the overhead must 
> scale with the number of active splices, not with the number 
> of RTP sessions flowing through the intermediary".
> >> 
> >> I'm not sure there's any solution for the combination of 
> non-detectable splicing and zero overhead when not actively 
> splicing (at least, not without revising RTP). All the 
> solutions I envisage have a per-stream overhead when not 
> splicing in order to achieve non-detectable behaviour: they 
> either need to continually rewrite RTP sequence numbers and 
> RTCP, or act as a mixer and add a CSRC to the stream, and 
> process RTCP packets. As such, they all scale with the number 
> of RTP streams flowing through the intermediary. 
> > 
> > Agree, even if we do not support non-detectability, 
> translator or mixer still needs to rewrite related RTP 
> parameters for main stream while not actively splicing. More 
> RTP session, more overhead on translator or mixer.
> 
> I don't think that's necessarily true. If you require 
> non-detectability, I believe the splicer will need to rewrite 
> RTP headers while not actively splicing. If you allow the 
> splicer to be detectable, I think you can avoid that 
> overhead. This, to me, seems one of the main design choices.
> 
> 

If we use mixer in detectability case, IMO the mixer still need to at least
rewrite SSRC, SN and CSRC, while not actively splicing unless otherwise is
used.

Jinwei

---

From: Colin Perkins <[email-masked]>
Date: Thu, 28 Apr 2011 08:55:16 +0100

On 28 Apr 2011, at 07:42, Xiajinwei wrote:
> If we use mixer in detectability case, IMO the mixer still need to at least rewrite SSRC, SN and CSRC, while not actively splicing unless otherwise isused.

This is one of the reasons why I don't think a mixer is appropriate.

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