From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp76.iad3a.emailsrvr.com (smtp76.iad3a.emailsrvr.com [173.203.187.76]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id BC3863B2A4 for ; Thu, 16 Apr 2020 12:16:35 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=g001.emailsrvr.com; s=20190322-9u7zjiwi; t=1587053795; bh=9bkdMhC1Q8QxrrEbnhwRyP0ILkfN/pq9DgGIBCezxgE=; h=Date:Subject:From:To:From; b=xRSxwNYlW+dmQJFupS57l2DyUPrYzC7yukCafia0pbdFmVT/kz14+J56VCSdoYg6S C84ERQzt12Vk9EUz6DnAn7Og7LckNY6D7HNeB0eacJxNnjWMM87GkvPIj/RouuJKsO GfSP4Kq+u9sK0BEL5XSj3yecvC7iY0FSGa4o9/u8= Received: from app5.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp18.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 4700D252B0; Thu, 16 Apr 2020 12:16:35 -0400 (EDT) X-Sender-Id: dpreed@deepplum.com Received: from app5.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Thu, 16 Apr 2020 12:16:35 -0400 Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app5.wa-webapps.iad3a (Postfix) with ESMTP id 2D932613FF; Thu, 16 Apr 2020 12:16:35 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Thu, 16 Apr 2020 12:16:35 -0400 (EDT) X-Auth-ID: dpreed@deepplum.com Date: Thu, 16 Apr 2020 12:16:35 -0400 (EDT) From: "David P. Reed" To: "Dave Taht" Cc: "cerowrt-devel" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20200416121635000000_33222" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: References: Message-ID: <1587053795.184230897@apps.rackspace.com> X-Mailer: webmail/17.3.7-RC X-Classification-ID: a4502f65-a700-4d3f-ba29-8ed14dd23f44-1-1 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 16:16:35 -0000 ------=_20200416121635000000_33222 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AIt does seem awfully complicated compared to how I would imagine the fun= ctionality could be implemented if you just did it on top of UDP. One of th= e 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.= =0A =0ATo me a far simpler idea would be to start with "UDP congestion cont= rol" that didn't assume UDP datagrams arrived in-order and at-most-once, us= ing observed drops and ECN marks, or end-to-end delay (by timestamping pack= ets).=0A =0AThen use on that logic a sort of erasure coding (allowing recon= struction of packets containing backspace/delete) that allows out-of-order = delivery as information becomes known. Erasure coding (like Digital Fountai= n 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 fi= nally).=0A =0AUp 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 d= ecrypt a block to feed into the erasure-code decoder is just a sequence num= ber for the transmitted block, so you can index into the OTP.=0A =0AVery si= mple.=0A =0ABut doing this on top of WebRTC (not a bad protocol, just a com= plicated platform) etc. seems to introduce problems that need to be patched= around.=0A =0A =0AOn Wednesday, April 15, 2020 7:34pm, "Dave Taht" said:=0A=0A=0A=0A> dave=0A> =0A> I am a big fan of udp. but = reading about how this was implemented made=0A> my head hurt. Then add cryp= to.=0A> =0A> https://www.meetecho.com/blog/realtime-text-sip-and-webrtc/=0A= > =0A> --=0A> Make Music, Not War=0A> =0A> Dave T=C3=A4ht=0A> CTO, TekLibre= , LLC=0A> http://www.teklibre.com=0A> Tel: 1-831-435-0729=0A> ------=_20200416121635000000_33222 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

It does seem awfully c= omplicated compared to how I would imagine the functionality could be imple= mented if you just did it on top of UDP. One of the costs of using UDP is t= hat one needs to support protocol-specific end-to-end congestion control as= well as protocol-specific datagram-loss handling.

=0A

 

=0A

To me a far simpler idea would be to s= tart 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-e= nd delay (by timestamping packets).

=0A

 

= =0A

Then use on that logic a sort of erasure coding (al= lowing reconstruction of packets containing backspace/delete) that allows o= ut-of-order delivery as information becomes known. Erasure coding (like Dig= ital Fountain codes) are more efficient than retransmission of duplicates o= f packets - if there are N packets queued in the network, you'd need some k= ind 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 queue= ing. Digital Fountains or its successors work great! (and I think the paten= t expired finally).

=0A

 

=0A

Up to this point, encryption hasn't been mentioned. But there are enc= ryption schemes that work very well for UDP - emulating a "one-time pad" ba= sed on a random start value fed back into a good cipher. Ideally it would b= e 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.

=0A

 

=0A

Very simple.

=0A

 

=0A

But doing this on top of WebRTC (not= a bad protocol, just a complicated platform) etc. seems to introduce probl= ems that need to be patched around.

=0A

 

= =0A

 

=0A

On Wednesday, Apr= il 15, 2020 7:34pm, "Dave Taht" <dave.taht@gmail.com> said:

=0A
=0A

> 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=C3= =A4ht
> CTO, TekLibre, LLC
> http://www.teklibre.com
&= gt; Tel: 1-831-435-0729
>

=0A
 ------=_20200416121635000000_33222--