Subject: [AVT] FW: I-D Action:draft-ietf-avt-post-repair-rtcp-xr-06.txt

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 15 Oct 2009 10:38:04 -0700

Fixes for the comments received from IESG.

-acbegen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, October 15, 2009 1:30 PM
To: [email-masked]
Cc: [email-masked]
Subject: [AVT] I-D Action:draft-ietf-avt-post-repair-rtcp-xr-06.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Audio/Video Transport Working Group of the IETF.

	Title           : Post-Repair Loss RLE Report Block Type for RTCP XR
	Author(s)       : A. Begen, et al.
	Filename        : draft-ietf-avt-post-repair-rtcp-xr-06.txt
	Pages           : 10
	Date            : 2009-10-15

This document defines a new report block type within the framework of
RTP Control Protocol (RTCP) Extended Reports (XR).  One of the
initial XR report block types is the Loss Run Length Encoding (RLE)
Report Block.  This report conveys the information regarding the
individual Real-time Transport Protocol (RTP) packet receipt and loss
events experienced during the RTCP interval preceding the
transmission of the report.  The new report, which is referred to as
the Post-repair Loss RLE Report, carries the information regarding
the remaining lost packets after all loss-repair methods are applied.
By comparing the RTP packet receipts/losses before and after the loss
repair is completed, one can determine the effectiveness of the loss-
repair methods in an aggregated fashion.  This document also defines
the signaling of the Post-repair Loss RLE Report in the Session
Description Protocol (SDP).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-post-repair-rtcp-xr-06.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Frank Xia <[email-masked]>
Date: Wed, 21 Oct 2009 09:58:31 -0500

Hi folks

We submitted the draft
http://tools.ietf.org/id/draft-xia-avt-mpeg2ts-preamble-00.txt
which is also prototyped by our company. 

This draft is another solution of the same problem comparing to 
http://tools.ietf.org/id/draft-begen-avt-rtp-mpeg2ts-preamble-02.txt.

Comments are very welcome.

BR
Frank

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 21 Oct 2009 11:25:14 -0700

Frank,

I read the draft. It is good to know more people agree that this is a real problem. However, I have several comments and questions. I'd like to understand why you think this is a better solution than our existing draft.

- First of all, is this an RTP payload format draft or not? The draft seems to be defining that, yet, title does not say so, and the draft does not have the sections needed for defining a new payload format. See the guidelines document.

- Not surprisingly, there are similarities with our draft on the subject. The motivation for your draft seems to be using the raw TS packets as Preamble, rather than generating a "summary" packet consisting of TLV elements. Do you need post processing on the packets you sent before feeding them to the demux? I suspect you do since you will be sending raw TS packets in an order that will likely upset the demux (i.e., CC discontinuity will likely to occur).

Moreover, TLV encoding is way more efficient from a bandwidth perspective. Most of the space in TS packets goes to padding because of the fixed 188-byte TS packet size anyway. So, to me TLV encoding is the way to go here.

- Using a TLV also identifies each preamble element explicitly. This  makes it easier for the RR to selectively use portions of the preamble for different tasks, e.g., priming system clock with PCR value. How do you deal with that?

- In our experience, we have seen with several settops that some manipulation of the preamble is either required or strongly beneficial. Consider repeating PATs/PMTs until the demux is initialized with them, or delaying sending the ECM into the decoder for some time. W/o post processing and TLV encoding, this is hard to do.

- Section 4 says:   

"Some other preamble information included in different TSes is also identified and stored in the retransmission server."

This sounds pretty vague. Please explain.

No details on the contents of the RTP PSI packets. Is only 1 PAT and 1 PMT per program included? What order are they found in? Any repetition?  How is Conditional Access data included? What about constructs required by the video codec (MPEG-2 sequence header, H.264 SPS/PPS/SEI)?

- Why do you use 4588 format for the Preamble packets? They are not retransmissions of earlier unmodified RTP packets, are they? Section 4.2 says PSI RTP packets are newly generated. Thus they cannot be retransmissions of previous packets. How do you set the OSN fields? 

