Subject: Re: 50000 connections and gigabit speeds
From: [email-masked] (Rob Warnock)
To: [email-masked]
Date: Sun, 29 Nov 1992 02:50:30 GMT

[email-masked] says:
+---------------
| > > It is highly unlikely that one would want to run 
| > > 50,000 tcp connections at gigabit speeds (you would need a 
| > > lot of buffer space).                                    
|
| Why not? The gigabit speed would just decrease the network latency time, 
| wouldn't it? Then you could get the same transaction rate on the host with
| fewer networks. The buffer space needed would not go up. I am interested in
| a transaction environment only, not doing 50,000 file transfers at the same
| time.
+---------------

Then you are going to be mightily disappointed in gigabit networks. Except
for some few cases of mongo-gram transactions in low-diameter LANs, you will
not find gigabit networks decreasing latency much. Consider: An 800 mile T3
link (through two routers) is about 25 ms [as reported by [email-masked],
now [email-masked]]. That latency will not lessen (and it probably will even
even go up a bit) if you run over an OC-12 ATM link (622 Mb/s). Unless each
separate "transaction" is *huge* [which creates error & flow control problems],
an increase in link speed beyond double-digit megabits/sec will not buy you
much of anything.

Even in a LAN, increases in link speed give disappointingly small decreases
in latency. Just ask anybody about NFS over Ethernet versus over FDDI...

Gigabits are for blasting files, not transactions [unless you have 50,000
outstanding transactions or something]....

-Rob

-----
Rob Warnock, MS-9U/510		[email-masked]
Silicon Graphics, Inc.		(415)390-1673
2011 N. Shoreline Blvd.
Mountain View, CA  94043

Date: Sat, 28 Nov 92 18:48:52 -0800
From: [email-masked] (Rob Warnock)
To: [email-masked]
Subject: Re: 50000 connections and gigabit speeds
Cc: [email-masked]

[email-masked] says:
+---------------
| > > It is highly unlikely that one would want to run 
| > > 50,000 tcp connections at gigabit speeds (you would need a 
| > > lot of buffer space).                                    
|
| Why not? The gigabit speed would just decrease the network latency time, 
| wouldn't it? Then you could get the same transaction rate on the host with
| fewer networks. The buffer space needed would not go up. I am interested in
| a transaction environment only, not doing 50,000 file transfers at the same
| time.
+---------------

Then you are going to be mightily disappointed in gigabit networks. Except
for some few cases of mongo-gram transactions in low-diameter LANs, you will
not find gigabit networks decreasing latency much. Consider: An 800 mile T3
link (through two routers) is about 25 ms [as reported by [email-masked],
now [email-masked]]. That latency will not lessen (and it probably will even
even go up a bit) if you run over an OC-12 ATM link (622 Mb/s). Unless each
separate "transaction" is *huge* [which creates error & flow control problems],
an increase in link speed beyond double-digit megabits/sec will not buy you
much of anything.

Even in a LAN, increases in link speed give disappointingly small decreases
in latency. Just ask anybody about NFS over Ethernet versus over FDDI...

Gigabits are for blasting files, not transactions [unless you have 50,000
outstanding transactions or something]....

-Rob

-----
Rob Warnock, MS-9U/510		[email-masked]
Silicon Graphics, Inc.		(415)390-1673
2011 N. Shoreline Blvd.
Mountain View, CA  94043

Subject: Re: 50000 connections and gigabit speeds
To: [email-masked]
Date: Mon, 16 Nov 92 8:30:12 CST
From: [email-masked]

> > 
> > It is highly unlikely that one would want to run 
> > 50,000 tcp connections at gigabit speeds (you would need a 
> > lot of buffer space).                                    
> > 
> > Sean W. O'Malley 
> > 
Why not? The gigabit speed would just decrease the network latency time, 
wouldn't it? Then you could get the same transaction rate on the host with
fewer networks. The buffer space needed would not go up. I am interested in
a transaction environment only, not doing 50,000 file transfers at the same
time.

