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

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

Dear all,
Thanks for these links, interesting reading. I do know about RLC in the 
binary field (i.e. using XOR) and also some of the 1D and 2D parity 
codes suggested for e.g. RTP. However, in Christian's paper it seemed to 
me that he was not doing RLC, but something different involving also a 
shift (I thought it might be something like a zigzag code). But I 
couldn't quite figure out the notation :) Perhaps some of you can 
enlighten me? :)

All the best,
Morten

On 12/11/19 4:12 PM, François Michel wrote:
> 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]
>>
> _______________________________________________
> EToSat mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/etosat