David Lang wrote: >> David Lang wrote: >> > my point is that the if the satellite links are not the bottleneck, no >> > queuing will happen there. >> >> It's a mesh of satellites. >> >> If you build it into a DODAG (RFC6550 would work well), then you will either >> a bottleneck at the top of tree (where the downlink to the DC is), or you >> will have significant under utilitization at the edges, which might encourage >> them to buffer. >> >> Now, the satellites are always moving, so which satellite is next to the DC >> will change, and this quite possibly could be exploited such that it's >> always a different buffer that you bloat, so the accumulated backlog that >> David P spoke about in his message might get to drain. >> >> But, the right way to use this mesh is, in my opinion, to have a lot of >> downlinks, and ideally, to do as much e2e connection as possible. >> Don't connect *to* the Internet, *become* an Internet. >> That is, routing in the satellite mesh, not just creation of circuits to DCs. > realistically, the vast majority of the people who have the mobile endpoints > are going to be talking to standard websites and services, and those are > going to be on the Internet, not on starlink nodes. Well, as along as we continue to build NATworks on the assumption that everyone is a consumer, not a citizen, that pattern will continue to happen. I think that when FACEBOOK suggested such a thing, explaining how they could accelerate everything through their servers, it was a major problem. Had this been the attitude in 1989, then the Internet would never have happened, and WWW would not have been a thing. The lockdown has shown that actual low-latency e2e communication matters. The gaming community has known this for awhile. -- ] 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 [