[Starlink] FQ_Codel

[Sebastian Moeller]

Hi David,


> On Jun 8, 2022, at 20:47, David P. Reed <dpreed at deepplum.com> wrote:
> 
> I'm just going to remind folks that fixing bufferbloat in Starlink won't be possible with FQ-Codel in the CPE equipment. If that were possible, it could be fixed entirely in a box sitting between the dishy and the user's "home network".

	While we can not fix it, we can remedy it to some degree.


>  
> Evidence exists that the bulk of the "bloat" can exist, not just in the dishy, but also in the central "access point" where satellites in a coverage region direct all the traffic from and to the public Internet. This connection from the region becomes bloated if the inbound link and outbound link become "underprovisioned" for peak rates of all the served dishy terminals.
> That public-Internet to StarLink access point (is there a more distinct, precise name) can develop a very long delay queue.  For the same reason that bufferbloat always gets designed in - memory is cheap and plentiful,

	... but CPU cycles are still precious, it is this combination that results in the "over-sized, but under-managed" combination that is so atrocious for latency under load/working latency. (Granted, decent management typically means that the queues never really grow to fill large memory buffers, but that also means that reserving large amounts of memory for buffering does not hurt anymore).

> so instead of dropping packets to minimize latency, the link just stores packets until multiple seconds worth of traffic build up on one or both ends of that link.

	As long as they service the remote stations in a somewhat predictable/fair rpund-robin fashion under load we should be able to remedy that though.

> This problem can be solved only by dropping packets (with packet drop rate mitigated by ECN-marking) to match the desired round-trip latency across the entire Internet. Typically, this queue size should max out and start dropping packets at about 2 * cross-Internet desired latency * bit-rate of this link.
> Cross-Internet desired latency can be selected these days by using light-speed in fiber between one side of the North American continent and the other - around 15 msec. is appropriate. (which should be the worst case end-to-end latency observed using Starlink, and is around the 20 msec. number bandied about by Musk - though he really never understood what end-to-end latency means).
>  
>  
> Now it may be that the dishy itself also has such bloat built in, which would make FQ-Codel in the dishy also important.
>  
> The problem called bufferbloat occurs whenever ANY router on ANY end-to-end shared path allows such queueing delay to accumulate before shortening the queue.
>  
> It really frustrates me that memory keeps being added to router outbound buffers anywhere. And it may be that the reason is that almost nobody who designs packet forwarding systems understands Queueing Theory at all! It certainly doesn't help that "packet drops" (even one or two per second) are considered a failure of the equipment.
>  
> FQ-codel is great, but why it works is that it makes the choice of what packet to drop far better (by being fair and a little bit elastic). However, the lack of FQ-Codel doesn't fix system-level bufferbloat.

	I would have guessed tat the FQ scheduler alone already helps a lot, as it restricts the pain from over-committing to the hash-bucket housing the offending flow. Sure selecting the most effective packet(s) to drop also helps, but FQ alone will already help non-capacity-seeking flows (that stay below their capacity share) a lot if competing with capacity seeking traffic on the same link.

Regards
	Sebastian


>  
>  
> _______________________________________________
> Starlink mailing list
> Starlink at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink