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 58A253B29E for ; Sun, 14 Jun 2020 11:57:28 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 16213389F7; Sun, 14 Jun 2020 11:54:55 -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 iqIwxQP9y4Lv; Sun, 14 Jun 2020 11:54:53 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id BC092389F6; Sun, 14 Jun 2020 11:54:53 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 48927608; Sun, 14 Jun 2020 11:57:26 -0400 (EDT) From: Michael Richardson To: "David P. Reed" , "David Lang" , "Jonathan Morton" , "bloat" In-Reply-To: <1592149254.956212731@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> 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 15:57:28 -0000 --=-=-= Content-Type: text/plain David P. Reed wrote: >> > The lockdown has shown that actual low-latency e2e communication matters. >> > The gaming community has known this for awhile. >> >> how has the lockdown shown this? video conferencing is seldom e2e > Well, it's seldom peer-to-peer (and for good reason, the number of > streams to each endpoint would grow linearly in complexity, if not > bandwidth, in peer-to-peer implementations of conferencing, and quickly > become unusable. In principle, one could have the video/audio sources > transmit multiple resolution versions of their camera/mic capture to > each destination, and each destination could composite screens and mix > audio itself, with a tightly coupled "decentralized" control > algorithm.) JITSI, whereby, and bluejeans are all p2p for example. There are n+1 webrtc streams (+1 because server). It's a significantly better experience. Yes, it doesn't scale to large groups. So what? My Karate class of ~15 people uses Zoom ... it is TERRIBLE in so many ways. All that command and control, yet my Sensei can't take a question while demonstrating. With all the other services, at least I can lock my view on him. My nieces and my mom and I are not a 100 person conference. It's more secure, lower latency, more resilient and does not require quite so much management BS to operate. > But, nonetheless, the application server architecture of Zoom and WebEx > are pretty distributed on the conference-server end, though it > definitely needs higher capacity than each endpoint, And it *is* > end-to-end at the network level. It would be relatively simple to > scatter this load out into many more conference-server endpoints, > because of the basic e2e argument that separates the IP layer from the > application layer. Blizzard Entertainment pioneered this kind of > solution - scattering its gaming servers out close to the edge, and did > so in an "end-to-end" way. Yup. > With a system like starlink it seems important to me to distinguish > peer-to-peer from end-to-end, something I have had a hard time > explaining to people since 1978 when the first end-to-end arguments had > their impact on the Internet design. Yes, I'm a big fan of moving > function to the human-located endpoints where possible. But I also > fought against multicasting in the routers/switches, because very few > applications benefit from multi-casting of packets alone by the > network. Instead, almost all multi-endpoint systems need to coordinate, > and that coordination is often best done (most scalably) by a network > of endpoints that do the coordinated functions needed for a > system. I see your point. You jump from e2e vs p2p to multicast, and I think that there might be an intermediate part of the argument that I've missed. > However, deciding what those functions must be, to put them in > the basic routers seems basically wrong - it blocks evolution of the > application functionality, and puts lots of crap in the transport > network that is at best suboptimal, ,and at worst gets actively in the > way. (Billing by the packet in each link being the classic example of a > "feature" that destroyed the Bell System architecture as a useful > technology). I'd like to go the other way: while I don't want to bring back the Bell System architecture, where only the network could innovate, I do think that being able to bill by the packet is an important feature that I think we now have the crypto and CPU power to do right. Consider the affect on spam and DDoS that such a thing would have. We don't even have to bill for good packets :-) There could be a bounty that every packet comes from, and if it is rejected, then the bounty is collected. >> and starlink will do very well with e2e communications, but the potential >> bottlenecks (and therefor potential buffering) aren't going to show up in e2e >> communications, they will show up where lots of endpoints are pulling data from >> servers not directly connected to starlink. > I hope neither Starlink or the applications using it choose to > "optimize" themselves for their first usage. That would be suicidal - > it's what killed Iridium, which could ONLY carry 14.4 kb/sec per > connection, by design. Optimized for compressed voice only. That's why > Negroponte and Papert and I couldn't use it to build 2B1, and went with > Tachyon, despite Iridium being available for firesale prices and > Nicholas's being on Motorola's board. Of course 2B1 was way too early > in the satellite game, back in the 1990's. Interesting story there. I agree: they need to have the ability to support a variety of services, particularly ones that we have no clue about. -- ] 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+93Q3WUFAl7mSOYACgkQgItw+93Q 3WXvHggApNeU9BMCXchxCJuy6YYFQrOjlUd+PUFA8hfZAmXemXJ6t9azo7U9B1dg V6ntUDbPN487PfTvJCIYdntvz/NEUVuE29ISlK0hMkZVd5unLYfEgIsXNZVzs1gm OzYSvwOspDRnbfJ35UbvH9sWATE/D/WZudTji6LC2+yO3JAAaIhOQGev7dTGONNB kkEgNibY7FDjn6YHCqC4SXM3YoOKGib5n/49mrV5ozqR4alROs0pEJhEOf0yTDei bAtAF8JPfP+auL3k4/c5gSBvP8tX/YeHX8scjIB6l98S1FtK+O9m65ingzbTCcL1 t6mUohpner7TPgl7l1Y64p4MFX0kNQ== =Nlv0 -----END PGP SIGNATURE----- --=-=-=--