Fast TCP?

Thu Jun 5 06:34:23 UTC 2003

MN> Date: Thu, 5 Jun 2003 08:02:33 +0200
MN> From: Mans Nilsson

MN> So, we need to come up with technolgies that can sustain
MN> multi-gbit (preferably) TCP streams over 50-100 mS RTT
MN> links. And, we've got the OC192 backbones to do it, if TCP
MN> were up to it..

10 Gbps * 100 ms * 2 = 2 Gbit = 1/4 Gbyte

I guess one can run huge windows, insane SACK, eschew anything
resembling slow-start, modify the recovery algorithm, and still
call it TCP as long as it fits in an IP protocol #6 packet.

Of course, in the absence of bw*delay-based autotuning, I suppose
servers should have plenty of mbuf memory. ;-)  Oh, wait, a few
thousand slow-moving TCP streams could nuke a server without
harming the clients, so slow start still is an issue.

Also witness the BGP data/keepalive mechanism.  Messages are sent
at least every <x so often>, and frequently contain data (or at
least a keepalive instead of data).  If ACKs were sent in the
same way, and packet fragments could be passed to the application
layer before all segments were received in order to alleviate
mbuf issues...

UDP, anyone?

Eddy
--
Brotsman & Dreger, Inc. - EverQuick Internet Division
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 (785) 865-5885 Lawrence and [inter]national
Phone: +1 (316) 794-8922 Wichita

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Date: Mon, 21 May 2001 11:23:58 +0000 (GMT)
From: A Trap <blacklist at brics.com>
To: blacklist at brics.com
Subject: Please ignore this portion of my mail signature.

These last few lines are a trap for address-harvesting spambots.
Do NOT send mail to <blacklist at brics.com>, or you are likely to
be blocked.