Development issues regarding the cerowrt test router project
 help / color / mirror / Atom feed
From: Michael Richardson <mcr@sandelman.ca>
To: "David P. Reed" <dpreed@deepplum.com>
Cc: "Dave Taht" <dave.taht@gmail.com>,
	cerowrt-devel <cerowrt-devel@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] real time text
Date: Thu, 16 Apr 2020 13:25:24 -0400	[thread overview]
Message-ID: <26107.1587057924@localhost> (raw)
In-Reply-To: <1587053795.184230897@apps.rackspace.com>

[-- Attachment #1: Type: text/plain, Size: 1686 bytes --]


David P. Reed <dpreed@deepplum.com> wrote:
    > Then use on that logic a sort of erasure coding (allowing
    > reconstruction of packets containing backspace/delete) that allows
    > out-of-order delivery as information becomes known. Erasure coding
    > (like Digital Fountain codes) are more efficient than retransmission of
    > duplicates of packets - if there are N packets queued in the network,
    > you'd need some kind of SACK-like scheme, but SACK doesn't work very
    > well when the buffering is a backup in the network, rather than in the
    > receive endpoint's OS queueing. Digital Fountains or its successors
    > work great! (and I think the patent expired finally).

I was reading the wikipedia entry on Fountain_code, because I didn't know
what that was.  I didn't know the IETF had published RaptorQ.
I have only read a page or two of the two RFCs.

While I understand that one could do this to megabyte-sized things,
but I'm unclear if all symbols have to be received before some pieces can be
extracted.  I'm specifically thinking about being able to broadcast firmware
updates to many (IoT) devices at the same time, and for the devices to be
able to not store the codes, just the results into flash.

I can well imagine that due to the FEC, that receipt of a single symbol would
could cause updates to many parts of the image, but I wanted to know if
all the received symbols had to be retained until the end?

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

      reply	other threads:[~2020-04-16 17:25 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-15 23:34 Dave Taht
2020-04-16 16:16 ` David P. Reed
2020-04-16 17:25   ` Michael Richardson [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/cerowrt-devel.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=26107.1587057924@localhost \
    --to=mcr@sandelman.ca \
    --cc=cerowrt-devel@lists.bufferbloat.net \
    --cc=dave.taht@gmail.com \
    --cc=dpreed@deepplum.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox