Re: [Starlink] Starlink "beam spread"

[Ulrich Speidel <u.speidel@auckland.ac.nz>]

On 1/09/2022 7:58 pm, Sebastian Moeller wrote:
> Hi Ulrich,
>
> focussing on the CDN part
Sure, we're not on the same song sheet there yet I guess.
>
>> On Aug 31, 2022, at 15:41, Ulrich Speidel <u.speidel@auckland.ac.nz> wrote:
>> [...]
>> CDNs & Co - are NOT just dumb economic optimisations to lower bit miles. They actually improve performance, and significantly so. A lower RTT between you and a server that you grab data from via TCP allows a much faster opening of the congestion window. With initial TCP cwnd's being typically 10 packets or around 15 kB of data, having a server within 10 ms of your client means that you've transferred 15 kB after 5 ms, 45 kB after 10 ms, 105 kB after 15 ms, 225 kB after 20 ms, and 465 kB after 25 ms. Make your RTT 100 ms, and it takes half a second to get to your 465 kB. Having a CDN server in close topological proximity also generally reduces the number of queues between you and the server at which packets can die an untimely early death, and generally, by taking load off such links, reduces the probability of this happening at a lot of queues. Bottom line: Having a CDN keeps your users happier. Also, live streaming and video conferencing aside, most video is not multicast or broadcast, but unicast.
>> [...]
> Sure, that is a consequence of slow start*, but I argue that having 2ms or 20ms is not going to result in too noticeable a slow down, and bulk transfers like movies really do not care since DASH in all likelihood leaves slow-start for good after the initial ramp-up. Yes, 1ms versus 100ms makes a difference for interactive uses, but putting the CDN in space versus at the base station IMHO is a less clear improvement. Add to this that caches partly work by exploiting "locality", so e.g. for video streaming platforms I expect different countries to have different viewing profiles and hence different content needs to be cached, but satellites cover large "rings" around the world; meaning either you cache everything (or at least the content for your primary market) in space multiple times over so that your main service area is covered at all times or...
>
> I am prepared to eat crow on this in the future, but I am highly skeptical about CDNs in space (in spite of it being a cool project from the technological side).

Did I propose putting CDNs in space? I merely discussed whether there 
was any merit in this, and the answer is no.

As for the merit of CDNs in general (feeding into terrestrial last mile 
networks), that debate has been settled long ago. The example I chose 
was for TCP slow start in general. The difference isn't between 2 and 20 
ms but between your cwnd opening so slowly that a ~500 kB transfer takes 
half a second rather than 25 ms. And that example is easily extended.

If you have a network console on your browser, open a website that 
people frequently visit and have a look at how many files your browser 
loads for that. Have a look at how large they are. Then divide the size 
of each by 1500 bytes to get the number of packets in the transfer. Do a 
ping to the server the request goes to, and get the RTT. Then allow 10 
packets during the first RTT, 20 packets during the 2nd RTT, 40 during 
the 3rd, 80 during the 4th, and so on, and ask yourself how long it'll 
take to get all those packets across. And then you'll notice quickly 
that for size ranges up to a few MB, it makes a big difference whether 
the RTT is a few ms or a couple of hundred ms. A lot of common web site 
elements are in the order of a few 100 kB these days, and that means a 
few RTTs.

And yes, really small transfers done in less than one initial cwnd are a 
bit of an issue. You can see that on really crowded trunk GEO satellite 
links to a remote ISP. Because these small flows don't really back off, 
they are the only sort of flow that gets through, and as the load on the 
link increases, these can gobble up all the capacity while large flows die.

> *) As it looks slow start is getting a bad rep from multiple sides, but I see not better alternative out there that solves the challenge slow-start tackles in a better way. Namely gradual ramping and probing of sending rates/congestion windows to avoid collapse, this in turn means that short flows will never reach capacity, the solution to which might well be, use longer flows then...
>
-- 
****************************************************************
Dr. Ulrich Speidel

School of Computer Science

Room 303S.594 (City Campus)

The University of Auckland
u.speidel@auckland.ac.nz
http://www.cs.auckland.ac.nz/~ulrich/
****************************************************************