Also check 4588 about the use of timestamps. The way you set the timestamp is not the way 4588 mandates.

This is a short draft, but brings forward a lot of questions/issues with it.

-acbegen

> From: Frank Xia [mailto:[email-masked]]
> Sent: Wednesday, October 21, 2009 10:59 AM
> To: [email-masked]
> Cc: Ali C. Begen (abegen)
> Subject: new draft on MPEG-TS preamble acquisition
> 
> Hi folks
> 
> We submitted the draft

---

From: Frank Xia <[email-masked]>
Date: Thu, 22 Oct 2009 14:03:26 -0500

Hello Ali

Thank for your insightful comments.

Besides my inline response,  I would also like to
point out the methodology difference between
your document and our draft.

Your way is:
   1) RR identifies, extracts preamble information
   2) RR generates  summary packets
   3) RS  transforms the summary packets into
      demux/decoder friendly stream in order to
      feed demux/decoder.

Our proposal skips step 2 and simlifies step 3.  That is,
let RR directly generates demux/decoder stream.

BR
Frank

----- Original Message ----- 
From: "Ali C. Begen (abegen)" <[email-masked]>
To: "Frank Xia" <[email-masked]>; <[email-masked]>
Sent: Wednesday, October 21, 2009 1:25 PM
Subject: RE: new draft on MPEG-TS preamble acquisition

Frank,

I read the draft. It is good to know more people agree that this is a real 
problem. However, I have several comments and questions. I'd like to 
understand why you think this is a better solution than our existing draft.
Frank=>Accuratly saying, I think we have some advantages
 from some perspectives.

- First of all, is this an RTP payload format draft or not? The draft seems 
to be defining that, yet, title does not say so, and the draft does not have 
the sections needed for defining a new payload format. See the guidelines 
document.
Frank=>This draft did not define a new payload format.
This is negotiatable if RFC4588 can't be used directly.
Some further  related response see below.

- Not surprisingly, there are similarities with our draft on the subject. 
The motivation for your draft seems to be using the raw TS packets as 
Preamble, rather than generating a "summary" packet consisting of TLV 
elements. Do you need post processing on the packets you sent before feeding 
them to the demux? I suspect you do since you will be sending raw TS packets 
in an order that will likely upset the demux (i.e., CC discontinuity will 
likely to occur).
Frank=>We don't need post processing.   I am not sure what issue you are
specifically referring to.  However, CC continuity can be obtained .
>From my perspective, we just move your post processing from RS to RR.

Moreover, TLV encoding is way more efficient from a bandwidth perspective. 
Most of the space in TS packets goes to padding because of the fixed 
188-byte TS packet size anyway. So, to me TLV encoding is the way to go 
here.
Frank=>Honestly, I don't bandwidth is issue.  Preamble is small size in 
volume
comparing to vedieo traffic.  Compressing preamble does not make perceivable
difference.

- Using a TLV also identifies each preamble element explicitly. This  makes 
it easier for the RR to selectively use portions of the preamble for 
different tasks, e.g., priming system clock with PCR value. How do you deal 
with that?
Frank=>You mean how to deal with PCR or some thing else?
As for PCR issue for unicast RTP burst,
we do have a solution 
http://tools.ietf.org/id/draft-yang-avt-rtp-synced-playback-00.txt.

- In our experience, we have seen with several settops that some 
manipulation of the preamble is either required or strongly beneficial. 
Consider repeating PATs/PMTs until the demux is initialized with them, or 
delaying sending the ECM into the decoder for some time. W/o post processing 
and TLV encoding, this is hard to do.
Frank=>The more specific is more understandable.  Our solution works in our 
experiment.
Could you give us more information?

- Section 4 says:

"Some other preamble information included in different TSes is also 
identified and stored in the retransmission server."

Frank=>I meant NIT, CAT.

