Re: [nwcrg] Sliding window draft and coding schemes (e.g. RLNC)

[Vincent Roca <[e-mail]>]

Hello Brian and everybody,

In order to move forward and enrich the end-to-end transport use-case discussions, I have
worked on an update to FECFRAME in order to support the sliding window approach (see
my other email). The general architecture and concepts seem okay to me at first glance.

Here also the next step is now to specify a first convolutional FEC Scheme… This I-D will be,
for some parts, FECFRAME specific, but the rest will be common with other NC proposals.

And we need a public repository to work collaboratively on this and other documents
(e.g., taxonomy)…

Cheers,

  Vincent


> Le 6 avr. 2015 à 18:44, Brian Adamson <[e-mail]> a écrit :
> 
> As a result of some discussion with Marie, I thought it would be a good idea to share a few of my thoughts on some of the near term activities we seem to have identified and making some progress on.  One of the nearer-term “products” of our NWCRG discussion is the end-to-end transport use case with the developing sliding window approach being documented in Jonathan, et al’s draft.
> 
> To support that work, it could be good to consider trying to document an accompanying “FEC Scheme or two (e.g. RLNC, etc) that could be applied with the sliding window protocol.  That may help us get the framework right.  It would perhaps even be an interesting thought exercise to see if something like RLNC could documented in the form of an RMT or FecFrame “FEC Scheme”?.  One thing to note here is the the main value proposition for unicast end to end use of coding lies somewhat with the delay improvements and that the sliding window type approach helps maximize the gains here as compared to the transport efficiencies coding yields for multicast (it also gets some delay benefits too under certain use cases).  While some of the formats / semantics of RMT/FecFrame may be reused, they may be too "block code oriented” as they are currently specified?
> 
> So I think we are sort of on a good course to get some consensus for defining a sliding window framework that one could then “plug in” RLNC and some of the other coding algorithms discussed (all the IPR issues notwithstanding).  It may be necessary to have the sliding window document to provide a reference for how to specify RLNC.  We did that in RMT where we wrote the “FEC Building Block” document that established some core packet formats (and IANA registries) so we could go on to document specific FEC coding algorithms (we called them FEC Schemes) including non-proprietary stuff like Reed Solomon, LDPC as well as the proprietary Raptor codes, etc.
> 
> I haven’t been too explicitly vocal on this aspect because it seemed we were getting some progress on this with Jonathan’s draft and more recently Morten’s constructive comments on that.  This may be one of the pieces that can transition more early to IETF working group activities for end-to-end transport purposes while we continue in NWCRG to work on the more “researchy” items. I think having this initiated in NWCRG is OK since we’ve assembled a set of people that may be able to work the problem?  And if we establish a basis of components (e.g. packet formats, coding scheme definitions) from this that may also be useful for other applications of network coding (i.e. more “in network” things like your DNC concept, ideas like Cedric described, SDN applications of coding, etc), then it is also beneficial to ongoing NWCRG work, too.  Then, when it’s sufficiently mature it might find a (transport area) working group home for the longer term?
> 
> Again I personally haven’t explicitly articulated this like I’ve done here since we seemed (to me) to be sort of proceeding (perhaps lurching) along this path anyway, but (with Marie’s help) have realized these might thoughts worth sharing.
> 
> best regards,
> 
> Brian
> _______________________________________________
> nwcrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/nwcrg