[Fecframe] Comments about draft-galanos-fecframe-rtp-reedsolomon-00

[Vincent Roca <vincent.roca at inrialpes.fr>]

Hello Orly/Sarit,

Here are a few comments concerning 
draft-galanos-fecframe-rtp-reedsolomon-00.
Sorry, it's a bit long and only a few hours before the FECFRAME 
meeting... But
better late than never.
Cheers,

 Vincent

-----

Main comments:

* Section 4 is confusing because it mixes the notions of packets, symbols,
and "elements of the Galois Field". The following is the official 
terminology:

- A symbol (according to RFC5052) refers to the high-level unit of data 
managed
 by the FEC scheme. It can differ from unit of transport, the packet.
- RFC 5510 clarifies that in some use-cases, several symbols may
 be grouped and sent together in a given packet ("Encoding Symbol Group").
- RFC 5510 clarifies that symbols are composed of S "m-bit elements", 
where m is
 the Galois Field exponent GF(2^m). In the usual case of GF(2^8), 
elements are
 bytes, and the size S in terms of elements is of course equal to the
 symbol size E in bytes.
- Finally, section 8.4 of RFC 5510 explains how to do encoding/decoding over
 symbols, and how it refers to Reed-Solomon elementary operations over 
the S
 m-bit elements.

Now, we need to apply all this to the FECFRAME context. But as it is written
today, I don't understand section 4. When I compare to section 5 I have 
the feeling
that "symbol" means "element", but this element is fully defined by the 
choice of
the GF, it's not an open point left to the implementer.

Similarly, in section 5, it is said:
 "A source block for the Reed-Solomon code contains K data blocks."
There is no notion of "K data blocks" in the official terminology. I 
think you
want to say:
 "A source block [...] contains K source symbols."
(idem for the following sentences).


* Section 5: is the "one symbol per RTP packet" really appropriate?
If RTP packets have largely different sizes (usual case), the sender may
want to use symbols of size the median value (for instance) in order to 
avoid
having too much padding. Of course padding is not sent (i.e. there's no
transmission overhead penalty), but encoding/decoding operations will be
faster with smaller symbols. There is a price to pay for that, essentially
complexity (it breaks the packet <=> symbol relationship and there are more
symbols), so I'm not sure there's a real benefit. What do you think?


* Section 5: It is said:
     "B.  The sequence number of the source packets must be consecutive
          in a source block."
IMHO the "MUST be consecutive" is too strong. It may happen that some source
RTP packets be lost in some networks prior to reaching the FECFRAME sender
(i.e. if FECFRAME is used in an intermediate box rather than end-to-end).
And what about (crazy) situations where RTP packets are lost (e.g. by a FIFO
overflow) before reaching FECFRAME?
IMHO it's worth designing a solutions that is robust against this kind of
situation, no matter the cause.


* Section 6.2.1:
One stupid question: if there are several repair flows and if they are
all sent to the same multicast group/port, how does a receiver tell the
difference between the packets belonging to the different repair flows?
I think it's by means of the PT. This is not said in any case.
(I understand that sending everything to the same destination is not
necessarily a good idea, but that's a different topic)


* Section 6.2.2, Fig. 3: the choice of the various field sizes has
implications that are not explicitly mentioned.
Num Packets (badly named, I'd prefer K): 16 bits => too much in case
       of RS over GF(2^8), more appropriate to GF(2^16).
i and N-K: 8 bits => okay with GF(2^8), a limit in case of GF(2^16),
but that's perhaps not the target.


* Whole document: More generally, I have the feeling nowhere it is explained
whether or not there are restrictions on the GF size. Which possible values
for the m parameter.


* Section 6.2.2: I have the feeling that carrying N-K in the FEC header is
perhaps not required. On the opposite, there MUST be a way to inform the
receiver of the GF(2^m) used (e.g. it can be done out-of-band in SDP 
description).
So if I know m, I don't need to know the actual N-K as I know K and 
max_K=(2^m)-1.


* Section 6.2.2: SN Base is used to identify the source block (since all
the FEC repair packets associated to the same source block have the same 
SN Base
value). Since SN Base is a field that regularly wraps around, there is a
(theoretical) risk that two consecutive source blocks use the same SN Base
value. This might happen in tricky configurations with large source blocks
(GF(2^16)) and in case the RTP sequence numbers are not consecutive (see 
above
discussion about possible erasures *before* FECFRAME).
Additionally, and more seriously, this vulnerability may also be 
exploited as
a possible DoS (Denial of Service) to make a FECFRAME sender crash.

So it's worth mentioning this topic in the doc, both in the core spec 
and in the
Security section.
If we clarify that this document is not for situations experiencing high 
erasure
rates before FECFRAME (which can be checked on-the-fly), it should be 
okay IMHO.


* Section 6.2.2: Back to the idea of removing the constraint on consecutive
source packets, I'm wondering if the following FEC header format wouldn't be
okay:

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Base SN              |           Max SN              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Source Block Length (k)    |   Enc. Symbol ID (16 bits)    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Thanks to this FEC header:
- We know that all SN values in {Base SN..Max SN} are included in this
 source block.
- We know their actual number (k) even if some of RTP SN are missing.
- We know the ESI of the FEC repair packet (in {K, N-1}), no matter the
 GF m parameter since it's 16-bit long.
- And we know in which order incoming source RTP packets should be
 stored in the block, even if there are gaps in the SN.
At a receiver, the actual SN value in the RTP header of an erased
source packet is anyway recovered along with the rest of the header/payload
so there's no problem either.
      

* Section 7.1.1: it is not clear to me if max_N is equal to 2^m or if
it is only a "codec limitation". I think it's related to the GF, but it's
worth mentioning. And the "symbol-size" should also clarified as already
mentioned.


* Section 8.3.1: This section does not explain how to manage the case where
there are several repair flows. It's a problem.


* Section 11.
You cannot get rid of the security aspects in this way. Most specifications
add additional security risks (like the DoS opportunities mentioned above).


Non critical:
-------------

* section 1, intro: the term "FEC packets" is used several times.
 Rather than FEC Packets, say FEC Repair Packets. In 3.1, correct
 and use FEC Repair Packet (several occurrences).

* section 6.2.2: instead of "i - 0 based packet index in the N-K FEC 
packets sequence."
(i-0 is misleading). I suggest:
       i: FEC repair packet index, in {0.. N-K-1} range.

* Whole document: you are using K and N (upper case), whereas usage (at 
least RMT)
 is more on using k and n.

* Whole document: "FEC header" is not the official name.