No details on the contents of the RTP PSI packets. Is only 1 PAT and 1 PMT 
per program included? What order are they found in? Any repetition?  How is 
Conditional Access data included? What about constructs required by the 
video codec (MPEG-2 sequence header, H.264 SPS/PPS/SEI)?
Frank=>I will elaborate them.  However, this is not the point of the draft.
Our point is draft-ietf-avt-rapid-acquisition-for-rtp-03 can be directly
used for  preamble acquistion with limited extension.

Any way,  identifying and analyzing preamble  is common processing
for your and our solution.

- Why do you use 4588 format for the Preamble packets? They are not 
retransmissions of earlier unmodified RTP packets, are they? Section 4.2 
says PSI RTP packets are newly generated. Thus they cannot be 
retransmissions of previous packets. How do you set the OSN fields?
Frank=>We do treat Preamble packets as unicast burst.  In fact,
draft-ietf-avt-rapid-acquisition-for-rtp-03 is using RETRANSMISSION server 
for
rapid acquisition.

Also check 4588 about the use of timestamps. The way you set the timestamp 
is not the way 4588 mandates.
Frank=>Let me think about it.

This is a short draft, but brings forward a lot of questions/issues with it.
Frank=>Thank your comments. Our solution is  simple too :-)

-acbegen

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 22 Oct 2009 12:27:09 -0700

Hi Frank, inline.

> Sent: Thursday, October 22, 2009 3:03 PM
> To: Ali C. Begen (abegen); [email-masked]
> Subject: Re: new draft on MPEG-TS preamble acquisition
> 
> Hello Ali
> 

Not RR but RS.

>    2) RR generates  summary packets

Again it is RS that generates the packets.

>       demux/decoder friendly stream in order to

This should be RR.

> let RR directly generates demux/decoder stream.

Yes, you skip the 2nd step but at a large cost IMO.
 
> Some further  related response see below.

You are carrying something in RTP, so one way or another, you are defining a new payload format. As I mentioned earlier, usage of 4588 does not seem to be correct here.
 
> specifically referring to.  However, CC continuity can be obtained .

How? The raw TS packets you need will not necessarily be consecutive. If you will have to keep redundant TS packets to keep the continuity, it will be far less efficient. You can set the discontinuity flag but there are limits on it.

> comparing to vedieo traffic.  Compressing preamble does not make perceivable

Preamble is small, correct. But the size of all TS packets making up the Preamble is not.
 
> http://tools.ietf.org/id/draft-yang-avt-rtp-synced-playback-00.txt.

The above draft does not address my question. And PCR was just an example. Different TLVs are often needed for different things to speed up the acquisition.

> Could you give us more information?

For example, you might feed the TS packets with the PAT/PMT/etc to the demux but once they are gone, they are gone. In certain cases, having that info readily available and using more than once may greatly help. In our post-processing, we can do it. But, if you don't have post-processing, I suspect you cannot do it or is at least more difficult.
 
> used for  preamble acquistion with limited extension.

I am not sure what you mean here. Of course, RAMS takes care most of the stuff. Here we are addressing the specific reqs for the MPEG2TS content. If we will only provide marginal benefit, I don't see much point in doing this (we would just use RAMS). If we are here to do something, I think we should decide on the best approach.
 
> draft-ietf-avt-rapid-acquisition-for-rtp-03 is using RETRANSMISSION server

The preamble packets are sent in the same retransmission session with the burst packets. But, that does not mean that they are 4588-formatted packets. Actually they cannot be since they are not the retransmissions of other RTP packets. In a typical RTP packet, there are 7 TS packets. I cannot get a few of those TS packets and send them as retransmission packets since the resulting RTP packet is a different packet now.

Either you are misusing 4588 or sending every whole RTP packet that carries a TS packet needed for your preamble (which might be OK from 4588 viewpoint but as I said will be pretty inefficient). Or, I am totally missing how you are doing it.

-acbegen

---

From: Frank Xia <[email-masked]>
Date: Thu, 22 Oct 2009 21:17:06 -0500

Hello Ali

Thank for you quick response, please check again.

BR
Frank
----- Original Message ----- 
From: "Ali C. Begen (abegen)" <[email-masked]>
To: "Frank Xia" <[email-masked]>; <[email-masked]>
Sent: Thursday, October 22, 2009 2:27 PM
Subject: RE: new draft on MPEG-TS preamble acquisition

Hi Frank, inline.

>    1) RR identifies, extracts preamble information

Not RR but RS.
Frank=>My typo

Frank=>My typo

>       demux/decoder friendly stream in order to

This should be RR.
Frank=>My typo too.

Yes, you skip the 2nd step but at a large cost IMO.
Frank=>Probably, I am just so focusing on our advantages
that I dont see the large cost yet.

> Some further  related response see below.

You are carrying something in RTP, so one way or another, you are defining a
new payload format. As I mentioned earlier, usage of 4588 does not seem to
be correct here.
Frank=>Good point. However, I  still believe it is make sense  to reuse
4588.
draft-ietf-avt-rapid-acquisition-for-rtp uses 4588 for unicast RTP burst
which are not RETRANSMISSION packets as to the RR.
Preamble can also be regarded as a part of unicast RTP burst session.

> specifically referring to.  However, CC continuity can be obtained .

How? The raw TS packets you need will not necessarily be consecutive. If you
will have to keep redundant TS packets to keep the continuity, it will be
far less efficient. You can set the discontinuity flag but there are limits
on it.
Frank=>According to my understanding, it is only necessary to keep CC
continuity
for a given PID.   RS can easily chain the TSes with CC continuity.
Setting the flag is also another alternative.

> comparing to vedieo traffic.  Compressing preamble does not make

Preamble is small, correct. But the size of all TS packets making up the
Preamble is not.
Frank=>Just make a simple calculation. let's say preamble consists of 20
TSes which
has 20*188*8 bits.  Assume unicast RTP burst last 3 seconds with 2M bandwith
which is 3*2M bits in total. Preamble occupies around 0.5% of total unicast.
Am  I right?

> http://tools.ietf.org/id/draft-yang-avt-rtp-synced-playback-00.txt.

The above draft does not address my question. And PCR was just an example.
Different TLVs are often needed for different things to speed up the
acquisition.
Frank=>Could you make it more specific?

> Could you give us more information?

For example, you might feed the TS packets with the PAT/PMT/etc to the demux
but once they are gone, they are gone. In certain cases, having that info
readily available and using more than once may greatly help. In our
post-processing, we can do it. But, if you don't have post-processing, I
suspect you cannot do it or is at least more difficult.
Frank=>Our solution does not exclude any possible optimization in RR.
You can say your solution has such by-products.  However, these by-products
are not the goal of the topic itself.

> used for  preamble acquistion with limited extension.

I am not sure what you mean here. Of course, RAMS takes care most of the
stuff. Here we are addressing the specific reqs for the MPEG2TS content. If
we will only provide marginal benefit, I don't see much point in doing this
(we would just use RAMS). If we are here to do something, I think we should
decide on the best approach.
Frank=>We are talking about format of unicast RTP  burst which is 4588
compliant. I just want to justify our usage of 4588

> draft-ietf-avt-rapid-acquisition-for-rtp-03 is using RETRANSMISSION server

The preamble packets are sent in the same retransmission session with the
burst packets. But, that does not mean that they are 4588-formatted packets.
Actually they cannot be since they are not the retransmissions of other RTP
packets. In a typical RTP packet, there are 7 TS packets. I cannot get a few
of those TS packets and send them as retransmission packets since the
resulting RTP packet is a different packet now.
Frank=>On the contrary, I believe we can get a few of those TS packets
and send them to the new joining RR.  This is a part of  rapid acquistion
processing.    The new joining RR can't tell any difference.

Either you are misusing 4588 or sending every whole RTP packet that carries
a TS packet needed for your preamble (which might be OK from 4588 viewpoint
but as I said will be pretty inefficient). Or, I am totally missing how you
are doing it.
Frank=>Your understanding is accurate.  We implemented both and selectively
proposed the former because we believe the two are similar.  As for 
efficiency,
I gave you a brief calculation, and you can check.

-acbegen

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 22 Oct 2009 20:18:51 -0700

