Tails and Dogs

11 Feb 1986 12:11:39 EST

Feeling that I owe myself one indulgence for not flaming about
the recent rash of unexpanded alien acronyms ("TOP" and [shudder]
"MAP"), I fear I've got to risk taking on Dave Mills (and perhaps
the spirit of Jack Haverty, though I hope and trust not) on what
I take to be a rather pernicious implication: Loath as I am to
be cruel to fuzzballs--not only on cruelty to animals grounds but
also out of respect for their/their person's ability to bite back--
and with some trepidation that I've misconstrued the relevant
cryptomillsisms, if Dave really thinks there should be limitations
imposed on logical constructs ("connections," whether SMTP or other)
to cater to the shortcomings of physical constructs (gateways,
whether fuzzy or other), then he seems to be to be letting the tail
wag the dog.

In the first place, aren't gateways fundamentally supposed to be
"receive and forward" devices? If so, what's the fuss about
consuming their buffers? In the second place, if line speeds
preclude rapid enough forwarding after receipt, isn't this a
"virtual comm subnet" problem of the "congestion control" kind?
If so, why should it be solved by imposing constraints on Hosts
other than through an appropriate, real, called-for for years
congestion control mechanism? In other words, the Hosts should worry
about how many connections they need/want and how much data they
can accept over them, and "the net" (all flavors of gateway and
all flavors of comm subnet) should worry about getting bits from
Host to Host. (And if some Hosts "abuse" the net by demanding
character-at-a-time traffic, let 'em--but charge by the kilo-
packet, not the mega-bit.)

In those thrilling days of yesteryear, Multics caused the TIPs to
crash by sending out full-ALL-field's-worths-of-one-bits in NCP's
flow control mechanism (something about they couldn't afford the
table space, assumed nobody would ever send a full allocation,
wound up clobbering the adjacent field...): I played along then,
in the spirit of "all pioneers together," and made the NCP send
small enough ALLs for them to handle, even though Multics was
perfectly happy to accept however many bits it was--but that was
some 15 years ago! "Great Wheel of Reincarnation" notwithstanding,
can't we solve the problems where the problems are yet?

     cheers, map

P.S. In my longhand draft of this, I was going to take issue with
the notion that 2 or 4 K "octet" windows are too large, but it
seems like gilding the ragweed compared to the more abstract issue
of rendering unto the Hosts that which is the Hosts' and unto the
net that which is the net's. It's not just an issue of whether
SMTP should be barred from using multiple TCP connections, though.
(To the same Host, of course; presumably even the greatest friend
of fuzzies wouldn't argue that we should force mail through "post
office" sorts of things over single connections with small windows
just to ease the strain on the gateways, when many Hosts are involved.)
Windows are and should be, in my humble but dogmatic opinion, Host
artifacts which pertain to Host-Host flow control; employing them
in lieu of a congestion control mechanism at least violates Layering
and at best is a bad hack.

P.P.S. Apologies for any cryptomapisms herein, it's just that even
if I were up to a fully-"tutorial" treatment--which I'm not--it
doesn't seem worthwhile to burden everybody with all those bytes,
however many connections they go over and however small the windows
are thought to have to be.

This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:35:40 GMT