Subject: [nwcrg] Review of draft-heide-nwcrg-rlnc-00

From: Vincent Roca <[email-masked]>
Date: Sun, 15 Jul 2018 16:06:38 -0400

Hi Janus et al.

Here is a review of draft-heide-nwcrg-rlnc-00.
My goal is to better understand your point and find ways to move forward,
in a constructive manner, even if there are many points.

Section 1.2. Evil is always in the details. You say:

  "In generation-based RLNC, input data as received from an upper layer
   in the protocol stack is segmented into equal-sized blocks, denoted
   as generations, and each generation is further segmented into equal-
   sized data symbols for encoding, with paddings added when necessary. »

This immediately raises many questions:

1- From this sentence, I understand that: (1) you append input data until you reach 
  the desired size, i.e., the desired number of bytes. Then as you know how
  many symbols you want, you compute the required symbol size to have this
  number. I think this is what you mean, but your text is pretty ambiguous.

Hence a few additional questions:

2- how do you determine the desired size of blocks? It typically depends on the
  input flow features.

3- what about situations where the input flow is of VBR? Do you wait to have received
   enough data before declaring the block as full? Do you pad? How do you manage
   real-time requirements?

More fundamentally:

4- I understand that Generation-Based RLNC, midway between traditional block
  codes and sliding window codes, is feasible. If I’m not wrong, this has long been
  the way Kodo was working.
  I understand it avoids the initial coding delay of traditional block codes, which is fine.
  But what’s the benefit of such codes WRT sliding window codes? The last source
  symbol of a generation is less protected than those received before since it is
  encoded in a fewer number of repairs. Where’s the gain? That’s something I don’t
  understand.

Later in section 3.1 it is said:

  "Such coding parameters
   can include one or more of field size, code specifications, index of
   the current generation being encoded at the sender, generation size,
   code rate, and desired feedback frequency or probability. »

5- Coding or protocol? Feedback parameters refer to protocol aspects, i.e.,
  the whole machinery that makes all the stuff provide the desired service.
  We are not talking about a code or FEC scheme specification. I don’t understand
  what's the intended I-D scope. Or do you mention it to highlight that the FEC scheme
  will be a little bit different when used in a protocol that includes feedback?

5b- BTW, I don’t think the code rate is needed by the receiver, at least from a coding
  perspective. It's different from fixed-rate traditional block codes. Same comment for
  Section 1.3.

Regarding section 1.4, you’re saying:
   "Recoding 
   is typically performed at intermediate network nodes, in either an
   intra-session or an inter-session fashion.  Intra-session coding
   refers to coding between packets of the same flow or session, while
   inter-session coding refers to combination of packets from different
   flows or sessions in a network."

6- Do you really want to consider inter-session coding?
  That’s ambitious, since it requires symbols of each session to be uniquely
  identified. How do you intend to do that? Do you assume a certain form
  of synchronisation between the sessions? It’s feasible if they come from
  the same host, otherwise it may quick become complex. And this identification
  needs to be compact as it is necessarily conveyed in the packet headers.

End of section 2: 
  "For example, if coding vectors are
   constructed using a pseudo-random generator, the maximum number of
   redundant symbols that can be transmitted is limited by the number of
   available generator states."

7- I think you can remove this sentence. I don’t know what PRNG you have in
  mind but that’s not the type of issue we have, even if you don’t re-seed the
  PRNG but transmit the current state. As far as I’m concerned, I always 
  re-seed, since some PRNG have a state that does not consist of a single
  word. I’ll talk a little bit about PRNG during IETF102...

In section 3:
 "Adding a header to each symbol may
   result in a high overhead when the symbol size is small or when
   generation or sliding window size is large. Adding a joint header to
   the beginning of each generation may also cause synchronization to be
   re-initiated only at the beginning of each generation instead of
   every symbol."

8- the above approach is not robust and cannot be recommended.
  If data (source or repair) packets are not auto-sufficient, you’ll have to send
  this signalling packet a certain number of times.

I won’t comment on the following header proposals (it’s too premature I think
to go into such considerations). BTW, current practice is to have 32-bit drawings
as in:

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

Globally, the current I-D should clarify assumptions and is IMHO too ambitious.
So from the above questions/comments, I notice that several aspects are worth to be
discussed/explored first.

E1- parameter derivations

E2- dynamic parameter adaptation

E3- inter-session re-coding: what are the exact scenario we want to address?
  What’s the associated signalling we need?
  Being too ambitious may quickly turn the proposal into something impractical IMHO.

May I suggest that you have a careful look at:
	https://tools.ietf.org/html/draft-ietf-tsvwg-rlc-fec-scheme-05 <https://tools.ietf.org/html/draft-ietf-tsvwg-rlc-fec-scheme-05>
because we already discuss/detail several of the above items. In particular 
parameter derivation.

Cheers,

     Vincent

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Mon, 16 Jul 2018 07:00:34 -0400

>   needs to be compact as it is necessarily conveyed in the packet headers.
I can think of two use case of un-structured “intersession" coding and it is sensor networks where individual sensors send coded data that is then aggregated at a gateway and possibly re-encoded  for further transmission downstream. The other one is peer to peer where each peer receives bits of information and recodes them before re-sending. I would however not call that really “intersession” but it’s fine. Is this what is considered here?

For more structured sessions like video while I fully support re-encoding in the network to support changing and dynamic conditions I agree with Vincent that there could be complexities that the authors may want to address.

mjm

Marie-Jose Montpetit, Ph.D.
[email-masked]
[email-masked]
@SocialTVMIT

---

From: "Kerim Fouli" <[email-masked]>
Date: Wed, 18 Jul 2018 07:51:32 -0400

Hi Vincent and Marie-José,

Thank you for your review and comments on draft-heide-nwcrg-rlnc-00. We agree that narrowing the scope and clarifying the functions is most practical, and your point there is well taken. However, we think provisions for major functions (e.g., recoding, feedback, possibly intersession) should be present for useful symbol representation. 

We are currently discussing a revision of the draft and will take your comments into consideration. I am happy to reiterate this point or give an update on Thursday (for item 2 of the agenda).

Best,

Kerim

-----Original Message-----
From: nwcrg <[email-masked]> On Behalf Of Marie-Jose Montpetit
Sent: Monday, July 16, 2018 7:01 AM
To: Vincent Roca <[email-masked]>
Cc: [email-masked]; Janus Heide <[email-masked]>
Subject: Re: [nwcrg] Review of draft-heide-nwcrg-rlnc-00

mjm

_______________________________________________
nwcrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/nwcrg

---

From: Vincent Roca <[email-masked]>
Date: Wed, 18 Jul 2018 09:04:43 -0400

Hi Kerim, Janus, all,

> Thank you for your review and comments on draft-heide-nwcrg-rlnc-00. We agree that narrowing the scope and clarifying the functions is most practical, and your point there is well taken. However, w…

Sure, if you want to design a coding solution that aims at supporting recoding, to take into consideration
feedbacks from the receiver (or receivers?), and intersession coding, then there is no problem. There are
very interesting questions associated to these features.

But clarify what your assumptions are at the start of the draft. Here there is a discussion of intra versus inter
session coding in the middle of the document (1.4) and at the end I don’t know if you want to consider it or
not whereas there can be major consequences. You’re not obliged to have clear ideas of how to address
each and every aspect at this step, but be clear on the goals.

> We are currently discussing a revision of the draft and will take your comments into consideration. I am happy to reiterate this point or give an update on Thursday (for item 2 of the agenda).

Perfect. Thanks.

Cheers,

  Vincent