On 2022-03-21, Scott Dorsey <kludge@panix.com> wrote:
> Few things are as well documented as the FTN. There are miles upon miles
> of Bell operating manuals.
> --scott

Bell Operating Manuals?

with <t10oiv$rln$1@tncsrv09.home.tnetconsulting.net> Grant Taylor wrote:
> On 3/17/22 11:11 AM, Eric Pozharski wrote:

>> Wanabe Sysop (aka a Point, aka FTN-Compatible Sysop) sends netmail to
>> their Boss (aka Sysop) with To set to special AreaFix nick (nicks are
>> arbitrary, routing is concerned with addresses) with a line '%AVAIL'.
>> Then waits.
>> Meanwhile, AreaFix (at the Boss) sends '%AVAIL' requests to
>> AreaFix'es to all its peers. Then waits.
> Okay. It sounds like '%AVAIL' propagates out multiple degrees; 1st
> point to node; 2nd node to nodes.
> How many degrees out does the '%AVAIL' go? Is there a limit? Or is
> it until it floods to all nodes in the FTN in question?

I think no more then one step further -- to NC ('Network Coordinator')
and Hubs (these bear so called "backbone" echos). Also note, FTN is so
robust that private echos of Hubs and NCs slip onto backbone by pure
chance (and are kept there even when those nodes are long gone).

*SKIP*
>> And they must be careful what they pick -- there are echos sources
>> from different networks, regions, and zones (potential to cause fatal
>> drama (potentianlly, international); such drama will be fatal to the
>> Point, because noone gives a fsck about points), unreachable
>> (physically) flea markets, and echos some bosses keep to deal with
>> their points.
> I can see how a point has a potential to cause ... problems by
> requesting something that disrupts the network.

Your interpretation is wrong.

*SKIP*
>> Well, looking how this thread is developing I'll better abstain.
> It seems to me like AreaFix / FileFix automate the process of what I
> consider to be newsgroup subscription management. What's more is that
> it seems like an off system (point) can initiate an automated change
> on a parent (point's upstream node) and maybe even remotes (parent's
> peer node(s)).
> I'm not aware of any automated subscription management on news servers
> / Usenet. In news servers / Usenet, this amounts to an email to the
> peer news master(s) asking them to alter the feed.

"Lipstick on a pig" would be fairer description.

--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom

In article <t1205g$qhs$1@dont-email.me>, Rich <rich@example.invalid> wrote:
>Grant Taylor <gtaylor@tnetconsulting.net> wrote:
>> On 3/17/22 8:50 AM, Dan Cross wrote:
>>> That's irrelevant. You are factually incorrect about the
>>> definition of a store-and-forward protocol.
>>
>> Why don't you share the definition that you're using for store-and-forward.
>>
>> I'm using the following definition for store-and-forward networking:
>> Something receives a message from a sender, stores it for some (possibly
>> indeterminate) amount of time, and then sends it to the next system in
>> the path at some point in the future.
>
>It appears that you two are talking past one another.
>
>Dan is conflating store and forward packet switching with store and
>forward networking and believing that both mean the same thing and then
>arguing that IP is a store-and-forward system (without any qualifiers
>to indicate what subset he is referencing).

I'll ask you to please not put words in my mouth. This
conversation had context that this sort of simplistic reading
ignores.

