From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 2E8BF3B2A4 for ; Thu, 16 Apr 2020 13:25:25 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id E1D6B3897C; Thu, 16 Apr 2020 13:23:41 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 7B67438B; Thu, 16 Apr 2020 13:25:24 -0400 (EDT) From: Michael Richardson To: "David P. Reed" cc: "Dave Taht" , cerowrt-devel In-Reply-To: <1587053795.184230897@apps.rackspace.com> References: <1587053795.184230897@apps.rackspace.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.1.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Subject: Re: [Cerowrt-devel] real time text X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 17:25:25 -0000 --=-=-= Content-Type: text/plain David P. Reed 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 [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl6YlQQACgkQgItw+93Q 3WUnbgf9HHTu5cVGQ47axB/L/Orw+X5wUt3A0oI8DcZ0E0EBv35HZVbeQqBrB6dF VgORFeR1HkCR+pg0eJjllaI5UDFknzUYxoYPgrtsadahEIwGk80jMsO5Yf5+8hTP OV7xjgMdEoM6JrkiQCkQAUk1TbnVVi5rjQWV6aWFhewZbTDEWGqftOVgRye0FmjJ mp+yH/29mbj+LuTXr6mx2cvQGUbqW6coOjtoKvqX4DMX73C2pXwwl+AlEbssTEoQ KlMGDJuNokfdwzkuP67CQsa+4vDZEdkX2nVlBM4XfQkQ9xWApAC9EZmExgfYqtx2 aiFXbhu8hng2Krt0Qf3N3xtQpPbKUg== =ORJL -----END PGP SIGNATURE----- --=-=-=--