Snipping off the redundant text.

> which are not RETRANSMISSION packets as to the RR.

I believe you are confused here. Burst packets are "retransmission" packets - totally in accordance with RFC 4588. They are retransmissions of earlier RTP packets sent in the primary multicast stream. And the receiver considers them as retransmission packets.

> Preamble can also be regarded as a part of unicast RTP burst session.

They are part of the retransmission session, but as I said they are not formatted according to 4588 because they are not retransmission of anything.

> for a given PID.   RS can easily chain the TSes with CC continuity.

I am not sure how you do this w/o getting RS to process the stream.

> Setting the flag is also another alternative.

In some cases, yes, in other cases, no.
 
> which is 3*2M bits in total. Preamble occupies around 0.5% of total unicast.

If the burst is taking 3 seconds even with the preamble, something seems to be wrong here.

> Frank=>Could you make it more specific?

As I mentioned earlier, some portions of the Preamble data may be used more than once. TLV gives us that flexibility.
 
> are not the goal of the topic itself.

?? These "by-products" are possible because of the post processing we do at the receiver. And it is certainly within the scope of this problem.

[snip]
> I gave you a brief calculation, and you can check.

If you are doing the former (i.e., sending only the necessary TS packets in 4588 format after ripping off the redundant ones), it is misusing the RFC 4588 because you are modifying the source packets. I don't know why you do it or need it.

If you were doing the latter, the calculation given above would be incorrect anyway (you need to take the whole RTP packet sizes into account).

The bottom line is one way or another the Retransmission Server needs to continuously parse and extract the required "Preamble" data in the incoming primary multicast stream(s). Once it does that, putting the Preamble in the format we defined by using the TLV elements is not a big deal (not more difficult than keeping the raw TS packets and trying to put them in the right order). But, doing that provides a lot of benefits.

-acbegen

---

From: Frank Xia <[email-masked]>
Date: Fri, 23 Oct 2009 10:37:13 -0500

Hi Ali

Thanks for your patience.
Please also check the inline response.

BR
Frank

----- Original Message ----- 
From: "Ali C. Begen (abegen)" <[email-masked]>
To: "Frank Xia" <[email-masked]>; <[email-masked]>
Sent: Thursday, October 22, 2009 10:18 PM
Subject: RE: new draft on MPEG-TS preamble acquisition

> which are not RETRANSMISSION packets as to the RR.

I believe you are confused here. Burst packets are "retransmission" 
packets - totally in accordance with RFC 4588. They are retransmissions of 
earlier RTP packets sent in the primary multicast stream. And the receiver 
considers them as retransmission packets.
Frank=>They are not retransmission packets.
In rapid acquistion (e.g fast channel change),
these packets are never sent to the RR before.
For this specific RR, there packets are not RETRANSMITTED.
Here is a brief procedure of fast channel change to faciliate discussion.
1)A RR requests a new channel
2)A RS  sends bufferred packets related to the channel to the RR
3)The RR receives the packets

By the way,  RS is designed for a RR to request a specific
SN of RTP packet because the packet is presumably lost.

> Preamble can also be regarded as a part of unicast RTP burst session.

They are part of the retransmission session, but as I said they are not 
formatted according to 4588 because they are not retransmission of anything.

I am not sure how you do this w/o getting RS to process the stream.
Frank=>All I want to say is RS can do this work on behalf of  RR.
RS has enough information and processing capability.

> which is 3*2M bits in total. Preamble occupies around 0.5% of total 

If the burst is taking 3 seconds even with the preamble, something seems to 
be wrong here.
Frank=>Could you give me a right simple calculation?

> Frank=>Could you make it more specific?

As I mentioned earlier, some portions of the Preamble data may be used more 
than once. TLV gives us that flexibility.
Frank=>Flexibility and Complexity.

> are not the goal of the topic itself.

?? These "by-products" are possible because of the post processing we do at 
the receiver. And it is certainly within the scope of this problem.
Frank=>IMO, the scope is how the RR gets preamble.
"How to organize received preamble in RR for further processing"
is not within the scope.

