[e2e] TCP un-friendly congestion control

[Injong Rhee]

> -----Original Message-----
> From: floyd at icir.org [mailto:floyd at icir.org]
> Sent: Friday, June 06, 2003 1:45 PM
> To: Injong Rhee
> Cc: end2end-interest at postel.org
> Subject: Re: [e2e] TCP un-friendly congestion control
> 
> >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.


Perhaps my statement was too broad. I was commenting on the announcement
stating that FAST achieves 1000 better performance than TCP in general
Internet. Agree that HSTCP and Scalable TCP have some mechanisms to
protect competing TCP and I think it is a right direction. But I believe
there must be some more study on this. Although they are intended to be
perfectly acceptable to interoperate with standard TCP, I am not
convinced that it is the case yet. More study is required to confirm
that. 

> 
> >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. But I am commenting not only on the drop tail, but also lack of
buffer space at the high speed routers.

> 
> 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.  


Yes. I am aware of the work. In fact, that is what I said. HSTCP shows
slowness to convergence to fairness under droptail. Scalable TCP in fact
do not converge. 

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/

No argument on this. However, please note that the amount of total
background traffic remains quite low in comparison to the total
available bw. Further, the number of large-window flows is not that many
in the production networks. Even if we add "enough" reverse traffic, and
short-lived web traffic with much diverse RTT ranges to remove the exact
phase problems you are mentioning, we still see the same behavior where
Scalable TCP does not converge under drop-tail or AQM with small
buffers. I need to look further on HSTCP and its slow convergence to
fairness and will let you know the results if you are interested.