[ih] OSI and alternate reality
Steve Crocker
steve at shinkuro.com
Fri Mar 15 12:45:17 PDT 2024
When we were designing the first suite of protocols for the Arpanet, I
worried a LOT about the number of round trips. It wasn't a cost issue; it
was a matter of responsiveness. I thought it important to be able to get a
connection started quickly.
Steve
On Fri, Mar 15, 2024 at 11:59 AM the keyboard of geoff goodfellow via
Internet-history <internet-history at elists.isoc.org> wrote:
> The Other Side of The Coin of the Internet not charging (by the ARPANET
> "WAN model") of packet data sent (or transited between WAN's) was that
> there was No Impetus on/for efficiency in:
>
> #1.) minimizing the amount of info/data sent across the network
> -or-
> #2.) the number of packets (handshakes) to effectuate a "transaction"
>
> for the sake of an e.g. SMTP necessitates ~13 back-and-forth interactions
> to transact the sending of an email from either a UA or MTA to another MTA.
>
> in a "thin pipe" RF environment where efficiency of spectrum (and cost!) is
> paramount not only is every BIT precious/sacred but also is the
> minimization/seizure of the spectrum "sacred"
>
> in the case of implementing RadioMail (the first two-way wireless email
> service on the ARDIS Single Frequency Reuse (SFR) MDC-4800 4.8 kbps
> wireless network with its max packet length of 256 bytes [
> https://www.sigidwiki.com/wiki/MDC-4800] (as well as on the Ericsson
> Mobitex wireless network of RAM Mobile Data at 8000 bit/s,) we developed
> the RadioMail Transport Protocol (RMTP) that not only sent/received email
> over-the-air in 1 packet "transaction" (if everything fit) but also
> "denuded" a transited email into being as "small" as possible -- for
> example rather than sending Date: xxx, From: yyy at host.com, Subject: foo,
> etc it became ^Dxxx^Fyyy at host.com^Sfoo and was "reconstituted" on the
> other
> end so as to minimize bits transmitted over the air.
>
> yours truly often thinks of how might our Dearly Beloved Internet (and the
> APRANET before it) protocols summarily evolved differently if there was
> such an emphasis put on efficiency/"bit miserliness" as well as making them
> be as less "chatty" (back-and-forths) as possible?
>
> the solution always seemed to be MORE BANDWIDTH (i.e. a fatter pipe) rather
> than from the get go making the protocols themselves be as bit (not byte!)
> miserly as possible.
>
> it seems that today we are reaching/now at a point where even with
> essentially "unlimited" bandwidth The Solution to "congestion" or the
> "cause" of degradation why things aren't "working" is/has been causing
> folks (say like Dave Taht and the bufferbloat.net fq_codel, cake
> & LibreQoS team) to be more "recognized"/"respected" for their efforts in
> making The Internet a better place/more efficient/usable for all.
>
> geoff
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
>
More information about the Internet-history
mailing list