I will respond with the voice of Jack Haverty, longtime and intrepid Internet
Engineer. If you really need to open n simultaneous connections, each with full
complement of windows, buffers and whatnot, then we must provide sufficient
buffering at all transit points for the aggregate of all such connections, even
if only infrequently used. However, a little care in the engineering of the
client software can result in major savings in total system cost. The multiple-
connection scenario I reported yesterday persisted for most of the day, from
which I infer either an unlikely multiplicity of users patiently waiting for
many messages to barge through the swamps or the existance of multiple mailer
daemons. The former are obviously patience-limited, so I don't worry overmuch
about them; however, I do worry about the latter.
Jack, who is usually more conservative than I, might toss off the following on
an envelope while waiting for an airplane. The two 2048-octet windows on one
machine and three 4096-octet windows on the other require up to 16K for
buffering on transit systems. If comfortably tucked in 576-octet packets (536
data octets), something like 30 packets could be wandering around our gateway.
A conservative might also observe from my observations that multiple ACKs are
sometimes returned from the destination that an additional number (we'll call
it 30) might be soaked up for traffic toward the source. However, those packets
have to live in real buffer space, which with most hardware and software require
a contiguous region of at least the MTU for the net, in the Ethernet case 1500
octets. Thus, our underpowered fuzzthing would have to cough up 60 1500-octet
buffers, or 90K of memory just for those two hosts. See RFC-970 for an even
less palatable scenario. The little dears only have about a fifth of that in
the present configuration, from which Jack would conclude we should either
pull the plug or convert to X.25.
While Jack and I do kid each other mercilessly, you have to admit he has a point.
The Internet Engineer cum Protocol Cop is seldom seen in these parts.
This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:35:40 GMT