Why is the congestion control process deployed at sender nodes?
I know one of the limitations that avoid deploying congestion control at routers is that routers need to maintain flow states, which increases the burden of routers. Put this aside, Is there any other defects that limit deploying congestion at router side?
There are indeed congestion controls that either require support from or is deployed in routers. An example is XCP (https://www.ietf.org/proceedings/61/slides/tsvwg-5.pdf) in which routers allocate bandwidth without keeping per-flow state. Another is Data Center TCP which uses ECN-marks provided by the routers to detect the extent of congestion. These two examples are ment for networks with one authority. In the Internet there are many authorities/actors with different goals. If we were to put the congestion control in the routers, what congestion control policy do we choose?
Imagine that you have two flows, A and B, and two routers, R1 and R2. R1 has a capcity of 100Mbit/s, and R2 has a capacity of 10Mbit/s. Flow A goes through only R1, while Flow B goes through R1 and R2. Let us say that we share the capacity of R1 equally, A and B gets 50Mbit/s each. B goes through R2 which has only 10Mbit/s, so it is unable to use the 50Mbit/s given to it by R1. What should happen in this case? R1 should probably change the allocation, but how? If the routers are in different domains which does not trust eachother negotiation is out of the question. The routers does not trust the end-systems, so the end-systems cannot communicate the allocation to the routers.
The main issue as I see it is defining a congestion control policy that is accepted by all the actors in the Internet. A strong argument for having congestion control in the end-system is the end-to-end principle. TCP congestion control is transport-layer functionality and should not be implemented in the internet-layer because it is not used by all transport-layer algorithms (UDP).