Kurt

Date: Fri, 13 Nov 1992 16:20:05 -0800
From: [email-masked] (Bob Braden)
To: [email-masked], [email-masked]
Subject: Re: PCB's and Timestamps
Cc: [email-masked]

(still processing old mail)

Sean,

This sort of defeats the purpose of the timetamp option (getting
a better estimate of the RTT) doesn't it?

Bob Braden

> From [email-masked] Thu Sep  3 11:49:56 1992
> Date: Thu, 3 Sep 1992 11:49:04 MST
> From: "Sean O'Malley" <[email-masked]>
> To: [email-masked]
> Subject: PCB's and Timestamps
> Cc: [email-masked]
> Content-Length: 1124
> X-Lines: 28
> 
> 
> I was incorrect in my last message:
> 
> > The problem with all of this is that we don't really have a hell
> > of a lot of room in the TCP option field if the SACK option is
> > ever standardized.
> 
> It is highly unlikely that one would want to run 
> 50,000 tcp connections at gigabit speeds (you would need a 
> lot of buffer space). Thus the problems would appear to 
> be orthogonal. 
> 
> Given this you could in fact simply overload the timestamp 
> option to contain a PCB index. Simply open a connection requesting 
> the timestamp option and a zero window scaling factor and use 
> the timestamp field to store a PCB index (or poniter if you 
> are brave). As define the recievier must treat the timestamp 
> as a magic cookie and return it. (It will waste some time 
> agonizing about which timestamp to return which in this 
> case is irrelevent.) The other side of the connection could 
> be using the timestamp for an actual timestamp or could also 
> be using it for a PCB pointer. It would not affect the outcome 
> in either case. Note that this could add signficant processing 
> overhead to very low bandwidth connections.
> 
> Sean W. O'Malley 
> 
>   
> 

Date: Fri, 13 Nov 1992 16:07:28 -0800
From: [email-masked] (Bob Braden)
To: [email-masked], [email-masked]
Subject: Re: eliminate TCP input demuxing
Cc: [email-masked]

> From [email-masked] Thu Sep  3 06:06:54 1992
> From: [email-masked] (Steve Wise)
> To: [email-masked] (William E. Fisher)
> Cc: [email-masked], [email-masked]
> Subject: Re: eliminate TCP input demuxing 
> In-Reply-To: Your message of Wed, 02 Sep 92 18:41:29 PDT.
>              <[email-masked]> 
> Date: Thu, 03 Sep 92 08:08:39 -0600
> Content-Length: 893
> X-Lines: 23
> 
> 
>  
> | One paper that was recnetly published in measuring the PCB lookup overhead was:
> | 
> | 1992 ACM SIGCOMM Conference Proceedings
> | August 17-20, 1992, Baltimore, Maryland
> | 
> | Efficient Demultiplexing of Incoming TCP Packets
> | Paul McKenney and Ken Dove
> | Sequent Computer Systems
> | 
> | The paper covers a number of different algorithms and presents some analytical
> | approximations to describe the behavior of various TCP demultiplexing algorithms
> | when presented with packet traffic resulting from running the TPC/A benchmarks.
> 

I'm just getting around to responding to this, with an historical note
which I cannot resist.  Paul's paper is a bood, thorough, and
competently done analysis, but the conclusion takes me back about 14
years.  Are we always destined to reinvent the same stuff every N
years?

I wrote one of the 6 original experimental TCP's commissioned by DARPA,
starting about 1978, and my implementation used exactly the (standard)
chained hashing algorithm that Paul concludes is best.  It seemed to me
then, and still seems, even without elaborate analysis, that using such
an algorithm is simply good software engineering.  I would expect any
graduate with a CS degree (and I mean *undergraduate*) to do the same.
Doing a linear search for demultiplexing is clearly wrong.

BTW, my TCP was implemented in IBM BAL for the IBM MVT/MVS operating
systems.  What an incredible luxury a good C compiler would have been!

Bob Braden