Subject: [Fecframe] New draft submitted: draft-roux-fecframe-repacketization-00.txt

From: "ROUX Pierre" <[email-masked]>
Date: Tue, 9 Feb 2010 12:11:27 +0100

Dear all,
I have recently submitted the following Internet-Draft:

Title		: Benefits of re-packetization for FEC based protection
of multimedia streams
Author(s)	: P. Roux, C. Janneteau, K. Mounir
Filename	: draft-roux-fecframe-repacketization-00.txt
Pages		: 12
Date		: 2010-2-9

URL: 
http://www.ietf.org/internet-drafts/draft-roux-fecframe-repacketization-
00.txt

This is an informational draft that presents the advantages of
re-packetizing multimedia streams to be FEC protected, for better
performance.

Any kind of feedback about this Internet-Draft will be very welcomed.

Best regards,

  Pierre

---

From: Thomas Stockhammer <[email-masked]>
Date: Tue, 9 Feb 2010 13:09:37 +0100

Pierre,

I quickly scanned through this draft. Some very initial comments:

Comment 1:
=========
You strategy (c) 
   (c) Have small repair symbols but put many repair symbols per repair 
   packet. 
and your pitfall:
  (c) will have poor performances because the loss of a single repair 
   packet will translate into a large number of repair symbol being 
   lost. 

I do not understand why this would results in poor performance. This works very well is applied in the MBMS streaming framework.
Despite you loose more symbols, you also get more symbols from correct packets. So it works very well, but you need a long code such as Raptor or RaptorQ.

Comment 2:
==========
I disagree with the approach to modify source packets the way you propose. This has significant backward-compatibility issues and had been discussed in AVT for some time. However, there are nice ways to achieve what you propose in a very simple manner. For example, RFC3984 permits the use of fragmentation units and you can fragment entire slice into fragments that exactly fit the purpose you want. the major advantage is that this is backward-compatible and it is part of the payload format. Creating a new layer for the purpose of generic fragmentation seems to create many problems.

Comment 3:
=========
What is strange about your results is that the performance of symbol size 16 with 20 symbols per packet performs worse than symbol size 32 with 10 symbols per packet. The same with 5x32 and 10x16.
It is also not clear why the alpha values are different for these configurations. Can you explain?

Best regards

Thomas

On Feb 9, 2010, at 12:11 PM, ROUX Pierre wrote:

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

---
Dr. Thomas Stockhammer (CEO) || [email-masked] || phone +49 89 978980 02 || cell +491725702667
Nomor Research GmbH  -  Sitz der Gesellschaft: München - Registergericht: München, HRB 165856 – Umsatzsteuer-ID: DE238047637 - Geschäftsführer: Dr. Thomas Stockhammer, Dr. Ingo Viering.

MWC 2010: Visit Nomor Research at booth 2F33

---

From: "ROUX Pierre" <[email-masked]>
Date: Tue, 9 Feb 2010 16:28:13 +0100

Thanks you for your quick feedback.
Here are tentative answers.

With respect to comment 1, I agree about your statement ("you get more symbols form correct packets"). I also agree that this strategy can be efficient with long codes. The context that we were interested in in this draft is when we can't afford long codes (low bitrates and no tolerance about latency). Then this strategy (short symbols and many symbols per repair packet) is probably not the best one.

With respect to comment 2: OK for the lack of backward compatibility. This drawback is pointed out in the draft. 
Exploiting RFC3984 is also a worthy suggestion. The advantage of the "new layer" is that it is applicable to any media stream. 

With respect to comment 3:
Alpha values are slightly different because the amount of padding depends on the symbol size. We have more padding when we use symbol size=32 as compared to symbol size=16. So if we want to reach the same total bit-rate target, we can afford a greater alpha when symbol size=16.
As for the simulation results they are not far away so that it is difficult to derive definitive conclusions. If we compare 20x16 to 10x32 or 10x16 to 5x32, then the winner depends on which table we look at: PLR=0.1 or PLR=0.2. 
What you were expecting seems to be what we got with PLR=0.2.

I hope it answers you first comments.

Best regards.

  Pierre

-----Message d'origine-----
De : Thomas Stockhammer [mailto:[email-masked]] 
Envoyé : Tuesday, February 09, 2010 1:10 PM
À : ROUX Pierre
Cc : [email-masked]
Objet : Re: [Fecframe] New draft submitted: draft-roux-fecframe-repacketization-00.txt

Pierre,

Comment 1:
=========
You strategy (c) 

Comment 2:
==========

Comment 3:
=========

Best regards

Thomas

---
Dr. Thomas Stockhammer (CEO) || [email-masked] || phone +49 89 978980 02 || cell +491725702667
Nomor Research GmbH  -  Sitz der Gesellschaft: München - Registergericht: München, HRB 165856 - Umsatzsteuer-ID: DE238047637 - Geschäftsführer: Dr. Thomas Stockhammer, Dr. Ingo Viering.

