From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 1BB1C3B29E for ; Sun, 14 Jun 2020 19:13:36 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 6DEAE389FF; Sun, 14 Jun 2020 19:11:02 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id bXovVxTWZFQS; Sun, 14 Jun 2020 19:11:01 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9FFF5389FD; Sun, 14 Jun 2020 19:11:01 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 722B375F; Sun, 14 Jun 2020 19:13:34 -0400 (EDT) From: Michael Richardson To: "David P. Reed" cc: "David Lang" , "Jonathan Morton" , "bloat" In-Reply-To: <1592168645.890914226@apps.rackspace.com> References: <1591891396.41838464@apps.rackspace.com> <1591901205.85717618@apps.rackspace.com> <1591902977.45963161@apps.rackspace.com> <12673.1591976376@localhost> <20571.1592095016@localhost> <1592149254.956212731@apps.rackspace.com> <23070.1592150246@localhost> <1592168645.890914226@apps.rackspace.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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: [Bloat] FW: [Dewayne-Net] Ajit Pai caves to SpaceX but is still skeptical of Musk's latency claims X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2020 23:13:36 -0000 --=-=-= Content-Type: text/plain David P. Reed wrote: > I have no problem with WebRTC based videoconferencing. In fact, I think > it is pretty good for 2-4 endpoints. But when you have lower cost > laptops, they drag down the conferencing because of the compositing and > mixing and multiple stream transmission load, even with 2-3 other > participants. As for "low-end" --- that definition is changing :-) The advantage of compositing locally is that the end point can actually do what the end user wants. Not the other way around. Smart end points, rather than smart networks. > [What do you think I and others fought for datagrams back in 1976 for? Yeah, I wasn't old enough to watch, but I did read of that debate. > As far as billing by packets, no, I hope it never happens. 70% of the > opex of the Bell System was billing-related, because of micro-specific > billing. I'm not so young (at 49, being a precocious teenager in 1984) as to not understand this :-) In fact, with VoIP business systems, there are still ridiculous attempts to do billing. A lot of effort for very little ROI. But, it turns out that the billing data let you get at other interesting results: like when are your busy times, and do you have enough of the right sales representatives present? how many days after that first 30C day do the calls to the pool store start? (I did have to figure that out...) I think that we can come up with different models that would help with the endless undesireable packets. It's not trivial, and I sure don't want to go back down the same road. But, I think there is something here. -- ] 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----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl7mrx4ACgkQgItw+93Q 3WXQyAf7B9JCvDsiZtI4bEWt+m1gU/nvaLYOIhZzmG4s9HtlfSdxSsvdEmFerwJP clwamT/HL/zMXD4yXgwlrFWHBcsLLmT5coQc0jBOp/np3BMbJNKRm4EETXwK2P65 YzpjXR5yV/mjWvPAOsFKlVIris9o/bm7zQ0Bs5VOLNWFU9Ms78t/eu3DVbLZqib5 T0DSwh7LeFId8ob5nIBMXdgDGePyOkyX9/Fo71oPboQa0UivwMXhT1HbGEUaoxyE 1pisVuKnzb8sI+UeDi17woWwsAi5rGjaV/pKCn3BRFxmfIljeuTuG+Vxi+JVi9bN S5V+25yHrYvoELkLwhu5c6mZ2Z/BaA== =Ly8Y -----END PGP SIGNATURE----- --=-=-=--