[e2e] TCP un-friendly congestion control

[Shivkumar Kalyanaraman]

Buffer space continues to be an unresolved myth...

The data point I know is that buffer space on the next generation Intel
IXA processors (2xxx series) is about 2GB (SRAM + DRAM), shared operating
at 10 Gbps. This is quite substantial for any practical B-D product..

While high-speed SRAM is scarce, only the header is stored there and the
payload is in DRAM. But this number is not indicative of CURRENT deployed
buffer space in practical routers deployed today in peering points etc. As
far as I know Cisco charges HEAVILY for any RAM (eg: to store FIBs) and
this might affect the economics of RAM provisioned for buffer space --
but this should change with time.

The talk about small delays/queues in buffers will change once the economics of
broadband access improve and ISPs can no longer pursue an
overprovisioning strategy where core bandwidth >> sum of average access
traffic. Jim Roberts (france telecom) mentioned to me that the economics
of overprovisioning are already changing because of the financial
pressures to consolidate. I would defer it to real operators to confirm or
deny either of these positions...

-Shiv
===
Shivkumar Kalyanaraman
Associate Professor, Dept of ECSE, Rensselaer Polytechnic Institute (RPI)
WWW: http://www.ecse.rpi.edu/Homepages/shivkuma


On Mon, 9 Jun 2003, Injong Rhee wrote:

>
> I came to know this work recently too.  I suspect that the high performance
> migth be due to a large buffer space some place on DropTail router network.
> In the droptail router with buffer space K, the congestion window drops down
> to (B*D + T)/2. If T is as much as B*D, then TCP drops its window down to
> B*D which is the capacity of the link. If RED is used, the result will be
> quite different, i believe because packet drop will happen well before the
> buffer fills up. Also DropTail with a large buffer adds a lot of congestion
> delays.
>
>  Could somebody confirm the amount of router buffer space at the bottleneck
> of this path and whether RED is being used? whether the buffer space is
> pooled or dedicated to a port? At some point, Tom Kelly reported a very
> little buffer space. But that could have been changed.
>
> -----Original Message-----
> From: end2end-interest-admin at postel.org
> [mailto:end2end-interest-admin at postel.org]On Behalf Of Richard Carlson
> Sent: Monday, June 09, 2003 11:04 AM
> To: end2end-interest at postel.org
> Subject: Re: [e2e] TCP un-friendly congestion control
>
>
> As chair of the Internet 2 Land Speed Record judging committee, I can
> confirm that TCP over long fat networks is not hopeless.  The last 2
> records, using IPv4 and IPv6, show that hosts can push the network to the
> limit.  For the latest IPv4 record a team from the US and Europe ran Iperf
> for 3700 seconds (yes just over 1 hour) between 2 PC's with 10 Gigabit
> Ethernet NICs.  They achieved a throughput rate of 2.3 Gbps, with the
> connection being limited by a transatlantic OC-48 link.  The latest IPv6
> record is being processed now, but it is equally impressive.  See the
> I2-LSR web page http://lsr.internet2.net for details.
>
> Another thing to consider, Les Cottrell from SLAC ran some tests with these
> 10 Gig NICs and tested the standard Linux 2.4 TCP, FAST TCP, HPTCP, and one
> other high performance implementation.  These tests showed no difference
> between any of the TCP implementations over 1 particular network path.  If
> Les is on this list maybe he can provide a pointer to these results.
>
> Rich
>
> At 05:26 PM 6/6/03 -0400, Craig Partridge wrote:
>
> >In message <20030606140028.A59651 at xorpc.icir.org>, Luigi Rizzo writes:
> >
> > >exactly -- that's the whole point, the packet rate is so high that
> > >there are many chances to have occasional losses anywhere in the
> > >system, not just due to the channel but even because of operating
> > >system issues on some of the intermediate boxes or end nodes.
> >
> >OK, let me get on my high horse here for a moment.
> >
> >The original poster asserted that in an environment where the network
> >went at 1 Gbps and had 50ms of delay, TCP was hopeless.
> >
> >The point I was trying to drive home is that it is not hopeless.  That
> >you have to define the environment far more carefully before you assert
> >that TCP can or cannot do the job.  One of my frustrations these days is
> >people who fail to be careful.  I was trying to encourage care in the
> >problem statement.
> >
> >Thanks!
> >
> >Craig
>
> ------------------------------------
>
> Richard A. Carlson                              e-mail: RACarlson at anl.gov
> Network Research Section                        phone:  (630) 252-7289
> Argonne National Laboratory                     fax:    (630) 252-4021
> 9700 Cass Ave. S.
> Argonne,  IL 60439
>
>
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.488 / Virus Database: 287 - Release Date: 6/5/2003
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.488 / Virus Database: 287 - Release Date: 6/5/2003
>