Subject: Re: [iccrg] Very fundamental congestion control questions...

From: "Schwarz Albrecht (ETAS/ESY1)" <[email-masked]>
Date: Fri, 1 Mar 2019 10:51:33 +0000

Hi Mario, all,

please ignore my comments if they are missing the detailed levels of your discussion.

However, that discussion reminded me to  two former application fields where state models related to congestion/overload were discussed in some details.

Firstly, you need a server model (queueing model) inclusive the model of the control loop (as an open or closed control, but normally a closed control in case of congestion and overload control).
Without a model in mind its difficult to discuss terminology, particularly in case of state models.

Secondly, the viewpoint is the perspective of the considered resource component (e.g., server, system, network, link, TCP endpoint, etc etc) in my understanding.
That viewpoint determines what is load (offered load) and performance (processed load, throughput, goodput, ...).
You need a state model for that resource.
In case of a real system it would be the so called *usage state model* 
Ref.: e.g., ITU-T M.3701 Common management services - State management - Protocol neutral requirements and analysis  
Such a  usage state model would need explicit states "Congested" (and "Overloaded") besides other usage state of interest.

That said:

Example application I: network gateways which are controlled by the gateway control protocol H.248
("you may use any other network equipment as well such as of type SDN, controlled by Diameter, OpenFlow, I2RS, whatever")

Congestion controls and overload controls were specified for such gateways:
(There's a free PDF download for all ITU-T Recommendations, here under https://www.itu.int/rec/T-REC-H/e )
e.g.,
H.248.10 Gateway control protocol: Media gateway resource congestion handling package  
H.248.11 Gateway control protocol: Media gateway overload control package  
H.248.82 Gateway control protocol: Explicit congestion notification support

The usage states "congested" and "overloaded" were NOT differentiated, but at least a simple model for overload was agreed:
see Appendix II, Basic traffic models ... 
in
H.Sup6 Control load quantum for decomposed gateways  
https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-H.Sup6-200604-I!!PDF-E&type=items 

Example application II: Traffic theory for physical traffic (such as car traffic)
There are two-state (congested, not congested) and three-state models (free flow and two congested flow states) (considering here the resource component "street segment"). 
The three state (or three phases) model would be of interest concerning the congestion discussion here:
https://rd.springer.com/book/10.1007/978-3-540-40986-1 
https://en.wikipedia.org/wiki/Three-phase_traffic_theory 

That physical traffic theory does only use the term congestion (and not overload), which might be thus interesting complementary information for the iccrg discussion.
I never thought about whether and how the communication network traffic theory could benefit of that detailed congestion models of the physical network traffic theory.
But here might be some reuse when mapping the spatial part of that model on the network topological part (e.g., multiple servers in series).
Anyway, good inspiration in my personal opinion .

Regards,
Albrecht

-----Original Message-----
From: Mario Hock <[email-masked]> 
Sent: 27 February 2019 19:16
To: Schwarz Albrecht (ETAS/ESY1) <[email-masked]>; [email-masked]
Subject: Re: [iccrg] Very fundamental congestion control questions...

Albrecht,

thanks for sharing your understanding. But I'm not sure if I can follow you entirely.

Am 23.02.19 um 08:52 schrieb Schwarz Albrecht (ETAS/ESY1):
> Mario,
> 
> my understanding:
>> Or do we say, this situation would result in congestion, if the congestion control were not there?
> 
> Because the metric *load* is effectively related to the *offered traffic load*, i.e., the product (let's say A) of the "observed traffic arrival process" and the "expected traffic service process".

As I just wrote in my other mail, the question is where do we consider this load. Demand of the application to send data or actually transmitted data.

> A rough rule of thumb for differentiation between overload and congestion was:
> a) A > 1 Erlang = Overload
> b) 0.x < A < 1 Erlang = Congestion ("in case of queueing effects ... 
> e.g. due to variance")

I would say the task of the congestion control is maintain the situation you describe in b). If the application demand already fulfills this requirement, congestion control is not really needed. But if the application demand is as in (a), i.e., would fulfill your "overload" 
criterion, the offered load has to be limited by the congestion control.

