[ih] The origin of variable length packets

[Noel Chiappa]

    > From: John Day <jeanjour at comcast.net>

    > it also occurred to me that this was not such a big deal and was
    > probably discovered by everyone who went to build one.
    > ...
    > in the fixed length case you have to send more bits than you need and
    > fill out the packet with zeros.
    > Wastes bandwidth ... in those days one saved everyplace you could!
    > ...
    > Not everything that looks like a major insight to the historians was.
    > Much of it was just common sense.
    > Anyone who went to build it would have done the same thing.

Exactly.


    > From: Guy Almes <galmes at tamu.edu>

    > This note invites anyone with experience on the Cambridge ring to chime
    > in.

I'm too lazy to go dig up the papers, but IIRC it had very small 'slots'
(rather like ATM cells,, but even smaller), so the amount of 'breakage' from
unused space at the back of the last slot of a packet was tiny.

In the context of a ring, small fixed-sized slots makes some sense, because
otherwise you have to have either i) a token-based ring (and then you have to
have logic for finding the token, creating a new token when it gets damaged
and/or lost, etc, etc), or ii) a contention ring (and then you have to have
logic for dealing with collisions). Of course, slots also allowed you to have
priorities, and high-priority traffic could be mixed into the middle of
low-priority, reducing channel access queueing delays (not sure if the
Cambridge ring did that). (Further mumblage about clock synchronization, an
issue in token/contention rings, etc, etc left out.)

In short, a high-speed ring is a very specialized environment, and it made
some sense to do things somewhat unusualy. But note that even there, the user
interface allowed for variable-length packets, as the bimodal distribution of
data traffic was by then pretty well understood.

	Noel