If you believe it is in the scope, please define them  for further 
discussion.
For me, the benefit of these by-products seems to be vague.

[snip]
> I gave you a brief calculation, and you can check.

If you are doing the former (i.e., sending only the necessary TS packets in 
4588 format after ripping off the redundant ones), it is misusing the RFC 
4588 because you are modifying the source packets. I don't know why you do 
it or need it.

If you were doing the latter, the calculation given above would be incorrect 
anyway (you need to take the whole RTP packet sizes into account).

The bottom line is one way or another the Retransmission Server needs to 
continuously parse and extract the required "Preamble" data in the incoming 
primary multicast stream(s). Once it does that, putting the Preamble in the 
format we defined by using the TLV elements is not a big deal (not more 
difficult than keeping the raw TS packets and trying to put them in the 
right order). But, doing that provides a lot of benefits.
Frank=>I never question the advantages of your solution.  Our
motivation is just to  keep RR simple.  In fact, there are no big difference
between yours and ours.  All what we do is offloading some processing from
RR to RS.

-acbegen

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 23 Oct 2009 09:00:03 -0700

>From RR's viewpoint, this does not matter (whether the packets were sent but they were lost or they were never sent - receiver cannot know the difference). The important thing here, the burst packets are the exact replicas of the original RTP packets encapsulated in 4588 format. But, the way you describe sending the raw TS packets does modify the source packets, which means 4588 should not be used.
 
> SN of RTP packet because the packet is presumably lost.

In NACKs yes. In RAMS-R, no.
 
> RS has enough information and processing capability.

I thought the reason you used raw packets instead of summary packets was to simplify the server. At the end, post processing is not a big deal.

> Frank=>Could you give me a right simple calculation?

I'd rather consider much shorter burst durations. But, this is rather a minor point.
 
> "How to organize received preamble in RR for further processing"

I beg to differ. I already gave a few examples. We can discuss this further in the meeting.
 
> between yours and ours.  All what we do is offloading some processing from

Post-processing is not a heavy-weight operation. But, of course, that depends on the implementation.

-acbegen

---

From: Frank Xia <[email-masked]>
Date: Fri, 23 Oct 2009 11:46:30 -0500

Hi Ali

Please check my reply...

BR
Frank

----- Original Message ----- 
From: "Ali C. Begen (abegen)" <[email-masked]>
To: "Frank Xia" <[email-masked]>; <[email-masked]>
Sent: Friday, October 23, 2009 11:00 AM
Subject: RE: new draft on MPEG-TS preamble acquisition

> > > to be defining that, yet, title does not say so, and the draft does 
> > > not
> > > have
> > You are carrying something in RTP, so one way or another, you are 
> > defining
> > a

>From RR's viewpoint, this does not matter (whether the packets were sent but 
they were lost or they were never sent - receiver cannot know the 
difference). The important thing here, the burst packets are the exact 
replicas of the original RTP packets encapsulated in 4588 format. But, the 
way you describe sending the raw TS packets does modify the source packets, 
which means 4588 should not be used.Hi
Frank=>Copies of the original RTP packets are  not retransmission packets.
I just want to say  that "rapid acquistion" document also stretches a little 
bit
of  4588.
Using raw TS packets or whole RTF packet is not the point of our debate.
We prototyped both.  If you feel more comfortable with the latter, we can
do some minor change with the document.

In NACKs yes. In RAMS-R, no.
Frank=> RAMS-R is defined in rapid acquistion document.
Just becuase of your newly defining RAMS-R, you change
the orginal meaning of RS.

> RS has enough information and processing capability.

I thought the reason you used raw packets instead of summary packets was to 
simplify the server. At the end, post processing is not a big deal.
Frank=>No, to simplify receivers, that is , RR.
The perfect goal is to let RR be agnostic to the extra effort.
However, nothing is perfect :-)

> Frank=>Could you give me a right simple calculation?

I'd rather consider much shorter burst durations. But, this is rather a 
minor point.

> > > Frank=>The more specific is more understandable.  Our solution works 
> > > in
> > > our
> > > experiment.

