nelson@sun.soe.clarkson.edu (Russ Nelson) (03/25/88)
What's going on with the SLIP working group that started up at the last interoperability conference? Has anyone come up with anything better than Russ Hobby's ASLIP? Can we get a status report from someone?
n2dsy@hou2d.UUCP (G.BEATTIE) (03/29/88)
Summary: Alternatives to ASLIP, SLIP, KISS, et al...
let add in some reliability and universality to solving the problem.
References: <625@sun.soe.clarkson.edu>
I remember seeing some articles here on the net regarding the
use of these somewhat homegrown solutions to the problem of
packet data transmission (your choice of protocol suite) over
an asynchronous link. As part of the work that our non-profit
Amateur Radio group (the Radio Amateur Telecommunications Society)
is doing on OSI protocols we have developed a package for
transmitting generic HDLC frames over an asynchronous interface.
This package is based on the Asynchronous Framing Technique
that was published by Toby Nixon from D. C. Hayes. This
proposal has been well received in various ISO workgroups and
basically offers a couple of reasonable variations.
The first is basic framing, transparency, and error checking.
This mode uses two characters for special purposes. The
framing character (7EH) and the escape character (7DH) are
all that require special handling. In the normal data flow
you prefix a 5EH (corresponding to a 7EH) or a 5DH
(corresponding to a 7DH) with a 7DH. The appearance of a 7EH
uniquely signals a frame start or end. This mode also
contains a feature not found in SLIP (and I believe ASLIP):
ERROR CHECKING. There is a check calculation (I forget what
type) on every frame.
The second mode adds the X-ON and X-OFF characters to the list
of characters transmitted transparently.
The third adds in most control characters.
There are several other options like 7-bit character
transparency and packet forwarding characters which can be
added AFTER the flag to force the packet to be forwarded.
In any case, our software was written by John Howell, N2FVN
and includes source code, source for some MS-DOS drivers and
test programmes, binaries for everything for MS-DOS and a lot
of GOOD documentation.
I will post this code to the net in a few days. It will be
posted in the same sequence as the RATS Open Systems
Environment (ROSE, formerly COSI) software to the
comp.sources.misc and comp.sources.ibmpc newsgroups.
I will also post an announcement here for those who need to
be signalled to the availability of the software.
Thanks,
J. Gordon Beattie, Jr.
E-mail: ihnp4!hou2d!n2dsy (Unix) n2dsy@kd6th.a3100201.ampr
Telephone: 201-615-4168 (Office) 201-615-4669 (Office FAX)
Telephone: 201-387-8896 (Home)ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins) (03/30/88)
I have a couple of RFC's partially completed. One RFC deals specifically with the framing protocol on async serial lines, called the "Asynchronous Framing Protocol (AFP)". It is basically the same as Rick Adams' defacto standard but includes a type field, a 16-bit crc, and a strong suggestion to transmit an extra FRAME_END character at the beginning of a non-back-to-back packet. Another RFC defines the "Point-to-Point Protocol (PPP)" which allows option negotiations over point-to-point links. It is written in the telnet spirit and allows future extensions to be easily incorporated. Other RFC's will handle IP address negotiation (via a PPP option) as well as some simple compression schemes. I'm currently implementing PPP on 4.3 in order to find problems before they're cast in stone. I should be finished real soon now. Drew
rick@SEISMO.CSS.GOV (Rick Adams) (03/30/88)
I still maintain that in the real world, there is no need for a checksum with packet transmission. IP and TCP do it fine. This is based on 4 years experience with 8 "real world" SLIP installations including leased lines from Washington, DC to Amsterdam, San Diego, Albany, and a few "local" sites < 50 miles away. Current modem technology is such that the connection is already virtually error free. The same can be said of dialup modems if you don't buy the cheapest junk you can get. (I.e. if you're cheap buy something with MNP error correction. If you want something to work great, spend the $1000 on a Trailblazer.) The biggest virtue of "my" SLIP is that it is so trivial to implement. A big part of that reason is that it makes TCP/IP do the retransmission & error detection. Complicated protocols won't catch on no matter how nice they look on paper. (E.g. a previous RFC on Async protocols for serial lines that was never implemented (or at least widely implemented.) Does anyone REALLY have proof that it is necessary to complicate the protocol? Or is it just an obsession with what is theoretically required. Often practical engineering confounds theoretical science. --rick
ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins) (03/30/88)
> I still maintain that in the real world, there is no need for > a checksum with packet transmission. IP and TCP do it fine. > Does anyone REALLY have proof that it is necessary to complicate the> > protocol? The unfortunate proof is in UDP. Adding a CRC (not a checksum!) is a necessary result of some vendors (read SUN) reluctance to use checksums. The UDP spec unfortunately allows this. Although most people disagree with this decision (not to checksum UDP), we decided to add the CRC to SLIP so that you have a lower chance of getting burned if you are following the spec. Calculating and sending the CRC really isn't a big deal. Depending on the implementation, the CRC calculation can be done incrementally with each character received thereby amortizing the cost over each character. Combined with table driven crc calculations, the cost is very low. It can also be argued that the time to send the crc is not a big deal if you use even crude compression schemes. I intend to document simple header compression schemes (similar to Noel's scheme) and probably some simple forms of run-length encoding for the data. > The biggest virtue of "my" SLIP is that it is so trivial to implement. > A big part of that reason is that it makes TCP/IP do the > retransmission & error detection. We are not making SLIP non-trivial. We are still counting of TCP/IP to do the retransmissions (error correction). We are only making it do error detection which is *much* simpler. It is not going to be anything like TCP or LAPB as was suggested by previous RFC's. Drew
rick@SEISMO.CSS.GOV (Rick Adams) (03/30/88)
Again, you haven't said that the actual line is bad enough that you have to worry about it. You've said that you think you need another checksum because some vendors stupidly doesn't use it. Do you have actual data showing the CRC16 is needed? Is so (or if not), why is a CRC16 strong enough and a "better checksum" not needed. No "feelings" or "guesses" need apply. Turning off the UDP checksums for performance reasons is VULGAR. It's really an admission that your vendor's engineering is either incapable or unwilling to fix the fundamental problem. (Besides, if you are running NFS over a 9.6 kbps line, the overhead of the UDP checksums is the least of your performance concerns.) Claiming that a low level protocol is broken because you are using lobotomized higher lever protocols is no solution. Fix the problem! Don't kludge around it! ---rick
Mills@UDEL.EDU (03/31/88)
Rick, I second your motion. I've been running fuzzballs with raw IP over everything from noisy leased lines to transcontinental dial-up circuits since 1978 with no problems. I ran my home fuzzball over a 1200-bps 15-mile dial-up circuit for five years and then a 4800-bps leased circuit for four years in raw IP. Those instances when the 24-hour dial-up circuit would drop, maybe once every month or so, plus the number of packets dropped due congestion, timeout and similar causes, easily outnumbered the number dropped due checksum errors. Yes, there is some chance that a few error bits did survive somewhere in the many megabytes of data transferred over that nine-year period, but I strongly suspect most of them were due to causes other than checksum errors. Having said that, I still would not recommend running raw IP between heavy- hitting nodes like backbone switches or gateways. The NSFNET Backbone fuzzies use DDCMP links with CRC checking and they do find significant numbers of errors sometimes on marginal trunks. I would be a little uneasy if the IP and/or TCP checksums were the only protection. However, I am completely comfortable without CRC protection on single-user PCs and workstations and would be even more comfortable if the drat Backfuzz links did NOT use retransmission (DDCMP interface retransmissions are done in hardware and cannot be disabled). Dave
bzs@BU-CS.BU.EDU (Barry Shein) (03/31/88)
>The unfortunate proof is in UDP. Adding a CRC (not a checksum!) is a necessary >result of some vendors (read SUN) reluctance to use checksums. The UDP spec >unfortunately allows this. Although most people disagree with this decision >(not to checksum UDP), we decided to add the CRC to SLIP so that you have a >lower chance of getting burned if you are following the spec. I've always thought that the optional checksum in UDP was a feature, if I choose not to use the UDP checksum I may have some good reasons (eg. I might be sending an ECC with each packet to avoid retransmission on every error.) This defeats this and would force someone to, well, even sending IP won't help, they'd have to re-write the SLIP, bother. It's straightforward to turn on UDP checksumming on a Sun, at worst you can fault them for not making it easier: % adb -w -k /vmunix /dev/mem udpcksum?W 1 $q % That could be put into a command script trivially enough. I think putting a CRC into SLIP is a rather odd way to disagree with Sun's design decision (which might still be wrong, that's irrelevant is my point.) Add that to Rick's experiences that IP and TCP seem to do the job well enough at that level, that UDP checksumming is trivial to turn on in Unix and the fact that modems which will do end to end checksumming are so common and inexpensive and we have an odd situation, let's calculate a checksum 3 or 4 times as we route all data? Seems like over-engineering, at least until someone can come up with better reasoning than doing it because the user may have turned it (left it) off at a higher layer. The user may have *wanted* it off. I'll anticipate the argument that the system admin who manages the file server may have turned it off and is out of the user's control. How is this putative user getting SLIP supported and NFS connections allowed if they have no influence with the sysadmin? Is the protocol spec the correct place to try to workaround bad personal relationships between users' and their sysadmins? &c. Of course, the real issue of simplicity of implementation has to be factored in also, as Rick points out, in the end that's a critical decision point. -Barry Shein, Boston University
jonab@CAM.UNISYS.COM (Jonathan P. Biggar) (03/31/88)
Why don't we make the new versions of SLIP upwards compatible? Add a negotiation feature to SLIP that will be ignored by the current implementations (such as a packet shorter that the minimum IP header size), and then negotiate the use of such things as checksum, CRC, header compression, etc. Everything can just default to the current SLIP usage. Jon Biggar jonab@cam.unisys.com
karn@thumper.bellcore.com (Phil R. Karn) (03/31/88)
The framing technique you describe is EXACTLY the same as SLIP, with one important difference -- the specific values of the "escape" and "frame end" characters are different. Why? Is gratuitous incompatibility with de-facto standards a prerequisite for ISO approval? I distinguish between the framing technique used by SLIP and the format of the information carried in a frame. There's nothing about SLIP framing that says you can't add a link-level CRC or checksum if you wish. It just hasn't been necessary, as there are already checksums at the IP and TCP layers. The error rate of a typical dialup link (if it works at all) is low enough that the extra software processing required to recompute a checksum over an entire packet at each hop is hard to justify. I keep a nailed-up 9600 bps V.32 modem link between work and home. In the 6 days since it was last rebooted, my machine at home has received 13,186 packets over the serial link. Of these, however, only 6 had IP header checksum errors and 8 contained TCP header checksum errors. I have also used SLIP heavily elsewhere, but I have NEVER seen a file corrupted by the failure of the TCP checksum to catch an error. The propensity of the ISORMites to reinvent the wheel (with seemingly deliberately incompatible lug-nut threads) never ceases to amaze me. Considering the popularity of SLIP, your time would be much better spent making incremental, desirable improvements (e.g., logins and passwords for switched environments) instead of devising totally new and gratuitously different protocols to do what is already being done. Phil
rick@SEISMO.CSS.GOV (Rick Adams) (03/31/88)
If you are going to add multiple protocol support to SLIP, please do it in the following manner. The first byte following a FRAME_END is the protocol type byte. If the byte is 0x40 - 0x4F the packet is considered to be an IP packet and the protocol type byte IS INCLUDED as part of the packet. (Astute observers will realize that this is an IP Version Number of 4 combined with all of the possible IP header lengths.) Otherwise, the protocol type byte selects a protocol family from the following table (stolen from socket.h on 4.3BSD) and the protocol type byte IS NOT INCLUDED as part of the packet. This will allow "old" SLIP implementations to talk to your new system without modification. It also provides all of the functionality you might need. If you feel that you MUST have error detection, error correction, header compression, or even encryption, please define a new address family number and add it to the table. That way those who feel it is not necessary will not be burdend with it and everyone is happy. It should be very easy to implement. I'd do it, but I have no need for multiple protocols. ---rick /* * Address families. */ #define AF_UNSPEC 0 /* unspecified */ #define AF_UNIX 1 /* local to host (pipes, portals) */ #define AF_INET 2 /* internetwork: UDP, TCP, etc. */ #define AF_IMPLINK 3 /* arpanet imp addresses */ #define AF_PUP 4 /* pup protocols: e.g. BSP */ #define AF_CHAOS 5 /* mit CHAOS protocols */ #define AF_NS 6 /* XEROX NS protocols */ #define AF_NBS 7 /* nbs protocols */ #define AF_ECMA 8 /* european computer manufacturers */ #define AF_DATAKIT 9 /* datakit protocols */ #define AF_CCITT 10 /* CCITT protocols, X.25 etc */ #define AF_SNA 11 /* IBM SNA */ #define AF_DECnet 12 /* DECnet */ #define AF_DLI 13 /* Direct data link interface */ #define AF_LAT 14 /* LAT */ #define AF_HYLINK 15 /* NSC Hyperchannel */ #define AF_APPLETALK 16 /* Apple Talk */
steve@cs.umd.EDU (Steven D. Miller) (03/31/88)
As of the last time I looked (SunOS 3.2), you can't turn UDP checksums on for NFS packets. A code path that is completely separate from the "normal" UDP and IP output code paths is being taken. Has this changed since 3.2 came out? How many NFS licensees are also not using checksums here? I still agree with Rick, though; why stuff additional checksumming into SLIP because of one vendor's code? NFS at SLIP speeds is likely to be too painful to contemplate seriously, anyway. Maybe Sun could add a "cksum" mount option if they're still reluctant to run with checksums on UDP/RPC/NFS packets in general? I fear I'm getting off the subject, though... -Steve
DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer) (03/31/88)
Date: Wed, 30 Mar 88 17:59:24 EST
From: rick@seismo.CSS.GOV (Rick Adams)
If the byte is 0x40 - 0x4F the packet is considered to be an IP packet
and the protocol type byte IS INCLUDED as part of the packet.
(Astute observers will realize that this is an IP Version Number of 4
combined with all of the possible IP header lengths.)
Modular programmers and people who program generically will realize this
is a Rube Goldberg mentality and will barf.louie@TRANTOR.UMD.EDU ("Louis A. Mamakos") (03/31/88)
Just to add fuel to the fire.. The NFS implementation under Ultrix (DEC's UNIX product) does in fact use UDP checksums. Works just fine. The intent of the CRC on the SLIP frame wasn't exclusively to support SUN NFS, although it was a large motivating factor. Once we thought about it, it seemed to be a good idea to be able to drop a frame which has been trashed in transit. This way you wouldn't be forwarding a broken frame across multiple (probably slow) SLIP links. There was no intention of having SLIP retransmit or attempt to recover broken frames. louie
bzs@BU-CS.BU.EDU (Barry Shein) (04/01/88)
Hm, perhaps I was wrong about modifying udpcksum enabling it for NFS. As far as NFS over a serial line I tried it one evening over our 9.6Kb Cypress line between BU and UCB. It really wasn't bad, NFS is not a particularly high overhead protocol, the info being exchanged is fairly similar to what gets exchanged in an FTP session (DIR,GET,PUT etc.) Of course this disregards transmission problems which I didn't seem to have that evening, the question was thruput. It's probably an intuitive confusion that because NFS is so useful and neat that it must therefore demand massive bandwidth (or perhaps people are mixing the thought with ND, the diskless protocol?) Doubtless you'd want your binaries local but as a very easy to use "ftp" (eg. snooping around directories, copying stuff, file management) it's really not bad on a relatively slow line in my experience, perhaps a little slower than FTP but being able to use the native OS interface to the remote file system can make it worthwhile. Note that there are various timeout parameters etc that would need to be tuned (can be set on a per mount basis) for smooth performance, but the concept is not nearly as wild as seems to be presented here. -Barry Shein, Boston University
n2dsy@hou2d.UUCP (G.BEATTIE) (04/01/88)
POINT 1
It has been suggested that the differences between SLIP
and AFT are limited to the "gratuitous" alteration of the
transparency and framing characters.
This is hardly the case...the additional features of
AFT are three levels of charater transparency, seven-bit
transparency and prefix and suffix characters outside the
frame to manipulate any intervening devices such as modems,
PADs, etc.
POINT 2
It has been suggested that these extra features are not
prohibited by SLIP.
We agree, they are not. Unfortunately, these additional
features have not been uniformly outlined in SLIP. This
may cause the evolution of several systems using SLIP which
will each have different way of handing the variations of
transparency found in asynchronous environments. AFT DOES
standardize these conditions and I suggest that maybe SLIP
should be altered to handle them too.
POINT 3
It has been suggested that this is a divisive issue wrought
by the ISO folks to further separate the DoD Internet
and OSI commmunities.
On this point I wholehartedly disagree. In fact, the problem
is identical for both groups and should help unite them.
The OSI model is not an issue here, the aysnchronous interface
and transparency through that interface is.
POINT 4
It has been suggested that the number of errors encountered
on an Asynchronous Link is minimal, therefore some error
checking is not required on the link and that error recovery
can be accomplished on an end-to-end basis.
If I was experiencing a low residual error rate, then I would
agree. The fact is I am not. Every dial-up link I have
outside of my local area, but within my LATA is noisy.
If your requirements are less, so be it, but I would like the
have the local loop tend to it's own housekeeping and not
send errored frames on through the network and force end-to-end
recovery.
POINT 5
Anyone want to work on the convergence of these protocols into
a common solution ? Please let me know and we can get
started.
Thanks,
J. Gordon Beattie, Jr.
E-mail: ihnp4!hou2d!n2dsy (Unix) n2dsy@kd6th.a3100201.ampr
Telephone: 201-615-4168 (Office) 201-615-4669 (Office FAX)
Telephone: 201-387-8896 (Home)rick@SEISMO.CSS.GOV (Rick Adams) (04/01/88)
Modular programmers and people who program generically will realize this is a Rube Goldberg mentality and will barf. Modular programers will someday give us the full OSI protocol suite (whenever they finish it). They also don't care about backwards compatibility. (I'd also say that they probably program in PASCAL, but that would be name calling.) "Real" programmers have to solve today's problems today. They try to avoid screwing up existing systems when it is possible. They try to avoid violating layers, but if there is no other way to make it work, they do so. --rick (Formally trained as a modular "computer scientist", but corrupted into a practical "engineer" by working in the real world.)
DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer) (04/01/88)
Date: Thu, 31 Mar 88 12:42:09 EST
From: rick@seismo.CSS.GOV (Rick Adams)
--rick
(Formally trained as a modular "computer scientist", but corrupted into
a practical "engineer" by working in the real world.)
I've also been "corrupted" into being a "practical" engineer too, by the
School of Hard Knocks. What I've found are that quick and dirty
expedient bit-saving hacks (a) last much longer than you expect them to,
and (b) turn into massive, MASSIVE maintenance headaches, especially
when some other bright engineer decides an extension is needed.
If you still disagree, I guess it's a religious argument and we might as
well stop.pritch@tut.cis.ohio-state.edu (Norm Pritchett) (04/01/88)
In article <1016@thumper.bellcore.com> karn@thumper.bellcore.com (Phil R. Karn) writes: >The framing technique you describe is EXACTLY the same as SLIP, with one >important difference -- the specific values of the "escape" and "frame >end" characters are different. Why? Is gratuitous incompatibility with >de-facto standards a prerequisite for ISO approval? For some time I've observed that phenomena and wondered the same thing. Then I attended A DECUS symposium session where DEC's representative to ANSI and ISO touched upon the subject and confirmed it is in fact true. He said the purpose of these committees is to produce a solution that makes technical sense AND places all parties involved at equal DISadvantage, this concept making more sense in a commercial environment. As a possible scenario, suppose a major vendor comes up with a neat solution to something. They development it and afterwords everyone (or if the vendor is big enough, they themselves) think it is great and submit it to a standards committee. Now, the standards committee thinks its great but some of the representatives are concerned because if the committee just puts the big rubber stamp on it then the submitting vendor is way ahead of the game because he already has the product making use of the standard developed or maybe even on the market. That vendor is now has a greater advantage over everyone else and some might consider it unfair. Making little "cosmetic" changes to the standard works towards evening out the work involved for everybody to implement the standard. In place of vendors, the standards organizations of a nation might be substituted in the case where a standard from one of them is being submitted to an internation standards organization. -- Norm Pritchett, The Ohio State University College of Engineering ARPA: pritchett@eng.ohio-state.edu BITNET: TS1703 at OHSTVMA UUCP: cbosgd!tut.cis.ohio-state.edu!pritch
egisin@watmath.waterloo.edu (Eric Gisin) (04/01/88)
In article <1016@thumper.bellcore.com>, karn@thumper.bellcore.com (Phil R. Karn) writes: [] > the IP and TCP layers. The error rate of a typical dialup link (if it > works at all) is low enough that the extra software processing required > to recompute a checksum over an entire packet at each hop is hard to > justify. I keep a nailed-up 9600 bps V.32 modem link between work and > home. In the 6 days since it was last rebooted, my machine at home has > received 13,186 packets over the serial link. Of these, however, only 6 > had IP header checksum errors and 8 contained TCP header checksum The overhead of a asyncronous link level checksum or CRC is very small. On an 8MHz 68000, Fletcher's checksum takes about 3 usec per byte, and CRC-16 takes about 8 usec per byte. This amounts to less than 1% overhead at 9600 baud, which is less than overhead of the asyncronous device driver (much less in the case of dumb asyncronous devices). Both of these are better than the 16 bit ones-complement checksum TCP/IP uses. Your example error rate is 1/1000 (high relative to LAN technologies), and I wouldn't trust only TCP/IP checksum to detect errors.
karn@thumper.bellcore.com (Phil R. Karn) (04/01/88)
> ... it is in fact true. He said the purpose of these committees is to > produce a solution that makes technical sense AND places all parties > involved at equal DISadvantage, this concept making more sense in a > commercial environment.... Thank you. I couldn't have asked for a more damning indictment of the international standards process. Someday, perhaps there'll be a protocol standards organization controlled completely by users. Realizing the importance of the process, they will each invest sufficient time and money so that they can be thoroughly versed with the technical issues. However, anyone associated with a commercial vendor of products controlled by the standards in question would be automatically disqualified from membership. I can dream, can't I? Phil
karn@thumper.bellcore.com (Phil R. Karn) (04/01/88)
Dave, We agree. Error detection and correction on an end-to-end basis is essential for most data applications. Doing it at the link level as well is almost always redundant and can only be justified as a performance enhancement under rare circumstances. If you're running a "heavy" backbone link you've probably already spent the money to run synchronous HDLC framing, since this shaves off 2 bits of overhead per byte sent. In this case I don't really object to simple link error detection (without retransmission) mainly because it comes "for free" in the HDLC chips, not because it's really necessary. But full ARQ protocols like LAPB at the link layer are a waste of bandwidth and cycles. Our ARPANET gateway is probably as active as any. It speaks 1822/HDH/LAPB over a 56kbps line to Columbia. Timers, RRs, keepalive polling at both the HDH and LAPB layers, the whole bit. In the 28+ hours since it was last booted, it received 4.3 million HDLC frames from the IMP. Only 48.7% contained IP datagrams; the rest were overhead frames. (The number of CRC errors on input frames was ZERO). Of the 6.3 million packets sent, a mere 33.3% were IP datagrams. This is silly. The only time LAPB tries to do recovery is when the link has been cut somewhere. It can retransmit all it wants, but it won't get anywhere until I call up AT&T and complain. DDS circuits either work perfectly or not at all. Fortunately, we've got plenty of excess link bandwidth and the CPU in the dedicated Sun gateway has nothing else to do anyway, so all of this is merely amusing and not a real problem. (I can only thank the Deities that we don't have to run X.25!) But as links and switches get faster, even the link overhead in HDH has got to go. Mr. Beattie really ought to read the classic paper by Saltzer, Reed and Clark, "End-to-End Arguments in System Design". Phil
rpw3@amdcad.AMD.COM (Rob Warnock) (04/01/88)
Uh... there is a good reason why you might not be ABLE to turn UDP checksumming
on, and thus would want some sort of (simple) CRC on your SLIP line. There was
a bug in some (all?) 4.2 BSD systems which calculated the UDP checksum wrong
(but consistently, for talking to other 4.2's), and 4.3 fixed it. So 4.3 can
now talk to non-BSD systems which checksum the right way. However, if you still
happen to have some "old" 4.2 systems on your net, and if they happen to be
binary-only systems (i.e., the kernel and/or the net code is supplied by a
3rd-party vendor who may or may not still be in business), you may have to
turn off checksumming to be able to talk UDP to them. (A client of mine has
that problem.) Since UDP checksum "on/off" is a per-host function and not per
"connection" (at least in 4.3), it's hard (without delving into the net code)
to get UDP cheksums on SLIP lines and not on the Ethernet. So a simple CRC
on the SLIP lines might be in order after all...
By the way, computing the standard Ethernet CRC-32 only takes a couple of
XOR's and a table lookup per byte (and the table is only 256 32-bit words).
The C code for the inner loop is:
while (len-- > 0)
sum = (sum >> 8) ^ CRC32_table[ (sum & 0xFF) ^ *cp++ ];
The overhead is thus tolerable on a serial line, even on micros, and there
is no reason not to do it (except compatibility with earlier SLIP's). My own
preference would be to extend the SLIP frame to include a full Ethernet header,
use the standard Ethernet numbers, type field, and CRC-32. (Let's call it SLEN,
for Serial Line EtherNet, to distinguish it from SLIP.)
The advantage of a SLEN is that you get ARP, RARP, XNS, DECnet (*ugh*),
and whatever else, besides IP. And you don't have to worry about lack
of UDP checksums.
(Of course, you now have to apply some clever flow control to Ethernet
broadcast packets... ;-} ;-} )
Note that Xerox already defined a "SLEN" for SDLC links. See "Level 0
Point-to-Point Protocol Spec T33-2.0", XSIPS 018201, January 1982 [~6 pages].
It includes some hooks for managing half-duplex lines (might be helpful for
some modems?) in a low-level "link command", which also provided for controlled
termination of dialup connections. Note that their protocol left off the
Ethernet destination number, but kept the source (for authentication?);
the type field was cut to 4 bits (*ugh*), and the CRC was a modified
CRC-16. Still, it's almost usable as it stands, if we could grab a couple
of types for ARP & IP (or go back to 16 bits?), and change the SDLC framing
to SLIP-like async (and maybe go back to CRC-32?).
Rob Warnock
Systems Architecture Consultant
UUCP: {amdcad,fortune,sun,attmail}!redwood!rpw3
ATTmail: !rpw3
DDD: (415)572-2607
USPS: 627 26th Ave, San Mateo, CA 94403bukys@cs.rochester.edu (Liudvikas Bukys) (04/01/88)
One should either leave SLIP alone (it works as it is), or re-do it altogether, addressing some of the most severe problems while you're at it. For instance, someone at UDEL (Dave Farber & et al) noted that header bytes are mostly predictable, and devised a faster (less wasteful) serial-line protocol for slower lines. If a SLIP working group emerges, *that* is the direction it should take off in. If you're going to have a new protocol, it might as well be better, not just different!
nelson@sun.soe.clarkson.edu (Russ Nelson) (04/01/88)
In article <8803302037.AA02493@PHOEBE.CAM.UNISYS.COM> jonab@CAM.UNISYS.COM (Jonathan P. Biggar) writes: >Why don't we make the new versions of SLIP upwards compatible? ... >Add a negotiation feature to SLIP ... >Everything can just default to the current SLIP usage. That's a good idea. Being that today's April 1, I'll just point out that the negotiation packet(s) could have a checksum, CRC, or go bare. By the way, I wasn't looking to start a public discussion. I thought, since all discussion of SLIP had vanished from tcp-ip, that people were working on it in the background. Obviously this is not the case. As for me, I'm convinced that a CRC is both necessary and sufficient and Efficient. -- -russ AT&T: (315)268-6591 BITNET: NELSON@CLUTX Internet: nelson@clutx.clarkson.edu GEnie: BH01 Compu$erve: 70441,205
budden@tetra.NOSC.MIL (Rex A. Buddenberg) (04/02/88)
In article <9312@tut.cis.ohio-state.edu> pritch@tut.cis.ohio-state.edu (Norm Pritchett) writes: [...] >representative to ANSI and ISO touched upon the subject and confirmed >it is in fact true. He said the purpose of these committees is to >produce a solution that makes technical sense AND places all parties >involved at equal DISadvantage, this concept making more sense in a ^^^ Is this why ISO uses the acronym for Draft International Standard? :-) b
melohn@SUN.COM (Bill Melohn) (04/03/88)
Error detection should be implemented as close to the potential source of the error as possible. In a IP link from my home PC to my workstation, there might be 5 hops, 4 of which are over various LANs and gateways all using CRCs and 1 SLIP on a lossy voice grade phone line with no error detection. With an end-to-end checksum, all of these links are treated equally, and as a result, packets which get mangled on my phone line are passed in mangled form throughout my reliable but heavily loaded internet only to be thrown away at the destination because of a bad checksum. Worse, because this checksum has to be calculated and compared, it uses cycles on the CPUs at both ends. Even worse is that fact that in 4bsd this is a host wide option, so if I have a single SLIP based client of my NFS fileserver and I want him to get checksummed packets, I have to checksum packets for all Ethernet only local users as well, users who are more likely to be concerned with speed and not with data corruption on the Ethernet. It seems to me that the sooner I can detect that a packet has been corrupted, the sooner I should throw it away and initiate a retransmission of the data, minimizing both the end-system CPU and the total network bandwidth spent. CRCs are commonly implemented in hardware on Ethernet, in various syncronous serial chips, and on many modems. Why not in SLIP framing as well? End-to-End checksums certainly have their place, but depending on them alone to catch data errors on a variety of media in a complex internet wastes both net bandwidth and host CPU.
ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins) (04/05/88)
> *Excerpts from: 30-Mar-88 Re: SLIP working group? Rick Adams@seismo.CSS.GO* > *(1929)* > If you are going to add multiple protocol support to SLIP, please do it > in the following manner. > The first byte following a FRAME_END is the protocol type byte. > If the byte is 0x40 - 0x4F the packet is considered to be an IP packet > and the protocol type byte IS INCLUDED as part of the packet. I'd originally planned on doing it exactly that way. Quite a few people I talked to thought that it wasn't worth it so I dropped the idea. Maybe I should take another look at it. There is one small problem with it which makes it slightly restrictive. Just being able to receive old-style packets doesn't make you backward-compatible. You have to transmit them also. To do that you probably need to keep some state about whether or not you have received old-style packets. If the first packet you receive is an old-style packet then set some flag. If later you disconnect or receive a packet with a type field (first byte something other than 0x4x) then reset the flag. However, this assumes that the first host to transmit packets is the old host. What if it is the other way around? What if you send a packet with a type field to a host which doesn't understand them? The receiving end won't understand them and will hopefully drop them on the floor because the IP checksum was not valid (which suggests that type 0 and 0xff should not be used!) or maybe because the IP header is not version 4 (which won't be true in the suggested scheme). However since the packet is dropped, it won't elicit a response which will cause the transmitter to continue transmitting new-style packets unless we add some other hacks like counting transmitted packets and switching modes after N packets if we don't receive any. In the simple case where we are using slip to link pc's and gateways this might not be a problem. The gateways will likely be the first to change (smaller numbers) and the pc's will follow (or maybe not). However we are shooting for wider use of slip than this simple application. Supporting gateway-gateway connections is a definite goal. Comments? Drew
swb@DEVVAX.TN.CORNELL.EDU (Scott Brim) (04/05/88)
Drew, consider version negotiation. The EGP3 crowd worked out a wonderful system for it. I can't remember if it was going to be its own RFC, or if it's included in the EGP3 document (or both). Scott
rminnich@udel.EDU (Ron Minnich) (04/06/88)
In article <8803311257.AA16410@mome.cs.umd.edu> steve@cs.umd.EDU (Steven D. Miller) writes: >As of the last time I looked (SunOS 3.2), you can't turn UDP checksums on >for NFS packets. A code path that is completely separate from the "normal" >UDP and IP output code paths is being taken. Has this changed since 3.2 >came out? How many NFS licensees are also not using checksums here? I got an interesting perspective on this from Sequent. Udel just got a 10-processor Balance system, with NFS. NFS did not come with it, though, as shipments of NFS had been halted. The reason, according to support people at Sequent, is that undetected errors were making their way through their enet hardware, undetected because checksums were turned off on NFS. The fix was to isolate the patterns and tighten up their enet hardware. The fix was hard because it was something like 10 patterns that occurred VERY infrequently. I am told that NFS is shipping again from Sequent, minus errors. We don't have ours yet, though. Going from Mt. Xinu 4.3 to an Ultrix system we can very easily and very repeatably (100%) get errors just compiling files. We haven't had a chance to track it down, but when we compile one of the X-windows files (a small one) the .o file gets trashed. And yes, no UDP checksums. -- ron (rminnich@udel.edu)
glenn@XN.LL.MIT.EDU (Glenn Adams) (04/13/88)
> It's straightforward to turn on UDP checksumming > on a Sun, at worst you can fault them for not making it easier: > % adb -w -k /vmunix /dev/mem > udpcksum?W 1 > $q Perhaps someone has pointed it out already, but Sun's NFS doesn't use the standard udp_output() routine which allows enabling checksums via the udpcksum variable. Instead, they chose to bypass udp_output(), building UDP packets in ku_fastsend() (/sys/rpc/kudp_fastsend.c). This routine has no provision for enabling checksums such as does udp_output(). I rewrote ku_fastsend() for Sun 3.2, but haven't done so for recent Sun releases, primarily because I don't have the more recent sources. I think we should make a lot of noise to Sun to at least code in checksumming similar to udp_output(), giving the system manager the decision to enable or disable checksums. By the way, performance tests which I performed on my modified ku_fastsend(), indicated that the addition of checksumming only resulted in a 2% decrease in performance. I don't believe they (SUN) have actually tried it as they won't provide any data to back up their claim that checksumming is a big performance loss. Personally, I think Sun's decision to exclude checksums is quite unconscionable. Glenn Adams
cpw%sneezy@LANL.GOV (C. Philip Wood) (04/14/88)
Hey, we all know that SUN is just a hardware company. We gotta figure where we can get the source and fix it ourselves. phil wood (cpw@lanl.gov)
smb@ulysses.homer.nj.att.com (Steven Bellovin) (04/15/88)
Has anyone modified the SLIP driver to do ``fair queueuing''? SLIP links are sufficiently slow that a file transfer operation can make remote logins exceedingly unpleasant. A queuer that favored short packets, or perhaps one that did per-hostport queueing, would be helpful. (I know -- what I'm really asking for is type-of-service support, but then I'd have to change all of my applications, and perhaps my TCP/IPs, to request it.) --Steve Bellovin ulysses!smb smb@ulysses.att.com
Mills@UDEL.EDU (04/15/88)
Steve, Yes, if what you mean by "fair queueing" (a term I find mesleading at best) is multiple priority queues in the conventional sense, the fuzzball gateways used on the NSFNET Backbone and at several other spots scattered over the US and Europe do that for all network links, including SLIP. The scheme is based on the Precedence field of the IP header, plus a few naughty tricks based on port number (when the precedence field is zero). Having used the scheme a lot on slow (9600 bps) serial links with SLIP and other link protocols, I can't say you should all go rush out and implement it. As implemented in the fuzzballs, priority scheduling ruthlessly shoves interactive traffic to the head of the queue, even if bulk-transfer (FTP, mail) traffic ends up waiting indefinitely at the end, then timing out. Then, little things like miscellaneous UDP and ICMP (ping) services sometimes stop working. Obviously, fancier service disciplines can be designed which would be more "fair," but the fuzzies have not yet learned those tricks. My point is not to discourage innovation in this area or even to conclude the fuzzball scheme does not work right; on the contrary, most of the time it works like a bandit. However, I do want to point out that the fairness issue is much more complex than you might suspect and deserves careful study in its own right. One of the most fertile experimental breeding swamps may well be hoked-up SLIP drivers for exactly the service you describe. After all, there are hundreds of times more Unix systems out there than fuzzballs. Dave
ralphw@IUS3.IUS.CS.CMU.EDU (Ralph Hyre) (04/19/88)
In article <8804150036.aa13833@Huey.UDEL.EDU> Mills@UDEL.EDU writes: >Steve, > >Yes, if what you mean by "fair queueing" (a term I find mesleading at best) >is multiple priority queues in the conventional sense, the fuzzball gateways ... do that for all network links, including SLIP. The scheme is >based on the Precedence field of the IP header, plus a few naughty tricks >... I can't say you should all go rush out and implement it. >... in the fuzzballs, priority scheduling ruthlessly shoves interactive >traffic to the head of the queue, even if bulk-transfer (FTP, mail) traffic >ends up waiting indefinitely at the end, then timing out. One might imagine something based on 'deadline scheduling', where a 'deadline to transmit', at which point some other layer will presumably retransmit. Theoretically (don't ask me - I can't prove it - I just heard it from an operating systems talk at another institution four years ago.) you can meet all the deadlines by picking the packet with the closest deadline first. [This assumes that all the deadlines can be met -- if they can't then you have a network enginerring problem which is beyond the scope of this message] Still not happy with interactive response? Then fragment those big packets and get the SLIP at the other end to unfragment them! Vendors everywhere will thank you for fully testing conformance of their TCP/IP implementations. -- - Ralph W. Hyre, Jr. Internet: ralphw@ius2.cs.cmu.edu Phone:(412)268-{2847,3275} CMU-{BUGS,DARK} Amateur Packet Radio: N3FGW@W2XO, or c/o W3VC, CMU Radio Club, Pittsburgh, PA
Mills@UDEL.EDU (04/19/88)
Ralph, There are lots of schemes to deal with the unfairness issue I mentioned, the most attractive of which may be based on schedule-to-deadline principles you mention. While fragmentation can be used to reduce latency, you have to be careful how the fragmentation is done. Those implementations I know about transmit all fragments of a gram one after the other, which would defeat the purpose. Fuzzballs (and maybe others I don't know about) requeue the datagram (with updated fragmentation info) after each fragment transmission. This results in a two-tier discipline; FB(n) (FIFO order in each priority queue) for grams less than the MTU and RR (round-robin in each priority queue) otherwise. Yes, the thought has struck me that actual queue priority could be adjusted for each fragment and also elapsed time on the queue. Dave