[Cerowrt-devel] real time text

[Cerowrt-devel] real time text

[Dave Taht]

dave

I am a big fan of udp. but reading about how this was implemented made
my head hurt. Then add crypto.

https://www.meetecho.com/blog/realtime-text-sip-and-webrtc/

-- 
Make Music, Not War

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-435-0729

Re: [Cerowrt-devel] real time text

[David P. Reed]

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


It does seem awfully complicated compared to how I would imagine the functionality could be implemented if you just did it on top of UDP. One of the costs of using UDP is that one needs to support protocol-specific end-to-end congestion control as well as protocol-specific datagram-loss handling.
 
To me a far simpler idea would be to start with "UDP congestion control" that didn't assume UDP datagrams arrived in-order and at-most-once, using observed drops and ECN marks, or end-to-end delay (by timestamping packets).
 
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).
 
Up to this point, encryption hasn't been mentioned. But there are encryption schemes that work very well for UDP - emulating a "one-time pad" based on a random start value fed back into a good cipher. Ideally it would be inserted under the erasure code layer. What you need to know to decrypt a block to feed into the erasure-code decoder is just a sequence number for the transmitted block, so you can index into the OTP.
 
Very simple.
 
But doing this on top of WebRTC (not a bad protocol, just a complicated platform) etc. seems to introduce problems that need to be patched around.
 
 
On Wednesday, April 15, 2020 7:34pm, "Dave Taht" <dave.taht@gmail.com> said:



> dave
> 
> I am a big fan of udp. but reading about how this was implemented made
> my head hurt. Then add crypto.
> 
> https://www.meetecho.com/blog/realtime-text-sip-and-webrtc/
> 
> --
> Make Music, Not War
> 
> Dave Täht
> CTO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-831-435-0729
> 

[-- Attachment #2: Type: text/html, Size: 3818 bytes --]

Re: [Cerowrt-devel] real time text

[Michael Richardson]

[-- 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 --]