Grant asserted that IP was _not_ (meaning, _could not be_ a
packet switched protocol because routers tend not to have a
"persistence" layer. Moreover, he insisted, and continues to
insist, that in order to successfully transmit IP datagrams from
one node to another along some path in a network, all links
along the path _must_ be up simultaneously; that is empirically
not true.

My initial comment about IP and store-and-forward was in
response to this comment:

>IP is not a store and forward networking protocol. There is no
>persistent storage for IP. Buffers, which /may/ be used for a very
>short period of time are transient at best.

Persistent storage is NOT a requirement for a store-and-forward
protocol. This is universally accepted. IP was designed for
packet-switched networks, as it states clearly at the top of RFC
791, and which at the time, predominantly used store-and-forward
techniques.

Consider this historical documentary, describing the ARPANET,
and in particular Bob Khan describing using "store-and-forward"
techniques when describing the network topology (at around the
4:10 minute mark):

https://www.youtube.com/watch?v=7tG7LZgOb-U

Before someone says, "that was the ARPANET, not IP" note that
TCP/IP was designed to implement the ARPANET reference model.

See also things like "TCP/IP Illustrated: Volume 1" by Fall
and Stevens, 2nd edition, page 4:

"When packets are received at a packet switch, they
are ordinarily stored in _buffer memory_ or _queue_..."

Thus, store and forward. Similarly, consider this article,
from Nichols and Jacobson:
https://queue.acm.org/detail.cfm?id=2209336

Note this line from the second section, "Attacking Bufferbloat":

"Packet networks require buffers to absorb short-term
arrival rate fluctuations."

Note that I never suggested that there were not alternatives;
things like AQM could imply different techniques, like
cut-through switching, or using TDMA techniques
(https://cseweb.ucsd.edu//~snoeren/papers/opera-nsdi20.pdf),
or even cutting packet techniques
(https://www.usenix.org/system/files/conference/nsdi14/nsdi14-paper-cheng.pdf).

Indeed, this is an active area of research in the HPC and
optical networking communities. But now we're really muddying
the waters between theory and pratice.

Whether IP is _using_ store-and-forward techniques or not
becomes a very difficult question to answer in some sense once
AQM and the like is on the table. However, it was undisputably
designed for packet-switched, store-and-forward networks. To
assert otherwise is laughably inaccurate.

>While some IP switches/routers can operate in a store-and-forward mode
>(whole IP packet is first received into memory before the header is
>analyzed to determine which link to transmit the IP packet, then the
>packet is transmitted (or dropped) depending upon the header analysis)
>this is not a requirement of IP networking.

That is a fair statement, but ignores congestion.

>It is also possible, and
>many very high performance switches/routers do, for the switch/router
>to analyze the headers as they are received off the line, decide where
>to send the packet, and begin transmitting the packet on the outbound
>link while the remainder of it is still being received on the inbound
>link.

You're referring to cut switching, which is very common at layer
two, but this ignores some details: often a router will
encounter contention and must buffer. The alternative is to
drop the datagram on the floor, which is often also acceptable.

This gets muddled very quickly. But this also elides context:
we're talking about communications in a conflict environment.
Those high-end switched and routers are unlikely to be used.

>Dan has conflated an invisible (to IP) implementation detail of
>router/switch hardware with a requirement of the protocol itself (as in
>SMTP protocol which explicitly requires that it operate in a store and
>forward networking mode) and is therefore arguing that IP is "store and
>forward". But IP does not require switches/routers operate in store
>and forward mode. Whether they do, or not, is invisible to, and
>unspecified by, IP.

Again, please don't put words in my mouth. This is ignoring all
context in the discussion, and in particular, is devoid of the
context of the inaccuracies I was commenting on.

>And even those routers/switches that /do/ operate in a store and
>forward like mode for IP, they do not 'store' said packet any longer
>than necessary to make their routing decision. If their header
>analysis indicates they do not know where to forward the packet, they
>drop it and move along. This is the critical distinction that Dan
>appears unaware of that differentates packet store and forward systems
>from what the rest of us term store and forward networking (i.e., SMTP
>like store and forward operation).

I think you are also taking a very narrow view of what "store
and forward" means, and trying to retroactively apply that
universally.

I suppose none of you have ever seen a bounced message after
sending email via SMTP? Or have you never seen cut-through
switching used for SMTP?

- Dan C.

In article <pTWZJ.305583$aT3.27985@fx09.iad>, meff <email@example.com> wrote:
>On 2022-03-21, Scott Dorsey <kludge@panix.com> wrote:
>> Few things are as well documented as the FTN. There are miles upon miles
>> of Bell operating manuals.
>
>Bell Operating Manuals?

Yes, and rooms and rooms full of Bell System Practices manuals.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 3/20/22 8:05 PM, Scott Dorsey wrote:
> Because much of the FTN and pretty much all of UUCP is now carried over IP.

IP != Internet

> All of that legacy physical infrastructure is long gone. It looks like it's
> there from up top because the functionality remains, but when you look under
> the hood you will find that functionality is provided by IP now.

I'll agree that many things are carried over IP now. But I strongly
question the veracity of the public Internet being used for things
inside of private enterprise networks.

--
Grant. . . .
unix || die

On 2022-03-21, Scott Dorsey <kludge@panix.com> wrote:
>>Bell Operating Manuals?
>
> Yes, and rooms and rooms full of Bell System Practices manuals.
> --scott

Are they available on the net anywhere?

In article <t1appb$cui$2@dont-email.me>, meff <email@example.com> wrote:
>On 2022-03-21, Scott Dorsey <kludge@panix.com> wrote:
>>>Bell Operating Manuals?
>>
>> Yes, and rooms and rooms full of Bell System Practices manuals.
>
>Are they available on the net anywhere?

I have no idea. The Phone Cops used to come after anyone who had copies
of the SS7 manuals, way back when. These days I doubt anyone cares.

It's a lot of stuff to scan, though. I think the Telephone Museum in
Seattle has paper copies complete up to at least 1980 or so.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

meff wrote:

> Scott Dorsey wrote:
>
>>> Bell Operating Manuals?
>>
>> Yes, and rooms and rooms full of Bell System Practices manuals.
>
> Are they available on the net anywhere?

Some are ...

<https://google.com/search?q=Bell+System+Practices>