[e2e] TCP un-friendly congestion control

[J. Noel Chiappa]

    > From: "David P. Reed" <dpreed at reed.com>

    > Congestion loss rates are hardly small!!!

Please, be gentle - as you well know, this is not my area of expertise! :-)

    > What you may wish to say is that congestion loss rate variation is too
    > small in the control region around the desirable operating point, where
    > congestion loss = 0 and throughput = maximum.

That's a clearer and probably better (I assume :-) restatement of what I was
groping (in my limited understanding :-) toward in my "second point".


    > But ultimately the problem remains with this research that trying to
    > optimize the system to operate at 100% capacity on the bottleneck
    > link(s) is the wrong way to run a network.
    > Instead of running such a network, increase the capacity of the
    > bottleneck links to 10x load!

I don't necessarily disagree with this (although 10x bandwidth can cost big
money over a long distance).

However, I don't think that operating at the 100% capacity point is the goal
of the FAST work, which, according to their paper, is:

 "10 Gbps of sustained throughput .. rising to terabit/sec ... The key
  challenge we face, and intend to overcome, is that the current congestion
  control algorithm of TCP does not scale to this regime."

Your point is definitely not relevant to my message, which related to the
effectiveness of packet-drop based congestion control at very high speeds,
and in particular the supposition that transmission-error-drops (which will
increase in frequency as the link rate goes up, assuming a constant BER) will
add a lot of (unfilterable) noise to the congestion-drop signal, effectively
rate-limiting TCP on very-high-speed paths to a speed far below that of the
actual bottleneck.


So, do you disagree with their contention (stated above) about the
effectiveness of the current congestion control system at very high speeds?
If you do, I'm sure you could have an intereting discussion with that
community!

If not, then perhaps you can help me with my question:

    >> I would suspect that in practise, the first aspect I mentioned (two
    >> different kinds of loss signal getting mixed up) is probably an even
    >> bigger problem than the other one (the difficulty of using such a
    >> small [variation] signal for feedback).

    >> Does anyone have sany information on this, either from real-life
    >> measurements, or simulations?

which I am very curious about.

	Noel