Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!sdd.hp.com!caen!uwm.edu!linac!att!bu.edu!m2c!seqp4!jdarcy
From: jdarcy@seqp4.ORG (Jeffrey d'Arcy)
Newsgroups: comp.unix.admin
Subject: Re: IRC Net Bandwidth (was IRC and Security)
Message-ID: <704@seqp4.UUCP>
Date: 22 Mar 91 16:29:35 GMT
References: <703@seqp4.UUCP> <16929:Mar2121:19:0091@kramden.acf.nyu.edu>
Reply-To: jdarcy@seqp4.UUCP (Jeffrey d'Arcy)
Organization: Sequoia Systems Inc., Marlboro, Mass
Lines: 44

brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>Rather than making up statistics, why don't you measure what actually
>goes on? The cost per byte is very small compared to the fixed cost per
>packet.

When he wasn't quoting parts of my previous article out of context, Chris Torek
pointed out what I (and probably most people here) already knew: the routers
used by NSFnet have pretty poor performance.  Let's see just how poor they'd
have to be for your original statement (that a 2-byte packet consumes nearly
the same resources as a 500-byte packet) to be true.

If I recall, T1 speed is 1.44 Mb/s, or 180 KB/s.  That means a single byte
takes ~5.5 microseconds to be transmitted.  Therefore, the difference in
transmission time between a 2-byte packet and a 500-byte packet is ~2.8ms.
The per-packet processing time would have to be greater than this in order
to be considered more significant than the transmission time.  Since the
reciprocal of the per-packet processing time is the packets-per-second rate,
the router would have to be limited to a sustained rate of <360pps for your
first statement to be true of routers attached to T1 links.  Arguments about
queuing delay do not apply since we're dealing with *sustained* packet rates
and therefore constant queue lengths.  Also, the break-even packet rate will
be much lower for slower links such as the near-ubiquitous 56Kb.

So, is anyone going to tell me that the NSFnet routers are unable to route
360pps?  I don't think so.  To debunk your specious little argument even
further, you're attempting to compare the *transmission* cost per byte to
the *routing* cost per packet, which is not what I was talking about.  What's
relevant here is the transmission cost *per packet* compared to the routing
cost per packet.  This relationship *will* vary according to packet size,
and for large packets the the routing cost is the lesser of the two.

Since you obviously need help finding valid arguments, I'll give you one for
free.  In the second paragraph above I failed to mention that the routing
delay *for all routers on a path* (not for a single router) would need to be
>2.8ms to be the governing factor.  Thus, on a 10-hop path the routing delay
on *each* router would have to be only 0.28ms, and the native packet rate
would have to be 3600pps.  Also, queuing delay does become a factor now since
the router interfaces are probably not all the same speed.  Nonetheless, I
think your statement as regards IRC is far from proven, especially since (a)
adjacent IRC servers are typically only a few IP hops apart, and (b) it's not
IRC's fault that the Internet has to deal with many unnecessarily small packets
generated by applications (or systems) that don't coalesce packets properly.

Chris, do you know if the NSFnet routers can handle 3600pps in loopback?