Comment by deathanatos

Comment by deathanatos 6 days ago

2 replies

As the OG post states, CF uses "Concurrent Streaming Acceleration" to batch those "270,000+" requests into one to the origin.

Now, let's grant that the public Internet is not CF's private backbone … but TFA makes it out to be more akin to a mobile connection in a tunnel than the Internet? Like transferring across the planet isn't going to be amazing … but that fails to explain how a download couldn't complete at all over multiple minutes…?

donavanm 6 days ago

The term of art is normally “request coalescing” or “collapse forwarding”; I believe the later came from the 90s/00s via squid or ocean.

Yes, multiple minutes to complete is very believable. Cloudflare reported 60% packet loss over ~100ms distance. Thats going kill window sizes and goodput. I wouldnt be surprised by this pathological case also exposing problems in their concurrent streaming window access between so many clients as well.

  • deathanatos 6 days ago

    > Yes, multiple minutes to complete is very believable. Cloudflare reported 60% packet loss over ~100ms distance. Thats going kill window sizes and goodput.

    You're begging the question: that 60% packet loss is exactly what I'm questioning. That's not normal for public Internet connectivity, so we need something beyond "oops, we routed the request over the public Internet" in order to fully explain the outage.

    Sure, given 66% packet loss, "multiple minutes to complete is very believable" and "Thats going kill window sizes and goodput" (sic), I agree with those points. But it's the premise — that packet loss on the external link was also absurd — that needs more explaining?

    (… this is where I wish Canva would have linked that quote to its source. AFAICT, Cloudflare never published that, so IDK if that's a private correspondence, or what.)