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

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

Thanks, Thomas.

I understand that you don't question anymore the use of different alpha values for, e.g. 20x16 versus 10x32.
And you come back to your original remark saying that 20x16 should perform better than 10x32 (e.g.).
Now I understand your point, and you are right. There is nothing wrong with small symbols indeed, even in the context of short FEC blocks.
This is confirmed if we observe the results in figure 5 in the draft. Those related to PLR=0.2.
For figure 4 with PLR = 0.1 we have weird results in this respect, that are related to the small difference that we want to evaluate, together with simulation times that should have been longer for this PLR.
The paragraph about the third pitfall mentioned in the draft (small symbols and many of them per repair packet) makes no sense and should be deleted. 

However, this doesn't affect the main purpose of the draft that consists in showing the benefits of re-packetization in terms of performance.

With respect to this comment:
>You can do it with FECFRAME by just not sending the original data. Just >send more repair symbols and repair symbols only.
When re-packetization is used, we assume only one symbol per source packet, and we have this property that if one source packet is lost, only one source symbol is lost. This property brings good performances. If we don't re-packetize the source packets that are sent, then this property is lost.

Best regards.

  Pierre

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

Pierre,

>> 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.
> 
> [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 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.

> 
>> 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. 
> 
> [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]
*** 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.

> 
>> 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.
> 
> [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]
*** 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

> Thomas
> 
>> 
>> 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,
>> 
>> 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:
>> 
>>> 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
>>> _______________________________________________
>>> 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
>> 
> 
> ---
> 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
> 

---
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