I beg to differ. I already gave a few examples. We can discuss this further 
in the meeting.
Frank=>Yes, I read your examples.  However,  I am inclined to
making the draft more focused on our goal, not a panacea.

> between yours and ours.  All what we do is offloading some processing from

Post-processing is not a heavy-weight operation. But, of course, that 
depends on the implementation.
Frank=>Probably, we can make the simple simpler.

-acbegen

---

From: David R Oran <[email-masked]>
Date: Fri, 23 Oct 2009 11:44:27 -0700

Couple of quick comments - sorry to be jumping into the middle.

On Oct 23, 2009, at 8:37 AM, Frank Xia wrote:

> ----- Original Message ----- From: "Ali C. Begen (abegen)" <[email-masked] 
> >
>> defining a
> packets - totally in accordance with RFC 4588. They are  
> retransmissions of earlier RTP packets sent in the primary multicast  
> stream. And the receiver considers them as retransmission packets.
Sure they were. It's just that the RR wasn't listening!

> For this specific RR, there packets are not RETRANSMITTED.
The notion of "for this specific RR" is not well-defined when you are  
mixing unicast and multicast as we are in RAMS. For example, check the  
DVB specifications, which use multicast retransmission as well as  
unicast.

> 3)The RR receives the packets
You're glossing over the key/hardest part, which is how manage the  
switchover from unicast to multicast. If all we cared about was  
unicast, we would not be bothering with any of this. You'd just use VoD.

> SN of RTP packet because the packet is presumably lost.
right, which is why RAMS is slightly different in the control plane  
from retransmission. The beauty of the overall approach we're taking  
is that the data plane, once the decoder is primed, can be identical  
from RAMS and regular transmission.

> As I mentioned earlier, some portions of the Preamble data may be  
> used more than once. TLV gives us that flexibility.
The minute you have to "reach into" the MPEGTS data stream and parse/ 
extract stuff, the rest is easy by comparison. As Ali has said, the  
advantage of TLV is that you don't have to mess with extracting taking  
a subset of a TS, re-constructing a legal mux (including CC and the  
rest) and sending as if it were RFC2550-compliant. I'd like to  
understand why you think TLVs are more complex than all that stuff.

> If you are doing the former (i.e., sending only the necessary TS  
> packets in 4588 format after ripping off the redundant ones), it is  
> misusing the RFC 4588 because you are modifying the source packets.  
> I don't know why you do it or need it.
>
> If you were doing the latter, the calculation given above would be  
> incorrect anyway (you need to take the whole RTP packet sizes into  
> account).
>
> The bottom line is one way or another the Retransmission Server  
> needs to continuously parse and extract the required "Preamble" data  
> in the incoming primary multicast stream(s). Once it does that,  
> putting the Preamble in the format we defined by using the TLV  
> elements is not a big deal (not more difficult than keeping the raw  
> TS packets and trying to put them in the right order). But, doing  
> that provides a lot of benefits.
Without arguing about whether moving the processing from the RR to the  
RS is a good tradeoff, I would like to caution you to make sure what  
you are doing will work with the current (and legacy) crop of STB data- 
plane/decoder implementations - without getting into details we have  
evidence from real boxes that there are problems.

Cheers, DaveO.

> -acbegen
>
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 23 Oct 2009 14:14:29 -0700

> Frank=>Copies of the original RTP packets are  not retransmission packets.

Ret packet payload = OSN field + original packet payload.

That is what I meant by "4588 format." That is what RAMS does.

> do some minor change with the document.

It is not a matter of being comfortable or not. 4588 can be used only if original packet payload is not modified (which is OK but pretty inefficient way of priming the decoders). 

Please show us how you select the TS packets and put them in RTP packets in your AVT presentation. That way, it will be easier to discuss.

-acbegen

---

From: Frank Xia <[email-masked]>
Date: Fri, 23 Oct 2009 16:34:34 -0500

Hello David

Welcome to the discussion.

I believe we covered many parts of your concerns
through previous discussion. However,
it is my pleasure for me to highlight my points.

