Subject: [tsvwg] Feedbacks on FECFRAME-extended and RLC I-Ds

From: Vincent Roca <[email-masked]>
Date: Wed, 19 Apr 2017 17:13:17 +0200

Hello everybody,

I’ve received useful comments (privately) from Marie-José M. for both I-Ds (FECFRAME-extended and
RLC). Here are the conclusions we’ve reached that could be implemented in next version.

Concerning the FECFRAME-extended I-D:

1- there’s a lot of historical notions both WRT terminology and architecture, so understanding current I-D
	without going back to RFC 6363 (i.e., FECFRAME specifications) is impossible. This is a side effect
	of providing only the delta WRT RFC 6363, i.e. the 10% specific to sliding window codes.
	Several misunderstandings derived from this lack of introductory material.

    Proposal: in Section 1, add an introduction to FECFRAME. Current introduction only motivates this
		extension which does not help understanding the background.

2- references to « convolutional codes » can be confusing, this term being too close to physical layer codes.

    Proposal: prefer « sliding window codes » (also in the title).

Concerning the RLC I-D:

1- the RLC name is confusing (too close to Network Coding).

    Proposal: "Sliding Linear Codes" (SLIC) seems more appropriate (thanks to MJM who suggested it).

2- references to « convolutional codes » can be confusing (same as above).

    Proposal: remove most of them.

3- question on the elastic or fixed size nature of the coding window. Not clear.

    Proposal: update text to clarify that this is left to the application/protocol relying on this FEC Scheme.
		The SLIC FEC Scheme addresses both situations. Also clarify that real-time aspects are the
		responsibility of the application, not the FEC Scheme.

Beyond these two TSVWG I-Ds, related works will be carried out in the context of NWCRG on a generic
protocol for robust and low latency tunnelling. Many open research points are raised, hence the « RG »
nature.

Cheers,

  Vincent