Based on your rule of thumb I understand you as follows: "Congestion is when the congestion control needs to limit the application demand to the available capacity." And maybe even: "If the congestion control fails to do this, it's not congestion anymore but overload." Is that right?

Best, Mario

> But that's just a coarse, stationary consideration for the classification between overload and congestion.
> Any useful definition needs to take into account the assumption of a time-scale (as the thread points out) in order to cover the non-stationarity effects.
> 
> Regards,
> Albrecht
> 
> 
> -----Original Message-----
> From: iccrg <[email-masked]> On Behalf Of Christian Huitema
> Sent: 22 February 2019 19:07
> To: Mario Hock <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [iccrg] Very fundamental congestion control questions...
> 
> The term that is well defined is "congestion collapse", which happens when each additional input causes more overload and fewer good output as if the additional input had not been present.
> 
> We call algorithms like Reno or Cubic congestion control because one of their functions is to prevent congestion collapse. The basic insight is that when the network appears congested, it is a good idea to slow down, rather than for example  aggressively repeat old packets as pre 88 TCP used to do.
> 
> The other function of these algorithms is to adapt the offered load to the available resource, and navigate between two extremes: not slowing enough and cause congestion, versus not accelerating enough and cause resource to go unused. We call that congestion control too for historical reasons.
> 
> Then there is the definition of overload and its consequences. One definition of overload is "more load than the network can carry", translating of course in packet losses. But buffering in network queues smoothes the load over time, so there is also a time component there, leading to another characteristic of overload, "long queues in the network that contribute to poor response time" (a.k.a. buffer bloat).
> 
> Some of our congestion control algorithms only care about packet losses (Reno, Cubic). Other care about transmission time (BBR) or about both time and losses (Vegas, LEDBAT).
> 
> -- Christian Huitema
> 
>> On Feb 22, 2019, at 5:45 AM, Mario Hock <[email-masked]> wrote:
>>
>>> Am 22.02.19 um 10:10 schrieb Kilkki Matti:
>>> Then as to the first option, it we use a car traffic analogy, a highway is congested only when the throughput of the highway (or speed of the cars) is decreased due to excessive traffic (regardless of the number of cars waiting to access the highway). Normally, when the load exceeds a limit the speed of cars is considerably reduced and then the highway certainly is congested. As there typically is a hysteresis in this process, the problem of defining timescale is alleviated.
>>
>> Thanks for sharing this analogy. I think it just points to another aspect that's kind of fuzzy with the current "congestion" term.
>>
>> Let's assume we have a good working congestion control and we have a situation in which the congestion control is actually need and does its job well. Do we consider this situation as congestion (since congestion control is active/needed). Or do we say, this situation would result in congestion, if the congestion control were not there?
>>
>> - If we call this "congestion", a network with zero packet loss and zero queuing delay, can still be congested.
>>
>> - If we say it's no congestion, how do we call a situation that requires a congestion control to take action, if not "congestion"?
>>
>>
>> Similar questions apply for terms like "overload". If the demand is larger than the capacity and the congestion control manages this well, is there a overload or not?
>>
>> - If we call it "overload", we can have a overloaded network with zero packet loss and zero queuing delay (if we have a really good congestion control).
>>
>> - Otherwise, we would denote the network as not overloaded even 
>> though the demand might be much higher than the actual throughput (or 
>> even output)
>>
>> Bottom line: How do we factor-in the effects of the congestion control feedback loop in our terminology?
>>
>> _______________________________________________
>> iccrg mailing list
>> [email-masked]
>> https://www.irtf.org/mailman/listinfo/iccrg
> 
> _______________________________________________
> iccrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/iccrg
>