BR
Frank

----- Original Message ----- 
From: "David R Oran" <[email-masked]>
To: "Frank Xia" <[email-masked]>
Cc: "Ali C. Begen (abegen)" <[email-masked]>; <[email-masked]>
Sent: Friday, October 23, 2009 1:44 PM
Subject: Re: [AVT] new draft on MPEG-TS preamble acquisition

>> packets - totally in accordance with RFC 4588. They are  retransmissions 
>> of earlier RTP packets sent in the primary multicast  stream. And the 
>> receiver considers them as retransmission packets.
Frank=>Just because the RR is in different session.
If there was no transmission to a RR, how does
come to the retransmission to the RR?

> DVB specifications, which use multicast retransmission as well as 
Frank=> see my above comments.

> switchover from unicast to multicast. If all we cared about was  unicast, 
> we would not be bothering with any of this. You'd just use VoD.
Frank=>I could not follow your idea.  However,  our topic seems
only be related to unicast retransmission session.  Lets stick to the theme.

> right, which is why RAMS is slightly different in the control plane  from 
> retransmission. The beauty of the overall approach we're taking  is that 
> the data plane, once the decoder is primed, can be identical  from RAMS 
> and regular transmission.
Frank=>This exactly my point which is RAMS stretch 4588 a little bit.
Probably, we can stretch more if it is within reasonable scope.

>> As I mentioned earlier, some portions of the Preamble data may be  used 
>> more than once. TLV gives us that flexibility.
> advantage of TLV is that you don't have to mess with extracting taking  a 
> subset of a TS, re-constructing a legal mux (including CC and the  rest) 
> and sending as if it were RFC2550-compliant. I'd like to  understand why 
> you think TLVs are more complex than all that stuff.
Frank=>Just I metioned, we skip summarization and post-possessing parts.
RR can do less work.

>> If you are doing the former (i.e., sending only the necessary TS  packets 
>> in 4588 format after ripping off the redundant ones), it is  misusing the 
>> RFC 4588 because you are modifying the source packets.  I don't know why 
>> you do it or need it.
>>
>> continuously parse and extract the required "Preamble" data  in the 
>> incoming primary multicast stream(s). Once it does that,  putting the 
>> Preamble in the format we defined by using the TLV  elements is not a big 
>> deal (not more difficult than keeping the raw  TS packets and trying to 
>> put them in the right order). But, doing  that provides a lot of 
>> benefits.
> Without arguing about whether moving the processing from the RR to the  RS 
> is a good tradeoff, I would like to caution you to make sure what  you are 
> doing will work with the current (and legacy) crop of STB data- 
Frank=>Our proposal is to let RS to do more on behalf of RR.
That means less requirements for STB.

---

From: Frank Xia <[email-masked]>
Date: Fri, 23 Oct 2009 16:43:00 -0500

Hi Ali

Please check again.

BR
Frank
----- Original Message ----- 
From: "Ali C. Begen (abegen)" <[email-masked]>
To: "Frank Xia" <[email-masked]>; <[email-masked]>
Sent: Friday, October 23, 2009 4:14 PM
Subject: RE: new draft on MPEG-TS preamble acquisition

> > > > - First of all, is this an RTP payload format draft or not? The 
> > > > draft
> > > > seems
> > > new payload format. As I mentioned earlier, usage of 4588 does not 
> > > seem
> > > to
> > > be correct here.
> > of

That is what I meant by "4588 format." That is what RAMS does.
Frank=>You use 4588 format, but twist  a little bit the semantics
I am fine with  your expansion. but I am not very comfortable
with the saying "you misusing 4588".

> do some minor change with the document.

It is not a matter of being comfortable or not. 4588 can be used only if 
original packet payload is not modified (which is OK but pretty inefficient 
way of priming the decoders).

Please show us how you select the TS packets and put them in RTP packets in 
your AVT presentation. That way, it will be easier to discuss.
Frank=>We will show you the two.   However, I don't think this is the core 
of our debate just
I metioned in previous emails.

-acbegen