---

From: Thomas Stockhammer <[email-masked]>
Date: Tue, 9 Feb 2010 17:05:06 +0100

Pierre,

inline
[Thomas]
***

> With respect to comment 1, I agree about your statement ("you get more symbols form correct packets"). I also agree that this strategy can be efficient with long codes. The context that we were int…

[Thomas]
***I am sorry, I miss the logic. If the source block size stays the same, but you only change the dimensions, this does not change the delay. You add the same amount of source packets in either case. This is independent of the bitrate and delay tolerance.

> Exploiting RFC3984 is also a worthy suggestion. The advantage of the "new layer" is that it is applicable to any media stream. 

[Thomas]
***I still do not understand the use case, but if the use case is really relevant (which I still need to be convinced) then you may use the FEC Framework as is and only send repair packets. Then you can have packets of the exact symbol size. So I do not see the necessity of a new layer as backward-comptibility is anyways broken with this new layer.

> Alpha values are slightly different because the amount of padding depends on the symbol size. We have more padding when we use symbol size=32 as compared to symbol size=16. So if we want to reach t…

[Thomas]
*** Still not getting it. Which padding are you referring to? In FEC framework the packets are sent unmodified (in case RTP is used) and your repair packets all have the same size. So where would the extra overhead come from? The padding in the source block to create the source symbols is never "transmitted".

> What you were expecting seems to be what we got with PLR=0.2.

[Thomas]
*** Again see above, I do not understand the logic. You are sending the same amount if repair packets, all of the same size, and you are also sending the same source packets and you are using MDS codes, so why would there be any difference?

Thomas

---

---

From: "Einat Yellin (Lachover)" <[email-masked]>
Date: Wed, 10 Feb 2010 11:30:01 +0200

Hi,

Adding to the discussion.
In general the ideal behind leveling the unit sizes in FEC is good, but I believe that with the suggested draft it could fail in practice.

On top of the backward compatibility "small" issue, there is also a computational drawback in implementing this.
If I understand correctly both sender and receiver would be required to rearrange RTP packets, which means recopying the bytes and producing new RTP headers.

Other comments that I would like to make are about different assumptions in the Appendix:
A. Block periodicity of 500ms is way to high if you target low-latency applications. It means that in some cases the receiver would have to wait 500 ms before packet restore can be done.
B. FEC bit rate that equals source bit rate seems to be unrealistic IMHO. If, as you suggested, you target low bitrate video you will get better quality by using more bitrate for the video itself and use only a fraction of the bit rate for FEC, especially in the common cases of  up to 5% packet loss - see C.
C. Packet loss rates - I think that you should experiment with lower and more typical packet losses in the range of 1-5% as well. 

Regards,
Einat

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Stockhammer
Sent: Tuesday, February 09, 2010 6:05 PM
To: ROUX Pierre
Cc: [email-masked]
Subject: Re: [Fecframe] New draft submitted:draft-roux-fecframe-repacketization-00.txt

Pierre,

inline
[Thomas]
***

[Thomas]

[Thomas]

[Thomas]

[Thomas]

Thomas

---

---

From: "ROUX Pierre" <[email-masked]>
Date: Wed, 10 Feb 2010 10:36:20 +0100

Hello Thomas, 
I was afraid about a possible lack of feedback, but I have not such fear anymore.
Let us try to solve misunderstandings.
Please find answers inline (after (Pierre]).

Best regards.

  Pierre

-----Message d'origine-----
De : Thomas Stockhammer [mailto:[email-masked]] 
Envoyé : Tuesday, February 09, 2010 5:05 PM
À : ROUX Pierre
Cc : [email-masked]
Objet : Re: [Fecframe] New draft submitted: draft-roux-fecframe-repacketization-00.txt

Pierre,

inline
[Thomas]
***

[Thomas]
***I am sorry, I miss the logic. If the source block size stays the same, but you only change the dimensions, this does not change the delay. You add the same amount of source packets in either case. This is independent of the bitrate and delay tolerance.
[Pierre]
What is compared is large FEC block on one side and medium FEC block on the other side.
The relation with bit-rate and delay tolerance is that when you have a low bit-rate and delay constraints, it is not possible to have large FEC block. As an example in the simulation, the average source bit-rate was around 120 kbit/s, and the FEC block periodicity was set equal 500 ms (to avoid excessive latency increase), so the average source block size in bytes was around 7 or 8 kbytes.

[Thomas]
***I still do not understand the use case, but if the use case is really relevant (which I still need to be convinced) then you may use the FEC Framework as is and only send repair packets. Then you can have packets of the exact symbol size. So I do not see the necessity of a new layer as backward-comptibility is anyways broken with this new layer.
[Pierre]
I am not sure if I understand your point. What is proposed is to use the FEC Framework as is. The re-packetization/restoration process is outside of the FEC Framework.

