Re: [EToSat] What we are looking for from QUIC

[François Michel <[e-mail]>]

Hello,

Le 11/12/19 à 15:49, Su, Chi-Jiun a écrit :
> Here are links to packet level FEC, XOR and beyond.
> 
> RFC 5109
> 
> https://tools.ietf.org/html/rfc5109
> 
> Francois Michel’s MS thesis
> 
> https://dial.uclouvain.be/memoire/ucl/fr/object/thesis%3A14650/datastream/PDF_01/view
> 
> page 29 describe XOR.
> 

Thank you so much for referencing this. I apologize in advance for the 
imprecisions that may be present in the master thesis. :-) A 
mathematical intuition behind XOR and RLC are present starting from page 
13 if needed.

You can also implement RLC using only XORs (and a pre-computed table) 
and it provides better correcting capabilities. The SWIF codec coming 
from the nwcrg does that: 
https://github.com/irtf-nwcrg/swif-codec/blob/master/src/swif_symbol.c
(the addition is a xor and the multiplication is an access in a 
pre-computed table)

Regards,

François

> *From:* EToSat <[e-mail]> *On Behalf Of *Morten V. Pedersen
> *Sent:* Tuesday, December 10, 2019 3:54 PM
> *To:* [e-mail]
> *Subject:* Re: [EToSat] What we are looking for from QUIC
> 
> Dear all,
> Thanks for your input.
> 
> @Christian Thanks for the paper - I will carefully go though it. It 
> looks like a really nice motivation why coding is useful in multicast / 
> broadcast scenarios.
> 
> For multicast I would say that the gain of coding should also be present 
> even if the receivers have no packet loss, but simply are blocked from 
> time to time (this creates a discrepancy between the N receivers) which 
> would be costly to fix with a retransmission based system.
> 
> I have one question on the encoding you describe, you write that it can 
> be done with with XOR and shifts alone. Could you provide some more 
> details on that?
> 
> @John & CJ: In general I think that makes a lot of sense for 
> point-to-point links. You would typically use packet level FEC to avoid 
> retransmissions in which case you add redundancy on the link and if you 
> don't needed it - well then it is essentially wasted bandwidth.
> 
> All the best,
> Morten
> 
> On 12/10/19 8:50 PM, Su, Chi-Jiun wrote:
> 
>      From Christian’s paper, the first two cases where use of packet
>     level FEC provides benefits are in satellite communication.
> 
> 
>     “There are in fact at least three environment where the reduced
>     error rate proves very valuable. When multicasting data toward large
>     groups, even a small individual error rate per recipient may result
>     in large retransmission rates for the whole group and the use of
>     redundancy will result in dramatic efficiency gains. In the case of
>     long transmission delays, the use of redundancy helps maintaining
>     the delivery delays within acceptable limits, even in presence of
>     errors. When the receivers do not have enough memory resources to
>     implement sophisticated retransmission techniques, forward error
>     correction can compensate the relative inefficiency of cheap
>     algorithms of the go-back N family.”
> 
>     *From:* EToSat <[e-mail]>
>     <mailto:[e-mail]> *On Behalf Of *Christian Huitema
>     *Sent:* Monday, December 9, 2019 1:05 PM
>     *To:* Su, Chi-Jiun <[e-mail]>
>     <mailto:[e-mail]>
>     *Cc:* Morten V. Pedersen <[e-mail]>
>     <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
>     *Subject:* Re: [EToSat] What we are looking for from QUIC
> 
> 
>     This reminds me of the "case for FEC" paper that I wrote a long time
>     ago. The abstract is here:
>     https://link.springer.com/chapter/10.1007%2F978-0-387-34986-2_8
> 
>     My copy of the text, in Postscript, is here:
>     http://huitema.net/papers/case4fec.ps
> 
>     -- Christian Huitema
> 
> 
> 
> 
>         On Dec 9, 2019, at 3:31 AM, Su, Chi-Jiun <[e-mail]
>         <mailto:[e-mail]>> wrote:
> 
>         Hi Morten,
> 
>         John may respond to you when he is available.
>         I work in the same company as John.
>         Yes. You're right more or less.
> 
>         - large window requires allocation of memory.  The number may be
>         significantly huge for a server serving tens/hundreds of
>         thousands of connections.
>         - FEC adds overhead in transmitted bytes and delay in encoding
>         and decoding of FEC in addition to computational resource
>         requirements.
> 
>         Hope it answers your questions.
>         Thanks.
>         cj
> 
>         -----Original Message-----
>         From: EToSat <[e-mail]
>         <mailto:[e-mail]>> On Behalf Of Morten V. Pedersen
>         Sent: Monday, December 9, 2019 6:20 AM
>         To: [e-mail] <mailto:[e-mail]>
>         Subject: Re: [EToSat] What we are looking for from QUIC
> 
>         CAUTION: This email originated from outside of the organization.
>         Do not click links or open attachments unless you recognize the
>         sender and know the content is safe.
> 
>         Hi John,
>         Could you elaborate on the point below:
> 
>         --------------------------
> 
>         On 12/3/19 7:43 PM, Border, John wrote:
> 
> 
>             We are looking at FEC to help with the packet loss problem
>             and large
> 
>             windows to address the throughput problem.  Since enabling
>             FEC and
> 
>             very large windows (especially initial windows) will not be
>             good
> 
>             defaults for general use, we need some sort of learning
>             capability to
> 
>             know when they should be used.
> 
> 
>         --------------------------
> 
>         Is it because of computational complexity or similar?
> 
>         All the best,
>         Morten
> 
>         _______________________________________________
>         EToSat mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/etosat__;!!Emaut56SYw!jbhJ11p7YT7--EvCJ88bLI55OqJl1kcHQ46EEnS7wGZdk3cJCgFk3JMytIjk4Fi9Cw$
> 
> 
>         _______________________________________________
>         EToSat mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/etosat
> 
> 
> 
>     _______________________________________________
> 
>     EToSat mailing list
> 
>     [e-mail]  <mailto:[e-mail]>
> 
>     https://www.ietf.org/mailman/listinfo/etosat
> 
> 
> _______________________________________________
> EToSat mailing list
> [e-mail]
>