[e2e] TCP un-friendly congestion control

[Sally Floyd]

>It is my understanding that in the environments where these protocols
>(HSTCP, Scalable TCP, and FAST) are intended to operate -- fast (>1Gbps)
>and long distance networks (>50ms) -- TCP friendliness is not a concern
>since TCP cannot fully utilize the available network bandwidth. These
>protocols try to overcome this under-utilization problem of TCP.
>However, if we try to apply this to the general Internet environments
>(as it is noted in the announcement by CalTech), I think there could be
>some TCP-fairness issues.

In environments with high or moderate congestion (e.g., a current
congestion window at most 38 segments, or roughly equivalently,
loss event rates of 10^-3 or more), HSTCP and Scalable TCP perform
*exactly* the same as Standard TCP.  And with a current congestion
window of at most 120 segments, or roughly equivalently, a loss
event rate or 10^-4 or more, HSTCP takes roughly twice the bandwidth
of a Standard TCP connection in the same environment.  So HSTCP is
intended, in fact, to be perfectly acceptable to interoperate with
Standard TCP in the real Internet.

>These protocols (HSTCP and Scalable TCP, not sure about FAST since its
>spec is not available) assume AQM with a sufficiently large buffer space
>at the bottleneck routers. Under drop-tail or small buffer situations,
>they cannot guarantee fairness (Scalable TCP) or exhibit very slow
>convergence to fairness (HSTCP) even among the flows of their own type.
>I am working on a paper on this now. Will make it available soon.

It is not correct that HSTCP assumes AQM.  The HSTCP internet-draft,
and Evandro de Souza's recent simulation-based paper on "A HighSpeed
TCP Study: Characteristics and Deployment Issues", both discuss
HSTCP in DropTail environments in some detail.  (In the HSTCP
internet-draft, available from "http://www.icir.org/floyd/hstcp.html",
you could look at Section 9.2 on "The Number of Packet Drops per
Loss Event, with Drop-Tail".)  I have not looked carefully at
Scalable TCP's performance in Drop-Tail environments, but I would
guess that it could be somewhat more problematic.

However, with that said, it is also the case, in my opinion, that
performance in high-delay high-bandwidth environments will 
significantly benefit from some form of AQM at the congested queue
or queues.  Regardless of the transport protocol.

I agree that convergence is much slower in a DropTail than in an
AQM environment, as one would expect.  It also depends on the
DropTail environment that one is looking at.  To avoid having one's
simulations or experiments simply reflect arbitrary phase effects,
it is a good idea to include some form of randomization in the
simulations or experiments with DropTail.  In my own explorations
of this, I am including some reverse-path traffic, using the
"overhead" parameter in NS to add some small jitter to the data
packets sent on the reverse path.  This minimizes arbitrary phase
effects, and makes the convergence more realistic, in my opinion.
(It would be an odd high-delay high-bandwidth path where there was
*no* ack traffic sharing the congested queue in the forward path
with the data traffic, I would say.)

- Sally
http://www.icir.org/floyd/