From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp123.iad3a.emailsrvr.com (smtp123.iad3a.emailsrvr.com [173.203.187.123]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id BAE533B29E for ; Sun, 14 Jun 2020 11:40:55 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=g001.emailsrvr.com; s=20190322-9u7zjiwi; t=1592149255; bh=8dnqLayU2OGHSXwtbbQZCJ36cU+Ht5rw9fhbsDYp2y0=; h=Date:Subject:From:To:From; b=Hedu+6Ja4jpTCwre5p9j9m8Ie7bSjW0Eiypczx9nlgJxbWO9HCwQ0Ll66JgOj0M0e EXVi/k6S+9DXJNVHrtYzSwA+BiZtNl34hCJlNXburbeF1KSVlCvZxcVwvDhhbYyPJc aQLfapD6FNrw8vAnfpiEL2xylIcOLQcPGX436Ge4= Received: from app27.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp24.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 0F8FD23A10; Sun, 14 Jun 2020 11:40:55 -0400 (EDT) X-Sender-Id: dpreed@deepplum.com Received: from app27.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Sun, 14 Jun 2020 11:40:54 -0400 Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app27.wa-webapps.iad3a (Postfix) with ESMTP id EA45C21624; Sun, 14 Jun 2020 11:40:54 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Sun, 14 Jun 2020 11:40:54 -0400 (EDT) X-Auth-ID: dpreed@deepplum.com Date: Sun, 14 Jun 2020 11:40:54 -0400 (EDT) From: "David P. Reed" To: "David Lang" Cc: "Michael Richardson" , "David Lang" , "Jonathan Morton" , "bloat" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20200614114054000000_46919" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: References: <1591891396.41838464@apps.rackspace.com> <1591901205.85717618@apps.rackspace.com> <1591902977.45963161@apps.rackspace.com> <12673.1591976376@localhost> <20571.1592095016@localhost> Message-ID: <1592149254.956212731@apps.rackspace.com> X-Mailer: webmail/17.3.12-RC X-Classification-ID: 2436feb4-635f-4c3b-8fc0-7cb28fb8fea5-1-1 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:40:55 -0000 ------=_20200614114054000000_46919 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AOn Saturday, June 13, 2020 9:17pm, "David Lang" said:=0A= > > The lockdown has shown that actual low-latency e2e communication matter= s.=0A=0A> > The gaming community has known this for awhile.=0A> =0A> how ha= s the lockdown shown this? video conferencing is seldom e2e=0A =0AWell, it'= s seldom peer-to-peer (and for good reason, the number of streams to each e= ndpoint would grow linearly in complexity, if not bandwidth, in peer-to-pee= r implementations of conferencing, and quickly become unusable. In principl= e, one could have the video/audio sources transmit multiple resolution vers= ions of their camera/mic capture to each destination, and each destination = could composite screens and mix audio itself, with a tightly coupled "decen= tralized" control algorithm.)=0A =0ABut, nonetheless, the application serve= r architecture of Zoom and WebEx are pretty distributed on the conference-s= erver end, though it definitely needs higher capacity than each endpoint, A= nd it *is* end-to-end at the network level. It would be relatively simple t= o 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" wa= y.=0A =0AWith a system like starlink it seems important to me to distinguis= h 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-cas= ting of packets alone by the network. Instead, almost all multi-endpoint sy= stems need to coordinate, and that coordination is often best done (most sc= alably) by a network of endpoints that do the coordinated functions needed = for a system. However, deciding what those functions must be, to put them i= n the basic routers seems basically wrong - it blocks evolution of the appl= ication 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 destr= oyed the Bell System architecture as a useful technology).=0A=0A> =0A> and = starlink will do very well with e2e communications, but the potential=0A> b= ottlenecks (and therefor potential buffering) aren't going to show up in e2= e=0A> communications, they will show up where lots of endpoints are pulling= data from=0A> servers not directly connected to starlink.=0A =0AI hope nei= ther Starlink or the applications using it choose to "optimize" themselves = for their first usage. That would be suicidal - it's what killed Iridium, w= hich 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 wa= s way too early in the satellite game, back in the 1990's. Interesting stor= y there.=0A=0A> =0A> David Lang=0A> ------=_20200614114054000000_46919 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Saturday, June 13, = 2020 9:17pm, "David Lang" <david@lang.hm> said:

=0A

> > The lockdown has shown that actual low-latency e2e communic= ation matters.

=0A
=0A

> > The gaming community has known this for awhile.
>
> how has the lockdown shown this? video conferencing is seldom e2e=0A

 

=0A

Well, it's seldo= m 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 imple= mentations 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 c= omposite screens and mix audio itself, with a tightly coupled "decentralize= d" control algorithm.)

=0A

 

=0A

But, nonetheless, the application server architecture of Zoom and = WebEx are pretty distributed on the conference-server end, though it defini= tely needs higher capacity than each endpoint, And it *is* end-to-end at th= e network level. It would be relatively simple to scatter this load out int= o many more conference-server endpoints, because of the basic e2e argument = that separates the IP layer from the application layer. Blizzard Entertainm= ent pioneered this kind of solution - scattering its gaming servers out clo= se to the edge, and did so in an "end-to-end" way.

=0A

 

=0A

With a system like starlink it seems i= mportant to me to distinguish peer-to-peer from end-to-end, something I hav= e 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 m= oving function to the human-located endpoints where possible. But I also fo= ught against multicasting in the routers/switches, because very few applica= tions 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 c= oordinated functions needed for a system. However, deciding what those func= tions 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 activ= ely in the way. (Billing by the packet in each link being the classic examp= le of a "feature" that destroyed the Bell System architecture as a useful t= echnology).

=0A


>
> and starlink w= ill do very well with e2e communications, but the potential
> bottl= enecks (and therefor potential buffering) aren't going to show up in e2e> communications, they will show up where lots of endpoints are pulli= ng data from
> servers not directly connected to starlink.

=0A 

=0A

I hope neither Starlin= k or the applications using it choose to "optimize" themselves for their fi= rst usage. That would be suicidal - it's what killed Iridium, which could O= NLY carry 14.4 kb/sec per connection, by design. Optimized for compressed v= oice 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 pr= ices and Nicholas's being on Motorola's board. Of course 2B1 was way too ea= rly in the satellite game, back in the 1990's. Interesting story there.

= =0A


>
> David Lang
>

=0A<= /div>
------=_20200614114054000000_46919--