Re: [iccrg] Will Fair Queuing change Congestion Control?

[Sebastian Moeller <[e-mail]>]

Hi Christian,


> On Jan 5, 2023, at 00:58, Christian Huitema <[e-mail]> wrote:
> 
> 
> 
> On 1/4/2023 3:38 AM, Sebastian Moeller wrote:
>> Dear Narasimha,
>>> On Jan 4, 2023, at 10:09, Annapareddy, Narasimha <[e-mail]> wrote:
>>> 
>>> There are many ways delay-based congestion protocols can compete with loss-based protocols.
>>>  Here is an example approach:
>>>  Kiran Kotla and A. L. Narasimha Reddy, Making a delay-based protocol adaptive to heterogenous environments, Proc. of IWQOS, June 2008.
>>>  The basic idea is to claim a bit more bandwidth than TCP per successful transmission of window for the extra/early backoff on delay signals.
>> 	[SM] Thanks for the link! To clarify, there appears to be no widely-used delay based congestion control algorithm in the unconstrained internet.
> 
> Well, BBR is deployed quite a bit, its goal of "settling on the elbow" is definitely a form of delay minimization,

	[SM] Fair point, no shade intended from my side, I was more thinking inn terms of TCP Vegas and forgot about BBR's control loop.

> and it has quite a few other similarities with delay based congestion control. When BBR is the lone user of the bottleneck, it definitely delivers low latency. When BBR competes with Cubic, sometimes in wins, sometimes it looses. In some cases, BBR can saturate the link faster than Cubic, causing Cubic to experience losses and back off. In other cases, especially in bufferbloat conditions, Cubic manages to build queues that causes delays way above the min delay and cause BBR to slow down. Whether one or the other happens depends on quite a few variables, and is hard to predict.

	[SM] I am not too happy about the "hard to predict part", but I guess I am not alone in this...

> Most implementations of flow queuing or fair queuing are based on some form of bucketing. Typically, compute a hash of some elements of the header, derive a bucket number from the hash, and manage one queue per bucket. There are all kinds of variants depending on whether the hash includes IP addresses, port numbers, protocol type, or maybe address prefixes, and also whether the hash is based on source addresses and ports, destination addresses and ports, or both. Each of those variants have different properties, but they all have a common result, that a given TCP or QUIC connection will only compete with the TCP or QUIC connections in the same "bucket" -- with an increased probability of being "alone in the bucket". For some time of course, because new connections can join or leave the bucket at any time.

	[SM] I agree, but note that Linux' fq qdisc uses a perfect hash and hence should never encounter "bucket/fate sharing", but that seems somewhat infeasible for on-path nodes.


> So yes, it would be nice to have a simple way to answer whether the current connection is alone on the bottleneck, or alone in its bottleneck bucket. Kind of a first step before kicking buffer-bloating loss-based algorithms out of the Internet...

	[SM] Not that I am an expert but my take is that loss-based signaling is never going away fully. If a node is deep under water the only way to dig itself out of overload is by shedding packets instead of trying to transmit them and in that case flows better react to that signal if the want to play nice. So I argue that some level of emergency response to massive loss likely is needed indefinitely, no?

Regards
	Sebastian


> 
> -- Christian Huitema
> 
> _______________________________________________
> iccrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/iccrg