[Bloat] FW: [Dewayne-Net] Ajit Pai caves to SpaceX but is still skeptical of Musk's latency claims

[David P. Reed]

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.
 
[What do you think I and others fought for datagrams back in 1976 for? If it hadn't been for our little cabal, you would have TCP virtual circuits. Period. And it took a lot of arguing - a whole year of nearly losing - until we forced the creation of the IP datagram layer separate from TCP. It was easier to disentangle Telnet from TCP - the initial TCP was going to have "break" and "formatting" characters defined in it and "line at a time" options, etc. Because it was thought that Telnet was the primary use of the Internet, and if you wanted binary octets, you could just quote them.]
 
So, WebRTC is fine, and it works as well as it works. However, the engineering thought needed to make peer-to-peer *conferencing* scale well (up to interactive webinars with meeting rooms that can be split off, etc) is simplified by having resources other than just "peers" to do that work. Simplifying scalability is a good thing.
 
I don't think forcing everyone to do media over WebRTC is any better than forcing everyone to use centralized servers. Each approach has tradeoffs. The point of the end-to-end argument was to enable those tradeoffs.
 
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.
To bill, you need auditability of the bills. It's not simple at all - you can't just send billing packets to accounts associated with endpoints in an Internet. Every packet on every link is potentially (and likely) billed differently.
 
If you want the amount you pay your access provider to be proportional to traffic you generate or receive, that may be feasible. Desirable? That's another issue not relevant here. I was talking about billing every packet back to "some responsible party" from every link to reimburse the investor who built that link, bit by bit. That's what the Bell System actually did (outside a local exchange, and between states). And that's why 70% of opex was billing, which would have soared if it were by packet rather than by "call".
 
You have the Internet ONLY because of Carterfone and other decisions that forced interfaces into the Bell System that they didn't want, because it wrecked their monopoly business model. Data was charged at an incredibly high rate, separate from voice, because to bill for it cost more. The UK got the Internet only because they had to follow the US (rather than billing outrageously). Europe got it last, because PTT's were essentially government revenue generators, so the government hated the idea of losing the money.
 
 
On Sunday, June 14, 2020 11:57am, "Michael Richardson" <mcr at sandelman.ca> said:



> 
> David P. Reed <dpreed at deepplum.com> 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 at sandelman.ca http://www.sandelman.ca/ | ruby on rails [
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20200614/8fd8b632/attachment.html>