WARNING: This server is unstable and will be retired in the next days.
If you want to keep this forum available, please request immediately a migration
on the Nabble Support forum.
Forums that don't receive any migration request will be deleted forever.
Ever since congestion control was included in TCP in 1988, this
function has helped the Internet to survive by ensuring its stable
operation. However, it has long been known that this mechanism is not
ideal, and that it shows deficiencies in the face of heterogeneous
link properties such as high capacities, long delays or noise.
Now, after almost two decades, it seems that the demand for more
performant mechanisms has become so strong that people are beginning
to use alternatives that do not adhere to the standard anymore. As
this can lead to adverse interactions among different mechanisms, it
is a major goal of the ICCRG to move towards consensus on which
technologies are viable long-term solutions for the Internet
congestion control architecture, and what an appropriate cost/benefit
As a starting point for designers of new mechanisms, the group is
currently working on two documents: a survey of congestion control
related RFCs (which should help to avoid reinventing the wheel) and an
overview of open issues in the field of congestion control.
A process for evaluating experimental congestion control proposals was
crafted, with the goal of arriving at a recommendation to the IETF
regarding publication of such proposals as RFCs; this process is
currently applied to two documents describing TCP variants (CUBIC and
Compound TCP), and discussions are ongoing.