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

["Morten V. Pedersen" <[e-mail]>]

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]> *On Behalf Of *Christian Huitema
> *Sent:* Monday, December 9, 2019 1:05 PM
> *To:* Su, Chi-Jiun <[e-mail]>
> *Cc:* Morten V. Pedersen <[e-mail]>; [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.
>
> 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 
> <https://urldefense.com/v3/__https:/link.springer.com/chapter/10.1007*2F978-0-387-34986-2_8__;JQ!!Emaut56SYw!ghR40lR1fPlxTxd2FAQ-A_MS23aqVeE3QWHRTwu4oXqBld0WqeiQZEFO8RA2UrI3xw$>
>
> My copy of the text, in Postscript, is here: 
> http://huitema.net/papers/case4fec.ps 
> <https://urldefense.com/v3/__http:/huitema.net/papers/case4fec.ps__;!!Emaut56SYw!ghR40lR1fPlxTxd2FAQ-A_MS23aqVeE3QWHRTwu4oXqBld0WqeiQZEFO8RClCMWs_Q$>
>
> -- 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$
>     <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]
> https://www.ietf.org/mailman/listinfo/etosat