[Thomas]
*** Still not getting it. Which padding are you referring to? In FEC framework the packets are sent unmodified (in case RTP is used) and your repair packets all have the same size. So where would the extra overhead come from? The padding in the source block to create the source symbols is never "transmitted".
[Pierre]
Let me try to clarify with a numerical example.
We have a block made of 4 source packets, with respective payload sizes equal to 447, 242, 741, 841 bytes.
Those packets are sent unmodified as source packets, as you have pointed out.
We also want to build repair packets on the basis of a symbol size equal either to 50 bytes or to 100 bytes. If the size is 50 bytes we will put 10 symbols per repair packet (default), and if the size is 100 bytes we will put only 5 symbols per repair packet (default).
If the symbol size is equal to 50 bytes we build 9,5,15,17 source symbols out of each respective source packet. The total is 46 source symbols for the block.
If the symbol size is equal to 100 bytes we build 5,3,8,9 source symbols out of each respective source packet. The total is 25 source symbols for the block.
Then is we assume the same alpha value equal to 1 in each case, we will derive as many repair symbols as there are source symbols. We will get 5 repair packets in each case, but when the symbol size is 50, the last repair packet will be filled with 6 symbols instead of 10.
So the repair bit-rate will be lower if the symbol size if 50.
Because we want that all configurations are compared with the same total bit-rate (that includes the repair bit-rate) we would assign a higher alpha value in case of symbol size equal to 50, as compared to symbol size equal to 100.

[Thomas]
[Pierre]
See above.

Thomas

---

---

From: Thomas Stockhammer <[email-masked]>
Date: Wed, 10 Feb 2010 11:35:08 +0100

Pierre,

> The relation with bit-rate and delay tolerance is that when you have a low bit-rate and delay constraints, it is not possible to have large FEC block. As an example in the simulation, the average s…

[Thomas]
*** I understand what you say, but again, if the you have small symbols, e.g. 16 and large source blocks size, e.g. 1024, or large symbols, e.g. 1024, and small source block size, e.g. 16. There is no difference in terms of delay. So I do not see the point.

> I am not sure if I understand your point. What is proposed is to use the FEC Framework as is. The re-packetization/restoration process is outside of the FEC Framework.

[Thomas]
*** Yes, I understand. But you do not need to have it outside. You can do it with FECFRAME by just not sending the original data. Just send more repair symbols and repair symbols only.

> Because we want that all configurations are compared with the same total bit-rate (that includes the repair bit-rate) we would assign a higher alpha value in case of symbol size equal to 50, as com…

[Thomas]
*** OK, maybe we are getting closer. So now you have how many packets?
- 4 source packets of size 447, 242, 741 and 841
- 5 repair packets, each of size 500 bytes

So I have 
for  50 byte symbols: 
	- source symbols: 9, 5, 15, 17 
	- sum is 46 source symbols
	- each repair packet has 10 symbols
for 100 byte symbols: 
	- source symbols: 5, 3, 8, 9
	- sum is 25 source symbols
	- each repair packet has 5 symbols
	- I need one of the following (at least)
		- all 5 repair packets, 
		- 4 repair + packet  (1) or  packet (3) or packet (4),
		- 3 repair + packet (1+ 3) or packet (1 + 4) or packet   (2 + 3) or packet (2 + 4)  or  packet (3 + 4)
		- 2 repair + packet (1 + 2 + 3) or  packet (1 + 2 + 4) or packet (3 + 4)
		- 1 repair + packet (1 + 3 + 4) or  packet (2 + 3 + 4) 
	- If I check then for all these cases I can also recover for 50 byte symbols

In any case I need at least the amount of source symbols at the receiver. So I am always doing at least as good or better if use 50 byte symbols instead of 100 byte symbols.

So there is a small difference expected when you use smaller source symbols, but it is always in favour of the smaller symbols. So I do not understand your results why the smaller symbols size perform worse.

Thomas

---

---

From: "ROUX Pierre" <[email-masked]>
Date: Wed, 10 Feb 2010 14:54:39 +0100

Thanks, Einat.
We take note of your remarks for possible study complements.

Best regards.

  Pierre

-----Message d'origine-----
De : Einat Yellin (Lachover) [mailto:[email-masked]] 
Envoyé : Wednesday, February 10, 2010 10:30 AM
À : Thomas Stockhammer; ROUX Pierre
Cc : [email-masked]
Objet : RE: [Fecframe] New draft submitted:draft-roux-fecframe-repacketization-00.txt

Hi,

Regards,
Einat

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Stockhammer
Sent: Tuesday, February 09, 2010 6:05 PM
To: ROUX Pierre
Cc: [email-masked]
Subject: Re: [Fecframe] New draft submitted:draft-roux-fecframe-repacketization-00.txt

Pierre,

inline
[Thomas]
***

[Thomas]

[Thomas]

[Thomas]

[Thomas]

Thomas

---