[e2e] Congestion control decision frequency + scaling of related
touch at ISI.EDU
Thu Jul 5 09:50:51 PDT 2001
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
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
More information about the end2end-interest