Date: Sun, 17 Oct 93 04:30:02 PDT
From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
Errors-To: TCP-Group-Errors@UCSD.Edu
Reply-To: TCP-Group@UCSD.Edu
Precedence: Bulk
Subject: TCP-Group Digest V93 #269
To: tcp-group-digest
TCP-Group Digest Sun, 17 Oct 93 Volume 93 : Issue 269
Today's Topics:
Header Standard
Packet Radio Standards
Packet Standards
TCP broadcast storm
Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
Problems you can't solve otherwise to brian@ucsd.edu.
Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".
We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party. Your mileage may vary. So there.
----------------------------------------------------------------------
Date: Fri, 15 Oct 93 11:55:23 PDT
From: enge@almaden.ibm.com
Subject: Header Standard
To: TCP-GROUP@ucsd.edu
In case anyone wanted it, here is the original header standard! The
'$:' was used later when bids appeared.
Roy, AA4RE
****************************************************************
R:870114/0819p S:870114/1206p AA4RE-1, Gilroy, CA -- 4983/NK6K
R:870113/1606 @:NK6K Redondo Beach, CA #: 4104 O:NK6K F:145.36/.01
Headers - a compromise proposal.
(1/13/87)
Note: These comments are necessarily terse, to make them easier to
forward. This proposal is based on input from VE3GYQ, W3IWI,
NK6K, WB6KAJ, and WB6YMH.
Executive summary.
A standard header format is proposed that permits 1) machine
parsable headers, 2) human readability, 3) extendability
4) standard non-standard information.
Why we need a standard.
There are at least two programs waiting to be written that
require a machine readable header. One is a subroutine for BBSes
that can find the originating BBS and send a service message
back. The other is a FWD.TNC file generator that can determine
paths and connectivity by examining passing headers. There are
more.
There is also a desire on the part of sysops to be able to rapidly
scan a message by eye to look for bad routing, loops, dups, and
delays. This task could be done programatically, but won't be
for some time to come, and will never be performed by simpler
programs on smaller machines.
Why the current standards are not sufficient.
Aside from the Sent and Received times, the R:S: format as
current specified does not provide an easy way to programatically
determine the following pieces of information: Originating User,
message number. These items have been stated as necessary by a
number of BBS sysops.
The /this/that/ standard does not provide enough visual fidelity
to permit the eyeball scan to take place. This is the reason
most often cited for the lack of converts to this standard. The
other shortfall is the lack of ability to add regional
information in a standard way. Some areas or networks want
additional information such as frequencies and grid, areacode,
airport, or other positional identifiers. In a fixed field
format where the item is identified by its location, null fields
would abound when handling several optional special items, e.g.
/call/call/city/state/rtime////freq///stime/.
As of late, there are at least three different versions of the
/that/that/ "standard", one with an area code field, one with a
separate state field, and one without either. This of course
invalidates an otherwise acceptable standard due to its
dependence on field order.
Attributes of an acceptable standard.
Based on the stated wishes of developers, the following are the
requirements of a well-formed header: Each field can be
identified by a program. Some fields are required.
Based on the stated wishes of some Sysops/Users, the requirements
are: the header is eyeball-readable, the individual sysop can
add information to suit his local needs.
Stated more formally:
1. Meet FCC third party requirements (whatever they are)
2. Be compatible with existing software (able to be emitted)
3. Be machine readable (read: easy to parse)
4. Provide all necessary information
5. Provide flexibility for optional information
6. Provide some degree of user friendliness (read: looks nice)
Note: These comments are necessarily terse, to make them easier to
forward. This proposal is based on input from VE3GYQ, W3IWI,
NK6K, WB6KAJ, and WB6YMH.
The proposal.
These requirements are not mutually exclusive. Rather than use
the fixed field/positional style of the /this/that/ standard to
meet the machine readable requirement, a field identifier is
proposed for each field. Note that the R:S: standard is already
close to this. The only thing lost over the /this/that/ format
is some efficiency, more characters are sent. Losses of
efficiency are common when humans are involved.
Proposed header format (for the machine readable camp):
<header line> ::= <header field> [<header field>...]
<header field> ::= <field identifier> <field contents>
<field identifier> ::= <field type> ':'
<field type> ::= any printable ASCII character except ':'
<field contents> ::= a string of printable ASCII characters except ':'
Rules:
1. The ':' character may only be used as the termination
character of a field type specifier
2. The minimum items which should be included in ALL headers are:
a) The callsign of the node relaying the message.
b) The time the message was received.
Items very (very) strongly recommended for all headers:
a) the message number of the relaying node.
b) the callsign of the station originating the message.
c) the location of the node relaying the message.
Optional information:
a) Additional location information
1. Grid squares
2. Area codes
3. longitude/latitude
b) Frequency of operation of node
c) time message was sent by node
d) Network name
e) group name
f) Major maildrop (nearest major node)
Field Identifiers: (Note new field types may be defined as
required)
#: message number
@: Node callsign followed by optional location
A: node ALIAS
F: frequency of operation. If gateway multiple frequencies are
separated by "/"
G: Grid square of node
L: Long/Lat of node
M: Major node callsign (nearest major relaying node, the APR
proposal)
N: Group, node, or network name
O: callsign of originating station
P: Telephone Area code of node
R: Time message was received
S: Time message was sent
While many of the above fields may be deemed of value by
different people the following suggested format is recommended
R:861003/0739z @:W1BBS Packet city, KA #:1234 O:W1ABC
Note if the timezone letter is not included it should be replaced
with a space to preserve field alignment for visual fidelity.
This header line provides the minimum information which is deemed
necessary by large number of SYSOPs, based on current
discussions.
The proposed header format allows much flexibility for the
individual sysop's without compromising the ability of software
to extract the needed information. Following is an example of
different headers which conform to this standard. Visual
fidelity and machine readability is maintained.
R:861003/0701z @:KB3UD, East Bangor, Pa, G:FN20jv
R:861003/0641z @:K3RLI Wilkes-Barre, PA F:145.01/145.05
R:861003/0430 @:N2AYY-1 Glens Falls, NY O:W1ABC
R:861002/2040z @:WA1FHB, Marlow NH #:5432
R:861002/1741z @:WB1DSW O:W1ABC S:861002/2039z
R:861002/1523z @:W9ZRX #:8768
R:861001/1240 @:WB6KAJ
R:861001/1836 @:W6AXM-1 M:WB6KAJ O:W1ABC P:714
Final Notes: The above differs from the current R:S: standard in
that the S: field is missing from the first part. For visual
fidelity to be maintained, all stations must agree to use the
first two fields in that order. Those wishing to send the S:
field may do so later in the header. Dropping the S: from the
required fields is based on the premise that the S: field of a
station can be inferred from the R: field of the next station.
The RLI/MBL format for the minimum required format is:
R:$J/$Kz @:$O location #:$M O:$P
'he "z" is replaced by a space if the BBS uses local time.
------------------------------
Date: Fri, 15 Oct 1993 14:18:17 -0500 (CDT)
From: Steve Sampson <ssampson@sabea-oc.af.mil>
Subject: Packet Radio Standards
To: TCP-Group@ucsd.edu
Hey, there's a good title: PRS-1, -2, etc :-)
Since Net/Rom isn't marketed any longer, maybe the people
involved in the X-1 and X-2 software can produce a The/Net
specification, or at least commission those interested in
it to build the specs from the current source code. Maybe
the BPQ boys can take the same challenge. It would be nice
to have it for historical purposes. I think a lot of the
problems stem from holding any information close to the chest
so others can't get ahead. The/Net, BPQ, and ROSE all suffer
from closed development and mass popularity. The developers
are basically programmers and not very good technical writers.
A technical writer will probably need to approach them and offer
their services.
I say historical purposes because hams certainly don't want to
be locked into these protocols 10 years from now. The connection-
oriented protocols have been interesting experiments, they do work,
but they fail the test of response speed, operation over range, and
provide no solutions to common RF problems (gomers with talkies and
antenna's on top of their refridgerator).
---
Steve N5OWK
------------------------------
Date: Fri, 15 Oct 1993 20:53:29 -0400 (EDT)
From: MIKEBW@ids.net (Mike Bilow)
Subject: Packet Standards
To: wbaggett@nmsu.edu, tcp-group@ucsd.edu
I had an exchange of mail with someone several months ago who was writing
a netrom protocol spec. He was one of the people involved with TheNet,
I believe. I am going to have to hunt through my last couple of months
of Internet mail archives with grep or something, but I will try and find
the fellow's Internet address for you.
You may not appreciate that a big reason the netrom protocol is badly
documented is because it began life as a proprietary scheme embedded in
EPROM chips sold by Software 2000, Inc. It was later "cloned" amidst
much controversy as TheNet in EPROM and also later as a pure protocol
by other implementors. As a result, there are subtle incompatibilities
between various implementations.
-- Mike Bilow, mikebw@ids.net
N1BEE @ WA1PHY.#EMA.MA.USA.NA
------------------------------
Date: Fri, 15 Oct 1993 17:53:38 -0400
From: Glenn Davis <davis@alien.vax.syncrude.com>
Subject: TCP broadcast storm
To: tcp-group@UCSD.EDU
Hello,
I am troubleshooting a particularly devilish network problem. About two
days ago I started seeing very high TCP broadcast traffic on our internal
TCP/IP network. After taking a network sniffer to the problem I discovered
packets like:
13-OCT-1993 02:59:09.76 02-60-8C-A5-4F-BD FF-FF-FF-FF-FF-FF 08-00 len= 46
IP: vers=4 hdrlen= 5 lngwrds, svc:Routine
total len= 40 ID=%X967E frag ofs= 0
TTL= 30 prot= 6 TCP (Transmission Control), cksum=%X3B1E
src=255.255.255.255 dest=255.255.255.255
TCP:port:src=31876 dest=132 seq#=523398 ack#=523398
window=0 len=5 Lwrds,ACK,RST cksum=39AD urgentptr=0
FFFFFFFF 3B1E061E 0000967E 28000045 E..(~......;.... 0000
86FC0700 86FC0700 8400847C FFFFFFFF ....|..... ... . 0010
4646 45434620 0000AD39 00001450 P...9Z.. FCEFF 0020
Approximately 35 network stations (PC's running Netmanage TCP/IP) were
sending out these packets as fast as their network adapters would allow!
What seemed to happen is: each station would see a packet like the one
above, and send out a RST (reset) response (ie this packet not for me).
This would repeat itself ad-nauseum, dragging the network down with all
the broadcast traffic!
Our network is an extended bridged twisted pair/fiber/ethernet covering
about 450 kilometers. We are using a class B address, with no routing.
There are normally 2000 or so systems on the net at any given time. Only
33 PC's became involved in this arguement, the rest of the unix/vaxen just
ignored it (although they were affected by the large ammount of traffic)
The only thing that stopped the beast was to shut down the entire network!
If anyone can give me some insight, I would greatly appreciate it.
Has anyone else seen the likes of this; if so, what was the cause/solution?
Thanks,
Glenn
---
Glenn Davis +1 403 790 4626 / davis@syncrude.com (Work)
Syncrude Canada Ltd +1 403 743 9675 / davis@realtime.ab.ca (Home)
------------------------------
End of TCP-Group Digest V93 #269
******************************
******************************