[e2e] Congestion control decision frequency + scaling of related signaling

[Joe Touch]

Michael Welzl wrote:
> 
> Hi all,
> 
> One major issue of Explicit Rate (and any other congestion control
> related) signaling is its scalability: whether it is designed for
> edge2edge or end2end usage, it must remain scalable.
> 
> Some key factors are obvious:
> - treatment of ER signaling packets in routers must be very efficient
> - per flow state (or even flow counting) in routers should definitely
>   be avoided
> 
> Another important factor is the amount of packets. It is well known
> that adapting the sending rate faster than once per RTT can lead to
> oscillations whereas adapting slower can lead to "unresponsive behaviour".
> So the RTT (SRTT) could be seen as an optimal choice for any congestion
> control related signaling / decision frequency.
> 
> There are two problems I have with that:
> 
> 1.) Shouldn't the optimal decision frequency for congestion control
>     generally be 2 RTT instead of 1 RTT?
> 
>     Here's a quote from "Congestion Avoidance in Computer Networks With
>     a Connectionless Network Layer", Raj Jain / K. K. Ramakrishnan /
>     Dah-Ming Chiu:
>     "System control theory tells us that the optimal control frequency
>      depends upon the feedback delay - the time between applying a control
>      (change window) and getting feedback (bits) from the network
>      corresponding to this control. In computer networks, it takes one
>      round-trip delay to affect the control, that is, for the new window
>      to take effect and another round-trip delay to get the resulting
>      change fed back from the network to the users. This leads us to
>      the recommendation that windows should be adjusted once every two
>      round-trip delays (two window turns) (..)."

Define decision frequency :-)

	at time T (zero) -
		you 'see' a picture of network state
		out to the endpoint, 1 RTT into the past

		you act on that picture (proactive) to
		effect a change

	at time T + 1 RTT -
		you 'see' 1 RTT into the past again, this time
		seeing everyone else's state _at the time
		you make your action decision_.

		you don't see the effect of your actions just yet,
		but you can update your actions if desired

	at time T + 2 RTTs - 
		you see the effect of your actions (2 RTTs
		after you make them).

I.e., you're always 1 RTT out of synch with network state, and
2 RTTs out of synch with seeing everyone else's actions on your
actions.

You still have to _ACT_ at time T+1RTT to see the effect
of your actions at time T+2RTTs. There are decisions at
time T+1 and at time T+2. At any given T, 

	you see network state 1 RTT into the past

	you see the result of your behavior 2 RTTs into the past 

As a result, you should wait 1 RTT to act on network 
state alone (loss, router congestion that you think you 
did not create, route changes, etc), and 2 RTTs to
correct your own behavior (if you think you caused the problem).

The decision frequency thus should depend on what you're
reacting to...
 
Joe