|
|
ARCHIVE: TCP-IP Distribution List - Archives (1988)
DOCUMENT: TCP-IP Distribution List for March 1988 (450 messages, 226039 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1988/03.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.
START OF DOCUMENT
-----------[000000][next][prev][last][first]----------------------------------------------------
Date: 1 Mar 88 02:03:10 GMT
From: JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To: comp.protocols.tcp-ip
Subject: Re: Need help with UNIX tcpOn our emulation of Berkeley sockets (on a DOS PC), select() will indicate that a connection is readable, writeable, and/or has an exception, depending on which conditions were select'ed, if the connection has died. The theory is to cause the caller to do an I/O specific to that connection, whereupon he will get an error. In the process of determining what to do, it was discovered that this behaviour is not consistent across real Unix implementations. What does POSIX say? James VanBokkelen FTP Software Inc.
-----------[000001][next][prev][last][first]---------------------------------------------------- Date: 1 Mar 1988 08:26-EST From: RWATKINS@G.BBN.COM To: tcp-ip@SRI-NIC.ARPA Cc: rwatkins@RCCB.BBN.COM Subject: Ethernet Terminal Servers
Does anyone have handy the phone number of Encore and Cisco ? Is anyone using Bridge CS200's (in particular, hanging printers off of ports) ? Are you loading them via a Bridge Server, a PC Server or a Sun ? Does the Encore and Cisco product allow loading and remote port configuration from a Unix/Ultrix machine ? Does anyone have printers connected to those ? Thank you Ron Watkins BBN 617-873-2817
-----------[000002][next][prev][last][first]---------------------------------------------------- Date: 1 Mar 1988 13:35-PST From: STJOHNS@SRI-NIC.ARPA To: bzs%bu-cs.bu.edu@BU-IT.BU.EDU Cc: wb6rqn!brian@SUN.COM, tcp-ip@SRI-NIC.ARPA Subject: Re: Exchanging serial numbers
From the ENTIRE IETF: "Applause!" Mike
-----------[000003][next][prev][last][first]---------------------------------------------------- Date: 1 Mar 88 11:58:19 GMT From: mf@savax.UUCP (Marc Fleischmann) To: comp.protocols.tcp-ip Subject: Re: FTP vs. VMS & long passwords
In article <8802292102.AA06989@macduff.ultra.com> shj@ultra.UUCP (Steve Jay) writes: > >when attempting to use FTP server on a VAX VMS system, and the password >for the VAX account is over 8 characters long. > >This has been observed with VAX's running Wollongong (versions 3.1 & 4.0) >and Excelan (EXOS Version 4.5) servers. Client FTP on a BSD 4.3 I am running Excelan Release 3.3 V3-3Vv2 which has the server EXOS Version 4.5 Mon Sept 8 8:41:17 PDT 1986 and have no problems with passwords of 16 characters using FTP clients from EXcelan, Ultrix V2.0-1 and Apollo. I am running MicroVMS V4.6. /marc --- -- Marc Fleischmann Sanders Associates, Inc. - Nashua N.H. (603) 885-5050 UUCP: ihnp4!decvax!savax!mf
-----------[000004][next][prev][last][first]---------------------------------------------------- Date: Tue, 01 Mar 88 17:16 EST From: "Mark D. Eggers (219) 239-7258" <CF4A8X%IRISHMVS.BITNET@CUNYVM.CUNY.EDU> To: tcp-ip@sri-nic.arpa Subject: Convergent Technologies
We are installing a campus network based on proNET 80, tcp/ip, and DECnet. One of the first colleges to connect will be the College of Engineering. They have several Convergent Technologies 'miniframe' boxes that run System V Unix and have tcp/ip. According to the grad student in charge of their networks, they have the latest tcp/ip software from Convergent Technologies. Unfortunately, there are problems. 1. The 'miniframes' do not seem to understand any other class B addresses than xxx.yyy.0.zzz. Class C addresses seem to work fine. Class A addresses must be xxx.0.0.yyy. Would someone comment on the feasibility of using xxx.yyy.0.zzz as a subnet ? 2. No subnet support. Engineering currently has two subnets, and the 'miniframes' cannot communicate from net A to net B. 3. No route support (goes with the above). 4. No ARP. Another annoying habit is that ftp between the 'miniframes' and an Ultrix 1.2 microVAX hangs on files larger than 1019 bytes (and yes, I have turned off trailers on the microVAX). Any possible solutions to the above problems (including using the boxes for boat anchors) would be greatly appreciated. /mde/
-----------[000005][next][prev][last][first]---------------------------------------------------- Date: 1 Mar 88 13:26:00 GMT From: RWATKINS@G.BBN.COM To: comp.protocols.tcp-ip Subject: Ethernet Terminal Servers
Does anyone have handy the phone number of Encore and Cisco ? Is anyone using Bridge CS200's (in particular, hanging printers off of ports) ? Are you loading them via a Bridge Server, a PC Server or a Sun ? Does the Encore and Cisco product allow loading and remote port configuration from a Unix/Ultrix machine ? Does anyone have printers connected to those ? Thank you Ron Watkins BBN 617-873-2817
-----------[000006][next][prev][last][first]---------------------------------------------------- Date: 1 Mar 88 15:00:41 GMT From: Mills@UDEL.EDU To: comp.protocols.tcp-ip Subject: Re: Exchanging serial numbers
Brian, With all due respect, this is a terrible idea and is not worth even the effort to determine if other implementations will/will not break if the option is used. The IP Security Option is a much better mechanism and understood by most implementations known to me. If your scheme is less than ubiquitous using this option, the Protocol Police would even be expected to cooperate, since there are a lot of folks who are concerned about the issue. If the option does not satisfy your needs and you have a concrete proposal to add another, ubiquitous option that does, then please honk and I expect the INENG and/or INARC Task Forces will take it seriously. As it is, a copy-protect option that works only at TCP initial- connection time will not be taken seriously. Notwithstanding my view taken here, I would very much like to encourage you to pursue the issue vigorously. In particular, I suggest you take it up with Steve Kent's Privacy Task Force and with Deborah Estrin's Autonomous Networks Task force. I will certainly keep it nearby in the INARC Task Force. Dave
-----------[000007][next][prev][last][first]---------------------------------------------------- Date: 1 Mar 88 16:52:32 GMT From: rossw@nezsupp.icl.co.nz (Ross Wakelin) To: comp.protocols.tcp-ip,comp.dcom.lans Subject: tn3270, what and where
Hi, people here are just starting to mumble about 3278 type terminals, connected to (yeuch) IBM type main(larf larf)frame machines, connected to unix boxes over the ethernet. Apparently there are boxes to convert "channel" to tcp/ip, but this tn3270 thing is needed on the unix box. Can anyone enlighten me please. Thanks in advance, Ross Wakelin Ross Wakelin uucp: uunet!vuwcomp!nezsupp!rossw Unix Support Consultant rossw@nezsupp.icl.co.nz ICL (NZ) Ltd audio: +64 4 724 884 Wellington, NEW ZEALAND snail: PO Box 394 Wellington, NEW ZEALAND "It's life Jim, but not as we know it, not as WE know it!!"
-----------[000008][next][prev][last][first]---------------------------------------------------- Date: 1 Mar 88 17:26:16 GMT From: bhoward@SOL.ENGIN.UMICH.EDU To: comp.protocols.tcp-ip Subject: (none)
Has anyone implimented support for SLIP on SVr3 or other SV variants? Bruce Howard Computer Aided Engineering Network University of Michigan
-----------[000009][next][prev][last][first]---------------------------------------------------- Date: 1 Mar 88 19:00:59 GMT From: shj@ultra.UUCP (Steve Jay) To: comp.protocols.tcp-ip Subject: Answer to FTP vs. long passwords
Thanks to those who responded to my query about long passwords & FTP. It turns out this is a known restriction in pre 4.3 clients, which apparently use the standard C library routine "getpass" to prompt for the password. "getpass" is restricted to 8 characters. FTP was fixed in 4.3, although obviously there are a lot of systems with the problem still out there (latest Ultrix & UTS still have problem.) Bob Bradford of Software Kinetics in Ontario (bradford@skl-crc.arpa) pointed out that the "quote" command in FTP can be used to get around the problem in pre 4.3 systems. Open the connection, then enter "quote user username" and "quote pass password" to the ftp prompt. The only disadvantage is the password is echo'd to the terminal. Thanks again to those who responded. -Steve Steve Jay domain: shj@ultra.com Ultra Network Technologies Internet: ultra!shj@ames.arc.nasa.gov 2140 Bering drive uucp: ...ames!ultra!shj San Jose, CA 95131 408-922-0100
-----------[000010][next][prev][last][first]---------------------------------------------------- Date: 1 Mar 88 19:11:57 GMT From: bzs@BU-CS.BU.EDU (Barry Shein) To: comp.protocols.tcp-ip Subject: Exchanging serial numbers
>The intention behind exchanging serial numbers is very simple: to keep >the software from being useful if it is copied. It protects by >preventing an operator from gaining an advantage from the copy while the >original is still running. In this way it is definitely a form of copy >protection. The intention is to provide a scheme that will help protect >our software in a manner that is totally transparent to the user. >Now I will ask my original question again. Will the appearance of a >strange option in the TCP header cause a problem for other >implementations of TCP? >Brian Lloyd, President >Sirius Systems, Inc. What I don't understand is given as you feel so comfortable with the idea of imposing various copy protection schemes to ensure maximizing profits etc (or your prediction that it will maximize profits, whether it will make your software fundamentally undesireable is argueable) why do you expect free advice to further your profits on this network? To respond in kind, many of us charge good money for consultations to provide the information you desire, I suggest you change your request to a help-wanted ad and put it somewhere appropriate. If it's not worth anything to you it's surely not worth anything to us. Check. Your move. -Barry Shein, Boston University
-----------[000011][next][prev][last][first]---------------------------------------------------- Date: 1 Mar 88 21:35:00 GMT From: STJOHNS@SRI-NIC.ARPA To: comp.protocols.tcp-ip Subject: Re: Exchanging serial numbers
From the ENTIRE IETF: "Applause!" Mike
-----------[000012][next][prev][last][first]---------------------------------------------------- Date: 1 Mar 88 21:48:47 GMT From: jsdy@hadron.UUCP (Joseph S. D. Yao) To: comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.misc,comp.windows.misc Subject: rlogin from windows
On a heterogenous (System V / Ultrix) TCP/IP network, several people
use 'rlogin' from windows, and are surprised when the computer on the
far side believes that they have the full complement of lines and
columns. My suggested solution was to add to the third rlogin
protocol setup line (for which I can find no definition) a third
field, so it would look like:
<$TERM>/<baud-rate>/<lines>x<columns>
Since the System V terminfo uses environment variables $LINES and
$COLUMNS, we could use those on the System V machines; and we'd have
to get the Berkeley machines somehow to modify $TERMCAP based on
$LINES and $COLUMNS.
But, first, I thought I'd turn to the net and see whether anyone else
had any solutions. Has anyone else had to address this problem?
Thanks muchly. Please reply by E-mail, as I am sufficiently swamped
as not to get to these newsgroups very often.
Joe Yao jsdy@hadron.COM (not yet domainised)
hadron!jsdy@{uunet.UU.NET,dtix.ARPA,decuac.DEC.COM}
arinc,att,avatar,blkcat,cos,decuac,dtix,\
ecogong,empire,gong,grebyn,inco,insight, \!hadron!jsdy
kcwc,lepton,netex,netxcom,phw5,rlgvax, /
seismo,sms,smsdpg,sundc,uunet /
-----------[000013][next][prev][last][first]----------------------------------------------------
Date: 1 Mar 88 22:16:00 GMT
From: CF4A8X@IRISHMVS.BITNET ("Mark D. Eggers 239-7258", 219)
To: comp.protocols.tcp-ip
Subject: Convergent TechnologiesWe are installing a campus network based on proNET 80, tcp/ip, and DECnet. One of the first colleges to connect will be the College of Engineering. They have several Convergent Technologies 'miniframe' boxes that run System V Unix and have tcp/ip. According to the grad student in charge of their networks, they have the latest tcp/ip software from Convergent Technologies. Unfortunately, there are problems. 1. The 'miniframes' do not seem to understand any other class B addresses than xxx.yyy.0.zzz. Class C addresses seem to work fine. Class A addresses must be xxx.0.0.yyy. Would someone comment on the feasibility of using xxx.yyy.0.zzz as a subnet ? 2. No subnet support. Engineering currently has two subnets, and the 'miniframes' cannot communicate from net A to net B. 3. No route support (goes with the above). 4. No ARP. Another annoying habit is that ftp between the 'miniframes' and an Ultrix 1.2 microVAX hangs on files larger than 1019 bytes (and yes, I have turned off trailers on the microVAX). Any possible solutions to the above problems (including using the boxes for boat anchors) would be greatly appreciated. /mde/
-----------[000014][next][prev][last][first]----------------------------------------------------
Date: 1 Mar 88 22:45:32 GMT
From: philipp@GMUVAX2.GMU.EDU ("Philip Prindeville")
To: comp.protocols.tcp-ip
Subject: Re: TCP/IP Terminal ServersAll of the support telnet, I take it. Most support rlogin. Do any support supdup also (on a try-sudpup-first-fallback-on-telnet basis)? Thanks, -Philip
-----------[000015][next][prev][last][first]---------------------------------------------------- Date: 1 Mar 88 23:29:03 GMT From: portal!cup.portal.com!rlhowe@uunet.uu.net To: tcp-ip@sri-nic.arpa Subject: Re: FTP vs. VMS & long passwords
In your discussion of long passwords on the VAX you said that you were running EXOS version 4.5. Is this really the case? I ask this because the latest version we have is 3.3. Thank for any info. Roger Howe rlhowe@cup.portal.com
-----------[000016][next][prev][last][first]---------------------------------------------------- Date: 1 Mar 88 23:59:00 GMT From: mogul@DECWRL.DEC.COM (Jeffrey Mogul) To: comp.protocols.tcp-ip Subject: maximum Ethernet throughput
Someone recently asked:
If anyone has figures on maximum through-put of 10 Mbps Ethernet, I could
make good use of them.
The snide answer is "10 Mbit/sec". Actually, the theoretical maximum is
about 9.9 Mbit/sec, because of the inter-packet gap, and perhaps closer
to 9.8 or 9.7 Mbit/sec if you count the addresses and CRC as wasted bits.
That's probably not quite what you wanted to know, but the question as
put does not have a single answer. For example, do you want the
aggregate maximum or the maximum for a single pair of hosts?
For the latter, I believe Bill Nowicki of Sun has obtained 5 Mbit/sec
using TCP between Suns, and the Sprite people at Berkeley have
reached somewhere near 5.6 Mbit/sec using their kernel-to-kernel
RPC. These numbers are both from memory; perhaps someone can confirm
or improve them.
The best numbers that I am aware of, for communications between a pair
of hosts, comes from Dave Boggs. Using a pair of 15 MIPs processors
with an interface and software of his own design, and without much
of an operating system or any protocol (aside from the Ethernet data
link headers), he can get about 7.5 Mbits/sec obeying the Ethernet
spec, or at least 8.6 Mbits/sec if he "cheats" by sending 4Kbyte
packets. (He once got >9 Mbits/sec with even larger packets, but
his current code doesn't support that.)
The limiting factor in his measurements seems to be that his interface
can only send one packet at a time; i.e., he must process one interrupt
per transmitted packet, which takes a few hundred microseconds. The
interface can receive up to 16 packets using only one interrupt. With
a more elaborate interface design, the theoretical limit should be
attainable.
-----------[000017][next][prev][last][first]---------------------------------------------------- Date: Wed, 2 Mar 88 9:04:05 EST From: Alex McKenzie <mckenzie@LABS-N.BBN.COM> To: tcp-ip@SRI-NIC.ARPA Subject: Flames to Brian Lloyd
I'm a little unhappy with the flames being sent to Brian Lloyd. I understood the basic form of his question to be: "If I invent my own option, is it likely to break other implementations? If anyone tells me that even one implementation is sure to break I won't invent my own option." This seems to me like the kind of reasonable and responsible behavior the folks on the tcp-ip list ought to be trying to encourage. It seems to me that we are not likely to encourage it if our response is to make nasty comments about Mr. Lloyd's motives. Mr Lloyd attempted to explain why he was thinking of inventing his own option. Lots of people told him why they thought it was silly, would be hard to implement properly, that there were alternatives, and so on. All those comments seem quite proper, and this message is not trying to suggest otherwise. If he wants to hang his ideas out in public he should expect them to draw critical comments. I think he acknowledged this in his last message. But I don't think its reasonable, or even in the group's own self interest, for us to flame him for asking the question. Cheers, Alex McKenzie
-----------[000018][next][prev][last][first]---------------------------------------------------- Date: 2 Mar 1988 14:25-PST From: STJOHNS@SRI-NIC.ARPA To: terry@DEC-VAX-11-750.ARPA Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: TCP Options/Copy Protect
Terry, Jon Postel has decreed that for both TCP and IP, any additional options will be of the second type... I.e. self encoding the length. Mike
-----------[000019][next][prev][last][first]---------------------------------------------------- Date: Wed, 02 Mar 88 13:33:35 EST From: terry@DEC-VAX-11-750.ARPA To: tcp-ip@sri-nic.arpa Cc: terry@dec-vax-11-750.arpa Subject: Re: TCP Options/Copy Protect
All,
If there is an update to this, feel free to flame me, but please
be gentle.
****----
Brian Lloyd,
Mil-Std-1778, 12-Aug-1983, Page 92:
There are two cases for the format of an option:
a) A single octet of option-kind.
b) An octet of option-kind, an octet of option-length,
and the actual option-data octets.
The option-kind field determines the option being processed. This
option-kind MUST be known, otherwise there is no way to tell whether
the next octet is a new option, or the length of the current option.
Therefore, further option processing cannot occur.
Your Question: Will this upset any TCP implementations?
My Answer: YES
In MY TCP implementation, an unknown option will cause a
message to be placed in a log file along with all of the
remaining bytes in the TCP header. If a valid option, such as
maximum segment size, occurred after the unknown option the
valid option would be ignored. This could be serious.
I would take a guess and say that ALL TCP implementations are probably
not as gracious as mine. Some probably would ignore the packet, others
might curl up and die, or worse.
*****-----
Non-TCP-Related-Topic:
There is a place for copy protection schemes in the world. However,
your scheme only prevents your TCP from talking to itself, not to other
TCP implementations. Besides the problem I stated above, it seems to
me that if you want to copy protect your software, do it right. Don't
do it halfway. There are several methods of controlling software execution
available. Pick One. If your company doesn't have the people to do the
job, hire someone.
****----
Terry Robb
-----------[000020][next][prev][last][first]---------------------------------------------------- Date: Wed, 2 Mar 88 17:53 EDT From: AB Stine <ABSTINE@clvms.clarkson.edu> To: TCP-IP@sri-nic.arpa Subject: re: tcp/ip terminal servers
Here at Clarkson, we've been evaluating a number of TCP/IP terminal servers.
We've had the Bridge CS/100 in for a while, and its worked out rather well.
Haven't had any problems with it at all... it talks to all of our hosts
(BSD4.2,4.3, VMS (under CMU TCP), Gould UTX, Sun/OS, Alliant, PC's).
We are now evaluating a Cisco box. My first impressions of it are good... seems
to work very well... i'm not sure if it can really handle all 32 ports at
high speed though (its only got a 68000... i understand that they now have
a 68020 also). it also does Rlogin, which the bridge does not (yet).
In addition, we tried a Micom Server. We didn't do much with it though...
it was kinda slow, not very configurable. cheap though...
art stine
network engineer
clarkson u
-----------[000021][next][prev][last][first]---------------------------------------------------- Date: 2 Mar 88 14:04:05 GMT From: mckenzie@LABS-N.BBN.COM (Alex McKenzie) To: comp.protocols.tcp-ip Subject: Flames to Brian Lloyd
I'm a little unhappy with the flames being sent to Brian Lloyd. I understood the basic form of his question to be: "If I invent my own option, is it likely to break other implementations? If anyone tells me that even one implementation is sure to break I won't invent my own option." This seems to me like the kind of reasonable and responsible behavior the folks on the tcp-ip list ought to be trying to encourage. It seems to me that we are not likely to encourage it if our response is to make nasty comments about Mr. Lloyd's motives. Mr Lloyd attempted to explain why he was thinking of inventing his own option. Lots of people told him why they thought it was silly, would be hard to implement properly, that there were alternatives, and so on. All those comments seem quite proper, and this message is not trying to suggest otherwise. If he wants to hang his ideas out in public he should expect them to draw critical comments. I think he acknowledged this in his last message. But I don't think its reasonable, or even in the group's own self interest, for us to flame him for asking the question. Cheers, Alex McKenzie
-----------[000022][next][prev][last][first]---------------------------------------------------- Date: 2 Mar 88 15:43:31 GMT From: shore@REASON.PSC.EDU To: comp.protocols.tcp-ip Subject: Re: Convergent Technologies
I never had any problem with class B addresses (128.135.12.x). The arp problem can be fixed by using adb to change the value of "oldmap" to 0x7fffffff. The code assumes that if the address is greater than some value (I forget what) the hardware address can be obtained by glomming together the first few bytes of your own Ethernet address and the last two bytes (in the case of a class B network) of the IP address of the host you're trying to reach. Melinda Shore Pittsburgh Supercomputing Center
-----------[000023][next][prev][last][first]---------------------------------------------------- Date: 2 Mar 88 17:05:29 GMT From: mar@ATHENA.MIT.EDU To: comp.protocols.tcp-ip Subject: rsh equivalent
I can't promise RFC conformance, but there is a way to make the Berkeley r programs secure, and at least this change is documented. I'm talking about the Kerberos authentication service. It was developed at MIT by Cliff Neuman, Jeff Schiller, and Jenifer Steiner among others, and is a trusted third-party key distribution system, as described by Needham and Schroeder. It allows a client and a server to both authenticate the entity at the other end of a connection, and to exchange a session key which may be used for encryption. Passwords are never sent over the network in cleartext. MIT's Project Athena has local versions of all of the Berkely r programs that attempt to exchange Kerberos authenticators, before falling back to the old-style authorization of .rhosts files. For more info, see "Kerberos: An Authentication Service for Open Network Systems" in the Winter 1988 Usenix Proceedings, or send mail to steiner@ATHENA.MIT.EDU. The new vesion of the code is going into beta release now, and will be generally available later this year. -Mark
-----------[000024][next][prev][last][first]---------------------------------------------------- Date: 2 Mar 88 17:06:41 GMT From: fennell@inco.UUCP (Tim Fennell) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: XENIX TCP/IP software (IBM PC)
HELP!!! I need to know if and where I can find TCP/IP to run on the IBMPC/AT under XENIX OS. I currently have a 3COM board but I only have a MS-DOS driver, I also need a XENIX driver with the TCP/IP. My time frame is real short. As usual, my managers have assigned this to me and they need it yesterday. Any help would be appreciated. Thanks, Tim Fennell (800) 368-4626
-----------[000025][next][prev][last][first]----------------------------------------------------
Date: 2 Mar 88 17:33:19 GMT
From: JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To: comp.protocols.tcp-ip
Subject: Re: rsh equivalentUnix has a near-equivalent of the RSH protocol in rexec(). One difference is the port number (rexec() uses 512, RSH uses 514). The other is that rexec() always requires a password, where RSH has no mechanism for one. We include a client program for rexec() in our DOS PC package, and I wrote a primitive client program for Unix (that uses the library function). It amounts to about 50 lines of code. We support the PC version because we feel the security hole gets even worse when single-user PCs are involved. As far as RFCs go, I don't know of any equivalent simple remote execution protocol described by an RFC, and the only documentation for the 4BSD protocols that I know of is in the man pages. James VanBokkelen FTP Software Inc.
-----------[000026][next][prev][last][first]---------------------------------------------------- Date: 2 Mar 88 18:33:35 GMT From: terry@DEC-VAX-11-750.ARPA To: comp.protocols.tcp-ip Subject: Re: TCP Options/Copy Protect
All,
If there is an update to this, feel free to flame me, but please
be gentle.
****----
Brian Lloyd,
Mil-Std-1778, 12-Aug-1983, Page 92:
There are two cases for the format of an option:
a) A single octet of option-kind.
b) An octet of option-kind, an octet of option-length,
and the actual option-data octets.
The option-kind field determines the option being processed. This
option-kind MUST be known, otherwise there is no way to tell whether
the next octet is a new option, or the length of the current option.
Therefore, further option processing cannot occur.
Your Question: Will this upset any TCP implementations?
My Answer: YES
In MY TCP implementation, an unknown option will cause a
message to be placed in a log file along with all of the
remaining bytes in the TCP header. If a valid option, such as
maximum segment size, occurred after the unknown option the
valid option would be ignored. This could be serious.
I would take a guess and say that ALL TCP implementations are probably
not as gracious as mine. Some probably would ignore the packet, others
might curl up and die, or worse.
*****-----
Non-TCP-Related-Topic:
There is a place for copy protection schemes in the world. However,
your scheme only prevents your TCP from talking to itself, not to other
TCP implementations. Besides the problem I stated above, it seems to
me that if you want to copy protect your software, do it right. Don't
do it halfway. There are several methods of controlling software execution
available. Pick One. If your company doesn't have the people to do the
job, hire someone.
****----
Terry Robb
-----------[000027][next][prev][last][first]---------------------------------------------------- Date: 3 Mar 1988 00:44-EST From: CERF@A.ISI.EDU To: karn@UCSD.EDU Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: Acking out-of-order packets?
My recollection of intent in RFC 793 was to have the TCP invite the proper next packet by responding with the "next packet" ACK and not with an ACK that references anything about the out of order packet. Perhaps others will either remember differently or have a better notion for how to behave under the circumstances described. Obviously, if TCP had "out of order" acking and selective retransmission, the response would be more complex. Vint
-----------[000028][next][prev][last][first]---------------------------------------------------- Date: 2 Mar 88 20:46:47 GMT From: latzko@athos.rutgers.edu (Alex ) To: comp.protocols.tcp-ip Subject: Re: TCP-IP for AT&T 3B2'S
In article <46200003@ntvax> jacob6@ntvax.UUCP writes: >Iam wondering if any of you folks know about any PD source >of TCP-IP for AT&T 3B2 machines. Your response in this matter >UUCP: convex!ntvax!jacob6 Surely, you jest. Seriously, there is non or I would have it. it costs $$ from ATT cheers /S*
-----------[000029][next][prev][last][first]---------------------------------------------------- Date: 2 Mar 88 21:53:00 GMT From: ABSTINE@CLVMS.CLARKSON.EDU (AB Stine) To: comp.protocols.tcp-ip Subject: re: tcp/ip terminal servers
Here at Clarkson, we've been evaluating a number of TCP/IP terminal servers.
We've had the Bridge CS/100 in for a while, and its worked out rather well.
Haven't had any problems with it at all... it talks to all of our hosts
(BSD4.2,4.3, VMS (under CMU TCP), Gould UTX, Sun/OS, Alliant, PC's).
We are now evaluating a Cisco box. My first impressions of it are good... seems
to work very well... i'm not sure if it can really handle all 32 ports at
high speed though (its only got a 68000... i understand that they now have
a 68020 also). it also does Rlogin, which the bridge does not (yet).
In addition, we tried a Micom Server. We didn't do much with it though...
it was kinda slow, not very configurable. cheap though...
art stine
network engineer
clarkson u
-----------[000030][next][prev][last][first]---------------------------------------------------- Date: 2 Mar 88 22:25:00 GMT From: STJOHNS@SRI-NIC.ARPA To: comp.protocols.tcp-ip Subject: Re: TCP Options/Copy Protect
Terry, Jon Postel has decreed that for both TCP and IP, any additional options will be of the second type... I.e. self encoding the length. Mike
-----------[000031][next][prev][last][first]---------------------------------------------------- Date: Thu, 03 Mar 88 08:32:04 -0500 From: haverty@CCV.BBN.COM To: Phil Karn <karn@UCSD.EDU> Cc: tcp-ip@SRI-NIC.ARPA, haverty@CCV.BBN.COM Subject: Re: Acking out-of-order packets?
Phil - even if a TCP sends 'do-nothing' ACKs, nothing should depend on that behavior, since the ACK is unreliable - as a datagram, it might get lost in transit. Jack
-----------[000032][next][prev][last][first]---------------------------------------------------- Date: 3 Mar 88 02:03:30 GMT From: ehrlich@blitz (Dan Ehrlich) To: comp.protocols.tcp-ip Subject: Re: Link level Ethernet bridges (Modified)! does that mean joke?
Once upon a time, in another job far, far, away I also encountered
these mysterious aa:0:4:0:xx:xx addresses. Read on. Maybe someone
can explain to me why DEC does what it does. :-)
In article <8802232312.AA02132@sneezy.lanl.gov> cpw%sneezy@LANL.GOV (C. Philip Wood) writes:
>...
>
> segment #1 segment #2
>
> 8:0:20:1:33:1e Ha--| |--Hz 8:0:2b:3:92:23
> | |
> 8:0:20:1:47:d2 Hb--| |--Hz-1 8:0:20:1:d7:e5
> |icmp icmp |--Hy 2:7:1:0:a6:59
> 8:0:9:0:65:3d Hp*--|echo-> echo->|--Hx aa:0:4:0:da:4 hummmm.
^^^^^^^^^^^^^
This mystery number is from a VAX running DECnet, either under VMS or
Ultrix. It could also be from another vendor that has implemented
DECnet's host->ethernet address mapping. DEC in their infinite wisdom
uses one of the maintenance functions in the DE[QU]NA to change the
physical ethernet address from what is in the ROM to this magic
number. I do not know if they have gotten around to documenting how it
is computed, but if memory serves me correctly it goes something like
this:
aa:0:4:0 is a magic constant that appears on any VAX
running DECnet.
da:4 is, get ready, the DECnet host and area number
(byte swapped of course). Educated guess says
that this is DECnet host 1.218. (Area number)
* 1024 + (Host number).
When I asked DEC why they do this I got numerous excuses.
"Keeping a table mapping DECnet host numbers to Ethernet addresses
would soak up too much memory"
"We do not have anything like ARP and do not expect to in the
near future"
"Whoes name is on the fron of the 'Blue Book' anyway?".
All of these are from the 1986 time frame and as I have not had reason
to ask the question of late do know know if the responses are still
valid.
> nada <-reply |
> . .
> . .
> . .
> 8:0:20:1:66:6a Hq--| |--Hr 8:0:2b:3:91:5c
> |----?[DEC lanBridge]?---|
>
> SUBNET 1 of Class B network 128.165, mask==0xfffffc00
>
>There is probably alot of irreverent/irrelevant, but, it was fun.
>...
Dan Ehrlich <ehrlich@psuvax1.{psu.edu,bitnet,uucp}>
The Pennsylvania State University, Department of Computer Science
333 Whitmore Laboratory, University Park, PA 16802
+1 814 863 1142 or +1 814 865 9723
-----------[000033][next][prev][last][first]---------------------------------------------------- Date: 3 Mar 88 02:36:20 GMT From: jwkhong@grand.waterloo.edu (James W. Hong) To: comp.protocols.tcp-ip Subject: Implicit acks in TCP?
I wonder if someone could clarify a point for me regarding acks in TCP. Are implicit acks allowed in TCP? What I mean by an implicit ack is that each request or response message serves as an implicit ack for the previous response or reqeust message from that client, respectively. What BSD4.3 version TCP seems to do is to ack a request packet immediately and sends the requested data in a separate packet. This requires 4 packet exchanges rather than 2 if an implicit ack is used. Does the TCP spec. disallow using implicit acks? Or does it depend on TCP implementations? ---------------------------------------------------------------------------- James W. Hong jwkhong@grand.waterloo.cdn Dept. of Computer Science jwkhong%grand%waterloo.csnet Univ. of Waterloo jwkhong%grand%waterloo.csnet@csnet-relay.arpa Tel: (519) 885-1211 x6178
-----------[000034][next][prev][last][first]---------------------------------------------------- Date: 3 Mar 88 02:58:20 GMT From: karn@UCSD.EDU (Phil Karn) To: comp.protocols.tcp-ip Subject: Acking out-of-order packets?
During conversations with Van Jacobsen here at the IETF meeting, I discovered an abiguity in the TCP spec (RFC-793 at least), to wit: What response (if any) should you make when you receive an out-of-order segment? RFC-793 says pretty clearly that you should return an empty ACK (indicating the sequence number you expect to receive next) if the packet is "unacceptable" (i.e., not in the window) but it doesn't say whether you should respond if the packet is in the window but not the next one expected. It says only that they should be kept for future processing. My TCP in fact makes no response to an out-of-order data segment. Others apparently respond with "do-nothing" ACKs. One of Van's performance tricks depends on that behavior. Any guidance on what is the Right Thing here? Thanks, Phil Karn
-----------[000035][next][prev][last][first]---------------------------------------------------- Date: 3 Mar 88 03:53:11 GMT From: wcs@ho95e.ATT.COM (Bill.Stewart) To: comp.protocols.tcp-ip Subject: Re: rsh equivalent
In article <23511@hi.unm.edu> cyrus@hi.unm.edu (Tait Cyrus) writes:
:The reason I am interested in something other than rsh is because
:here at UNM we are strongly considering disallowing the r* programs
:(rsh/rcp/rlogin) because they do NOT conform to the RFC's
:[(machine name case independent).]
:as well as being BIG security problems (.rhosts).
My big gripe with the r* programs is that they lose UNIX semantics.
For instance, rsh doesn't return the condition code from the remote process -
rsh foovax false
returns true if the connection succeeded. Less important but harder to fix,
rsh is non-interactive; I've gotten real used to Datakit's remote execution
capabilities ("dk other3b /bin/ksh"). It would also be nice to have a
convenient rcp-variant that didn't update modification times.
I'm less bothered by machine-name-case dependence - r* are specifically
UNIX utilities, and case dependence is appropriate. (By contrast, HP's
NS-9000, NS-VAX, NS-etc. utilities are supposed to be transparent between
systems; it took us several days of cable-testing to find that the 350
didn't accept it's name in uppercase, as generated on a VMS microvax.)
--
# Thanks;
# Bill Stewart, AT&T Bell Labs 2G218, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs
-----------[000036][next][prev][last][first]---------------------------------------------------- Date: 3 Mar 88 03:55:06 GMT From: brian@wb6rqn.UUCP (Brian Lloyd) To: comp.protocols.tcp-ip Subject: Creating TCP options
Thanks for the feedback. Although some of you were a bit vociferous I think
that all the responses I received were useful and well thought out. We did
do an implementation of the concept (adding a serial number as a TCP option
field) and it worked fine when talking to a 4.3 bsd system.
I think that we are going to take a different tack. The UDP broadcast idea
seems to be the most reasonable I have heard so far. I will let you know
where we go.
Again, thanks for the feedback.
Brian Lloyd, President
Sirius Systems, Inc.
(301) 540-2066
{bellcore, syscad, cp1, irs3, n3dmc}!wb6rqn!brian
Share and enjoy!
-----------[000037][next][prev][last][first]---------------------------------------------------- Date: 3 Mar 88 05:44:00 GMT From: CERF@A.ISI.EDU To: comp.protocols.tcp-ip Subject: Re: Acking out-of-order packets?
My recollection of intent in RFC 793 was to have the TCP invite the proper next packet by responding with the "next packet" ACK and not with an ACK that references anything about the out of order packet. Perhaps others will either remember differently or have a better notion for how to behave under the circumstances described. Obviously, if TCP had "out of order" acking and selective retransmission, the response would be more complex. Vint
-----------[000038][next][prev][last][first]---------------------------------------------------- Date: 3 Mar 88 06:04:07 GMT From: karels@OKEEFFE.BERKELEY.EDU (Mike Karels) To: comp.protocols.tcp-ip Subject: Re: rsh equivalent
> I am looking for PD version of code that accomplishes the same thing > as rsh but conforms to the RFC's (machine name case independent). > We have users who like to pipe BIG jobs from one machine to another > machine via rsh's. Conforms to *what* RFCs? In particular, machine name case independence isn't the subject of any RFC, and has no bearing on remote login or execution facility protocols or specification. It's a user-interface issue. Incidentally, when using the nameserver for hostname lookup, this interface *is* case insensitive. You seemed to have picked upon the most trivial of criteria for judging such protocols and implementations. (None of the above should be construed as defense of the rlogin and rsh facilities. The main reason that I haven't made any attempt to document these "protocols" publically is that it might help to keep them from proliferating. I've been lobbying a few people to try putting a few options into telnet that would give it every capability of rlogin and many more, so that we could toss rlogin out. The current wish-list is negotiation of local or remote flow control, automatic user-name propagation and login, and maybe even exporting the Unix environment, which rlogin doesn't do either. Sun's "on" program does this, but I haven't looked at it much. Automatic switching between character and line mode with local echoing may be a win, and can already be done by our current telnet clients.) > The reason I am interested in something other than rsh is because > here at UNM we are strongly considering disallowing the r* programs > (rsh/rcp/rlogin) because they do NOT conform to the RFC's as well > as being BIG security problems (.rhosts). The .rhosts file isn't the problem; you're picking on the wrong things. However, see the reply about Kerberos. Mike
-----------[000039][next][prev][last][first]---------------------------------------------------- Date: 3 Mar 1988 1459-PST (Thursday) From: mogul@decwrl.dec.com (Jeffrey Mogul) To: tcp-ip@sri-nic.ARPA Subject: Ethernet speeds revised
Two days ago I sent a message describing some experiments Dave Boggs had been doing to see what kind of host-to-host throughput the Ethernet could carry. Science marches on; since I sent that message, he has revised his results twice (once by clever programming; once by turning on the compiler optimizer). Again, this is for data sent from one host to another over a 10 Mbit/sec Ethernet, not using any protocols aside from the data link header, nor much of an operating system. The new numbers are: 1536-byte packets 9.2 Mbits/sec (maximum "legal" Ethernet packet) 4000-byte packets 9.6 Mbits/sec (don't try this at home)
-----------[000040][next][prev][last][first]---------------------------------------------------- Date: 3 Mar 88 13:30:08 GMT From: jmg@cernvax.UUCP (jmg) To: comp.protocols.tcp-ip Subject: Re: FTP vs. VMS & long passwords
In article <8802292102.AA06989@macduff.ultra.com> shj@ultra.UUCP (Steve Jay) writes: > > "530 Login failed (bad Username or Password), give new USER and PASS " > >when attempting to use FTP server on a VAX VMS system, and the password >for the VAX account is over 8 characters long. Same problem seen on trying to FTP to a Vax from the IBM TCP/IP on our VM system. (After hacking attacks many people go beyond 8 characters!) -- _ _ o | __ | jmg@cernvax.uucp | | | | _ / \ _ __ _ __ _| jmg@cernvax.bitnet | | | | |_) /_) | __/_) | (___\ | (_/ | J. M. Gerard, Div. DD, CERN, | | |_|_| \_/\___ \__/ \___| (_|_| \_|_ 1211 Geneva 23, Switzerland
-----------[000041][next][prev][last][first]---------------------------------------------------- Date: 3 Mar 88 13:32:04 GMT From: haverty@CCV.BBN.COM To: comp.protocols.tcp-ip Subject: Re: Acking out-of-order packets?
Phil - even if a TCP sends 'do-nothing' ACKs, nothing should depend on that behavior, since the ACK is unreliable - as a datagram, it might get lost in transit. Jack
-----------[000042][next][prev][last][first]---------------------------------------------------- Date: 3 Mar 88 14:04:13 GMT From: pgc@newcastle.ac.uk (P. G. Cutting) To: comp.dcom.lans,comp.protocols.tcp-ip Subject: campus ethernet help?
As a research group at Newcastle University England, investigating the monitoring and management aspects of our prospective campus network (ethernet backbone). We would like to hear from other universities / sites on the following in particular: a) Internetworking using Bridge Links via Backbone. b) Information regarding Network Monitering and Management methods in use. c) synopses of users of the network - equiptment/software/loading. d) problems eg bottlenecks in the Network. We would be interested to hear from users of any large campus - not specifically using ethernet. Thanks in advance, CSSD@UK.AC.NEWCASTLE Computing Laboratory, The University of Newcastle, Newcastle Upon Tyne, NE1 7RU, ENGLAND.
-----------[000043][next][prev][last][first]---------------------------------------------------- Date: 3 Mar 88 16:15:54 GMT From: karn@UCSD.EDU (Phil Karn) To: comp.protocols.tcp-ip Subject: Re: Acking out-of-order packets?
Nothing really "depends" on those do-nothing ACKs, in the sense that the protocol still operates correctly even if they are lost. I should probably let Van describe his own technique, but basically it involves interpreting a flurry of do-nothing ACKs as an indication that an early packet was lost. This triggers a retransmission before the timer would ordinarily expire and do it. This appears to be a big performance win over networks with large bandwidth*delay products (e.g., the Wideband net). Phil
-----------[000044][next][prev][last][first]---------------------------------------------------- Date: 3 Mar 88 20:48:00 GMT From: DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer) To: comp.protocols.tcp-ip Subject: Re: Acking out-of-order packets?
[I wasn't on the design team.] I would strongly suggest that any next-packet ACKs generated by out of order segments wait until the network input queue is empty. For a multitude of reasons, the medium or the implementation may reverse some packets on you. (E.g., in past releases, the 3600 had LIFO transmit and receive queues, but since transmitting a packet is fast the transmit queue is effectively FIFO, and the receive queue is processed by a process/task. We now reverse the receive list.) I agree that encouraging the sender to retransmit a packet that should have arrived helps performance. I'm asking that people be careful in making the "should" determination.
-----------[000045][next][prev][last][first]---------------------------------------------------- Date: 3 Mar 88 21:15:27 GMT From: dzoey@TERMINUS.UMD.EDU To: comp.protocols.tcp-ip Subject: Re: rsh equivalent
> Less important but harder to fix, rsh is non-interactive;
There's nothing in the rsh/rexec protocol that says it's not
interactive. It is possible to write your own rsh/rexec program that
accepts and issues character i/o. After all, rsh/rexec protocols just
describe how to establish data streams and do some trivial
authentication. If you invoke an interactive process with your rsh
command you can do interactive processing (with some exceptions).
Certain programs (like more) will not work correctly since there is no
terminal attatched. Rsh/rexec are not virtual terminal protocols
and the BSD server does not establish a pty for the process.
Programs will work if they only look at environment variables for
terminal information.
I've only tried this in a BSD (or derivitive) environment. I don't know
how other OS's handle rsh/rexec requests.
Joe Herman
PC/IP project.
The University of Maryland
dzoey@terminus.umd.edu
-----------[000046][next][prev][last][first]---------------------------------------------------- Date: 3 Mar 88 21:24:22 GMT From: dewey@auscso.UUCP (Dewey Coffman) To: comp.protocols.tcp-ip Subject: TLI?
Does anyone have any information or pointer to information about a new product called TLI out of AT&T(?) that is supposed to replace tcp/ip on UNIX? E-mail is preferable, but post if of general interest. dewey coffman austin, texas auscso!dewey
-----------[000047][next][prev][last][first]---------------------------------------------------- Date: 3 Mar 88 21:39:25 GMT From: rfox@AMES-NAS.ARPA (Richard Fox) To: comp.protocols.tcp-ip Subject: Re: Acking out-of-order packets?
>During conversations with Van Jacobsen here at the IETF meeting, I discovered >an abiguity in the TCP spec (RFC-793 at least), to wit: > >What response (if any) should you make when you receive an out-of-order >segment? RFC-793 says pretty clearly that you should return an empty ACK >(indicating the sequence number you expect to receive next) if the packet >is "unacceptable" (i.e., not in the window) but it doesn't say whether >you should respond if the packet is in the window but not the next one >expected. It says only that they should be kept for future processing. > >My TCP in fact makes no response to an out-of-order data segment. Others >apparently respond with "do-nothing" ACKs. One of Van's performance tricks >depends on that behavior. Any guidance on what is the Right Thing here? Getting a packet out-of-order can mean 1 of 2 things: 1. Preceding packets were dropped or corrupted and dropped. 2. The preceding packets are taking a different path than the one just received. In case 1, responding with a "do-nothing" ACK, would get the original sender to resend the packets before the timeout period elapses. In the case of a high delay large bandwidth link this is very advantageous to do. Our TCP will keep out-of-sequence packets on a queue and try to reassemble packets as they come in until we are caught up. This is a win situation if you delay your acks. If you immediately send a "do-nothing" ACK the sender will resend whats already been sent again. Since the packets need to be resent anyways, being that they will never make it, sending a "do-nothing" packet seems to be a winner. Also, we might assume that the packet was lost/dropped because of congestion ( since less than 1% of dropped packets is due to corruption due to link errors) and then this would set the congestion control algos. into action much quicker. Thus, congestion can be stopped much quicker! As an aside: So the question at this point is do we really want to keep the extra complexity of doing reassembling of packets in the TCP layer as well as the IP? In case 2, responding with a "do-nothing" ACK would, like in case 1, get the sender to resend the packets before the timeout period elapses. But since the packets are going to make it, just a little later than the out-of-seq packet, this would cause excess packets to be sent over the net. If we assume that the packets took different paths because of congestion on a particular link, this could potentially aggravate the congestion problem. Of course, Van;s algorithm will back off a bit to control the congestion. Ultimately this could mean that the receiver would tell the sender to re-xmit all of the packets again, the sender will assume that the network is congested and should use caution in resending the packets, the receiver receives all of the packets before the sender has time to re-xmit them all. The receiver then sends an ACK for all of the data and the sender will not have to re-xmit all of the packets and can go on transferring new data by opening back up its congestion window. I think in case 2 this will work if the assumption that the packets took different routes because of congestion, with the use of Van's algo. If a gateway puts packets on different links for the purpose of load balancing and congestion avoidance then the scenario above for case 2 would break down and the best solution would be to delay any acking for a period to see if the data is still yet to come. W might still want to wait for a small period, being that the period be less than the normal timeout periods currently used. I am not convinced that load balancing is a good idea, thus, would like to be able to assume that the only time a packet would travel on a different route than the previous packet is due to congestion. Then I think immediately sending a "do-nothing" ACK would be feasible even for out-of-seq packets that are in the window. >Perhaps others will either remember differently or have a better >notion for how to behave under the circumstances described. >Obviously, if TCP had "out of order" acking and selective >retransmission, the response would be more complex. > >Vint Up above I have stated that sending a "do-nothing" ACK immediately is probably the correct thing to do because to try and do anything else would require more complexity, complexity that TCP was not intended to handle. If we want the extra complexity, this would mean moving towards a transport level protocol like VTMP or something like a NETBLT type protocol, which is quite different than TCP. In the future I think we will need to move in the direction of a VTMP like protocol so would like to keep it out of TCP. Rich
-----------[000048][next][prev][last][first]---------------------------------------------------- Date: 3 Mar 88 22:08:20 GMT From: rfox@AMES-NAS.ARPA (Richard Fox) To: comp.protocols.tcp-ip Subject: Re: Implicit acks in TCP?
TCP is a byte stream protocol. This means that it works based on bytes being sent, not packets per se. Thus, you'll notice that the ACK field is acking bytes not packets sent. To ack each byte individually would take forever, so the ack is stating which byte it expects to receive next ( or as you put it, it is implicity ACK'ing all data up to a certain point). Since each packet of data contains an ACK, if you notice that you are sending 4 packets instead of 2, where 2 would suffice if ACKS are piggybacked, then it is your implementation adding the extra packets, not the protocol. I believe the problem you stated with your implementation is happening because you have delayed acking turned off. This means as soon as you know you can ack something received do so, then go ahead and process the request ( ie: get and send the data). Hope this helps some, rich
-----------[000049][next][prev][last][first]---------------------------------------------------- Date: 4 Mar 88 15:17:47 GMT From: geoff@eagle_snax.UUCP ( R.H. coast near the top) To: comp.protocols.tcp-ip Subject: Re: Exchanging serial numbers
In article <669@taurus.BITNET>, leonid@TAURUS.BITNET writes:
> In article <8802251906.AA04676@wb6rqn.UUCP> brian@wb6rqn.UUCP writes:
> >Here at Sirius Systems we have been discussing a means to protect our
> >TCP/IP software without placing undue strain on the users. ...
>
> May I mention a very much similar solution done by Sun Microsystems in their
> PS-NFS 2.0 product, and please excuse me if this has already been mentioned.
> They just used ICMP discard packets to broadcast the serial number of each
[...]
> To tell you the truth, I'm not really sure weather they use ICMP discard or
> UDP discard packets...
We use UDP discard packets (UDP port 9), and we wind up sending one about
once an hour (depending on usage pattern). It hasn't broken any nets yet,
as far as I know (and I'm sure the flames would have come thick and fast :-).
And like Leonid I'd prefer an "official" solution. Anyone interested in
talking about it?
>
> Leonid
Geoff Arnold
PC-NFS architect
--
Geoff Arnold, Sun Microsystems | "Universes are just one of those things
SPD at ECD (home of PC-NFS) | that happen from time to time..."
UUCP:{ihnp4,decwrl...}!sun!garnold | [Dunno who said it - if you know, pass it
ARPA:garnold@sun.com | on. G.A.]
-----------[000050][next][prev][last][first]----------------------------------------------------
Date: 4 Mar 88 15:59:41 GMT
From: slevy@UC.MSC.UMN.EDU ("Stuart Levy")
To: comp.protocols.tcp-ip
Subject: Re: Acking out-of-order packets?Be aware that packets may have other reasons for arriving out of order than that they've followed multiple paths. One possible strategy for giving interactive traffic priority over bulk data on a crowded link is to preferentially forward small packets. I don't know of any specification that says this shouldn't be done. We've used an Ethernet bridge that actually does this, and caused a 4.2 TCP bug to be exercised (when a FIN arrived earlier than some trailing data, the FIN was ignored. The peer TCP had a bug that caused it to never retransmit a FIN, and so...).
-----------[000051][next][prev][last][first]---------------------------------------------------- Date: 4 Mar 88 16:09:53 GMT From: bzs@BU-CS.BU.EDU (Barry Shein) To: comp.protocols.tcp-ip Subject: TCP-IP for AT&T 3B2'S
>In article <46200003@ntvax> jacob6@ntvax.UUCP writes: >>Iam wondering if any of you folks know about any PD source >>of TCP-IP for AT&T 3B2 machines. Your response in this matter >>UUCP: convex!ntvax!jacob6 > >Surely, you jest. Seriously, there is non or I would have it. it >costs $$ from ATT As a callow youth I wrote a udp/ip and tftp for the 3B which can be picked up from BU-IT.BU.EDU's anon area, src/network/udp.3b/*. I have no idea of it works under current releases although other than the ethernet device assumptions (/dev/ni if I remember right) I can't imagine it's too far off. Feel free, I certainly have no interest in supporting it etc as we don't use 3B's anymore, mostly due to its lack of TCP/IP... -Barry Shein, Boston University
-----------[000052][next][prev][last][first]---------------------------------------------------- Date: 4 Mar 88 16:40:38 GMT From: clyde@ut-emx.UUCP (Head UNIX Hacquer) To: comp.protocols.tcp-ip Subject: Re: Ethernet Terminal Servers
We here have Encore Annexes, most of which are connected to our Encore Multimax, but we are using one for general Ethernet access. They seem to work fairly well, and you can upload/download port configurations from any UNIX host, since Encore supplies the source for the Annex administrator program. An Annex has 16 serial ports and one parallel printer port. We are using Printronix P300 (I think) on a parallel port. You can remote access serial ports on an Annex from a network host via telnet, if they have been set up so, and from the UCB line printer system. If you want to run a simple serial printer this way, it will work - I don't know about "smarter" printers such as Apple LaserWriters. The Annex boxes are nice, but for general usage I would probably look at the Cisco boxes, for they have (on paper at least) more useful features (such as Serial Line IP). Encore phone #: 1-800-336-2673 -Clyde Hoover -- Shouter-To-Dead-Parrots @ Univ. of Texas Computation Center; Austin, Texas clyde@ngp.utexas.edu; ...!ut-sally!ut-ngp!clyde "It's a sort of a threat, you see. I've never been very good at them myself, but I've told they can be very effective."
-----------[000053][next][prev][last][first]---------------------------------------------------- Date: 4 Mar 88 17:56:51 GMT From: NIC@SRI-NIC.ARPA (DDN Reference) To: comp.protocols.tcp-ip Subject: Mil-Standards draft docs available
The Defense Communications Engineering Center (DCEC) Protocol Laboratory invites comments from the Internet community on the following draft documents. These documents outline the conformance tests developed for the DoD Mil Std protocols. The comments can be about any aspect of the document, but in particular, opinions are requested on the accuracy and completeness of the test procedures. The documents are unrestricted so comments will be accepted from the entire Internet community. THE DOCUMENT TITLES ARE: 1. DCEC Protocol Laboratory Internet Protocol MIL-STD-1777 Certification Tests Index, DRAFT 2. DCEC Protocol Laboratory Transmission Control Protocol (TCP) MIL-STD-1778 Traceability Matrix, DRAFT 3. DCEC Protocol Laboratory File Transfer Protocol (FTP) MIL-STD-1780 Certification Tests Index, DRAFT 4. DCA Protocol Laboratory Simple Mail Transfer Protocol (SMTP) MIL-STD-1781 Traceability Matrix, DRAFT 5. DCEC Protocol Laboratory TELNET Protocol (TELNET) MIL-STD-1782 Certification Tests Index, DRAFT HOW TO OBTAIN THE DOCUMENTS: Online versions are available through FTP or through SERVICE, the NIC's automatic mail service. The pathnames and byte sizes are: PROTOCOLS:MSTD-1777-TESTS1.DOC 394602 bytes PROTOCOLS:MSTD-1777-TESTS2.DOC 356791 PROTOCOLS:MSTD-1778-TESTS.DOC 102460 PROTOCOLS:MSTD-1780-TESTS.DOC 62915 PROTOCOLS:MSTD-1781-TESTS.DOC 75244 PROTOCOLS:MSTD-1782-TESTS.DOC 55962 The DDN NIC can provide hardcopies of the set of documents for $50 (USA and Canada) and $90 overseas to cover the cost of reproduction, postage and handling. Send a written request, accompanied with payment in the form of check, money order, or company purchase order (made payable to SRI International) to: SRI International DDN Network Information Center Room EJ291 333 Ravenswood Avenue Menlo Park, CA 94025 Please include your full name, business address, and zip code. California residents should add 6.5% sales tax to their order total (except military users). SENDING YOUR COMMENTS: Comments are to be sent via electronic mail to COMMENTS@EDN-UNIX.ARPA Please be sure to indicate to which document or documents your comments refer. -------
-----------[000054][next][prev][last][first]---------------------------------------------------- Date: 4 Mar 88 18:34:31 GMT From: taylor@ATOM.HPL.HP.COM (Dave Taylor) To: comp.protocols.tcp-ip Subject: TCP / Berkeley Networking Suite wanted...
[Please Reply To: motsj1!nswed5!efb, motsj1!nswed5!unicom!dlt]
Hello.
The following is a forwarded message from a chap with the USN in Port Hueneme,
California, and another chap at UNICON in Santa Ana, California about TCP/UDP
sources and the related protocol suite.
As I believe this group to be the appropriate forum for answering this
question, I am herein forwarding the message sent to me. I should also
point out that neither I, Everett, or Dan currently receive this mailing
list, so replies should be sent direct (to them, not me, please).
Thank you very much.
-- Dave Taylor
--------
From: hplabs!motsj1!nswed5!efb (Everett F. Batey II),
hplabs!motsj1!nswed5!unicon!dlt (Dan Taylor)
Subject: A question about TCP / UDP sources
Date: Thu, 3 Mar 88 14:39:23 PST
[...] We have a Unix 5.2 / 5.3, Motorola 68020 (VME 10 / 1100 ),
and hold AT&T / Motorola, V68 5.3.3 Source license with RFS.
Dan Taylor, of UNICON, Santa Ana, a VME sw/hw system development shop
has examined the 5.3 sources and the CMC, Santa Barbara, sources which
Motorola resells for VME / V68 system:
> You are aware of the tools that are not supplied by CMC, both TCP/IP and
> the total lack of UDP/IP support.
>
> I am hoping to find is a complete TCP, UDP, and IP protocol suite, generic,
> that is coded for a UNIX host ( if you find one, it will probably be bsd),
> and sources for the associated utilities. Given that so much development
> of those protocols was funded by the government, I was hoping to avoid
> large fees.
We are trying hard not to reinvent the public domain wheel.
Can anyone suggest a source for the TCP and UDP utility socket source code?
Everett F. Batey II - USNSWSES EDMICS V Project
sun!tsunami!nswed5!efb - Port Hueneme,CA 805/982-5881
--------
-----------[000055][next][prev][last][first]---------------------------------------------------- Date: 4 Mar 88 19:23:47 GMT From: markl@ALLSPICE.LCS.MIT.EDU To: comp.protocols.tcp-ip Subject: Re: Acking out-of-order packets?
Date: Fri, 4 Mar 88 09:59:41 CST From: "Stuart Levy" <slevy@uc.msc.umn.edu> > Be aware that packets may have other reasons for arriving out of order than > that they've followed multiple paths. I recall that at one point Wideband Network BSATS also had a tendency to re-order packets--by pushing to the end of the queue those packets which had missed their satellite reservations. markl Internet: markl@ptt.lcs.mit.edu Mark L. Lambert MIT Laboratory for Computer Science Distributed Systems Group ----------
-----------[000056][next][prev][last][first]---------------------------------------------------- Date: 4 Mar 88 20:38:11 GMT From: barmar@think.COM (Barry Margolin) To: comp.protocols.tcp-ip Subject: Re: Implicit acks in TCP?
In article <17229@watmath.waterloo.edu> jwkhong@grand.waterloo.edu (James W. Hong) writes: >I wonder if someone could clarify a point for me regarding acks in >TCP. Are implicit acks allowed in TCP? What I mean by an implicit >ack is that each request or response message serves as an implicit >ack for the previous response or reqeust message from that client, >respectively. Your question indicates that you misunderstand TCP. TCP does not have any notion of "request" and "response" messages; some higher-level protocols, such as RPC (Remote Procedure Call), may have them, though. TCP implements a reliable bidirectional stream of octets on top of a lower-level unreliable datagram facility (generally IP). TCP doesn't require that every transmission in one direction be followed by a transmission in the other direction. Every TCP datagram includes an explicit ack, so there can be no "implicit" acknowledgements. However, for ease of implementation, most implementations send an empty acknowledgement datagram as soon as they receive a datagram. While they could wait and try to piggy-back it on the next outgoing datagram to that host, they would also have to set a timer so that an empty ack could be sent out sooner if no outgoing data is sent soon. For applications where a large amount of data is going one way and very little goes the other way (e.g. mail transfer) this could reduce throughput, because acks would not come as soon as the receiver was actually ready to receive more. And if the acks are sent too late, the sender might end up retransmitting packets that were actually received intact. Barry Margolin Thinking Machines Corp. barmar@think.com uunet!think!barmar
-----------[000057][next][prev][last][first]---------------------------------------------------- Date: 4 Mar 88 23:59:06 GMT From: gordan@maccs.UUCP (gordan) To: comp.protocols.tcp-ip Subject: Re: Link level Ethernet bridges (Modified)! does that mean joke?
In article <3343@psuvax1.psu.edu> ehrlich@blitz.cs.psu.edu (Dan Ehrlich) writes: -Once upon a time, in another job far, far, away I also encountered -these mysterious aa:0:4:0:xx:xx addresses. Read on. Maybe someone -can explain to me why DEC does what it does. :-) - -This mystery number is from a VAX running DECnet, either under VMS or -Ultrix. [...] DEC in their infinite wisdom uses one of the maintenance -functions in the DE[QU]NA to change the physical ethernet address from -what is in the ROM to this magic number. I wondered about those funny addresses myself when I found this in one of my log files some time ago (it appeared to have snuck in as a multicast packet). Then those lists of Ethernet packet types were posted to this group, and 6003 was listed as "DEC/DNA Routing". Out of sheer idle curiosity, anybody know what the protocol header fields are for this packet? aa 00 04 00 02 04 aa 00 04 00 01 04 60 03 1d 00 ............`... 81 26 00 00 aa 00 04 00 02 04 00 00 aa 00 04 00 .&.............. 01 04 00 00 00 00 04 0a 18 0a 04 5d 86 00 00 00 ...........].... 00 00 00 00 00 00 00 00 00 00 00 00 ............ Ethernet -- aa 0 4 0 1 4 --> aa 0 4 0 2 4 Packet type (hex) : 6003
-----------[000058][next][prev][last][first]---------------------------------------------------- Date: 5 Mar 88 00:46:13 GMT From: wcs@ho95e.ATT.COM (Bill.Stewart.<ho95c>) To: comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.misc,comp.windows.misc Subject: Re: rlogin from windows
In article <707@hadron.UUCP> jsdy@hadron.UUCP (Joseph S. D. Yao) writes: :On a heterogenous (System V / Ultrix) TCP/IP network, several people :use 'rlogin' from windows, and are surprised when the computer on the :far side believes that they have the full complement of lines and :columns. My suggested solution was to add to the third rlogin [....] :Since the System V terminfo uses environment variables $LINES and :$COLUMNS, we could use those on the System V machines; and we'd have :to get the Berkeley machines somehow to modify $TERMCAP based on :$LINES and $COLUMNS. I run into this problem with my AT&T Datakit network and 5620 window terminal. Datakit has two separate remote login equivalents, plus "live" remote exec. For machines with a "real" hardware interface, there's a variable called "DKEXPORT", which is a list of the environment variables you want passed to the remote machine on remote login and remote execution. So I set DKEXPORT="TERM,LINES,COLUMNS,WHATEVER" and the current value of those variables is set in the remote environment. For machines that only have RS-232 connections, you get a "cu" equivalent, with no special support. When I'm talking to one of them, my .profile prints an escape sequence that the terminal program responds to with LINES=xx; COLUMNS=yy; export LINES COLUMNS which is boring but almost always enough, and offeres a csh-variant. Neither of these programs tells the remote system to set the various ioctl modes associated with the windowing terminal, but the most applications look for the environment variables first. -- # Thanks; # Bill Stewart, AT&T Bell Labs 2G218, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs
-----------[000059][next][prev][last][first]---------------------------------------------------- Date: 5 Mar 88 01:35:30 GMT From: jerry@oliveb.olivetti.com (Jerry Aguirre) To: comp.protocols.tcp-ip Subject: Re: rsh equivalent
In article <2028@ho95e.ATT.COM> wcs@ho95e.UUCP (46323-Bill.Stewart,2G218,x0705,) writes:
>My big gripe with the r* programs is that they lose UNIX semantics.
>For instance, rsh doesn't return the condition code from the remote process -
> rsh foovax false
>returns true if the connection succeeded.
This is a real anoyance when writing automated procedures. I did find a
work around though. Run something like:
rsh foovax "command && echo CMDOK" | grep CMDOK
The returned status will now be that of the grep and will reflect the
success of the remote (but not its actual status). This is good enough
for scripts that need to check command success on remote systems.
> Less important but harder to fix,
>rsh is non-interactive; I've gotten real used to Datakit's remote execution
>capabilities ("dk other3b /bin/ksh").
I don't understand what you mean by non-interactive. Certainly there is
no tty or terminal type so screen oriented editors and such don't work.
But I frequently run "rsh foovax sh -i" when I need to poke around on
another system. Certainly that qualifies as interactive, at least as
compared to batch. Certain programs do cause problems as they buffer
their I/O when run under rsh but enough work for examining or fixing
file modes, ownership, and such.
> It would also be nice to have a
>convenient rcp-variant that didn't update modification times.
It wasn't all that long ago that "cp" acquired its "-p" option. In
practical terms I usually find that I want to move multiple files and
preserve more than even "cp -p" does. I usually run:
tar cF - files ... | rsh 'cd dir && tar xpF -'
This keeps dates, ownership, directory, and link structure. And then
there is "rdist".
Jerry Aguirre
-----------[000060][next][prev][last][first]---------------------------------------------------- Date: 5 Mar 88 03:02:06 GMT From: chris@ACC-SB-UNIX.ARPA (Chris VandenBerg) To: comp.protocols.tcp-ip Subject: TN3270 on Terminal Servers
An open letter to all those involved in the design of TCP/IP terminal servers... Is there some logical reason why none of the currently available TCP/IP terminal servers do not employ a TN3270 mode? I have long thought this would be a major selling point, now that the IBM 'frame environment is becoming an ever-present player in the scheme of interoperability. I am fully aware of the "cpu hog" nature of the 3270 to ASCII conversion but, let's face it, we've got some pretty capable CPU chips in these boxes. Am I the only one who sees that the need has yet to be filled(this is certainly the classic "rhetorical question". I make no claims to fore- sight but I AM a well-recognized Monday morning quarterback...). Have I missed a point somewhere? Please address replies and/or comments to me personally and I will forward appropriate text to the net. Thanks in advance, Chris VandenBerg Advanced Computer Communications(ACC) chris@acc-sb-unix.arpa Disclaimer - Comments are my own and do not reflect the viewpoints of my employer or (frankly) ANYONE ELSE I know.
-----------[000061][next][prev][last][first]---------------------------------------------------- Date: 5 Mar 88 18:51:03 GMT From: chris@ACC-SB-UNIX.ARPA (Chris VandenBerg) To: comp.protocols.tcp-ip Subject: (none)
From tom@tut.cis.ohio-state.edu Sat Mar 5 09:39:17 1988
Received: by ACC-SB-UNIX.ARPA (5.51/4.7)
id AA03947; Sat, 5 Mar 88 09:39:12 PST
Received: by tut.cis.ohio-state.edu (5.54/2.0)
id AA12473; Sat, 5 Mar 88 12:38:51 EST
Date: Sat, 5 Mar 88 12:38:51 EST
From: tom@tut.cis.ohio-state.edu (Tom Easterday)
Message-Id: <8803051738.AA12473@tut.cis.ohio-state.edu>
To: chris@acc-sb-unix.arpa
Subject: 3270 terminal servers
Status: R
Chris,
Bridge Corporation makes a TCP/IP terminal server called the CS1-SNA which
does 3270 emulation on various terminal types. We (Ohio State) have one
installed, connected to our CICS system. It works well but has some
disconnection problems. Also, many of its advertised features do not yet
work although Bridge says the next software release will implement these
and correct the disconnect problems. A word of warning (which is solely
my opinion) Bridge has promised alot but has yet to deliver, also it is
tough to get much technical help from them (at least in our area). The
box is still worth a try and who knows, that software could show up on the
door step anyday :-) Let me know if you hear of any others as we would
likely be interested in trying them. Thanks.
Tom Easterday
The Ohio State University
Instruction & Research Comp Cntr
tom@tut.cis.ohio-state.edu
-----------[000062][next][prev][last][first]---------------------------------------------------- Date: 5 Mar 88 23:43:36 GMT From: philipp@LARRY.MCRCIM.MCGILL.EDU (Philip Prindeville [?]) To: comp.protocols.tcp-ip Subject: Re: TCP/IP Terminal Servers
Well, if the terminal is hardwired to a port, you could configure
that port's information to include a terminal type. Also, the
server could download into itself termcap(-like) information
to support supdup, which would do the appropriate translation.
Terminals? Everything: hp-26*, vt{52,100,200}, ansi, tvi*, etc.
As for supporting supdup, I'm not sure. Just about every place
I've worked has installed it (mostly universities). And the
standard BSD distribution comes with supdup in the /etc/services
file, even if the /etc/inetd.conf doesn't include a server.
My guess is that if it were supported by a terminal server
manufacturer, it would be a real win, and they might get a
leg up on the competition. But please, oh please, make
scrolling the default.
-Philip
-----------[000063][next][prev][last][first]---------------------------------------------------- Date: 5 Mar 88 23:45:23 GMT From: philipp@LARRY.MCRCIM.MCGILL.EDU (Philip Prindeville [?]) To: comp.protocols.tcp-ip Subject: Re: TCP/IP Terminal Servers
Sorry, that last one should have been private... -Philip
-----------[000064][next][prev][last][first]---------------------------------------------------- Date: 6 Mar 88 04:50:48 GMT From: mb@tulane.tulane.edu (Mark Benard) To: comp.protocols.tcp-ip,comp.unix.questions Subject: TELNET character mapping problem
I have a LAN with a mixture of vendor products: Sun, Pyramid, and a VAX running VMS and using EXCELAN's EXOS product. I am having trouble with the mapping of two control characters (^C and ^M) from the users connected across the network from the VAX via Excelan's TELNET. For the VAX to Pyramid connection, ^M is appearing as ^J. For the VAX to Sun connection, when running Gnu Emacs, ^C is appearing as a ^@. Outside of Emacs, it still generates SIGINT. ^M is mapped ok. In both cases I am setting my terminal to be VT100 across the board. Any ideas on how I can alter the mapping? And why is it happening? Is it just slightly different (i.e., incompatible) implementations of TELNET? -- Mark Benard Department of Computer Science INTERNET: mb@TULANE.EDU Tulane University USENET: pyramid!tulane!mb New Orleans, LA 70118 BITNET: mb%TULANE.EDU@RELAY.CS.NET (or pyramid!tulane!mb at DECWRL.DEC.COM)
-----------[000065][next][prev][last][first]---------------------------------------------------- Date: Sun 6 Mar 88 12:55:45-PST From: Alan Larson <LARSON@KL.SRI.COM> To: karn@ka9q.bellcore.com Cc: van@LBL-CSAM.ARPA, tcp-ip@SRI-NIC.ARPA Subject: Re: TCP rate control?
> To see this, consider the case of 10 simultaneous FTP/TCP transfers > taking place through a common bottleneck link. The gateway feeding this > link has only 5 packet buffers. Even if the ten TCPs have their > congestion windows permanently set to 1 packet, there will be room for > only half of their packets in the buffer queue at any one time... Phil, This seems an important point. What would people think of a system where only 50% of the senders will transmit in a time window would be appropriate? Who transmits could be determined by having each of the senders transmit with 50% probability. The senders would need to determine the correct probability of send in any given interval. This might just be the result of the congestion window calculation when it is less than one segment. Alan -------
-----------[000066][next][prev][last][first]---------------------------------------------------- Date: 6 Mar 88 06:44:18 GMT From: karn@KA9Q.BELLCORE.COM (Phil Karn) To: comp.protocols.tcp-ip Subject: TCP rate control?
Van, It was fun to talk to you in San Diego. Now I'm sorry I didn't go to the earlier IETF meetings. Many thanks for the patient explanations of your TCP congestion control techniques; I'm continuing to implement them in my own TCP. However, I still think something further may still be required, at least on the (admittedly pathological) packet radio links I use. My reasoning goes as follows. You never allow the congestion window to decrease below one MSS. You argue that letting it go lower would increase header overhead, wasting link (and network) bandwidth when it can least be spared. I agree. However, this limits your ability to throttle the connection's bandwidth further should even one MSS-sized packet per connection be too much. To see this, consider the case of 10 simultaneous FTP/TCP transfers taking place through a common bottleneck link. The gateway feeding this link has only 5 packet buffers. Even if the ten TCPs have their congestion windows permanently set to 1 packet, there will be room for only half of their packets in the buffer queue at any one time, and there will be a steady-state 50% packet loss. True, the link itself will be efficiently utilized, but the upstream links will be carrying lots of retransmissions. Even if these links aren't themselves congested this seems undesirable. Here's another way to look at the problem. Assume the link bandwidth is 10 packets/second. Then the maximum queuing delay that can be imposed on the sending TCPs by the gateway is 5 packets / 10 packets/sec = 1/2 sec. Since the bandwidth required by any one TCP is the window size (1 packet in this case) divided by the round trip time (1/2 sec -- we'll assume that the smaller acks encounter negligible delay) each of the ten TCPs will still attempt to generate two packets per second, for a total offered load of 20 packets per second. This is twice the link's capacity, so half of the generated packets will be dropped. So it seems that some sort of rate control timing is necessary. In other words, if packets are still being lost even with a 1-packet window, then the sending TCP should insert increasing amounts of delay between incoming ACKs and outgoing data packets. I suppose there are lots of ways this could be done (I'll probably have the retransmission timer do double-duty) but as you point out it's important to adjust the delays so as to produce linear changes in the offered load. If I heard correctly, certain gateways on the Internet can only buffer two packets at a time, so perhaps this scheme would help in places other than my pathological 1200 baud packet radio channels. Comments? Rebuttals? (I'd be happy if you proved me wrong so I could avoid implementing this!) Phil
-----------[000067][next][prev][last][first]---------------------------------------------------- Date: 6 Mar 88 15:07:37 GMT From: cpw%sneezy@LANL.GOV (C. Philip Wood) To: comp.protocols.tcp-ip Subject: Re: campus ethernet help?
One does not Internetwork using bridge links. Tis a non sequitur. Phil Wood cpw@lanl.gov LANL
-----------[000068][next][prev][last][first]---------------------------------------------------- Date: 6 Mar 88 20:24:29 GMT From: budden@tetra.NOSC.MIL (Ray A. Buddenberg) To: comp.protocols.tcp-ip Subject: Re: maximum Ethernet throughput
definition to give a straight answer. Unless you know what reference model layer, you can't properly reply. Similarly, the number of nodes on the net makes an awful lot of difference. OK, to the ethernet problem. 10 Mbit/sec at the physical layer turns into about 4 Mbits at the network layer (neglecting trivial cases of only two nodes on the network). This decrease is due to the carrier sense multiple access characteristics of ethernets. At the transport layer, this tends to decrease further to around 1 Mbit due to transport overhead. The figure is plastic depending on whose TCP you are using. Unless you've got a lot of overhead in the higher layers, this 1Mbit figure is pretty much the application-to application value. So what does this all mean? At the network layer, a '4 Mbit' 802.5 token ring gets just as much data thru as a '10 Mbit' ethernet. Caveat emptor when the salesman comes to call. As higher speed networks become common -- FDDI starts out at 100 Mbit at the physical and network layers, the Transport layer becomes an even more obvious bottleneck. Indeed, it appears that the bottleneck may be shifting from the LAN media toward the DMA hardware. Rex Buddenberg
-----------[000069][next][prev][last][first]---------------------------------------------------- Date: 6 Mar 88 21:35:26 GMT From: kurt@hi.unm.edu (Kurt Zeilenga) To: comp.protocols.tcp-ip Subject: EGP networks reachable
I would like to add a network to a MILnet gateway's EGP'er. Technically, I have everything ready to go. But, I assume, some sort of registration is needed. Hints would be greatly appreciated. Thanks -- Kurt (zeilenga@hc.dspo.gov)
-----------[000070][next][prev][last][first]---------------------------------------------------- Date: 7 Mar 88 09:09:00 PST From: "Keith McCloghrie" <kzm@twg.arpa> To: "karn" <karn@ka9q.bellcore.com> Cc: <van@lbl-csam.arpa>,<tcp-ip@sri-nic.arpa>, <kzm@twg.com> Subject: Re: TCP rate control?
Phil, Your comments to Van state : > You never allow the congestion window to decrease below one MSS. You > argue that letting it go lower would increase header overhead, wasting > link (and network) bandwidth when it can least be spared. I agree. > However, this limits your ability to throttle the connection's bandwidth > further should even one MSS-sized packet per connection be too much. > > To see this, consider the case of 10 simultaneous FTP/TCP transfers > taking place through a common bottleneck link. The gateway feeding this > link has only 5 packet buffers. Even if the ten TCPs have their > congestion windows permanently set to 1 packet, there will be room for > only half of their packets in the buffer queue at any one time, and > there will be a steady-state 50% packet loss. True, the link itself > will be efficiently utilized, but the upstream links will be carrying > lots of retransmissions. Even if these links aren't themselves > congested this seems undesirable. Your analysis of steady-state 50% packet loss, does not take into account the retranamission timeout and backoff, ie. each packet dropped by the net causes the next packet (on the dropped packet's TCP connection) to be a retransmission which is inserted into the network at a later time than it would have been if the original packet had gotten through and been acked. Also, the returning acks are themselves subject to be queued/dropped in the gateways. But, I agree with the conclusion you are drawing : that the network has a finite amount of buffering (say N packets), and so once there are more than N active TCP connections, it is impossible to reach the steady-state where one packet per connection is buffered in the net; in this situation the network has only one way to compensate which is to drop packets; and without a rate-based control, the senders have no way to reduce their offered load below the one packet per active connection. > So it seems that some sort of rate control timing is necessary. In > other words, if packets are still being lost even with a 1-packet > window, then the sending TCP should insert increasing amounts of delay > between incoming ACKs and outgoing data packets. Exactly. Keith.
-----------[000071][next][prev][last][first]---------------------------------------------------- Date: Mon, 07 Mar 88 09:50:31 -0500 From: Mike Brescia <brescia@PARK-STREET.BBN.COM> To: Kurt Zeilenga <hi!kurt@HC.DSPO.GOV> Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: EGP networks reachable
I would like to add a network to a MILnet gateway's EGP'er.
If you have registered the network with the NIC (hostmaster@sri-nic.arpa) to
acquire a valid net number , and registered the gateway also to acquire a
valid autonomous system number, you are ready.
If you notify 'gateway@bbn.com' when you actually start coming up, we know who
to contact if we see problems, or who to expect a call from if you see them.
Mike Brescia, for 'gateway@bbn.com'
-----------[000072][next][prev][last][first]---------------------------------------------------- Date: Mon, 7 Mar 88 10:39:46 MST From: cpw%sneezy@LANL.GOV (C. Philip Wood) To: wpl%at6-03@LANL.GOV Cc: tcp-ip@sri-nic.arpa Subject: Re: Slow response in rlogin to Brookhaven
I have received a number of complaints about the connection between nets 128.165.32 and 192.12.15. Does anyone have an inkling as to why the echo turnaround is over 10 seconds or non existent? An example complaint: > "It's always been bad. I tried it last yesterday. It's not working at > all at the moment. Is there any trick ... " Is there an official channel to voice complaints? Phil Wood (cpw@lanl.gov)
-----------[000073][next][prev][last][first]---------------------------------------------------- Date: 7 Mar 88 04:53:26 GMT From: hedrick@athos.rutgers.edu (Charles Hedrick) To: comp.protocols.tcp-ip, BEAME@MCMASTER.BITNET Subject: Re: IEEE 802.3 LAN Considerations vs. 802.5 Token Ring
The early Ethernet design studies claimed you could get at least 9Mbits out of Ethernet. However you normally don't want to configure networks so that they are working that way. THis is true for any network, whether Ethernet or token. In order to give people good response on demand, you want peak capacity to be about a factor of 10 above what you expect typical useage to be. In fact people are now getting transfers in excess of 1Mbit over Ethernet. (I've heard claims of several Mbits with highly tuned software on fast machines, but 1Mbit is fairly common these days.) In order to allow several things to go on at once, this says you really do want a medium that's at least 10Mbit. This is why the whole business about token delivering predictable response is so wierd. Even if it is true that a heavily loaded token system splits bandwidth evenly, nobody in his right mind would configue a network so that it runs at full capacity for anything more than a few milliseconds at a time. (And anecdotal evidence is that token rings aren't really any more predictable anyway.) The main argument for IBM token ring is when you have lots of IBM equipment and want to do things like have your IBM 3270 cluster controllers talk over the LAN. This is quite a reasonable thing to do. On one of our campuses we expect to set up a token ring for administrative use. However we expect to limit it to that. It will handle 3270's and IBM PC's on administrative desks. For security reasons, we don't want any student traffic on the same LAN. So we'll use Ethernet and related technology for most of the general traffic. Unless you have this sort of specific need for IBM-related networking, Ethernet has the advantages of ubiquity and robustness. That is, you can get Ethernet support for everything. Token ring hasn't been a great success in the market. According to all the guys in Datamation it's been about to wipe out Ethernet for the last 5 years now, but somehow it has never taken off. Ethernet was also designed to be very robust. You can install new taps without disrupting traffic. People have violated the specs in all sorts of ways and still gotten it to work. It is very conservative technology, and very well understood. One of the chief designers for a well-known token ring company gave a talk here a few years ago. He showed a bunch of performance statistics and sort of surprised people by saying that as far as he was concerned at 10Mbits and lower, token ring has only a minor performance advantage. Certainly IBM's attempt to convince people that 4 > 10 is simply absurd. It would be impossible to do Ethernet at 100Mbits (cables would be restricted to 50 meters in length), so all new protocols being designed are token ring. But that has led some people to think that somehow token ring is a newer and better technology. Not so. It's that we are beginning to move to faster technology, and token rings make sense there. For 10Mb and slower, the tradeoffs are different, and there are situations where each is faster. In general Ethernet is better for a random mix, e.g. terminal traffic and random FTP's, whereas token ring would be better for certain kinds of graphics applications or real-time control work. For most LAN's I'd say you're going to be better off to stick with Ethernet unless you have good reason to do otherwise. The magic initials IBM do carry some weight. When they first released the token ring, I can see why people thought it was bound to succeed. But IBM does sometimes fail to dominate an industry. Look at their attempt to foist PL/I on us all. Token ring looks like one of these cases.
-----------[000074][next][prev][last][first]---------------------------------------------------- Date: 7 Mar 88 05:13:56 GMT From: eric@otc.oz (Eric Dutkiewicz) To: comp.protocols.tcp-ip,comp.dcom.lans Subject: Fax number wanted
Does anyone know the Fax Number of Siecor Electro-Optic Products who are located at Research Triangle Park in North Carolina, USA ? If so, please reply directly to me by E-mail. Thanks in advance! Eric Dutkiewicz |||| OTC || ACSnet: eric@otc.oz UUCP: tuunet,mcvax}!otc.oz!eric Snail: GPO Box 7000, Sydney 2001, Australia
-----------[000075][next][prev][last][first]---------------------------------------------------- Date: Mon, 7 Mar 88 11:55:44 EST From: "James B. VanBokkelen" <JBVB@AI.AI.MIT.EDU> To: munnari!vuwcomp!nezsupp!rossw@UUNET.UU.NET Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: tn3270, what and where
TN3270 is a special subset of Telnet, that sends and receives data in EBCDIC block-mode, with 3270 control sequences embedded. Non-EBCDIC machines effectively need a 3270 emulator between the network connection and the local display. Greg Minshall did a 'tn3270' for Unix which does this function. 'tn3270's are also available for DOS PCs, from us and IBM, and most IBM mainframe TCP/IP implementations come with both a client and a server. Note that the recent RFC detailing a "tn3270" standard is *not* the one that is actually in general use. The RFC has not yet been implemented anywhere that I know of (unless someone inside IBM has done so). I'm not going to do it until I have a server I can test against... James VanBokkelen FTP Software Inc..
-----------[000076][next][prev][last][first]---------------------------------------------------- Date: Mon, 7 Mar 88 11:56:34 EST From: "James B. VanBokkelen" <JBVB@AI.AI.MIT.EDU> To: chris@ACC-SB-UNIX.ARPA Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: TN3270 on Terminal Servers
I assume that memory is a question, too, because the server vendors really want to do it like Greg Minshall did, with support for many different asynch terminals, which needs 1) the 3270 emulator, with one or more screen images worth of buffering, 2) a curses-like module, with more buffering and code, and 3) a TCP which can handle decent-sized data transfers efficiently. Many of them still rely on small windows to cram N ports into 256K RAM or something like that. James VanBokkelen FTP Software Inc.
-----------[000077][next][prev][last][first]---------------------------------------------------- Date: Mon, 7 Mar 88 14:56:34 EST From: bzs%bu-cs.bu.edu@bu-it.BU.EDU (Barry Shein) To: munnari!vuwcomp!nezsupp!rossw@uunet.uu.net Cc: tcp-ip@sri-nic.ARPA Subject: tn3270, what and where
>Hi, people here are just starting to mumble about 3278 type terminals, >connected to (yeuch) IBM type main(larf larf)frame machines, connected to >unix boxes over the ethernet. >Thanks in advance, Ross Wakelin You're talking about sitting at a 3278 talking to an IBM mainframe and then telnet'ing to a Unix (or other full-duplex ASCII system.) Basically, you can't *really* do it, although I can tell you how... The problem is that the 3278 is a half-duplex device. When you type in characters they are not sent to the host until an ENTER or other PF key is struck, the plain text chars are buffered locally in the terminal controller. Much of the software on Unix and other hosts depend on seeing every character as it is typed to perform properly (although full-screen editors are the most extreme case even simply deleting a character on a line-oriented command expects this capability.) There is TCP software/hardware that supports Telnet available on the IBM mainframe, for example Wiscnet (the current IBM TCP/IP product) for VM or ACC's products for MVS. You can telnet with this to a Unix or similar host. It will be very similar to logging in from a paper terminal. No full screen (eg. editors) software will be useable. I would imagine there are people for whom this is satisfactory (eg. you just want to recompile and run a program who's input/output is all to disk files.) We all did live with this sort of environment for years. The only other way I know of defeating this are black boxes which splice into your 3278 coax and present an RS232 out the side. There's a switch (similar to an A/B port selector), in one position you are using the 3278 as such onto the IBM via the coax, in the other position the black box uses the 3278's screen/keyboard more or less directly to emulate a VT100 over the RS232 line which must then be attached to something else (eg. a terminal server.) If there are any other solutions (eg. mods on the 3270 controllers) I too would be curious, time marches on, who knows, someone may have something new. -Barry Shein, Boston University
-----------[000078][next][prev][last][first]---------------------------------------------------- Date: 7 Mar 88 10:14:23 GMT From: pdb@sei.cmu.edu (Patrick Barron) To: comp.protocols.tcp-ip Subject: Re: TCP/IP Terminal Servers
In article <8802292140.AA14355@scotty.dccs.upenn.edu> hagan@SCOTTY.DCCS.UPENN.EDU (John Dotts Hagan) writes: >I would also go on record as saying the Bridge products we evaulated about >12 months ago were not good at all. However, a new major release of software >is out and I have no experience with it. Note that Bridge's new software release, TCP 20000, needs at least 512K of memory to run on the CS/100. I have a few 256K CS/100's, and found out about this some time after Bridge promised that TCP 20000 would solve the problems I was having with the older versions, and would include a domain name resolver to boot. My sales rep tells me there'll be a TCP 19000 out "soon" that works as well as TCP 20000, but will run on a 256K CS/100. Of course, they had to cut out a few features to make it fit. Like the domain name resolver, for instance.... Sigh...Since it would cost Far Too Much to upgrade them to 512K, we're probably just going to scrap them at this point and buy Annexes. --Pat.
-----------[000079][next][prev][last][first]---------------------------------------------------- Date: Mon, 7 Mar 88 15:24:40 EST From: Mills@UDEL.EDU To: ineng-interest@isi.edu Cc: tcp-ip@sri-nic.arpa Subject: NTP update
Folks, As a result of several comments received from the true clockwatchers among us, I have updated the new Network Time Protocol draft document announced recently. The latest revision includes several editorial changes, several amendments and clarifications to the protocol specification and an extensive discussion and comparison of NTP and other proposed time-synchronization protocols and models, including Unix 4.3bsd timed and other schemes based on convergence and consistency (agreement) algorithms. For those brave enough to endure a 127K-octet transfer or foolish enough to care about such an esoteric (but fun) subject, the document is anonymously ftpable from louie.udel.edu as the file pub/ntp.doc. I would like to make this the final resist before the RFC etch. As always, your comments and suggestions are welcome. As one of the intended applications of this technology is at gigabit speeds, your comments on the generic self-organizing, hierarchical master-slave, returnable time (to put it gloriously, but accurately) architecture would be most interesting. Dave
-----------[000080][next][prev][last][first]---------------------------------------------------- Date: 7 Mar 88 12:38:52 GMT From: peter@nuchat.UUCP (Peter da Silva) To: comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.misc,comp.windows.misc Subject: Re: rlogin from windows
The right thing to do for this one is to have the terminal program send a NEWSIZE escape sequence to the application when you resize the window. Something like "\E[%d;%dZ". After the application has sent a newsize-on sequence to the terminal program, of course. The terminal should probably send one newsize message immediately upon receiving that message to get things synched up right in the first place. Flames always welcome :->. -- -- a clone of Peter (have you hugged your wolf today) da Silva `-_-' -- normally ...!hoptoad!academ!uhnix1!sugar!peter U -- Disclaimer: These aren't mere opinions... these are *values*.
-----------[000081][next][prev][last][first]---------------------------------------------------- Date: 7 Mar 88 14:50:31 GMT From: brescia@PARK-STREET.BBN.COM (Mike Brescia) To: comp.protocols.tcp-ip Subject: Re: EGP networks reachable
I would like to add a network to a MILnet gateway's EGP'er.
If you have registered the network with the NIC (hostmaster@sri-nic.arpa) to
acquire a valid net number , and registered the gateway also to acquire a
valid autonomous system number, you are ready.
If you notify 'gateway@bbn.com' when you actually start coming up, we know who
to contact if we see problems, or who to expect a call from if you see them.
Mike Brescia, for 'gateway@bbn.com'
-----------[000082][next][prev][last][first]---------------------------------------------------- Date: 7 Mar 88 15:57:41 GMT From: jas@MONK.PROTEON.COM (John A. Shriver) To: comp.protocols.tcp-ip Subject: Digital DECnet <-> Ethernet address translation
The AA:00:04:xx:xx addresses are indeed DECnet Phase IV addresses. The low two bytes are the 16-bit DECnet node address, with the low 10 bits node, and the high 6 bits area. It is inserted in PDP-11/VAX byte order, so it looks backwards printed Ethernet/big-indian. (All of DECnet uses PDP-11 byte order.) Note that they are setting the locally administered bit in the prefix (02 in the first byte), so they are not claiming that these addresses are globally unique. Presumably they paid their $300 for that block from Xerox. Well, from my understanding, the architects did not know that ARP existed, so that option did not present itself to them. They chose this scheme because it was simple. It is documented in "DECnet DNA Phase IV Ethernet Data Link Functional Specification", AA-Y298A-TK. This is not required in DECnet Phase V. Since it will use ISO CLNS as a network protocol, it will support big long ISO addresses (12 bytes?). The little old 6 byte Ethernet address gets wrapped up somewhere inside these big addresses, so they can use the PROM address. Phase V will also eliminate their need for name-to-address translation tables, by provide a well-designed naming service. It looks much more flexible and dynamic than the Internet's Domain Name System.
-----------[000083][next][prev][last][first]---------------------------------------------------- Date: 7 Mar 88 18:41:55 GMT From: kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) To: comp.protocols.tcp-ip Subject: Re: IEEE 802.3 LAN Considerations vs. 802.5 Token Ring
Hedrick, as always, makes a clear and concise exposition of Ethernet versus Token Ring. I think most users don't have a choice with network technology, you take what your vendor gives you. 802.5 for Big Blue, 802.3 for DEC and Un*x. I see great usefulness for Token Ring bandwidth allocation schemes, such as proposed in the IEEE MAN work, for allocating bandwidth and minimizing packet delays for voice traffic versus data. I'm not really looking to integrate voice/data on the campus, but it will be indispensible in the MAN standard. Coupled with the need for high bandwidth and the preference for fiber (what ever happened to the promises of the CATV evangelists?), Token Ring (not 802.5) is a clear technology winner. This means that TR will trickle down to eventually supplant Ethernet, although there is no technical reason to do so until 50Mbps link speeds are required for workstations. (Can't wait!) Kent England Boston University
-----------[000084][next][prev][last][first]---------------------------------------------------- Date: 7 Mar 88 20:54:31 GMT From: rkh@mtune.ATT.COM (964[jak]-Robert Halloran) To: comp.protocols.tcp-ip Subject: Re: TLI?
In article <2584@auscso.UUCP> dewey@auscso.UUCP (Dewey Coffman) writes:
> Does anyone have any information or pointer to information about
> a new product called TLI out of AT&T(?) that is supposed to
> replace tcp/ip on UNIX? E-mail is preferable, but post if
> of general interest.
TLI (Transport Level Interface) is NOT a replacement for TCP/IP. It
is an program-level interface to the protocol, and is intended as
an alternative to the BSD socket library. It is implemented for
the AT&T-supported local networks such as TCP/IP, Starlan and Datakit
(insert appropriate trademarkings here) as of System V release 3, with
a common set of routines for open/close/read/write/etc. The WIN/3B
package for TCP/IP on the 3Bx machines provides most of the system calls
for SVr2 machines, as well.
Hope this clarifies things.
Bob Halloran
Distributed Programming
Tools Group
=========================================================================
UUCP: {ATT-ACC, rutgers}!mtune!rkh DDD: (201)957-6034
Internet: rkh@mtune.ATT.COM
USPS: AT&T DSG, 200 Laurel Ave Rm 3G-314 Middletown NJ 07748
Disclaimer: If you believe I'm speaking for anyone but myself,
you're sadly mistaken.
Quote: "Good morning, the Russians still beating the pants off us in space?"
-- Opus to Oliver, "Bloom County"
=========================================================================
-----------[000085][next][prev][last][first]---------------------------------------------------- Date: 7 Mar 88 21:38:53 GMT From: kurt@hi.unm.edu (Kurt Zeilenga) To: comp.protocols.tcp-ip Subject: Re: EGP networks reachable
In article <23535@hi.unm.edu>, kurt@hi.unm.edu (Kurt Zeilenga) writes: > I would like to add a network to a MILnet gateway's EGP'er. > Technically, I have everything ready to go. But, I assume, > some sort of registration is needed. Hints would be greatly > appreciated. Thanks Thanks for all the comments. I found the problem. Time. When I was playing with the EGP'er I was expecting the core to pick up on the routes quickly. After leaving the EGP'er up all night, everything was working fine in the morning. Happy netting.... -- Kurt (zeilenga@hc.dspo.gov)
-----------[000086][next][prev][last][first]---------------------------------------------------- Date: 7 Mar 88 22:05:12 GMT From: andrew@mitisft.Convergent.COM (Andrew Knutsen) To: comp.protocols.tcp-ip Subject: Re: Convergent Technologies
in article <8803020723.AA11973@ucbvax.Berkeley.EDU>, CF4A8X@IRISHMVS.BITNET ("Mark D. Eggers 239-7258", 219) says:
>
> We are installing a campus network based on proNET 80,
> tcp/ip, and DECnet. One of the first colleges to connect
> will be the College of Engineering. They have several
> Convergent Technologies 'miniframe' boxes that run System V
> Unix and have tcp/ip. According to the grad student in
> charge of their networks, they have the latest tcp/ip
> software from Convergent Technologies.
>
> Unfortunately, there are problems.
>
Unfortunately, the Miniframe is an obsolete product. It has an
ethernet interface different from the MightyFrame line, so the actual
latest software does not run on it. The software you have is probably
several years old, and is based on 4.2BSD rather than 4.3, as our Streams
(latest) product is.
Actually, you shold not be having problems with (non-subnet) route
or ARP. Perhaps you meant routed; true, that isnt supported but should port
easily. There does seem to be a bug with some kinds of internet addresses,
and subnets were not supported in 4.2. I dont know about the Ultrix hang;
you might want to try ifconfig'ing -trailers on the Mini...
If you are interested, I can check into getting you a source
release of just the network part of the Mini kernel, so you can upgrade it.
I'm an engineer though, so no promises.
Andrew Knutsen
Convergent Technologies
(408) 435-3623
-----------[000087][next][prev][last][first]---------------------------------------------------- Date: Tue, 08 Mar 88 10:18:33 -0500 From: Mike Brescia <brescia@PARK-STREET.BBN.COM> To: "C. Philip Wood" <cpw%sneezy@LANL.GOV> Cc: wpl%at6-03@LANL.GOV, tcp-ip@SRI-NIC.ARPA Subject: Re: Slow response in rlogin to Brookhaven
complaints about the connection between nets 128.165.32 and 192.12.15.
You need to start with the people in charge of the gateways on arpanet
(rochester) and milnet (lanl), and trace out the route. For each gateway,
find out if it is dropping packet, or suffering from long queueing delays.
This will be an interesting exercise in following the pointing fingers.
If you find a direct problem involving the core gateways, call the Network
Operations Center (NOC) at 800-492-4992, and be clear about describing what
sort of gateway problem you suspect. Most of the people who would answer are
more adept at handling the PSN problems in Arpanet and Milnet.
Is there an official channel to voice complaints?
I hope you will be voicing observations rather than gripes. Name (and
address) of gateways and nets will help.
Mike
-----------[000088][next][prev][last][first]---------------------------------------------------- Date: 8 Mar 88 04:48:52 GMT From: bakken@hrsw2.UUCP (David E. Bakken) To: comp.protocols.tcp-ip,comp.sys.apollo,comp.sys.ibm.pc.rt Subject: SLIP on the IBM RT (w/AIX) or Apollo workstations
Does anyone know of a port of SLIP to the IBM RT (running AIX) or the Apollo workstations? If so, please email me with the details. Thanks!!!! -- Dave Bakken Boeing Commercial Airplanes (206) 277-2571 uw-beaver!apcisea!tahoma!hrsw2!bakken Disclaimer: These are my own views, not those of my employers. Don't let them deter you from buying the 747 you've been saving hard for.
-----------[000089][next][prev][last][first]---------------------------------------------------- Date: Tue, 8 Mar 88 15:21:54 EST From: "Drew M. Powles" <dpowles@ccd.bbn.com> To: tcp-ip@sri-nic.arpa Cc: dpowles@ccd.bbn.com Subject: IP/DDN X.25 implementation survey
I am doing a survey on available TCP/IP implementations over DDN Standard X.25 and would appreciate any and all information on the following aspects (the vendor guide form the NIC doesn't go into sufficient detail): 1) which implementations negotiate precedence for a DDN Standard X.25 call as defined on page 1-481 (volume 1) of the DDN Protocol Handbook and the mapping of precedence from IP to DDN Standard X.25 as defined on 1-494 of the same. Additionally, what mechanisms are provided allow a user or application process (i.e. FTP, Telnet, etc) to specify the precedence of a session so that the precednce level is passed down to the IP layer? 2) which implementations can utilitize DDN X.25 Logical addressing as specified in pages 1-495 thru 1-498 of the DDN Protocol Handbook - which includes mapping from IP addresses (either fully implemented or partially implemented)? many thanks for your help! Drew Powles BBN Communications
-----------[000090][next][prev][last][first]---------------------------------------------------- Date: 8 Mar 1988 20:44-PST From: Steve Deering <deering@pescadero.stanford.edu> To: Jon Peha <peha@spam.istc.sri.com> Cc: tcp-ip@sri-nic.arpa Subject: Re: remote broadcasts
Jon, Concerning "remote broadcast" (also known as "directed broadcast"), you wrote: I am quite aware of the dangers of such packets. One caused a broadcast storm on our ethernet effectively bring down the net. As far as I know there is no defence against one of these packets coming in from the Internet. Could you explain in more detail what that one broadcast packet contained that effectively brought down your network, and why the fact that it came from another network was significant? I realize that there are lots of bugs out there in the way hosts handle broadcasts (and multicasts), but surely it's time to fix the bugs and make our hosts a little more robust in the face of unwanted packets, rather than imposing arbitrary gateway controls to protect the hosts from their own stupidity. As you observed, multi-destination datagrams can be a valuable tool; rather than imposing gateway controls, I suggest that the right defence is: 1) Fix hosts to ignore (i.e., silently discard) packets that they are not equiped to handle properly. 2) Insist on the use of multicast, rather than broadcast, so that unwanted packets can be ignored efficiently. Steve Deering
-----------[000091][next][prev][last][first]---------------------------------------------------- Date: 8 Mar 88 14:51:37 GMT From: swb@TCGOULD.TN.CORNELL.EDU (Scott Brim) To: comp.protocols.tcp-ip Subject: X.400<->RFC822
I know work has been going on for a while on gateways between X.400 mail and RFC822 mail (ISO and DoD IP-based Internet). Could someone give me pointers and contacts to find out how the work is progressing, what is available, and what will be available this year? Thanks very much....Scott
-----------[000092][next][prev][last][first]---------------------------------------------------- Date: 8 Mar 88 15:18:33 GMT From: brescia@PARK-STREET.BBN.COM (Mike Brescia) To: comp.protocols.tcp-ip Subject: Re: Slow response in rlogin to Brookhaven
complaints about the connection between nets 128.165.32 and 192.12.15.
You need to start with the people in charge of the gateways on arpanet
(rochester) and milnet (lanl), and trace out the route. For each gateway,
find out if it is dropping packet, or suffering from long queueing delays.
This will be an interesting exercise in following the pointing fingers.
If you find a direct problem involving the core gateways, call the Network
Operations Center (NOC) at 800-492-4992, and be clear about describing what
sort of gateway problem you suspect. Most of the people who would answer are
more adept at handling the PSN problems in Arpanet and Milnet.
Is there an official channel to voice complaints?
I hope you will be voicing observations rather than gripes. Name (and
address) of gateways and nets will help.
Mike
-----------[000093][next][prev][last][first]---------------------------------------------------- Date: 8 Mar 88 15:42:32 GMT From: kevin@vger.NBI.COM (Kevin Brooks) To: comp.protocols.tcp-ip Subject: tcpdump
I'm in the process of looking into either building or purchasing a
tcp-ip network monitor. The question is does any one know of any
sources to a public domain monitor? I know of the pcip package
but I'm really looking for something to run on a UNIX based system.
I've heard some talk of a package called tcpdump? What does it do?
Is it public domain? Any help in this area would be most appreciated.
--
Kevin Brooks
Usenet: ...{pyramid!isieng}uunet|hao!nbires}!vger!kevin
-----------[000094][next][prev][last][first]---------------------------------------------------- Date: 8 Mar 88 19:37:47 GMT From: mdm@TRWRB.DSD.TRW.COM (Michael D. Marcinkevicz) To: comp.protocols.tcp-ip Subject: PRIME TCP/IP OS software
Folks,
I've a user group that is interested in connecting his two Primes to
our Ethernet backbone. What can you tell me about TCP/IP options from Prime?
Thanks.
Michael Marcinkevicz (213) 812-2154
TRW Space and Defense Sector, Communications services
trwrb!mdm@trwind.TRW.COM (ARPA)
...{decvax,ihnp4,ucbvax}!trwrb!mdm (UUCP)
-----------[000095][next][prev][last][first]---------------------------------------------------- Date: 8 Mar 88 19:41:15 GMT From: mdm@TRWRB.DSD.TRW.COM (Michael D. Marcinkevicz) To: comp.protocols.tcp-ip Subject: CDC TCP/IP and CDCnet
Does anyone have an opinion about CDCnet and TCP/IP interface software
support by Control Data Corp.. Here at TRW, we have some CDC Cybers with
CDCnet that could potentially be connected to the rest of the campus
via Ethernet. What kind of TCP services do you get with the CDC package.
Please answer.
Michael Marcinkevicz (213) 812-2154
TRW Space and Defense Sector, Communications services
trwrb!mdm@trwind.TRW.COM (ARPA)
...{decvax,ihnp4,ucbvax}!trwrb!mdm (UUCP)
-----------[000096][next][prev][last][first]----------------------------------------------------
Date: 8 Mar 88 20:21:54 GMT
From: dpowles@CCD.BBN.COM ("Drew M. Powles")
To: comp.protocols.tcp-ip
Subject: IP/DDN X.25 implementation surveyI am doing a survey on available TCP/IP implementations over DDN Standard X.25 and would appreciate any and all information on the following aspects (the vendor guide form the NIC doesn't go into sufficient detail): 1) which implementations negotiate precedence for a DDN Standard X.25 call as defined on page 1-481 (volume 1) of the DDN Protocol Handbook and the mapping of precedence from IP to DDN Standard X.25 as defined on 1-494 of the same. Additionally, what mechanisms are provided allow a user or application process (i.e. FTP, Telnet, etc) to specify the precedence of a session so that the precednce level is passed down to the IP layer? 2) which implementations can utilitize DDN X.25 Logical addressing as specified in pages 1-495 thru 1-498 of the DDN Protocol Handbook - which includes mapping from IP addresses (either fully implemented or partially implemented)? many thanks for your help! Drew Powles BBN Communications
-----------[000097][next][prev][last][first]---------------------------------------------------- Date: 8 Mar 88 22:00:00 GMT From: CASNER@VENERA.ISI.EDU (Stephen Casner) To: comp.protocols.tcp-ip Subject: Re: Acking out-of-order packets?
Mark Lambert remarked that the Wideband Network would re-order packets that missed their satellite reservations. This is true, but such packets are not "pushed to the end of the queue" as Mark stated. A new reservation is sent for the packet as soon as the BSAT determines that the previous reservation was lost. In a sense the packet sits at the head of the queue, but with the high data rate and long delay time of the satellite channel, several later packets whose reservations were not lost may be transmitted while the unfortunate packet is waiting for the repeated reservation to be received. -- Steve Casner -------
-----------[000098][next][prev][last][first]---------------------------------------------------- Date: 9 Mar 88 01:02:01 GMT From: peha@SPAM.ISTC.SRI.COM (Jon Peha) To: comp.protocols.tcp-ip Subject: remote broadcasts
Can any one tell me any thing about "remote broadcasts" in TCP/IP. By that I mean having a packet broadcast on a network other than the one to which you are directly attached. I am quite aware of the dangers of such packets. One caused a broadcast storm on our ethernet effectively bring down the net. As far as I know there is no defence against one of these packets coming in from the Internet. On the other hand, if the packet were a UDP packet that did not engender a response (i.e. network monitoring info, routing tables, etc.), it could be a valuble tool, which may even prove useful in some of my present work. Is there any attempt in the Internet to regulate or block such packets. If so, where and how? If not, has any one considered it? I would think that if there is any control over remote broadcasts, it must take place in the gateway attached to the destination network, but perhaps the overhead would be too great. Jon Peha
-----------[000099][next][prev][last][first]---------------------------------------------------- Date: 9 Mar 88 01:49:21 GMT From: david@uowcsa.cs.uow.oz (David E A Wilson) To: comp.sys.pyramid,comp.protocols.tcp-ip Subject: SLIP on a Pyramid
Has anyone managed to configure SLIP to work on a Pyramid (90xe, OSx4.0). After a bit of hacking into the sun/vax version I have now found that it uses IFF_ROUTE which has been removed from net/if.h and the bit reused for IFF_LOOPBACK. Please e-mail me if you have SLIP running on a Pyramid, explaining what you did to get it going (and what sort of performance we could expect if it were running ((and how easy it is to interface the Pyramid supplied higher level packages to it))). David E.A. Wilson ACSnet: david@uowcsa.oz Dept. of Computing Science UUCP: ...!munnari!uowcsa.oz!david Uni. of Wollongong ARPA: david%uowcsa.oz@uunet.UU.NET
-----------[000100][next][prev][last][first]---------------------------------------------------- Date: 9 Mar 88 03:21:09 GMT From: postel@VENERA.ISI.EDU To: comp.protocols.tcp-ip Subject: CBD - SNIPE
----- Begin Forwarded Message ----- Subject: CBD - SNIPE 3/2/88 Date: Thu, 03 Mar 88 17:18:50 PST 1952549 SDI NETWORK INTERFACE PROCESSING ELEMENT (SNIPE) POC Donna Masi, Contr Officer, 315/330-2308 or Mark Zonca, Program Mgr, 315/330-2805. Completion: 12 months. Build prototype pocket-oriented data switches that interconnect IEEE 802.3 networks via Tl carrier trunk lines using MIL-STD-1777 IP protocol. These prototypes, called SDI Network Interface Processing Elements (SNIPEs), will be evaluated as the potential design for production units that will be used to implement SDI net. This effort will include the hardware and software design as well as the construction of deliverable prototype SNIPEs. Foreign firms should be aware that restrictions may be imposed which could preclude their participation in this cont. See Note 11 (however, size standard is changed to 1,000 employees). Responses must reference Code B-8-3563-M-2 and include your Commercial and Govt Entity (CAGE) number. All responsible firms may submit a proposal which shall be considered. (060) SPONSOR: Rome Air Development Center, Griffiss AFB, NY 13441-5700 SUBFILE: PSE (U.S. GOVERNMENT PROCUREMENTS, SERVICES) SECTION HEADING: A Experimental, Developmental, Test and Research Work PUBLICATION DATE: MARCH 2, 1988 ISSUE: PSA-9538 ----- End Forwarded Message -----
-----------[000101][next][prev][last][first]---------------------------------------------------- Date: 9 Mar 88 04:02:31 GMT From: hedrick@athos.rutgers.edu (Charles Hedrick) To: comp.protocols.tcp-ip Subject: Re: maximum Ethernet throughput
I've heard a second-hand report that Van Jacobson recently claimed an 8.2Mbit/sec TCP transfer between two Sun 3/50's using a very aggressively tuned 4.3 BSD TCP. If I got that right, it's quite impressive, considering that a 3/50 is by current standards not that fast a machine. This suggests - that 10 > 4 (i.e. that you can get an Ethernet transfer that is faster than the maximum transfer on a 4Mbit token ring) - that you don't necessarily have to abandon robust, long-haul protocols such as TCP in order to get good performance I wonder if we could nominate Van for a Nobel prize? It seems to me that he deserves something for all the work he has been doing for TCP/IP.
-----------[000102][next][prev][last][first]---------------------------------------------------- Date: 9 Mar 88 04:44:00 GMT From: deering@PESCADERO.STANFORD.EDU (Steve Deering) To: comp.protocols.tcp-ip Subject: Re: remote broadcasts
Jon, Concerning "remote broadcast" (also known as "directed broadcast"), you wrote: I am quite aware of the dangers of such packets. One caused a broadcast storm on our ethernet effectively bring down the net. As far as I know there is no defence against one of these packets coming in from the Internet. Could you explain in more detail what that one broadcast packet contained that effectively brought down your network, and why the fact that it came from another network was significant? I realize that there are lots of bugs out there in the way hosts handle broadcasts (and multicasts), but surely it's time to fix the bugs and make our hosts a little more robust in the face of unwanted packets, rather than imposing arbitrary gateway controls to protect the hosts from their own stupidity. As you observed, multi-destination datagrams can be a valuable tool; rather than imposing gateway controls, I suggest that the right defence is: 1) Fix hosts to ignore (i.e., silently discard) packets that they are not equiped to handle properly. 2) Insist on the use of multicast, rather than broadcast, so that unwanted packets can be ignored efficiently. Steve Deering
-----------[000103][next][prev][last][first]---------------------------------------------------- Date: 9 Mar 88 06:07:32 GMT From: Mills@UDEL.EDU To: comp.protocols.tcp-ip Subject: Re: remote broadcasts
Jon, I thought it would be cute if the fuzzball implementation exploded letter bombs to the broadcast address and they do that. Great fun and a good headscratcher to figure out what happens when you do that to a bunch of TCPs. However, it sure turned out to be a Real Bad Idea to allow that to happen past a gateway. Thus, the fuzzballs carefully nuke any broadcast-apparent packet that attempts to transit from one net to another. See RFC-1009. Dave
-----------[000104][next][prev][last][first]---------------------------------------------------- Date: 9 Mar 88 08:00:02 GMT From: alan@mn-at1.UUCP (Alan Klietz) To: comp.protocols.tcp-ip Subject: Re: maximum Ethernet throughput
In article <8803012359.AA00957@acetes.dec.com> mogul@DECWRL.DEC.COM (Jeffrey Mogul) writes:
<The best numbers that I am aware of, for communications between a pair
<of hosts, comes from Dave Boggs. Using a pair of 15 MIPs processors
<with software of his own design he can get about 7.5 Mbits/sec obeying
<the Ethernet spec, or at least 8.6 Mbits/sec if he "cheats" by sending
<4Kbyte packets.
<
<The limiting factor in his measurements seems to be that his interface
<can only send one packet at a time; i.e., he must process one interrupt
<per transmitted packet, which takes a few hundred microseconds. The
<interface can receive up to 16 packets using only one interrupt. With
<a more elaborate interface design, the theoretical limit should be
<attainable.
In general the maximum channel utilization possible by a single host,
assuming no errors, no contention, an unlimited output queue, and
no copy is,
t
f
D = ------------
t + t
f p
where t is the time required to wiggle over the wire the bits of an
f
average length data frame over the wire, and t is the processing
p
overhead time to interrupt the host CPU, switch context, reset the
interface hardware, allocate buffers, and do other (fixed) overhead.
To push the utilization curve to near 1, you have to either make
your data frames big (increase t , or equivalently process more frames
f
per interrupt) or make your processing overhead small (decrease t ).
p
Dave Boggs did both things and got good results. His processing overhead
is 50us, or a 20,000 packets per second. Impressive. (The results for
the 4K case show a 66us overhead, from which we can infer that one of
our original assumptions, such as no data copy, were probably wrong,
but the results are still valid.)
But herein lies the problem. As machines get faster and bigger, with
more pipelining and vectorization, and as the host network software
becomes bigger and more complicated, the per-message processing overhead
gets more expensive. And yet the data-links are becoming faster and
faster. FDDI is 100+ mbit/s. The GaAs version will be 1000+ mbit/s.
The ANSI X3T9 Working Group is developing a spec for a HSC channel rated
at 1600 mbit/s per second. The importance of absolutely minimizing
the host overhead is something that I think is critical to get any sort
of decent usage of these links (e.g. buffering multiple messages per host
interrupt).
The problem is that many vendors still think the "critical path" for
getting better performance is the wire. (Make the wire go faster and
you get better results), when in actuality the critical path is reverting
back the processor. Chop off the zeros and its not unlike the olden
days of writing a 9600 baud serial driver for a Intel 8080 processor :-)
--
Alan Klietz
Minnesota Supercomputer Center (*)
1200 Washington Avenue South
Minneapolis, MN 55415 UUCP: alan@mn-at1.k.mn.org
Ph: +1 612 626 1836 ARPA: alan@uc.msc.umn.edu (was umn-rei-uc.arpa)
(*) An affiliate of the University of Minnesota
-----------[000105][next][prev][last][first]---------------------------------------------------- Date: Wed, 9 Mar 88 17:56:36 EST From: Ken Pogran <pogran@ccq.bbn.com> To: hedrick@aramis.rutgers.edu Cc: hedrick@sccgate.scc.com, oconnor@sccgate.scc.com, tcp-ip@sri-nic.arpa, pogran@ccq.bbn.com Subject: Re: maximum Ethernet throughput
Charles, Getting "maximum throughput" from a LAN has been a challenge since the inception of Local Area Network technology back in the '70s. Often there's a disparity between what the LAN specs permit (at the "MAC" layer) and what practical controller implementations are capable of delivering. The challenge is to implement a controller that can deliver something approaching the maximum throughput without being prohibitively expensive (i.e., from a vendor's perspective: "Well, we could build one that would go that fast, but it would price us out of the market."). So one sees compromises in what a SINGLE flow can obtain from a LAN. In ETHERNET implementations, the compromise usually centers on how fast one can "turn around" a controller following one transaction (packet sent or received) to begin another one. On transmit, this limits how quickly you can send on an unloaded net. There are (or at least there were five years ago) some controller products that did a lot of "housekeeping" between outgoing packets, lowering throughput (I used one; I was disappointed.). On receive, the effect is is much more pernicious: If your controller takes "a long time" to get ready to receive the next incoming packet, and the controller sending to you has a faster turn-around than you do, your controller might be "blind" to the net and miss a packet, requiring retransmission by a higher-level protocol. Applications can't bank on getting a significant fraction of a LAN; after all, what would happen when two (or ten) of 'em happen to run simultaneously? On the other hand, software implemented in an environment that only contains "slow" controllers might break in embarrassing ways when employed on systems with quick turn-around controllers and a lightly loaded net! Which brings up a good point for developers of software that run right above the MAC layer: make sure it'll run on hardware "quicker" than yours. > When designers were thinking of Ethernet, I rather suspect > they might not have considered the possibility that one host > could actually use all 10Mb of bandwidth. The mechanisms of the ETHERNET care not a whit whether the next packet on the line is from the same guy as the last, or from someone else. I think it's clear that there were (are?) a number of CONTROLLER designs that assumed that no individual host would want to TRY to use all 10 Mb/s. I haven't looked at the insides of any recent controllers (or the timing specs of recent controller chips) but I'd be willing to bet that the choke point is more likely to be either the controller or its interface to the host, rather than the specs of the ETHERNET itself. This all applies to token-ring LANs, too, of course. And the faster the aggregate data rate on the LAN, the more these arguments apply. (So I might, for example, be able to get a greater PERCENTAGE of a 4 Mb/s Token Ring than I can of a 10 Mb/s ETHERNET). Any comments from designers of LAN controllers? Ken Pogran
-----------[000106][next][prev][last][first]---------------------------------------------------- Date: 9 Mar 88 14:44:53 GMT From: oconnor@SCCGATE.SCC.COM (Michael J. O'Connor) To: comp.protocols.tcp-ip Subject: Re: maximum Ethernet throughput
I also have heard "unofficial" reports of TCP transfers at greater than 8Mbps between a couple of SOS boxes by Van Jacobson. Stories of crashing Vaxen accompany the reports. At least one reporter claimed that this helped to demonstrate that Sun violates the Ethernet spec, allowing packets to be put on the wire too close together, effectively denying access to other hosts. Any chance of an "official" confirmation or denial of these rumors? Possibly an IDEA or RFC? Which leads to another question, what ever happened to IENs? Mike
-----------[000107][next][prev][last][first]---------------------------------------------------- Date: 9 Mar 88 15:59:09 GMT From: eshop@saturn.ucsc.edu (Jim Warner) To: comp.protocols.tcp-ip Subject: Re: remote broadcasts
There is no guarantee that any particular (sub)net that you're sending to supports broadcasting. This topic is discussed in RFC1009, mostly in appendix A. Briefly, the local gateway may forward a "directed broadcast datagram", but not through the interface that it came in. A local gateway is permitted to black hole a directed broadcast. Presumably, there should be a software switch. It may be useful to remember that intermediate gateways may not be able to determine if a particular IP address is a broadcast address unless they know the local subnet mask. Thus disgarding directed broadcasts is always done by the gateway guarding the destination net.
-----------[000108][next][prev][last][first]---------------------------------------------------- Date: 9 Mar 88 18:07:07 GMT From: hedrick@ARAMIS.RUTGERS.EDU (Charles Hedrick) To: comp.protocols.tcp-ip Subject: Re: maximum Ethernet throughput
We know of no evidence that Suns violate the minimum spacing requirement. Indeed if they did, things that work for us would fail, so I don't believe it. However 8Mb transfers would certainly open us to a whole range of things that have never been tested before. While Ethernet should in theory tolerate multiple simultaenous high-speed users, as far as I know it isn't being used that way now. Proper functioning would depend upon everybody's random backoff working right. Given the past history in networking, I am not prepared to bet that untested features work. One could imagine failures everywhere from Ethernet controller microcode to device drivers to protocols implementation. It would also let us test whether protocol designs implicitly assume that an Ethernet can never be congested. Certainly DECnet deals very differently with Ethernet than with point to point lines, and to a certainly extent IP does as well. When designers were thinking of Ethernet, I rather suspect they might not have considered the possibility that one host could actually use all 10Mb of bandwidth. It is possible that protocols such as ARP and DECnet hello would have to be rethought in this context. (For the benefit of the person asking the original question, let me note that there's no reason to think that a token ring would help. Indeed it is slower, so one is in danger of reaching this unknown realm sooner.)
-----------[000109][next][prev][last][first]---------------------------------------------------- Date: 9 Mar 88 18:23:47 GMT From: pgc@newcastle.ac.uk (P. G. Cutting) To: comp.protocols.tcp-ip Subject: bridge/router summary request?
I would be most grateful if someone could send me a summary of the bridge vs router debate that took place in this newsgroup recently. thanks in advance. our address is CSSD@UK.AC.NEWCASTLE CSSD, Computing Laboratory, The University of Newcastle, Newcastle Upon Tyne, NE1 7RU, ENGLAND.
-----------[000110][next][prev][last][first]---------------------------------------------------- Date: 9 Mar 88 18:45:46 GMT From: grr@cbmvax.UUCP (George Robbins) To: comp.dcom.lans,comp.protocols.tcp-ip Subject: ethernet monitor needed?
We have a single modest ethernet with a fair assortment of equipment
spread around the building. So far, network mangagment has been on
a plug-it-in-and-see-if-it-works-good basis. I'd like to be able to
so some monitoring with the following goals:
1) define ethernet loading and identify transceiver/interface level
malfunctions.
2) investigate problems with systems that won't talk to each other or
interfere with other conversations.
3) support development/debugging of in-house ethernet related hardware
software projects.
I've seen an ad for an Excelan 5100/5300 unit that seems to fit the
bill, but they want maybe $5K for it, which seems pretty expensive for
the amount of use it would get. I'd appreciate any comments about
this unit, good, bad or something else is better.
Also, is there any software, either 4.3 BSD or Sun related that could
be used to support this monitoring funciton, instead of going with a
piece of specialized equipment?
--
George Robbins - now working for, uucp: {uunet|ihnp4|rutgers}!cbmvax!grr
but no way officially representing arpa: cbmvax!grr@uunet.uu.net
Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
-----------[000111][next][prev][last][first]---------------------------------------------------- Date: 9 Mar 88 22:46:20 GMT From: doug@wbcs.UUCP (Doug Kratky) To: comp.protocols.tcp-ip,comp.dcom.lans Subject: ARP hardware field
What does a 2 value in the hardware field of ARP (ar_hrd) represent? Does anyone have a list of the different values that are valid for the hardware field and the types of hardware they correspond to?
-----------[000112][next][prev][last][first]---------------------------------------------------- Date: 9 Mar 88 22:56:36 GMT From: pogran@CCQ.BBN.COM (Ken Pogran) To: comp.protocols.tcp-ip Subject: Re: maximum Ethernet throughput
Charles, Getting "maximum throughput" from a LAN has been a challenge since the inception of Local Area Network technology back in the '70s. Often there's a disparity between what the LAN specs permit (at the "MAC" layer) and what practical controller implementations are capable of delivering. The challenge is to implement a controller that can deliver something approaching the maximum throughput without being prohibitively expensive (i.e., from a vendor's perspective: "Well, we could build one that would go that fast, but it would price us out of the market."). So one sees compromises in what a SINGLE flow can obtain from a LAN. In ETHERNET implementations, the compromise usually centers on how fast one can "turn around" a controller following one transaction (packet sent or received) to begin another one. On transmit, this limits how quickly you can send on an unloaded net. There are (or at least there were five years ago) some controller products that did a lot of "housekeeping" between outgoing packets, lowering throughput (I used one; I was disappointed.). On receive, the effect is is much more pernicious: If your controller takes "a long time" to get ready to receive the next incoming packet, and the controller sending to you has a faster turn-around than you do, your controller might be "blind" to the net and miss a packet, requiring retransmission by a higher-level protocol. Applications can't bank on getting a significant fraction of a LAN; after all, what would happen when two (or ten) of 'em happen to run simultaneously? On the other hand, software implemented in an environment that only contains "slow" controllers might break in embarrassing ways when employed on systems with quick turn-around controllers and a lightly loaded net! Which brings up a good point for developers of software that run right above the MAC layer: make sure it'll run on hardware "quicker" than yours. > When designers were thinking of Ethernet, I rather suspect > they might not have considered the possibility that one host > could actually use all 10Mb of bandwidth. The mechanisms of the ETHERNET care not a whit whether the next packet on the line is from the same guy as the last, or from someone else. I think it's clear that there were (are?) a number of CONTROLLER designs that assumed that no individual host would want to TRY to use all 10 Mb/s. I haven't looked at the insides of any recent controllers (or the timing specs of recent controller chips) but I'd be willing to bet that the choke point is more likely to be either the controller or its interface to the host, rather than the specs of the ETHERNET itself. This all applies to token-ring LANs, too, of course. And the faster the aggregate data rate on the LAN, the more these arguments apply. (So I might, for example, be able to get a greater PERCENTAGE of a 4 Mb/s Token Ring than I can of a 10 Mb/s ETHERNET). Any comments from designers of LAN controllers? Ken Pogran
-----------[000113][next][prev][last][first]---------------------------------------------------- Date: Thu, 10 Mar 88 08:32 CST From: RYAN POPKEN <POPKEN@crcvms.unl.edu> To: TCP-IP@SRI-NIC.ARPA Subject: CDC TCP/IP and CDCnet
CDCnet currently includes a subset of the TCP/IP suite of prorocols. They consist of ICMP and TELNET for both their NOS and NOS/VE systems. FTP is also available for the NOS/VE system. In their Spring Release of CDCnet, they have added FTP for NOS and ARP for both systems. We currently have both TELNETs and FTP for NOS/VE running on our systems. TELNET we use fairly regularly, and it appears to work quite well. FTP we tested out when it was first installed and it worked at that time. I do not know how stable it is over regular use. Ryan Popken Cyber System Manager University of Nebraska Lincoln, Nebraska <POPKEN@UNLVAX1.BITNET> <RYAN@UNLCDC3.BITNET>
-----------[000114][next][prev][last][first]---------------------------------------------------- Date: 10 Mar 88 02:55:48 GMT From: barmar@think.COM (Barry Margolin) To: comp.protocols.tcp-ip Subject: Re: remote broadcasts
In article <88.03.08.2044.910@pescadero.stanford.edu> deering@PESCADERO.STANFORD.EDU (Steve Deering) writes: >Could you explain in more detail what that one broadcast packet contained >that effectively brought down your network, and why the fact that it came >from another network was significant? I don't know what the original poster's answer will be, but my answer to this is that one generally has some control over the systems on the local net. If they start abusing broadcasts we can remove the programs that are causing trouble. But if broadcasts can come from anywhere there's not much that you can do to prevent them, and instead you must defend against them. While it is a good idea for systems to be resilient, it's also harder to implement. Barry Margolin Thinking Machines Corp. barmar@think.com uunet!think!barmar
-----------[000115][next][prev][last][first]---------------------------------------------------- Date: 10 Mar 88 03:45:47 GMT From: van@LBL-CSAM.ARPA (Van Jacobson) To: comp.protocols.tcp-ip Subject: Re: maximum Ethernet throughput
I don't know what would constitute an "official" confirmation but maybe I can put some rumors to bed. We have done a TCP that gets 8Mbps between Sun 3/50s (the lowest we've seen is 7Mbps, the highest 9Mbps -- when using 100% of the wire bandwidth, the ethernet exponential backoff makes throughput very sensitive to the competing traffic distribution.) The throughput limit seemed to be the Lance chip on the Sun -- the CPU was showing 10-15% idle time. I don't believe the idle time number (I want to really measure the idle time with a uprocessor analyzer) but the interactive response on the machines was pretty good even while they were shoving 1MB/s at each other so I know there was some CPU left over. Yes, I did crash most of our VMS vaxen while running throughput tests and no, this has nothing to do with Sun violating protocols -- the problem was that the DECNET designers failed to use common sense. I fired off a 1GB transfer to see if it would really finish in 20 minutes (it took 18 minutes) and halfway through I noticed that our VMS 780 was rebooting. When I later looked at the crash dump I found that it had run out of non-paged pool because the DEUNA queue was full of packets. It seems that whoever did the protocols used a *linear* backoff on the retransmit timer. With 20 DECNET routers trying to babble the state of the universe every couple of minutes, and my Suns keeping the wire warm in the interim, any attempt to access the ether was going to put a host into serious exponential backoff. Under these circumstances, a linear transport timer just doesn't cut it. So I found 25 retransmissions in the outbound queue for every active DECNET connection. I know as little about VMS as possible so I didn't investigate why the machine had crashed rather than terminating the connections gracefully. I should also note that NFS on our other Sun workstations wasn't all that happy about waiting for the wire: As I walked around the building, every Sun screen was filled with "server not responding" messages. (But no Sun crashed -- I later shut most of them down to keep ND traffic off the wire while I was looking for the upper bound on xfer rate.) I did run two simultaneous 100MB transfers between 4 3/50s and verified that they were gracious about sharing the wire. The total throughput was 7Mbps split roughly 60/40. The tcpdump trace of the two conversations has some holes in it (tcpdump can't quite hack a packet/millisecond, steady state) but the trace doesn't show anything weird happening. Quite a bit of the speedup comes from an algorithm that we (`we' refers to collaborator Mike Karels and myself) are calling "header prediction". The idea is that if you're in the middle of a bulk data transfer and have just seen a packet, you know what the next packet is going to look like: It will look just like the current packet with either the sequence number or ack number updated (depending on whether you're the sender or receiver). Combining this with the "Use hints" epigram from Butler Lampson's classic "Epigrams for System Designers", you start to think of the tcp state (rcv.nxt, snd.una, etc.) as "hints" about what the next packet should look like. If you arrange those "hints" so they match the layout of a tcp packet header, it takes a single 14-byte compare to see if your prediction is correct (3 longword compares to pick up the send & ack sequence numbers, header length, flags and window, plus a short compare on the length). If the prediction is correct, there's a single test on the length to see if you're the sender or receiver followed by the appropriate processing. E.g., if the length is non-zero (you're the receiver), checksum and append the data to the socket buffer then wake any process that's sleeping on the buffer. Update rcv.nxt by the length of this packet (this updates your "prediction" of the next packet). Check if you can handle another packet the same size as the current one. If not, set one of the unused flag bits in your header prediction to guarantee that the prediction will fail on the next packet and force you to go through full protocol processing. Otherwise, you're done with this packet. So, the *total* tcp protocol processing, exclusive of checksumming, is on the order of 6 compares and an add. The checksumming goes at whatever the memory bandwidth is so, as long as the effective memory bandwidth at least 4 times the ethernet bandwidth, the cpu isn't a bottleneck. (Let me make that clearer: we got 8Mbps with checksumming on). You can apply the same idea to outgoing tcp packets and most everywhere else in the protocol stack. I.e., if you're going fast, it's real likely this packet comes from the same place the last packet came from so 1-behind caches of pcb's and arp entries are a big win if you're right and a negligible loss if you're wrong. In addition to the header prediction, I put some horrible kluges in the mbuf handling to get the allocation/deallocations down to 1 per packet. Mike Karels has been working in the same area and his clean code is faster than my kluges. As soon as this semester is over, I plan to merge Mike's and my versions then the two of us will probably make a pass at knocking off the biggest of the rough edges. Sometime in late spring or early summer we should be passing this code out to hardy souls for beta-testing (but ask yourself: do you really want workstations that routinely use 100% of the ethernet bandwidth? I'm pretty sure we don't and we're not running this tcp on any of our workstations.) Some of the impetus for this work came from Greg Chesson's statement at the Phoenix USENIX that `the way TCP and IP are designed, it's impossible to make them go fast'. On hearing this, I lept to my feet to protest but decided that saying "I think you're wrong" wasn't going to change anybody's mind about anything. Now I can say that I'm pretty sure he was wrong about TCP (but that's *not* a comment on the excellent work he's doing and has done on the XTP and the Protocol Engine). The header prediction algorithm evolved during attempts to make my 2400-baud SLIP dial-up send 4 bytes when I typed a character rather than 44. After staring at packet streams for a while, it was pretty obvious that the receiver could predict everything about the next packet on a TCP data stream except for the data bytes. Thus all the sender had to ship in the usual case was one bit that said "yes, your prediction is right" plus the data. I mention this because funding agents looking for high speed, next-generation networks may forget that research to make slow things go fast sometimes makes fast things go faster. - Van
-----------[000116][next][prev][last][first]---------------------------------------------------- Date: 10 Mar 88 04:44:38 GMT From: hedrick@ARAMIS.RUTGERS.EDU (Charles Hedrick) To: comp.protocols.tcp-ip Subject: Re: maximum Ethernet throughput
I thought it was obvious that I was talking about systems designers, not the people who made up the Ethernet specs. As I said, when we get into untests realms, such as 8Mb single transfers, we run the danger of finding bugs in the controller, its microcode, device drivers, and possibly even (though we will hope not) the protocols defining the Ethernet encapsulation for IP, DECnet, or whatever. We see very clearly the fact that many controllers can't handle bursts of packets with minimum spacing. Normally however they simply drop packets, not crash the machine they are running on. I have no idea why DECnet machines would crash during bursts of TCP traffic (or even whether that rumor is true), but I would start looking at the design of the Ethernet controller and the device driver that is dealing with it. It could be something as simple as a bug in the code that handles situations where you are unable to get the Ethernet for an extended period of time, or something as complex as implicit assumptions in some piece of the DECnet protocol design. Of course it could also be a bug in the Sun that causes it to fail to defer to someone else when it is supposed to do so, but I sort of doubt that, since that should be handled by the Lance chip.
-----------[000117][next][prev][last][first]---------------------------------------------------- Date: Thu, 10 Mar 88 09:46:52 EST From: Bob Dixon <TS0400%OHSTVMA.BITNET@CUNYVM.CUNY.EDU> To: TCP-IP@SRI-NIC.ARPA Subject: Re: PRIME TCP/IP OS software
The local Prime salesman tells me that they support tcp/ip and ethernet as
of last October. Telnet is curently inbound only, ftp is both ways, and smtp
is not at all. The missing pieces are claimed to be under development.
Bob Dixon
Ohio State University
Acknowledge-To: <TS0400@OHSTVMA>
-----------[000118][next][prev][last][first]---------------------------------------------------- Date: 10 Mar 88 06:56:11 GMT From: dannyb@kulcs.uucp (Danny Backx) To: comp.protocols.tcp-ip Subject: Re: rsh equivalent
In article <23511@hi.unm.edu> cyrus@hi.unm.edu (Tait Cyrus) writes:
>
>I am looking for PD version of code that accomplishes the same thing
>as rsh but conforms to the RFC's (machine name case independent).
>We have users who like to pipe BIG jobs from one machine to another
>machine via rsh's.
>
>The reason I am interested in something other than rsh is because
>here at UNM we are strongly considering disallowing the r* programs
>(rsh/rcp/rlogin) because they do NOT conform to the RFC's as well
>as being BIG security problems (.rhosts).
You might want to look at the "rex" service in SUN's RPC package.
This is something quite similar to rexec(3) and rsh(1).
What I mean is : it also doesn't provide a virtual terminal for your remote
processes.
If you have access to SUN manuals, look at on(1c), rexd(8c), and rex(3r).
If not, you could get the idea by looking in the RPCSRC 3.9 package,
which was recently posted to the net (comp.sources.???).
It is also accessible via anonymous ftp and via Email from the archives of
Sun-Spots.
If you need better authentication than BSD's r*, I think this may do :
the rex-system uses the same "UNIX-style authentication" that the entire RPC
package uses.
If you have a SUN or a 4.3 system from Mt.Xinu, you should be able to use it
right away.
Danny Backx
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Danny Backx | mail: Katholieke Universiteit Leuven
Tel: +32 16 200656 x 3537 | Dept. Computer Science
E-mail: dannyb@kulcs.UUCP | Celestijnenlaan 200 A
... mcvax!prlb2!kulcs!dannyb | B-3030 Leuven
dannyb@kulcs.BITNET | Belgium
-----------[000119][next][prev][last][first]---------------------------------------------------- Date: 10 Mar 88 14:32:00 GMT From: POPKEN@crcvms.unl.EDU (RYAN POPKEN) To: comp.protocols.tcp-ip Subject: CDC TCP/IP and CDCnet
CDCnet currently includes a subset of the TCP/IP suite of prorocols. They consist of ICMP and TELNET for both their NOS and NOS/VE systems. FTP is also available for the NOS/VE system. In their Spring Release of CDCnet, they have added FTP for NOS and ARP for both systems. We currently have both TELNETs and FTP for NOS/VE running on our systems. TELNET we use fairly regularly, and it appears to work quite well. FTP we tested out when it was first installed and it worked at that time. I do not know how stable it is over regular use. Ryan Popken Cyber System Manager University of Nebraska Lincoln, Nebraska <POPKEN@UNLVAX1.BITNET> <RYAN@UNLCDC3.BITNET>
-----------[000120][next][prev][last][first]---------------------------------------------------- Date: 10 Mar 88 14:46:52 GMT From: TS0400@OHSTVMA.BITNET (Bob Dixon) To: comp.protocols.tcp-ip Subject: Re: PRIME TCP/IP OS software
The local Prime salesman tells me that they support tcp/ip and ethernet as
of last October. Telnet is curently inbound only, ftp is both ways, and smtp
is not at all. The missing pieces are claimed to be under development.
Bob Dixon
Ohio State University
Acknowledge-To: <TS0400@OHSTVMA>
-----------[000121][next][prev][last][first]---------------------------------------------------- Date: 10 Mar 88 19:51:19 GMT From: romkey@kaos.UUCP (John Romkey) To: comp.protocols.tcp-ip,comp.dcom.lans Subject: Re: ARP hardware field
In article <117@wbcs.UUCP> doug@wbcs.UUCP (Doug Kratky) writes: >What does a 2 value in the hardware field of ARP (ar_hrd) >represent? Does anyone have a list of the different values >that are valid for the hardware field and the types of >hardware they correspond to? Check the most recent version of the Assigned Numbers RFC (1010, I think). And the winner is...3Mb/sec ethernet... -- - john romkey ...harvard!spdcc!kaos!romkey romkey@kaos.uucp romkey@xx.lcs.mit.edu
-----------[000122][next][prev][last][first]---------------------------------------------------- Date: 11 Mar 88 00:06:45 GMT From: sob@bcm.tmc.edu (Stan Barber) To: comp.protocols.tcp-ip Subject: Bridge Communications TCP/IP 20000
There has been some discussion about terminal servers and the Bridge
Communications products. Most of it has been "hear-say". I thought I'd
take this opportunity to make some concrete comments based on our
use of two versions of their software accross three products.
We run a large network that uses CS/1s, CS/100s and CS/200s. We had been
running XNS on the terminal servers until the end of last year when we
converted the TCP (version 13000). This version of TCP/IP was functional,
but no more than that. It was slow and it seemed that many useful TELNET
functions were not implemented. However, it worked well enough for the
month we had to wait for TCP 20000. [We were intending to convert to
20000 directly, but Bridge was delayed in getting it to us.] One useful
feature was the addition of permanent virtual circuits. This made remote
printers easy to do.
The new version was MUCH better than the older version. Flow control
was much more responsive (flow stops within a couple of bytes). TELNET's
binary option was now available (useful for some types of file transfers and
graphics). Throughput was MUCH improved.
Additionally, a rich macro language has been added as well as support for
the Domain Name Service.
Until recently, I was only marginally satisfied with the Bridge product. Now,
I am quite pleased with it. My only major remaining complaint is the lack
of support for a non-proprietary system logging function. I have suggested
that they make their log information available to the unix syslog function.
I hope they will.
Stan Barber, Baylor College of Medicine
Stan internet: sob@tmc.edu Baylor College of Medicine
Olan uucp: {rice,killer,hoptoad}!academ!sob
Barber Opinions expressed are only mine.
-----------[000123][next][prev][last][first]---------------------------------------------------- Date: 11 Mar 88 00:53:14 GMT From: wesommer@athena.mit.edu (William E. Sommerfeld) To: comp.protocols.tcp-ip Subject: Re: rsh equivalent
In article <102@icarus.kulcs.uucp> dannyb@kulcs.UUCP (Danny Backx) writes: >If you need better authentication than BSD's r*, I think this may do : >the rex-system uses the same "UNIX-style authentication" that the entire RPC >package uses. Have you actually looked at what `UNIX style authentication' is for Sun RPC? The client puts its hostname, userid and group set in the packet; the server is expected to take the client's word for it, and usually does. Calling Sun's rex, with UNIX style authentication, ``more secure than rlogin'' is like calling a Medeco padlock on a paper bag more secure than a Master padlock on a cardboard box. Sun may have a `secured RPC' version of `rex' in release 4.0 which would be more secure than rlogin/rsh, although not quite as secure as a modified rsh using Kerberos (the MIT/Athena authentication system). Bill Sommerfeld MIT Project Athena.
-----------[000124][next][prev][last][first]---------------------------------------------------- Date: 11 Mar 88 01:26:41 GMT From: kak@stc-auts.UUCP (Kris Kugel) To: comp.mail.uucp,comp.protocols.tcp-ip Subject: using TCP/IP for news and mail
I'd like to get uucp to use our ethernet connection
to "Building 2" but I don't know how.
In investigating this, I managed to get "sendmail"
to connect from our local sun to our vax running ultrix
(a slightly downlevel ultrix, probably 2.0),
but not the other direction.
1. How do I make the ultrix sendmail aware of my sun?
(it always responds, "User unknown")
2. How can I alter uucp to take advantage of the ethernet?
(will eventually be talking to a BSD 4.3 machine)
We're running a BSD4.2 mail system on the ultrix vax,
but I'm missing the 4.2 documentation.
Any help would be welcome!
Thanks in advance,
Kris A. Kugel
Storage Tek: ...{ uunet!nbires, hao, ihnp4 }!stcvax!stc-auts!kak
"It is better to light one small cannibal than to torch the duchess"
P.S. please respond by e-mail.
-----------[000125][next][prev][last][first]---------------------------------------------------- Date: 11 Mar 88 03:06:59 GMT From: bzs@BU-CS.BU.EDU (Barry Shein) To: comp.protocols.tcp-ip Subject: maximum Ethernet throughput
Breathtaking, in a word, who made that comment about Nobel Prizes for networking? At any rate, there is another interesting issue here: >(but ask yourself: do you really want workstations >that routinely use 100% of the ethernet bandwidth? I'm pretty >sure we don't and we're not running this tcp on any of our >workstations.) My temptation is to ask the converse: Do I wish to believe that merely mediocre algorithms protect me from this as a problem? It seems that given what we might call near-capacity algorithms (for ethernets, of course new wire technologies such as direct fiber hookups will be interesting again) we need to think about rational ways to administer such networks. In the trivial case we could isolate many of these workstations, as we already do here, to their own ethernets, barely shared, so it is less of a problem. Perhaps this would spur vendors to provide hardware to make that even easier and more economical. This would certainly be useful in the case of networked file systems using a client/server model (eg. diskless or disk-poor clients.) Beyond that I have often thought of the idea of a network "throttle", a settable parameter that might control maximum throughput (packets output per second, for example) that a machine might limit itself to. Obviously that requires voluntary compliance (although it could be an extension of window advertising, that is, making the window behavior tunable by the system administrator rather than calculated for maximum throughput always based upon blind assumptions about resources.) Interesting, at any rate... -Barry Shein, Boston University
-----------[000126][next][prev][last][first]---------------------------------------------------- Date: 11 Mar 88 04:39:50 GMT From: mike@BRL.ARPA (Mike Muuss) To: comp.protocols.tcp-ip Subject: Re: expo ftp bug?
Greg - Good work on the detailed sleuthing. Phil here at BRL experienced the same problems when using 3 different TCPs here, which definitely points the finger at the TCP on poor <expo>. I'm the original proponent of the tcp_mss code, and moving it to 1024 will actually cause you significantly more trouble than the 512 setting, as it will case the packets to be fragmented as they enter the IMP-based networks (ARPANET, MILNET). If you are trying to squeeze a few more data bytes per packet from the network, be certain that this relationship holds: tcp_mss <= Network_MTU - Max_Header_Size In the case of IMPs, the MTU is 1006. The max header (TCP+IP) isn't huge, perhaps 42 bytes :-). Therefore, your tcp_mss should not exceed 964 bytes. If you want to be really conservative, a number like 920 or 930 would allow lots of room for IP Options (which are rare, but not unheard of). Even at 920 that would give you a 1.8x performance advantage. HOWEVER, note that no system is REQUIRED to accept a packet with more than 512 data bytes, so by implementing this change you may reduce your interoperability. No UNIX system is likely to mind, but some non-UNIX systems (esp. some MULTICS machines) are unhappy with larger MSS settings. If you induce IP fragmentation through the core network system, you will do very much worse than with the current setting. The problem is that if one fragment of a multi-fragment IP datagram is dropped, then the whole transmission (all fragments) are not useful, and have to be re-sent. If each TCP transmission fits in a single IP datagram, then TCP has the opportunity to be more sensible with it's retransmission strategy. At BRL, we run SUNOS 3.4, with the "Van" TCP code replacing the Sun code. I believe he offers the fixes in both source and Sun-binary-patch form. It's a real winner, consult the archives of the <TCP-IP> list for details. Best, -Mike
-----------[000127][next][prev][last][first]---------------------------------------------------- Date: 11 Mar 88 06:21:49 GMT From: melohn@SUN.COM (Bill Melohn) To: comp.protocols.tcp-ip Subject: Re: maximum Ethernet throughput
In article <8803091444.AA24112@sccgate.scc.com> oconnor@SCCGATE.SCC.COM (Michael J. O'Connor) writes: >... At least one reporter claimed that this helped to >demonstrate that Sun violates the Ethernet spec, allowing packets to be put >on the wire too close together, effectively denying access to other hosts. We hear these stories at Sun all the time, usually from customers who have been told by other computer vendors that the Sun somehow "cheats" on the Ethernet spec by "putting too many packets on the wire", or "sending too many packets too fast for Ethernet". These are complete falsehoods. Sun uses standard chips supplied by both Intel and AMD for our ethernet interfaces, and while they may be the fastest implementations available on the market, they are completely within Ethernet specifications. Next time you hear one of these stories from a sales person for another computer vendor, ask them to back their claim with facts, and seriously consider the source.
-----------[000128][next][prev][last][first]---------------------------------------------------- Date: 11 Mar 88 16:54:05 GMT From: rajaei@ttds.UUCP (Hassan Rajaei) To: comp.protocols.tcp-ip Subject: Re: maximum Ethernet throughput
In article <412@mn-at1.UUCP> alan@mn-at1.UUCP (0000-Alan Klietz) writes: >But herein lies the problem. As machines get faster and bigger, with >more pipelining and vectorization, and as the host network software >becomes bigger and more complicated, the per-message processing overhead >gets more expensive. And yet the data-links are becoming faster and >faster. FDDI is 100+ mbit/s. The GaAs version will be 1000+ mbit/s. >The ANSI X3T9 Working Group is developing a spec for a HSC channel rated >at 1600 mbit/s per second. The importance of absolutely minimizing >the host overhead is something that I think is critical to get any sort >of decent usage of these links (e.g. buffering multiple messages per host >interrupt). > You are right. We are reaching a point that a host machine no longer can cope with the communication problems alone. We have to offload the host as much as we can by introducing dedicated communications system rather than some simple board. The protocol engines are something to think about. Hassan Rajaei rajaei@ttds.tds.kth.se
-----------[000129][next][prev][last][first]---------------------------------------------------- Date: 11 Mar 88 19:25:29 GMT From: jas@MONK.PROTEON.COM (John A. Shriver) To: comp.protocols.tcp-ip Subject: maximum Ethernet throughput
One way to deal with those violent controller speed mismatches that are starting to show up is to use a LAN with some form of hardware ACK. This is part of all token ring networks (ProNET, Apollo, 802.5, FDDI), as well as Hyperchannel and DEC's CI. While these bits cannot be used to guaruntee end-to-end reliability, they do let you know when you are sending faster than the other guy can receive. The simplest thing to do is just retransmit until the other guy copies it, but this is a waste of network bandwith. The more sophisticated thing to do is put the packet back on the front of the output queue, and search up the queue for a packet to a different hardware destination. This way the packet retransmissions are interleaved with potentially useful transmissions. You don't, however, want to shuufle the order of packets to a particular node, this can be pathological to some protocols. (The NSP in DECnet-VAX did not accept out-of-order packets until Version 4.7, some TCP's have the same problem.) Good programming interfaces are indeed important. While our earlier boards were only single-buffered (one each way), their simple and fast programming interface (start a transmit in 4 C statements) made up for it. (The ACK bit also helps on the single-buffer problem.) It is very hard to try and get below the interrupt-per-packet threshold and keep a simple programming interface. However, even if you make it, you run into programming interfaces, such as the 4.3bsd network device interface, that make it very difficult to get a pipeline going. By comparison, in VAX/VMS, where pipelining is quite feasible, when you pipeline two packets deep, you nearly double the throughput. As an example of how programming interfaces and interface design affect performance, note that Van's benchmarks were run on a Sun-3/50, which uses the AMD LANCE Ethernet chipset. I doubt he could match those numbers on a Sun-3/160, which uses a Intel 82586 Ethernet chip. The '586 has an inferior programming interface, and some nasty internal "housekeeping" delays that make it a good bit slower.
-----------[000130][next][prev][last][first]---------------------------------------------------- Date: 11 Mar 88 22:22:21 GMT From: sean@cadre.dsl.PITTSBURGH.EDU (Sean McLinden) To: comp.protocols.tcp-ip Subject: LAN Terminal server (TELNET and SUPDUP)
Is anyone aware of an Ethernet terminal server which supports both TELNET and SUPDUP? Sean McLinden Decision Systems Laboratory University of Pittsburgh
-----------[000131][next][prev][last][first]---------------------------------------------------- Date: Sat, 12 Mar 1988 06:33:46.82 EST From: <droms%BKNLVMS.BITNET@CUNYVM.CUNY.EDU> To: <tcp-ip@sri-nic.arpa> Subject: Re: Another example of the joys of BITNET mail
> %%% Issue 17 was sliced in half by some unkind IBM systems using SMTP. Glenn > %%% Vanderburg informs me that the reason was a line that was longer than > %%% 80 columns got wrapped, ... If the moderator would only submit tex-hax on a deck of punch cards, (rather than these new-fangled "disk files"), BITNET would be perfectly happy. Oh, and make sure you refrain from using those "tab" characters, whatever *they* are... - Ralph Droms Bucknell University (coming to you live from bknlvms.*bitnet*)
-----------[000132][next][prev][last][first]----------------------------------------------------
Date: 12 Mar 88 03:16:19 GMT
From: dougm@violet.ico.isc.COM ("Doug McCallum")
To: comp.protocols.tcp-ip
Subject: Re(2): maximum Ethernet throughputIn reply to your message of Thu, 10 Mar 88 22:21:49 PST ------- > falsehoods. Sun uses standard chips supplied by both Intel and AMD for > our ethernet interfaces, and while they may be the fastest > implementations available on the market, they are completely within > Ethernet specifications. Next time you hear one of these stories from Just having controllers made with standard chips does not ensure that they are within specification. I don't remember the details of the LANCE chip, but the Intel 82586 can be configured to violate just about every parameter you might think of. The interpacket spacing is one such parameter. The parameterization makes it useful for implementing different speed networks (like Starlan) with the same chips. So, even though Sun's products are made with standard parts doesn't guarantee that someone hasn't changed parameters to something non-standard.
-----------[000133][next][prev][last][first]---------------------------------------------------- Date: 12 Mar 88 05:08:13 GMT From: A.Eric@GSB-WHY.STANFORD.EDU (Eric M. Berg) To: comp.protocols.tcp-ip Subject: Another example of the joys of BITNET mail
[Extracted from a recent digest posted to the TeXhax mailing list...] Date: 21 Feb 88 From: Malcolm Subject: Immoderate notes: brief pause in texhax; issue 17 sliced up %%% Issue 17 was sliced in half by some unkind IBM systems using SMTP. Glenn %%% Vanderburg informs me that the reason was a line that was longer than %%% 80 columns got wrapped, which resulted in the next line beginning with %%% a period. SMTP though that this meant it was about to get a command. So %%% it went through the remainder of the digest, looking for a command, which %%% of course it didn't find -- only more TeXhax. -------
-----------[000134][next][prev][last][first]---------------------------------------------------- Date: 12 Mar 88 09:02:11 GMT From: amdcad!charlie@ucbvax.Berkeley.EDU (Charlie Slater) To: tcp-ip@sri-nic.arpa Subject: AT&T ISN as a Method of Connecting Ethernets
This is a report on AT&T's Information Systems Network (ISN). Correcting to points on which I was confused: 1. ISN does not transfer voice 2. ISN controllers do statistically multiplex data traffic over long lines to other controllers such as 56Kb or T1 lines. 3. ISN does support BSC, SDLC, 3270. AT&T brochures include long list of IBM terminals and controllers with which ISN is said to be compatible. 4. It does support asynchronous ASCII terminals at speeds up to 19.2 Kbps. Routing: ISN provides sophisticated routing for all of its digital services except the Ethernet bridge. Like Vitalink's, AT&T's bridge mixes (internal) network address resolution with routing. Because the "learning" algorithm used for network address resolution cannot handle polygon topologies (e.g. a triangle of three sites), all polygons are broken by taking one line in the polygon out of service (e.g. a triangle is converted to a dog-leg). There is no reason a "disconnected" polygon (e.g. a dog-leg) cannot be used for network address resolution and a closed polygon used for transferring data over the shortest path once addressing has been resolved. Like Vitalink, AT&T just did not bother. If you understand this, you can skip the next four paragraphs. All learning bridges work by building tables of Ethernet addresses and internal network address which help the bridge decide which network to send it to. These addresses can be very simple such as "local," "line1," and "line2." When the bridge sees a new Ethernet source address it adds it to its list of local addresses and informs the other bridges that the new address is on its local network. The remote bridges have add to their list of addresses associated with the bridge which just saw the packet. Thus bridges learn which packets go to which bridge. The problem occurs when a bridge sees a packet with a destination address that is not in its table. The bridges must send this packet to all Ethernets. The bridge sends the packet to all connected bridges. One bridge sends it to the next, and so on. If bridges are connected via a closed polygon, the packet stays "in flight" forever. Almost all packets on the Ethernet, however, have destination addresses already in the bridge's table. The bridges should route packets with known destination networks over the shortest path, and packets for which the network is unknown over an administratively defined path which does not close the polygon. Such an algorithm is not hard to implement. The problem is that most bridge vendors are insensitive to the customer's desire to send data over one hop consuming one long line, rather than two or more hops consuming two or more long lines. Having separated routing from automatic network address resolution, there is no reason why bridge vendors cannot develop more sophisticated routing algorithms than those of IP routers. Among the metrics that should be included in the objective function are: line speed, line quality, and line utilization. Line Utilization: Because the bridge knows nothing of the network and connection level protocols, it must forward the entire Ethernet packet (except for preamble) This means there is an extra 18 bytes of overhead in addition to the protocol overhead. One respondent from AT&T said that ISN eliminated part of this overhead by mapping the Ethernet source and destination addresses to shorter addresses. Assuming that all 18 bytes of Ethernet overhead are sent, then the overhead on a TCP/IP connection is increased from 40 bytes to 58 bytes. This means that the maximum line utilization for an ftp file transfer which uses packets containing 512 bytes of user data decreases from 93 per cent to 90 per cent. The difference is even more pronounced for telnet connections. If one is sending a single character via a router, the packet is 41 bytes long. However, the minimum Ethernet packet length is 46 bytes. With Ethernet's 14-byte heading and some form of CRC (unlikely to be less than Ethernet's 4 bytes) a bridge must send 64 bytes to send a single character on a virtual terminal connection. Converting from a router to a bridge devotes an at least an additional 3 per cent of total traffic to overhead. This cost may well be offset by the efficiencies which acrue from ISN's statistical multiplexing of 3270 traffic with inter Ethernet traffic. As an aside, the DEC router server moves DECnet traffic more slowly over a 56Kb line than the Vitalink bridge. This well-known phenomena is contrary to what I just said about routers achieving better line utilization to Bridges. The DEC router server is simply too slow to drive a 56Kb line. A Bridge GS/3 IP router uses 4-year old hardware to achieve the theoretical maximum of 93 per cent line utilization for an ftp file transfers. Routers really do drive 56Kb lines faster than bridges. Will ISN work for large networks? As a rule, bridges do well on networks with small numbers of stations and less well on networks with large numbers of stations. There are two reasons for this: 1. A bridge must read every packet. If a T1 bridge connects two Ethernets, each with only one station attached, it may achieve a station-to-station file transfer speed in excess of one megabit per second. However, if one of the Ethernets has, say, 300 stations and an average load of, say, five megabits per second, the bridge's throughput may drop to, say, 200 Kb per second. This is because most of the bridge's CPU cycles are consumed sifting through five packets for every one it forwards. 2. Both DECnet and what people call TCP/IP (but is really the Address Resolution Protocol or ARP which goes with TCP/IP), use Ethernet broadcast packets to resolve logical addresses to Ethernet addresses (and in the case of diskless workstations, vice versa). With no knowledge of the next level protocol, it is difficult for the bridge to know which broadcast packets to forward. The choice is usually none or all. If the bridge does not forward broadcast packets, neither DECnet nor TCP/IP will work. On the otherhand, If the bridge forwards all broadcast traffic then some of the long line to the next bridge will be wasted on broadcast packets which should have stayed on the local Ethernet. While local broadcast traffic small with respect to the 10-megabit capacity of Ethernet it may be large with respect to the capacity of a 56Kb line. Summary: AT&T's Bridge is far from state of the art. It is slower and less efficient than multiple protocol routers available from Wellfleet Communications or cisco Systems. ISN's ability to move SDLC, BSC, and Async on the same line can be matched by using products from Bridge Communications which convert these protocols to TCP/IP. However, ISN is an improvement over previous products from AT&T. The advantages of having a single vendor take end-to-end responsibility for all corporate communications may well justify the cost of still being one generation behind. Thanks to all who responded to my original inquiry and helped in the preparation of this article. I take full blame for any mistakes in this article. The opinions expressed are my own and do not necessarilly reflect those of AT&T or AMD. charlie slater charlie@amdcad.amd.com
-----------[000135][next][prev][last][first]---------------------------------------------------- Date: 12 Mar 88 12:18:45 GMT From: droms@BKNLVMS.BITNET To: comp.protocols.tcp-ip Subject: Re: Another example of the joys of BITNET mail
> %%% Issue 17 was sliced in half by some unkind IBM systems using SMTP. Glenn > %%% Vanderburg informs me that the reason was a line that was longer than > %%% 80 columns got wrapped, ... If the moderator would only submit tex-hax on a deck of punch cards, (rather than these new-fangled "disk files"), BITNET would be perfectly happy. Oh, and make sure you refrain from using those "tab" characters, whatever *they* are... - Ralph Droms Bucknell University (coming to you live from bknlvms.*bitnet*)
-----------[000136][next][prev][last][first]---------------------------------------------------- Date: 12 Mar 88 20:45:02 GMT From: csg@pyramid.pyramid.com (Carl S. Gutekunst) To: comp.sys.pyramid,comp.protocols.tcp-ip Subject: Re: SLIP on a Pyramid
In article <274@uowcsa.cs.uow.oz> david@uowcsa.cs.uow.oz (David E A Wilson) writes: >Has anyone managed to configure SLIP to work on a Pyramid (90xe, OSx4.0). Sure. It will be a supported product in OSx 4.4, now in beta test. Harrass your salescritter if you want to be a beta test site. I suspect that the problem you had porting the Sun/VAX version to OSx 4.0 is that OSx 4.0 is 4.3BSD; it sounds like you had the 4.2BSD version of SLIP. Performance has been pretty good; we had to make some minor modifications to get dropped packets on the source side to work properly. (Otherwise we occa- sionally got long TCP timeout delays.) rlogin over a 19.2K SLIP line is not visibly different from rlogin over Ethernet. Of course, when you get several people doing cat /etc/termcap at the same time, it gets a bit sluggish. :-) We've also just started running SLIP on the Telebit TrailBlazer between here and Ames; interactive really stinks (1 to 4 second echo delays), but that's because the TrailBlazer is half duplex. File transfer is better. We'll be compiling (and posting) specific numbers as the project moves along. <csg>
-----------[000137][next][prev][last][first]---------------------------------------------------- Date: 12 Mar 88 21:41:52 GMT From: avolio@decuac.dec.com (Frederick M. Avolio) To: comp.mail.uucp,comp.protocols.tcp-ip Subject: using TCP/IP for news and mail
The sendmail problem sounds like you need to putz around with your sendmail.cf. There is no problem tlaking to/from any system via SMTP, but the sendmail.cf needs to be a proper sendmail.cf (one that knows about an SMTP mailer, for example). It sounds like you don't really want UUCP over TCP/IP (which is doable) but you want to transfer news. A better way is to use NNTP which works very nicely. An added feature is that it implements the ihave/sendme protocol so only those articles which must be sent are sent. (It does it in real time as opposed to how one can do this over real uucp dialup links which works but requires multiple phone calls, etc.) Fred
-----------[000138][next][prev][last][first]---------------------------------------------------- Date: 12 Mar 88 22:46:18 GMT From: hedrick@athos.rutgers.edu (Charles Hedrick) To: comp.protocols.tcp-ip, chris@ACC-SB-UNIX.ARPA Subject: Re: TN3270 on Terminal Servers
I know at least one vendor who claims to be working on tn3270 mode. I think I can tell you why it hasn't been done yet. First, it needs more memory and CPU than a normal telnet connection. You have to maintain a screen image and various other state information, and you have to do the emulation. Most terminal servers currently use a 68000 with not much memory. But that's not the big problem. The big problem is that you need to have access to somthing like termcap for the user's terminal. Terminal servers don't have disks, and they don't have enough memory to store the whole thing in memory. My theory is that they're going to have to define a "termcap server" that runs on a host and gives you the termcap entry for a single requested terminal type. Of course those machines that support tftp booting (which I think is common) could always download /etc/termcap and just throw away everything except the one entry that they needed. Presumably when the vendors do it, they'll use it to help sell us upgrades that use the SPARC chip and have 32MB of memory... (Well, not really, but I think you might need more than 1MB, and at least a 68020.)
-----------[000139][next][prev][last][first]---------------------------------------------------- Date: 13 Mar 1988 09:12-EST From: CERF@A.ISI.EDU To: jif@VENERA.ISI.EDU Cc: tcp-ip@SRI-NIC.ARPA Subject: NRI New Address
Forgive the broadside - it seemed most efficient to do it this way. NRI has moved its location to: Corporation for National Research Initiatives 1895 Preston White Dr., Suite 100 Reston, VA 22091 (703) 620-8990 The telephone number is the same. The old Post Office Box is still valid, but mail sent to our physical location will reach us faster. Vint Cerf and Bob Kahn
-----------[000140][next][prev][last][first]---------------------------------------------------- Date: 13 Mar 88 12:28:59 GMT From: mouse@mcgill-vision.UUCP (der Mouse) To: comp.protocols.tcp-ip Subject: Re: SLIP for Ultrix
In article <1535@uhccux.UUCP>, torben@dorsai.ics.hawaii.edu (Prof. Torben N. Nielsen) writes: > In article <8802060858.AA08978@ucbvax.Berkeley.EDU> AFDDN.TCP-IP@GUNTER-ADAM.ARPA writes: >> We have a uVAX running Ultrix that I would "like" to have SLIP on. I have a pseudo interface driver that is known to work on MicroVAX-IIs running Ultrix 1.2 and 2.0. This can function as a SLIP driver, in conjunction with a user-level program. I can send details if anyone is interested. > I took a look at an Ultrix system at one time and kind of came to the > conclusion that trying to do it yourself to a binary Ultrix > distribution was no fun. Trying to do anything to a binary distribution is no fun. I hold the view that if you don't have source, you shouldn't even consider using it. However it is possible to drop a new network interface driver into a binary distribution. I can send you the distribution package for my IP-over-DECnet stuff, which contains the pseudo interface driver and directions for installing it even on a binary distribution. I started to write the user program I mentioned above, but I don't recall whether I finished it or not. If anyone cares, I can check and possibly finish it. der Mouse uucp: mouse@mcgill-vision.uucp arpa: mouse@larry.mcrcim.mcgill.edu
-----------[000141][next][prev][last][first]---------------------------------------------------- Date: 13 Mar 88 14:12:00 GMT From: CERF@A.ISI.EDU To: comp.protocols.tcp-ip Subject: NRI New Address
Forgive the broadside - it seemed most efficient to do it this way. NRI has moved its location to: Corporation for National Research Initiatives 1895 Preston White Dr., Suite 100 Reston, VA 22091 (703) 620-8990 The telephone number is the same. The old Post Office Box is still valid, but mail sent to our physical location will reach us faster. Vint Cerf and Bob Kahn
-----------[000142][next][prev][last][first]---------------------------------------------------- Date: 14 Mar 88 02:44:00 GMT From: brunner@SPAM.ISTC.SRI.COM (Thomas Eric Brunner) To: comp.protocols.tcp-ip Subject: Re: remote broadcasts
Steve, Jon, list, Jon wrote that a directed broadcast "caused a broadcast storm on our ethernet effectively bring down the net." In the 18 months that I've had a largish part of SRINET to watch, storms have come and gone due to local broadcast address mismatches, and broken cable. I have on occasion seen directed broadcasts, which didn't do as Jon describes - trigger a broadcast storm. ...I've just spoken to Jon, it appears that the directed broadcasts I saw here (SRI) from UCSC some many moons ago, were mentioned to him by our hardware facility manager as the/a cause of one-or-more of our network failures in the winter. This is wrong, so I'll make the informational corrections locally. Unless anyone has anything else to add, the "directed causes network meltdowns" discussion is at its end. Eric
-----------[000143][next][prev][last][first]---------------------------------------------------- Date: Mon 14 Mar 88 09:26:37-EST From: Stephen M. King <KING@AFSC-HQ.ARPA> To: tcp-ip@SRI-NIC.ARPA Subject: WHOIS for VMS Vax...
Does anyone know where I can get a copy of WHOIS which will run on a VMS based Vax? We have a VaxCluster (780s, 785, 8700, 8650) running VMS and Wollongong Shared-Deuna products. Source/binary is preferred... but binary only will still be appreciated. Need ASAP... thanks in advance. Steve -------
-----------[000144][next][prev][last][first]---------------------------------------------------- Date: 14 Mar 88 11:23:44 GMT From: dannyb@kulcs.uucp (Danny Backx) To: comp.protocols.tcp-ip Subject: Re: rsh equivalent
In article <3647@bloom-beacon.MIT.EDU> wesommer@athena.mit.edu (William E. Sommerfeld) writes:
>In article <102@icarus.kulcs.uucp> dannyb@kulcs.UUCP (Danny Backx) writes:
>>If you need better authentication than BSD's r*, I think this may do :
>>the rex-system uses the same "UNIX-style authentication" that the entire RPC
>>package uses.
>
>Have you actually looked at what `UNIX style authentication' is for
>Sun RPC?
>
>The client puts its hostname, userid and group set in the packet; the
>server is expected to take the client's word for it, and usually does.
I know the original system from Sun is far from secure.
You can make it MUCH better, though.
You can always check :
1) does the client have a port nr. < 1023
If not, throw this request away
2) is the host the client is sending from one of a selected set of
'trusted' machines.
If not, throw this request away
I can think of two possible ways to break into this :
1) put a machine on the net who believes he is somebody else
This can be detected by the other machines, though, especially the one
that the fraud pretends to be.
2) the user trying to break in already broke the protection on the
machine he is sending from.
I don't think defense against this is possible.
I'm sure Kerberos is better... I only wanted to state that rex could be used.
Danny Backx
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Danny Backx | mail: Katholieke Universiteit Leuven
Tel: +32 16 200656 x 3537 | Dept. Computer Science
E-mail: dannyb@kulcs.UUCP | Celestijnenlaan 200 A
... mcvax!prlb2!kulcs!dannyb | B-3030 Leuven
dannyb@kulcs.BITNET | Belgium
-----------[000145][next][prev][last][first]---------------------------------------------------- Date: 14 Mar 88 13:43:15 GMT From: isns01@ms3.UUCP (Jim Chappell) To: comp.protocols.tcp-ip Subject: IMP interface design
I'm teaching myself how this sucker works because when its broke no one in BBN or DCA that I contact can help, and I'm left in the dark like those mushrooms in a PA farm. Can anyone interpret the following netstat -h output? IMP Host Table Flags Host Qcnt Q Address RFNM Timer A ardec.arpa 8 8090a780 8 127 A isec-oa.arpa 8 80908f80 8 125 A nosc-tecr.arpa 0 0 4 0 A ria-1.arpa 8 80906e00 8 72 A usadhq2.arpa 8 80907d80 8 126 A optimis-pent.ar 8 80908500 8 128 A brl.arpa 8 8090ab80 8 127 A 26.0.0.104 8 8090b980 8 127 A sri-nic 6 8090e180 8 0 Thanks, -- Jim Chappell UUCP: ...!umd5!vrdxhq!ms3!jrc ISN Corp. (703) 979-8900 ARPA: jrc@hios-pent 1235A Jeff Davis Hwy, Suite 220 Arlington, Va 22202
-----------[000146][next][prev][last][first]---------------------------------------------------- Date: 14 Mar 88 14:26:37 GMT From: KING@AFSC-HQ.ARPA (Stephen M. King) To: comp.protocols.tcp-ip Subject: WHOIS for VMS Vax...
Does anyone know where I can get a copy of WHOIS which will run on a VMS based Vax? We have a VaxCluster (780s, 785, 8700, 8650) running VMS and Wollongong Shared-Deuna products. Source/binary is preferred... but binary only will still be appreciated. Need ASAP... thanks in advance. Steve -------
-----------[000147][next][prev][last][first]---------------------------------------------------- Date: 14 Mar 88 15:08:22 GMT From: jas@MONK.PROTEON.COM (John A. Shriver) To: comp.protocols.tcp-ip Subject: Re(2): maximum Ethernet throughput
I quick look with adb at SunOS 3.4 reveals that Sun is initializing the Intel 82586 Ethernet chip per Ethernet specifications for interfame spacing. The instruction: _iedefaultconf+0x5a: movb #0x60,a5@(0xb) is moving an interfame spacing of 96 bits (9.6 microseconds) to the interfame spacing (offset 0xb) field in the Configure command block for the 82586. Confirm this for yourself on your Sun. They are not cheating. There are simply Ethernet boards that crash trying to do address compares at full speed, and there are host implementations (DECnet-VAX) that assume that the Ethernet interface will always send packets than they can generate them. These implementations have Ethernet-related bugs--the Sun does not. The Sun proves to be a good tool for finding these bugs. Enough said?
-----------[000148][next][prev][last][first]---------------------------------------------------- Date: 14 Mar 88 15:59:26 GMT From: thompson@dalcs.UUCP (Michael A. Thompson) To: comp.protocols.tcp-ip,comp.dcom.lans Subject: Re: ARP hardware field
In article <117@wbcs.UUCP> doug@wbcs.UUCP (Doug Kratky) writes:
>What does a 2 value in the hardware field of ARP (ar_hrd)
>represent? Does anyone have a list of the different values
>that are valid for the hardware field and the types of
>hardware they correspond to?
The following is extracted from rfc1010:
ADDRESS RESOLUTION PROTOCOL PARAMETERS
The Address Resolution Protocol (ARP) specified in RFC 826 [64] has
several parameters. The assigned values for these parameters are
listed here.
Assignments:
Operation Code (op)
1 REQUEST
2 REPLY
Hardware Type (hrd)
Type Description References
---- ----------- ----------
1 Ethernet (10Mb) [JBP]
2 Experimental Ethernet (3Mb) [JBP]
3 Amateur Radio AX.25 [PXK]
4 Proteon ProNET Token Ring [JBP]
5 Chaos [GXP]
6 IEEE 802 Networks [JBP]
7 ARCNET [JBP]
Protocol Type (pro)
Use the same codes as listed in the section called "Ethernet
Numbers of Interest" (all hardware types use this code set for
the protocol type).
--
Michael A. Thompson, Dept. Math, Stats, & C.S., Dalhousie U., Halifax, N.S.
thompson@dalcs.uucp From Bitnet or Uucp
thompson@cs.dal.cdn From Bitnet or Cdn
thompson%dalcs.uucp@uunet.uu.net From Arpa
-----------[000149][next][prev][last][first]---------------------------------------------------- Date: 14 Mar 88 17:28:20 GMT From: boesch@VAX.DARPA.MIL To: comp.protocols.tcp-ip Subject: Rumors about the death of the ARPANET
There have been a number of rumors about the impending death of the ARPANET. Here is the current DARPA position. Brian Boesch ------------------------------------------------------------------------ DEATH OF THE ARPANET AND OTHER PARANOIA There have been a number of rumors throughout the community that the ARPANET project is being terminated. Many individuals and organizations have expressed concern that the service that they have become accustomed to will be terminated. Enough rumors, now a word from your sponsor, DARPA. The ARPANET project in fact is being terminated, but not soon. DARPA is in the business of conducting research into critical NEW technologies that will advance the state of the art. ARPANET is neither new, nor state of the art. It is slow and expensive. ARPANET was founded in the early 70's when 56Kbit/second trunks were on the cutting edge of modulation and transmission technology. Packet switching was unheard of. (An interesting fact is that the average terminal of the day was 30cps giving the net trunks about a factor of 230 faster than the average user interface). Since that time the project expanded into the INTERNET where a number of dissimilar networks could be interconnected relatively transparently. The internet grew from about 63 hosts to over 20,000. The local nets that connect to the ARPANET and other Wide Area Nets (WANs) progressively increased in speed. The result is that while in '73 a large number of users could effectively share one trunk, today, one user on a PC can overload the entire capacity of the ARPANET. In addition to being overloaded, the ARPANET is no longer able to support its other prime function, that of a research base. To conduct any kind of experiment on the ARPANET causes too much service disruption to the community. Finally, the ARPANET is absorbing a significant fraction of our total research budget in what is really a support function. Solution, eliminate the source of the problem. Rather than cutting off the community our approach is to outgrow the ARPANET in a few years. The follow on network experiment will be called the Defense Research Internet (DRI). We are also working in conjunction with other Federal agencies, most notably National Science Foundation, to integrate our networking experiments with the new regional networks, the NSFNET project, and other agency networks. An additional source of confusion is the fact that we are currently arranging for NSFNET to support some ARPANET users, as part of a joint effort to reduce costs by phasing out overlapping service. Our intention, as always, is to do this with minimal disruption to the reserach community. While this happening, we will be putting together the initial version of the DRI apart from the ARPANET. From the beginning the DRI will provide the long distance trunk capacity that the ARPANET lacks. Initial speeds will be 1.5Mbit/second per link (a factor of 25 improvement). The DRI will also be segregated into an "experimental" and an "operational" side. The experimental side will have higher performance, with the possibility of higher degree of net problems; the operational side will support high data-rate applications such as image transfer. The experimental side will be phased from 1.5Mbit to higher and higher bandwidths with the intent of eventually reaching gigabit/second performance; the operational side will take over for the ARPANET. It will be operated by a contractor, and will be funded as overhead on individual users' projects rather than becoming a drain on the Networking research budget. After the DRI is stable, the ARPANET will be phased out. PLEASE DON'T BURY US WITH QUERIES ON THE DETAILS OF THE IMPLEMENTATION, WE DON'T HAVE TIME TO ANSWER THEM. AS DETAILS ARE FINALIZED AND READY FOR PUBLIC DISSEMINATION, WE WILL POST THEM. Mark Pullen & Brian Boesch - -------
-----------[000150][next][prev][last][first]---------------------------------------------------- Date: 14 Mar 88 18:30:45 GMT From: mohsen@retix.retix.COM (Mohsen Banan) To: comp.protocols.tcp-ip Subject: Re: X.400<->RFC822
In article <8803081451.AA24107@tcgould.TN.CORNELL.EDU> swb@TCGOULD.TN.CORNELL.EDU (Scott Brim) writes: >I know work has been going on for a while on gateways between X.400 >mail and RFC822 mail (ISO and DoD IP-based Internet). Could someone >give me pointers and contacts to find out how the work is progressing, >what is available, and what will be available this year? > Thanks very much....Scott RFC987 (Mapping between X.400 and RFC822) is the title of the document that you want. (S. E. Kille, University College London, June 1986.) It was posted to the net in Nov. 1987. I am also interested in X.400 <---> RFC822 mapping work that people are doing.
-----------[000151][next][prev][last][first]---------------------------------------------------- Date: 14 Mar 88 20:36:29 GMT From: haas@gr.utah.edu (Walt Haas) To: tcp-ip@sri-nic.arpa Subject: Re: AT&T ISN as a Method of Connecting Ethernets
In article <20778@amdcad.AMD.COM>, charlie@amdcad.AMD.COM (Charlie Slater) writes:
[stuff deleted]
> ISN provides sophisticated routing for all of its digital
> services except the Ethernet bridge. Like Vitalink's, AT&T's
^^^^^^^^^
> bridge mixes (internal) network address resolution with routing.
[stuff deleted]
> There is no reason a "disconnected" polygon (e.g. a
> dog-leg) cannot be used for network address resolution and a
> closed polygon used for transferring data over the shortest path
> once addressing has been resolved. Like Vitalink, AT&T just did
^^^^^^^^
> not bother. If you understand this, you can skip the next four
> paragraphs.
[stuff deleted]
Vitalink's new software release does exactly what you suggest.
Furthermore the Vitalink software now interoperates with DEC
LANbridges to form a unified spanning tree for routing. Call
Mike Coker at Vitalink and ask him to explain it to you.
Cheers -- Walt Haas haas@cs.utah.edu utah-cs!haas
-----------[000152][next][prev][last][first]----------------------------------------------------
Date: 14 Mar 88 20:49:00 GMT
From: WANCHO@SIMTEL20.ARPA ("Frank J. Wancho")
To: comp.protocols.tcp-ip
Subject: Whither MILNET?(There is a possible pun in the Subject line...) I'm jealous. Can I get my host rehomed/dual-homed to ARPANET/DRI? I'll bet our traffic is the cause of a major portion of the mailbridge congestion (if that helps the cause to be moved)... It's time for the MILNET management to speak up and tell us what's in store for the production side of this INTERNET... and when... --Frank
-----------[000153][next][prev][last][first]---------------------------------------------------- Date: 14 Mar 88 23:58:22 GMT From: brad@cayman.COM (Brad Parker) To: comp.dcom.lans,comp.protocols.tcp-ip Subject: who posted the delni summary? (enet in a can)
A few years ago (was it that long?) some kind soul posted a very elaborate explanation / expose about "ethernet in a can" a.k.a. delni boxes. It contained a nice list of features/problems/issues which I would like to read. Could someone send it to me or tell me where's it archived or ftp'able (or whatever). Something tells me it was someone from NASA/Ames (home of the P-3's) or a cad company or AMD? Truth is I don't remember. Help! Thanks in advance. -brad ps: could someone send me mail if this gets out; I'm not sure posting is working here. -- Brad Parker Cayman Systems "You are sleeping; you don't want to believe..." brad@Cayman.com - from a (yet another) Smith's tune
-----------[000154][next][prev][last][first]---------------------------------------------------- Date: Tue, 15 Mar 88 10:20:29 CST From: hrp%windsor.CRAY.COM@uc.msc.umn.edu (Hal Peterson) To: tcp-ip@sri-nic.arpa Subject: offloading the protocols
An interesting point came up in the recent discussion prompted by Van Jacobson's improvements on TCP capacity: since network capacity is increasing drastically, it is becoming ever more important to put protocol handling where it won't interfere with a host's real work; that is, on an outboard processor. But Dave Clark has said that in practice these outboard processors don't save much, because of the necessary complexity of the interface between the OP and the CPU. If this is true (and I'm sure we can find someone to debate against it), then the next generation of protocols should be designed with OPs specifically in mind. But what does that mean? What does a protocol suite need to look like so it has a clean point of cleavage between the duties of the central and the outboard processor? -- Hal Peterson / Cray Research / 1440 Northland Dr. / Mendota Hts, MN 55120 hrp%hall.CRAY.COM@umn-rei-uc.ARPA ihnp4!cray!hrp (612) 681-3145
-----------[000155][next][prev][last][first]---------------------------------------------------- Date: 15 Mar 88 07:11:55 GMT From: romkey@kaos.UUCP (John Romkey) To: comp.protocols.tcp-ip Subject: Re: rsh equivalent
In article <1188@kulcs.kulcs.uucp> dannyb@kulcs.UUCP (Danny Backx) writes: >I know the original system from Sun is far from secure. >You can make it MUCH better, though. > >You can always check : > 1) does the client have a port nr. < 1023 > If not, throw this request away "Trusted ports" (when port numbers less than 1024 can only be used by a trusted user) exist only in the world of the Berkeley UNIX TCP. Virtually no TCP/IP implementations that are not derived from BSD UNIX have the concept of "trusted ports"; they will allow any user program to open a connection on any port that isn't already in use. Some of the non-BSD TCP's also support rsh; I know of at least one. Rsh is a simple enough protocol that you can bring it up pretty easily on non-UNIX systems. It's useful enough that it's desireable to do so. Trusted ports are a phenomenally bad idea in a heterogeneous environment where you really want security. Even in a homogenous environment of all BSD systems, if some are being used as personal workstations chances are that their users can easily boot them in single user mode and run programs as root. They shouldn't be depended upon to do anything other than provide security holes. -- - john romkey ...harvard!spdcc!kaos!romkey romkey@kaos.uucp romkey@xx.lcs.mit.edu
-----------[000156][next][prev][last][first]---------------------------------------------------- Date: 15 Mar 88 08:58:00 GMT From: karn@thumper.bellcore.com (Phil R. Karn) To: comp.protocols.tcp-ip Subject: Re: TCP Keep-alives, also push bit
In BSD at least, keepalives are implemented by sending a TCP segment containing a single byte of "garbage". However, the SEQ field is one less than the receiver is expecting, so it is not accepted as real data. When the receiver sees an "old" data packet (i.e., a packet containing data that has already been acked, i.e., the sequence number in the header plus the length of its data is less than the receiver's RCV.NXT) it is required by the spec to send a segment with its next expected sequence number, i.e., RCV.NXT, in the ACK field. (This is primarily intended to prevent deadlock in normal data transfer should an acknowledgment packet be lost.) The "polling" TCP uses this "do-nothing ACK" as the indication that the remote host is still there. So hosts that don't respond properly to BSD-style keepalives are most likely not following the spec. Having said this, I should point out that keepalives are NOT a formal part of the TCP spec. I also think they're a very bad idea. I didn't always feel this way. However, some long and frustrating experiences with slow, unreliable and often expensive network paths (amateur packet radio, as well as commercial X.25 networks that charge for every packet) have turned me into a crusader against keepalive pinging. It simply isn't worth the cost, especially when there's no way for me to tell the other end to cease and desist. Besides, the whole philosophy of TCP and the datagram approach to networking was supposed to be reliability and robustness in the face of network problems. Why should the system gratuitously close a connection just because the network path happens to go down for a few minutes? If the connection has been idle during the entire outage, the user wouldn't even know (or care) that there had been a problem, as long as it's back by the time he sends more data. But keepalive pinging will make SURE he knows in the most annoying way possible! In the same category are TCPs that immediately close a connection when they get an ICMP Unreachable message. At most they should abort connections only before they are established; once established they should serve as diagnostic messages only. Phil
-----------[000157][next][prev][last][first]---------------------------------------------------- Date: 15 Mar 88 16:05:15 GMT From: ftp!nancy@bloom-beacon.mit.edu (Nancy Connor) To: tcp-ip@sri-nic.arpa Subject: Re: ARP hardware field
Michael Thompson writes:
Protocol Type (pro)
Use the same codes as listed in the section called "Ethernet
Numbers of Interest" (all hardware types use this code set for
the protocol type).
I don't believe that this is true. I know that Proteon uses a
different set of codes from the Ethernet list I sent out a while ago.
-Nancy Connor
FTP Software
... !harvard!spdcc!ftp!nancy
nancy@ftp.com
-----------[000158][next][prev][last][first]---------------------------------------------------- Date: 15 Mar 88 18:52:37 GMT From: oconnor@SCCGATE.SCC.COM (Michael J. O'Connor) To: comp.protocols.tcp-ip Subject: IP options crash our Sun gateway
When our stock SMI DDN gateway attempted to forward IP-grams containing RR or LSRR options, it would crash. Our box is a 3/260 running SOS 3.5 and acts as a gateway between our local ethernet-based network and the ARPANET. We have only been able to test this behavior on outgoing packets, but if we are correct in our diagnosis, the problem should occur when the box attempts to forward any IP-option bearing packets in either direction. According to the engineer assigned to our service request, Sun has assigned the problem bug number 1008944 but will not supply a fix for 3.n SOS. He stated that the problem should be fixed in 4.0 SOS which will be distributed later in 1988. Based on a report from Allison Mankin of MITRE, that the crashing is caused by a previously reported typo in ip_stripoption(), I have patched our binary in an attempt to reverse the effects of the typo. The patch has been working now for a little over 2 weeks. Working in the sense that our machine no longer crashes when forwarding IPgrams which contain options. I have yet to verify what is going out the other interface. If anyone else is affected by this, and the legal boys allow it, I am willing to supply the binary patch. It only consists of modifying a register value in 2 consecutive instructions. Mike
-----------[000159][next][prev][last][first]---------------------------------------------------- Date: 15 Mar 88 19:05:02 GMT From: ron@topaz.rutgers.edu (Ron Natalie) To: comp.protocols.tcp-ip Subject: Re: TCP/IP on IBM (was Re: BITNET)
Perhaps Kludge was too harsh a word. I haven't seen one of these yet although we will probably end up with one. It uses an Industrial IBM-PC with a channel interface. That's about all I know. -Ron
-----------[000160][next][prev][last][first]---------------------------------------------------- Date: 16 Mar 88 00:53:11 GMT From: iglesias@ICS.UCI.EDU (Mike Iglesias) To: comp.protocols.tcp-ip Subject: Turning off ip forwarding in Ultrix v1.2
We have a microvax II running Ultrix v1.2 that is doing ip forwarding We don't want it to that. Is there a way to turn it off, given that we don't have sources? Please reply directly to me - I don't want the whole list to have to read all the replies (I hope to get!). Thanks, Mike Iglesias University of California, Irvine
-----------[000161][next][prev][last][first]----------------------------------------------------
Date: 16 Mar 88 01:06:02 GMT
From: cheriton@PESCADERO.STANFORD.EDU ("David Cheriton")
To: comp.protocols.tcp-ip
Subject: Re: offloading the protocolsVMTP (RFC 1045) is specifically designed to work well with hardware support on a network adaptor board with its own processing power. In fact, we have designed and are implementing such a board to support VMTP, and this process, concurrent with the protocol design and refinement, has significantly influenced the design of the protocol. I would agree there are severe limits on what such intelligent interfaces can provide with current protocols independent of how well the boards are designed. I would also agree that most intelligent interfaces to date are slower than the dumb fast ones when you look at transport-level performance. However, my experience with VMTP and the NAB (Network adaptor Board) we are building convinces me that this approach is essential for transport-level performance in the same general range as the network when we go to 100 Mb networks and higher. Moreover, offboarding the processing load of protocols seems to have additional advatnages on multiprocessors machines because the interrupts and cache demands of protocols leans on the critical resources, namely the system bus. Interested parties can send to my secretary (nevena@pescadero.stanford.edu) for a copy of our draft paper on the NAB. The VMTP spec is of course available as an RFC - only the first 30 pages are really needed to get a feeling for the protocol. David Cheriton
-----------[000162][next][prev][last][first]---------------------------------------------------- Date: Wed, 16 Mar 88 17:16:16 PST From: satz@clash.cisco.com To: Hank Nussbacher <HANK%TAUNIVM.BITNET@cunyvm.cuny.edu> Cc: tcp-ip@sri-nic.arpa Subject: Re: ISN
>> In addition, it has implemented a TTL type >> of field so that packets that loop around between REBs get >> removed. You can configure in each REB what the maximum TTL >> should be and each outgoing packet gets assigned that number. >> As the packet passes thru other REBs, the number is decremented. >> When it hits zero, the packet is thrown away. If it is acting as a router it should use the TTL field in the IP header. It seems, from your message, that another field may be used possibly from a REB-REB protocol.
-----------[000163][next][prev][last][first]---------------------------------------------------- Date: Wed, 16-Mar-88 16:23:55 EST From: tomwest@gpu.utcs.toronto.edu (Tom West) To: comp.protocols.tcp-ip Subject: Wanted: Book on TCP/IP
A little while ago, there were several recommendations for a book that might serve as an introduction to the technical aspects of TCP/IP. It (if I remember correctly) was to be published by Addison-Wesley. Unfortunately, I lost the reference. Could kind person mail me the author and title of the book. Thank you very much. -- Tom West BITNET: tomwest@utorgpu.bitnet, tomwest@gpu.utcs.utoronto Internet: tomwest@gpu.utcs.toronto.edu UUCP: tomwest@utgpu utzoo, yetti, harpo, mnetor \ cbosgd, deepthot, utoronto - !utgpu!tomwest ihnp4, lsuc, sfmin, vnr-vpa /
-----------[000164][next][prev][last][first]---------------------------------------------------- Date: 16 Mar 88 12:36:00 GMT From: backman@interlan.UUCP (Larry Backman) To: comp.protocols.tcp-ip Subject: Re: TN3270 on Terminal Servers
In article <Mar.12.17.46.18.1988.5479@athos.rutgers.edu> hedrick@athos.rutgers.edu (Charles Hedrick) writes: >I know at least one vendor who claims to be working on tn3270 mode. I >think I can tell you why it hasn't been done yet. First, it needs >more memory and CPU than a normal telnet connection. You have to >maintain a screen image and various other state information, and you >have to do the emulation. Most terminal servers currently use a 68000 >with not much memory. But that's not the big problem. The big >problem is that you need to have access to somthing like termcap for >the user's terminal. Terminal servers don't have disks, and they [] From my past, I remember implementing a 3270 emulator under UNIX using termcaps. It doesn't work! 3270 terminals need 5 or 6 modes of screen attributes to be effective (normal, hilight,reverse,reverse hilight,blinking,underline,etc.). Verry few termvcaps entries have these attributes defined completely. Now the vendor has to decide... do I want to start mucking with termcaps for each and every terminal type I wish to support, or... let the user do it themselves. As I remember, neither way was a viable solution. Yes you could define a limited subset of terrminals that would be supported, but that subset grows rapidly based on user feedback. As to memory and CPU. The EBCDIC --> ASCII stuff eats some cycles, but the byte stream interpretation was no worse than any VT220 application. You have to scan for order codes and parse some following bytes accoordingly. Each screen image needs roughly 4K of memory, 2 K for the image, and 2K for the attributes, not a lot of memory these days. As with anything else, it can be done, but its a pain. Is it worth it? Count the number of PC based 3270 emulators sold; multiply by $500. What do you think? Larry Backman Micom - Interrlan
-----------[000165][next][prev][last][first]---------------------------------------------------- Date: 16 Mar 88 16:43:35 GMT From: braden@VENERA.ISI.EDU To: comp.protocols.tcp-ip Subject: Re: ISN
There is a bridge that is about 70% of a router. It is called REB (Remote Ethernet Bridge). The designer has taken a small number of the fields in the IP header and has done a similar implementation at level II. For example, REB can close loops. I can assign a weight to each line (i.e. one line is 9.6kb, another is T1, another is X.25, and another should hardly ever be used) and based on the weight and the network load, the REB will determine the routing the packet should take. In addition, it has implemented a TTL type of field so that packets that loop around between REBs get removed. You can configure in each REB what the maximum TTL should be and each outgoing packet gets assigned that number. As the packet passes thru other REBs, the number is decremented. When it hits zero, the packet is thrown away. There are many other functions that was designed via 802.3 D - Managament specs. What it cannot do is ARP or ICMP but if you are looking for a bridge replacement, you should seriously evaluate the RAD REB. Hank I would describe this as a level-2 router, essentially an IMP for Ethernets. Seems like a reasonable concept. The bridge guys work very hard to keep the overhead low enough to handle back-to-back Ethernet packets; can the REB guys do as well, with the extra protocol processing? Bob Braden
-----------[000166][next][prev][last][first]---------------------------------------------------- Date: 16 Mar 88 18:22:52 GMT From: jc@heart-of-gold (John M Chambers x7780 1E342) To: comp.protocols.tcp-ip Subject: Ping, checksum algorithm?
Does anyone have a PD version of ping? How about a C-coded routine that does the IP checksum calculation? We have one that is written in VAX assembly language, which is OK for a VAX, but it doesn't work too well on a 68020....
-----------[000167][next][prev][last][first]---------------------------------------------------- Date: Wed, 16 Mar 88 17:15:43 IST From: Hank Nussbacher <HANK%TAUNIVM.BITNET@CUNYVM.CUNY.EDU> To: tcp-ip@sri-nic.ARPA Subject: ISN
>If bridges are connected via a closed polygon, the packet stays >"in flight" forever. > >charlie slater >charlie@amdcad.amd.com There is a bridge that is about 70% of a router. It is called REB (Remote Ethernet Bridge). The designer has taken a small number of the fields in the IP header and has done a similar implementation at level II. For example, REB can close loops. I can assign a weight to each line (i.e. one line is 9.6kb, another is T1, another is X.25, and another should hardly ever be used) and based on the weight and the network load, the REB will determine the routing the packet should take. In addition, it has implemented a TTL type of field so that packets that loop around between REBs get removed. You can configure in each REB what the maximum TTL should be and each outgoing packet gets assigned that number. As the packet passes thru other REBs, the number is decremented. When it hits zero, the packet is thrown away. There are many other functions that was designed via 802.3 D - Managament specs. What it cannot do is ARP or ICMP but if you are looking for a bridge replacement, you should seriously evaluate the RAD REB. Hank
-----------[000168][next][prev][last][first]---------------------------------------------------- Date: 16 Mar 88 21:00:31 GMT From: eshop@saturn.ucsc.edu (Jim Warner) To: comp.protocols.tcp-ip Subject: Re: Ping, checksum algorithm?
The 'ping.c' distributed with Berkeley unix is public domain, distribution unlimited, according to comments in the source. What's your address?
-----------[000169][next][prev][last][first]---------------------------------------------------- Date: 17 Mar 1988 05:12-EST From: CERF@A.ISI.EDU To: hrp%windsor.CRAY.COM@UMN-REI-UC.ARPA Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: offloading the protocols
I'm not goin to get into the front-end versus operating system resident
protocol argument (I argued against the front-end years ago on the same
basis you suggest Dave Clark argues, if anyone cares about my historical
biases).
However, it seems to me that as you approach the gigabit channels, you
really want to simplify the host's view of networking. An analogy might be
found in disk/file access and virtual memory. Years ago, an operating
systme was designed at UCLA called the Sigma EXperimental system (SEX for
short - the user's manual was a popular item!). It ran on a Sigma 7 made
by Scientific Data System (later, Xerox Data Systems, later, R.I.P.).
The notion of associating ("coupling" - God, I never thought about how
suggestive that term was in connection with the operating system acronym)
virtual memory with pages of files was an essential design element.
One would associate a particular virtual page space with disk pages
occupied by a file. This is not much different than virtual memory
linked to pages of a disk, except in this case, actions to the memory
content were reflected in changes to the FILE (not just changes to a
disk page which happened to represent a page of virtual memory space).
So, the user's virtual memory space was mapped onto the file system. I
imagine Multics could be considered to have done something like that
only even more elegantly with its rich addressing structure.
Perhaps what is needed is a way to associate virtual memory with places
in the networking space. Writing to virtual memory would be like writing
to the network. PDP-11's had the concept of associating certain words of
memory with I/O channels. But what I am looking for is a notion that lets
very simple actions to memory be interpreted by outboard processors as
network-related actions.
Perhaps Dave Clark could expand on his theme which I view as related to
your question if not the rather poorly expressed ideas above.
Vint Cerf
-----------[000170][next][prev][last][first]---------------------------------------------------- Date: 17 Mar 88 01:16:16 GMT From: satz@CLASH.CISCO.COM To: comp.protocols.tcp-ip Subject: Re: ISN
>> In addition, it has implemented a TTL type >> of field so that packets that loop around between REBs get >> removed. You can configure in each REB what the maximum TTL >> should be and each outgoing packet gets assigned that number. >> As the packet passes thru other REBs, the number is decremented. >> When it hits zero, the packet is thrown away. If it is acting as a router it should use the TTL field in the IP header. It seems, from your message, that another field may be used possibly from a REB-REB protocol.
-----------[000171][next][prev][last][first]---------------------------------------------------- Date: 17 Mar 88 03:48:09 GMT From: thomson@oldhub.toronto.edu (Brian Thomson) To: comp.protocols.tcp-ip Subject: Re: maximum Ethernet throughput
Van Jacobson's results are certainly startling, but I can't help believing that a significant part of that speedup must be in changes to the mbuf handling, the socket code, and the LANCE driver. My evidence is a test I ran on a 3/50: I defined a 'protocol' whose PRU_SEND action was to checksum each mbuf then hand it directly to the driver, with a dummy AF_UNSPEC destination so there would be no ARPing going on. This exercises vanilla SUN mbuf, socket, and interface driver code, while replacing all of TCP/IP by simple checksumming - so no protocols at all. The data goes nowhere, and there are no acks to deal with. Even so, this configuration could not source data to the wire faster than about 3.6Mb/sec. I could hit 8Mb/sec if I threw the data away right after checksumming, without passing it to the driver at all. -- Brian Thomson, CSRI Univ. of Toronto utcsri!uthub!thomson, thomson@hub.toronto.edu
-----------[000172][next][prev][last][first]---------------------------------------------------- Date: 17 Mar 88 05:52:55 GMT From: mouse@mcgill-vision.UUCP (der Mouse) To: comp.protocols.tcp-ip Subject: Re: Need help with UNIX tcp
In article <8802181625.AA27348@cod.nosc.mil>, neerma@COD.NOSC.MIL (Merle A. Neer) writes: > The problem simply stated is this: the user process cannot get the > status of its tcp connections from UNIX. > Have any UNIX guru-types ever considered offering a > 'status(myconnect)' call? We'll gladly pay for one. If you're running 4.3, I can give you a socket ioctl to return the status of the connection (as in one of the values in ../netinet/tcp_fsm.h, like TCPS_LISTEN, TCPS_ESTABLISHED, TCPS_CLOSING, etc). It's not really hard; it'd take all of an afternoon. Just drop another ioctl into ../h/ioctl.h and into ../netinet/tcp_usrreq.c (in the if req == PRU_CONTROL statement). der Mouse uucp: mouse@mcgill-vision.uucp arpa: mouse@larry.mcrcim.mcgill.edu
-----------[000173][next][prev][last][first]---------------------------------------------------- Date: Thu, 17 Mar 88 11:02 From: "Antony F.Martin" (on UK.MOD.RSRE) <AFM%rsre.mod.uk@relay.MOD.UK> To: tcp-ip <@relay.MOD.UK:tcp-ip@sri-nic.arpa> Subject: RE: WHOIS for VMS Vax...
We have a version of WHOIS, written in Ada, which runs on a MicroVAX II with VMS and Wollongong TCP/IP with Shared-Deqna. We are prepared to make this available (perhaps via SIMTEL20?). Antony Martin Royal Signals and Radar Establishment Ministry of Defence UK
-----------[000174][next][prev][last][first]---------------------------------------------------- Date: 17 Mar 88 06:23:55 GMT From: mouse@mcgill-vision.UUCP (der Mouse) To: comp.protocols.tcp-ip Subject: Re: rsh equivalent
In article <23511@hi.unm.edu>, cyrus@hi.unm.edu (Tait Cyrus) writes:
> I am looking for PD version of code that accomplishes the same thing
> as rsh [...]. The reason I am interested in something other than rsh
> is because here at UNM we are strongly considering disallowing the r*
> programs (rsh/rcp/rlogin) because they do NOT conform to the RFC's
> [as previously indicated, the non-conformance in question is
> case-sensitivity of hostname lookups]
Why is this a disadvantage? The nameserver does case-insensitive
lookups; why should the user program have to care?
> as well as being BIG security problems (.rhosts).
If this is a problem at all, it's a problem with your user community.
They won't create .rhosts files unless they care more about convenience
than security, and if that's the case, nothing you do will help
(assuming you've educated them in the security holes implicit in
creating .rhosts files). People are almost always the weakest link in
any security system. You can "fix" the hosts.equiv and .rhosts
"problem" very easily by running this every night:
rm -f /etc/hosts.equiv
< /etc/passwd awk -F: '{printf("rm -f %s/.rhosts",$6);}' | sh
der Mouse
uucp: mouse@mcgill-vision.uucp
arpa: mouse@larry.mcrcim.mcgill.edu
-----------[000175][next][prev][last][first]---------------------------------------------------- Date: 17 Mar 88 16:35:00 PST From: "Gabriel Hirl" <gabi@twg.com> To: "king" <king@afsc-hq.arpa> Cc: <tcp-ip@sri-nic.arpa> Subject: Re:WHOIS for VMS Vax
The Wollongong WIN/TCP 3.2 release includes the WHOIS utility. First customer shipment is scheduled for April 1988. Also, for those interested, this release supports Van Jacobson's and Mike Karel's TCP code.
-----------[000176][next][prev][last][first]---------------------------------------------------- Date: 17 Mar 88 10:12:00 GMT From: CERF@A.ISI.EDU To: comp.protocols.tcp-ip Subject: Re: offloading the protocols
I'm not goin to get into the front-end versus operating system resident
protocol argument (I argued against the front-end years ago on the same
basis you suggest Dave Clark argues, if anyone cares about my historical
biases).
However, it seems to me that as you approach the gigabit channels, you
really want to simplify the host's view of networking. An analogy might be
found in disk/file access and virtual memory. Years ago, an operating
systme was designed at UCLA called the Sigma EXperimental system (SEX for
short - the user's manual was a popular item!). It ran on a Sigma 7 made
by Scientific Data System (later, Xerox Data Systems, later, R.I.P.).
The notion of associating ("coupling" - God, I never thought about how
suggestive that term was in connection with the operating system acronym)
virtual memory with pages of files was an essential design element.
One would associate a particular virtual page space with disk pages
occupied by a file. This is not much different than virtual memory
linked to pages of a disk, except in this case, actions to the memory
content were reflected in changes to the FILE (not just changes to a
disk page which happened to represent a page of virtual memory space).
So, the user's virtual memory space was mapped onto the file system. I
imagine Multics could be considered to have done something like that
only even more elegantly with its rich addressing structure.
Perhaps what is needed is a way to associate virtual memory with places
in the networking space. Writing to virtual memory would be like writing
to the network. PDP-11's had the concept of associating certain words of
memory with I/O channels. But what I am looking for is a notion that lets
very simple actions to memory be interpreted by outboard processors as
network-related actions.
Perhaps Dave Clark could expand on his theme which I view as related to
your question if not the rather poorly expressed ideas above.
Vint Cerf
-----------[000177][next][prev][last][first]---------------------------------------------------- Date: Thu, 17 Mar 88 20:59:46 -0500 From: Mike Brescia <brescia@PARK-STREET.BBN.COM> To: "kwe@bu-it.bu.edu (Kent W. England" <kwe@BU-CS.BU.EDU> Cc: tcp-ip@SRI-NIC.ARPA Subject: useful RR and SR (was: IP options crash our Sun gateway )
I have found source routing useful for tracing routes, both for local net access problems and routing problems between gateways. Today I had to bemoan the fact that a particular gateway would not source-route, even though it did not crash, because they had called to see why they could ping a core gateway but not establish an EGP connection. With source routing I send a packet from gateway A to B and back to myself, and vice versa. If it fails, I may get ICMP net-unreachable for route problems, or host-unreachable for host access problems. One additional feature would make problem tracking useful; that is the ability to ask a gateway to give back its opinion of the next hop for a particular destination net. This is the info that RR gives you, but only if the packet gets back to you. If gateway A wants to send to B and B is a black hole, you would like to get the info from A instead. I have been able to do source routing through 4.3BSD systems. I think they may do it even if IP_FORWARDING is off. LSI11 core gateways do source-and-record-route but not record-route. Butterfly gateways do both. In both gateways, the alignment of the IP address fields in the options is not critical. Mike Brescia BBNCC Gateway Development
-----------[000178][next][prev][last][first]---------------------------------------------------- Date: 17 Mar 88 14:23:33 GMT From: robert@richp1.UUCP (Robert Miller) To: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: who posted the delni summary? (enet in a can)
MICOM (1-800-LAN TALK) has just come out with an equivilant
of the DELNI box called 8-4-1 Multiport Transceiver.
Does everything the DELNI can plus costs less plus has more LED's
on front panel to provide more status. Real nice!
I have no connection with either DEC or MICOM other than that
we use both here.
--
.......................................
"To open, cut along dotted line." ....:.......................................
: : Robert Miller @ ihnp4!richp1!robert
.....
-----------[000179][next][prev][last][first]---------------------------------------------------- Date: 17 Mar 88 16:14:39 GMT From: kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) To: comp.protocols.tcp-ip Subject: Re: IP options crash our Sun gateway
In article <8803151852.AA12900@sccgate.scc.com> oconnor@SCCGATE.SCC.COM (Michael J. O'Connor) writes: >When our stock SMI DDN gateway attempted to forward IP-grams containing RR or >LSRR options, it would crash. Our box is a 3/260 running SOS 3.5 and acts as >a gateway between our local ethernet-based network and the ARPANET. > >Based on a report from Allison Mankin of MITRE, that the crashing is caused by >a previously reported typo in ip_stripoption(), I have patched our binary in an >attempt to reverse the effects of the typo. The patch has been working now for >a little over 2 weeks. It seems that IP RR and LSRR options will crash a lot of gateways. I would like to hear from others how widespread the problem is (other known implementation failures) and what they think the utility of RR and LSRR is for debugging and network management. Seems to me that record route and loose source routing options would be extremely useful for checking router tables without actually doing a netstat or equivalent. However, if there are too many routers that crash or don't record themselves or follow the route request, then such an option is unusable. I have never read a conversation on this in tcp-ip. Anyone able to make use of IP route options? If so, how useful is it?
-----------[000180][next][prev][last][first]---------------------------------------------------- Date: 17 Mar 88 17:37:58 GMT From: phil@EAST.BERKELEY.EDU (Phil Lapsley) To: comp.protocols.tcp-ip Subject: LSRR and RR IP options
These options can be extremely useful for figuring out what routes are being used to get from point A to point B. Although some gateways crash when presented with an IP datagram with LSRR/RR options (and almost as bad, other gateways simply drop the packet), things are generally getting better. Proteon gateways now (version 7.4) correctly handle LSRR/RR, and 4.3 BSD now does the right thing as well (although it had a bug that caused it to do some wrong stuff for a while). Buttergates also do the right thing. Ultrix (2.0) simply eats the packets, as does HPUX and Dynix (sequent OS). As mentioned, Suns often crash in the action of forwarding the packets. I don't know how the Fuzz fares under IP option attack. Still, one shouldn't say that the options are useless. Rather, one should beat on the vendors for selling joe code. (Call 1-800-USA4SUN and complain! :-) Phil
-----------[000181][next][prev][last][first]---------------------------------------------------- Date: 17 Mar 88 17:58:04 GMT From: toms@amdcad.AMD.COM (Tom Slykhouse) To: comp.protocols.tcp-ip,comp.dcom.lans Subject: PC/AT LANCE Card
Advanced Micro Devices has completed development on a Public Domain Ethernet board for the PC/AT's and Clones, based on our LANCE controller. Manuals, schematics and artwork are available for this product. We are additionally considering porting several of the common communications packages to this board. One possibility is KA9Q TCP/IP. If anyone on the net would like this package ported, or would prefer another package please respond to me with EMail. Tom Slykhouse Advanced Micro Devices toms@amdcad.AMD.COM decwrl!amdcad!toms (408)749-2517
-----------[000182][next][prev][last][first]----------------------------------------------------
Date: 17 Mar 88 19:02:00 GMT
From: AFM@rsre.mod.UK ("Antony F.Martin", on UK.MOD.RSRE)
To: comp.protocols.tcp-ip
Subject: RE: WHOIS for VMS Vax...We have a version of WHOIS, written in Ada, which runs on a MicroVAX II with VMS and Wollongong TCP/IP with Shared-Deqna. We are prepared to make this available (perhaps via SIMTEL20?). Antony Martin Royal Signals and Radar Establishment Ministry of Defence UK
-----------[000183][next][prev][last][first]---------------------------------------------------- Date: 17 Mar 88 20:28:54 GMT From: pedersen@acf3.NYU.EDU (paul pedersen) To: comp.protocols.tcp-ip Subject: Re: Ping, checksum algorithm?
In article <123@heart-of-gold> jc@heart-of-gold (John M Chambers x7780 1E342) writes: >[question about 'ping'] Sorry to post about this, but addresses like "jc@heart-of-gold" are really unacceptable. I tried to comment via e-mail, but of course no sane mailer will accept such an address. "Heart-of-gold" is too long for UUCP, and doesn't have the right format for the domain system. Puh-leeze get your system fixed so it doesn't send out articles with meaningless addresses.
-----------[000184][next][prev][last][first]----------------------------------------------------
Date: 18 Mar 88 00:35:00 GMT
From: gabi@TWG.COM ("Gabriel Hirl")
To: comp.protocols.tcp-ip
Subject: Re:WHOIS for VMS VaxThe Wollongong WIN/TCP 3.2 release includes the WHOIS utility. First customer shipment is scheduled for April 1988. Also, for those interested, this release supports Van Jacobson's and Mike Karel's TCP code.
-----------[000185][next][prev][last][first]---------------------------------------------------- Date: 18 Mar 88 01:59:46 GMT From: brescia@PARK-STREET.BBN.COM (Mike Brescia) To: comp.protocols.tcp-ip Subject: useful RR and SR (was: IP options crash our Sun gateway )
I have found source routing useful for tracing routes, both for local net access problems and routing problems between gateways. Today I had to bemoan the fact that a particular gateway would not source-route, even though it did not crash, because they had called to see why they could ping a core gateway but not establish an EGP connection. With source routing I send a packet from gateway A to B and back to myself, and vice versa. If it fails, I may get ICMP net-unreachable for route problems, or host-unreachable for host access problems. One additional feature would make problem tracking useful; that is the ability to ask a gateway to give back its opinion of the next hop for a particular destination net. This is the info that RR gives you, but only if the packet gets back to you. If gateway A wants to send to B and B is a black hole, you would like to get the info from A instead. I have been able to do source routing through 4.3BSD systems. I think they may do it even if IP_FORWARDING is off. LSI11 core gateways do source-and-record-route but not record-route. Butterfly gateways do both. In both gateways, the alignment of the IP address fields in the options is not critical. Mike Brescia BBNCC Gateway Development
-----------[000186][next][prev][last][first]---------------------------------------------------- Date: 18 Mar 1988 10:19-EST From: Alessandro.Forin@SPEECH2.CS.CMU.EDU To: tcp-ip@sri-nic.arpa Subject: Re: Off loading the protocol
Work in the area of networked shared memory is progressing quite rapidly: It is not just a crazy thought. The following is a short list of references to recent work that is relevant to the subject. I'll be glad to receive notice of any other activity in the area by people in this list. 1. Bisiani, R. and Forin, A., ``Architectural Support for Multilanguage Parallel Programming on Heterogeneous Systems'', 2nd International Conference on Architectural Support for Programming Languages and Operating Systems, IEEE, Palo Alto , October 1987, pp. 21-30. 2. Cheriton D.R., ``Problem-oriented Shared Memory: A Decentralized Approach to Distributed System Design'', Proc. of the 6th Intl. Conf. on Distributed Computing Systems, May 1986, pp. 190-197. 3. Kai Li and Paul Hudak, ``Memory Coherence in Shared Virtual Memory Systems'', Proceedings of the Fifth Annual Symposium on Principles of Distributed Computing, ACM, 1986, pp. 229-239. 4. Krishnaswamy, Ahuja, Gelernter, Carriero, ``Progress Towards a Linda Machine'', Proc. ICCD, IEEE-CS and IEEE Circuits, October 1986, pp. 97-101. 5. Ramachandran, U., Ahamad, M., Khalidi, M., ``Hardware Support For Distributed Shared Memory'', Report GIT-ICS-87/41, Georgia Tech, November 1987. 6. Rashid, R. et al., ``Machine-Independent Virtual Memory Management for Paged Uniprocessors and Multiprocessor Architectures'', 2nd International Conference on Architectural Support for Programming Languages and Operating Systems, IEEE, Palo Alto , October 1987, pp. 31-39. 7. Wendorf, J. and Tokuda, H., ``An Interprocess Communication Processor: Exploiting OS/Application Concurrency'', Tech. report CMU-CS-87-152, Carnegie-Mellon University, March 1987. 8. Zayas, R.E., The Use of Copy-on-reference in a Process Migration System, PhD dissertation, Carnegie-Mellon, January 1987. ----------------------------------------------------------------------------- Alessandro Forin, Computer Science Dept., Carnegie-Mellon University, 5000 Forbes Pittsbugh PA, 15213. ARPA: af@cs.cmu.edu Phone: (412) 268-2569
-----------[000187][next][prev][last][first]---------------------------------------------------- Date: Fri, 18 Mar 88 12:00 EST From: DAN <S72TDAN%TOWSONVX.BITNET@CUNYVM.CUNY.EDU> To: TCP-IP@SRI-NIC.ARPA Subject: RE: Re: IP options crash our Sun gateway
I'M NOT TOO SURE ON HOW TO SEND A MAIL MESSAGE SO I'M DOING IT THIS WAY.
PLEASE UNSUSCRIBE ME FROM LIST TCP-IP.
-----------[000188][next][prev][last][first]---------------------------------------------------- Date: 18 Mar 88 07:17:11 GMT From: nishida@nsisv2.nec.junet (Takeshi.Nishida) To: comp.protocols.tcp-ip Subject: (none)
Dear Sir, I would like to get the "ARPANET Protocol Handbook", "Internet Protocol Transition Workbook", and other related published documents. How can I get such kind of documents? Thanks in advance. Takeshi Nishida Communication Research Lab. C&C Systems Research Labs. NEC Co. Kawasaki, Kanagawa 213, Japan
-----------[000189][next][prev][last][first]---------------------------------------------------- Date: 18 Mar 88 11:38:56 GMT From: farber@CIS.UPENN.EDU (David Farber) To: comp.protocols.tcp-ip Subject: Off loading the protocol
The following is abstracted from a note on our experiences with a line
of research aimed at eamining a radically different approach to "off
loading" designed for the very high speed networking era -- "Gigabit
networking". I would be happy to supply the full text and/or memnet
documents to any interested people.
Some Thoughts on the Impact of Very High Speed Networking on
Processor Interfaces
......
Approach
This note proposes a completely different view of computer
networking, a view which derives from experiments started in my
group at the University of Delaware (and continuing at the
University of Pennsylvania) resulting in the creation a novel
local network architecture called "MEMNet." MEMNet is a research
system aimed at exploring ways of removing the severe processing
overhead found in distributed operating systems. The approach
MEMNet takes is to treat the network as a mechanism which allows
a processor to access the collective memory space of the
distributed system. Thus, when a processor in a MEMNet
environment needs to send data via the high-speed local network,
it simply writes to memory addresses which are in the memory
space of the recipient processor. Similarly, the recipient
processor, when it chooses to examine data which has been "sent"
by another processor, reads its local memory (or physically-
remote memory, in a hierarchical memory system) simply by the
normal memory access mechanisms of that processor. In the MEMNet
environment, there is a set of special memory controllers with
adequate caching, connected together via a high-speed (200
megabit) ring. The caching provides a mechanism equivalent to the
snooping caches of modern multiprocessors.
During this research, we examined the architecture of software
systems which would run in a MEMNet environment. Much to our
surprise (although we should not have been surprised), the
software implications of such a distributed environment are
essentially non-existent. That is, a software system written to
run on the fully distributed MEMNet environment is essentially,
in all respects, identical to the same software system designed
to run on a simple multiprocessor, shared-memory environment.
The issues one must face in designing the architecture of
future wide-area, high-speed networks ......
......
In summary, this note suggests that we reexamine what we mean
by "networking" in the future. It essentially suggests that
networking is simply a special case of interprocess communication
over a widely-distributed computer system, and thus can take
advantage of technology already developed.
_________________________________________________________________________
---------------
David J. Farber; Prof. of CS and EE, Director - Distributed Systems Labs.
University of Pennsylvania/200 South 33rd Street/Philadelphia, PA 19104-6389
Tele: 215-898-9508; FAX: 215-274-8192
-----------[000190][next][prev][last][first]---------------------------------------------------- Date: 18 Mar 88 15:19:00 GMT From: Alessandro.Forin@SPEECH2.CS.CMU.EDU To: comp.protocols.tcp-ip Subject: Re: Off loading the protocol
Work in the area of networked shared memory is progressing quite rapidly: It is not just a crazy thought. The following is a short list of references to recent work that is relevant to the subject. I'll be glad to receive notice of any other activity in the area by people in this list. 1. Bisiani, R. and Forin, A., ``Architectural Support for Multilanguage Parallel Programming on Heterogeneous Systems'', 2nd International Conference on Architectural Support for Programming Languages and Operating Systems, IEEE, Palo Alto , October 1987, pp. 21-30. 2. Cheriton D.R., ``Problem-oriented Shared Memory: A Decentralized Approach to Distributed System Design'', Proc. of the 6th Intl. Conf. on Distributed Computing Systems, May 1986, pp. 190-197. 3. Kai Li and Paul Hudak, ``Memory Coherence in Shared Virtual Memory Systems'', Proceedings of the Fifth Annual Symposium on Principles of Distributed Computing, ACM, 1986, pp. 229-239. 4. Krishnaswamy, Ahuja, Gelernter, Carriero, ``Progress Towards a Linda Machine'', Proc. ICCD, IEEE-CS and IEEE Circuits, October 1986, pp. 97-101. 5. Ramachandran, U., Ahamad, M., Khalidi, M., ``Hardware Support For Distributed Shared Memory'', Report GIT-ICS-87/41, Georgia Tech, November 1987. 6. Rashid, R. et al., ``Machine-Independent Virtual Memory Management for Paged Uniprocessors and Multiprocessor Architectures'', 2nd International Conference on Architectural Support for Programming Languages and Operating Systems, IEEE, Palo Alto , October 1987, pp. 31-39. 7. Wendorf, J. and Tokuda, H., ``An Interprocess Communication Processor: Exploiting OS/Application Concurrency'', Tech. report CMU-CS-87-152, Carnegie-Mellon University, March 1987. 8. Zayas, R.E., The Use of Copy-on-reference in a Process Migration System, PhD dissertation, Carnegie-Mellon, January 1987. ----------------------------------------------------------------------------- Alessandro Forin, Computer Science Dept., Carnegie-Mellon University, 5000 Forbes Pittsbugh PA, 15213. ARPA: af@cs.cmu.edu Phone: (412) 268-2569
-----------[000191][next][prev][last][first]---------------------------------------------------- Date: 18 Mar 88 16:01:45 GMT From: oconnor@SCCGATE.SCC.COM (Michael J. O'Connor) To: comp.protocols.tcp-ip Subject: Re: IP options crash our Sun gateway
Maybe I should have worded it differently. It's my contention that a Sun gateway running a version of SOS earlier than 4.0 can crash when it attempts to forward any option bearing datagram not just the record route types. The only option generating software that I have access to is the Ping with RR and LSRR which was described in this forum a month or so ago. People were crashing our gateway every time they tried to send one of those packets through our SMI box. Excuse my pontificating, but it is the presence of IP-options that is optional not the implementation. I don't have a copy of the Mil-Std handy but my copy of the RFC states "Every internet module must be able to act on every option." I just don't think that crashing was the act that the authors had in mind. The part that still irritates me is SMI's attitude that this is a bug that I should be able to live with until they release SOS 4.0. On top of that there is the rumor that the Sunlink DDN package will not be updated until well after the 4.0 release. If true, that means our gateway will be the last machine upgradable to SOS 4.0. Mike
-----------[000192][next][prev][last][first]---------------------------------------------------- Date: 18 Mar 88 16:13:10 GMT From: mtune!codas!ablnc!gil@rutgers.edu (Gil Widdowson) To: tcp-ip@sri-nic.arpa Subject: TLI HELP!!!
I need some help with WIN/3B 2.1 and UNIX 5.3.1 TLI. I have an application that worked with both the TLI and sockets interface under WIN/3B 1.1. I have had to make some changes to make sockets work under 2.1, but I can not get even get to first base with TLI. The AT&T TLI documentation describes things at a generic level since it does not know anything about the transport provider you will be using. Unfortunately, the WIN documentation that I got, does not address what data structures need to be used. Is it still the sockets structures such as sockaddr_in when you deal with network addressing. Here is the problem I have now. I am trying to send a datagram. I do a t_open() and get a stream with a service type of T_CLTS according to the info returned to me. I do a t_bind(fd, NULL, &ret) and seem to get a port. What is the format of the eight byte ret.addr.buf returned? I am getting back what looks like a the port id in the first four bytes and zeroes in the last four? For ha-has, I do a t_getstate() before the t_sndudata() and it says the stream is in the idle state. Then when I attempt the t_sndudata(), I get errno 203 Socket operation on non-socket A rather strange TLI error. I am using the same udata structure I used under WIN/3B 1.1. This uses a sockaddr_in structure to define the destination address for the datagram. I would appreciate ANY help. I would really like some working code fragments using TLI and poll() to manage multiple stream I/O in the same process. Additional documentation references would also be appreciated. I currently have: UNIX Sys V programmer's ref and guide UNIX Sys V Network programmer's ref UNIX Sys V Streams programmer's ref Enhanced TCP/IP WIN/3B Reference Manual for release 2.1 Please reply via email to ihnp4!ablnc!utiprod!gil. thanks, gil widdowson AT&T (305) 660-6123
-----------[000193][next][prev][last][first]---------------------------------------------------- Date: 18 Mar 88 17:00:00 GMT From: S72TDAN@TOWSONVX.BITNET (DAN) To: comp.protocols.tcp-ip Subject: RE: Re: IP options crash our Sun gateway
I'M NOT TOO SURE ON HOW TO SEND A MAIL MESSAGE SO I'M DOING IT THIS WAY.
PLEASE UNSUSCRIBE ME FROM LIST TCP-IP.
-----------[000194][next][prev][last][first]---------------------------------------------------- Date: 18 Mar 88 18:13:12 GMT From: tsudik@MALIBU.USC.EDU (Gene Tsudik) To: comp.protocols.tcp-ip Subject: Re: LSRR and RR IP options
"4.3 does the right thing well"???? Does that include incorrectly filled out IP headers when fragmentation is performed and option(s) is(are) present in the header? Until this bug is fixed using any IP option is not safe. Gene Tsudik
-----------[000195][next][prev][last][first]---------------------------------------------------- Date: 18 Mar 88 19:13:15 GMT From: kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) To: comp.protocols.tcp-ip Subject: Re: offloading the protocols
In article <[A.ISI.EDU]17-Mar-88.05:12:56.CERF> CERF@A.ISI.EDU writes: [discussion of simplifying and speeding up network/host interface] > >Perhaps what is needed is a way to associate virtual memory with places >in the networking space. Writing to virtual memory would be like writing >to the network. PDP-11's had the concept of associating certain words of >memory with I/O channels. Doesn't Apollo's Domain [proprietary] networked operating system do just that?
-----------[000196][next][prev][last][first]---------------------------------------------------- Date: 18 Mar 88 21:08:14 GMT From: cpw%sneezy@LANL.GOV (C. Philip Wood) To: comp.protocols.tcp-ip Subject: Re: IP options crash our Sun gateway
I have found IP options and ICMP functions useful. I also feel that if they crash gateways, then the gateway should be replaced darned quick. I also think that users planning on joining or doing an Internet should become familiar with RFC1009 which explicitly states that Record Route, Loose and Strict Source Route,among the others, are required for gateways. OPTION does not mean its up to the discretion of the Vendor, only that it may or may not be in an IP header! We are planning to use the IP Security Option, or son of ... You bet the IP options are important. A vendor who's product does not work correctly will not be looked on kindly from here. cornett philip wood (cpw@lanl.gov) Los Alamos National Laboratory
-----------[000197][next][prev][last][first]---------------------------------------------------- Date: 18 Mar 88 22:03:24 GMT From: cpw%sneezy@LANL.GOV (C. Philip Wood) To: comp.protocols.tcp-ip Subject: IP Options and ICMP Messages
For those of you with 4.3BSD implimentations, as in Berkeley UNIX on a VAX, or SunOS 4.0 on a SUN, and those of you who think you have a 4.3 implimentation on your operating system, this, bud, is for you: Product: Tools to exercise the Internet Access: Anonymous FTP Source Host: lambda.lanl.gov Source Directory: /pub/inet Source Files: total 175 -r--r--r-- 1 cpw 786 Mar 18 14:38 Copyright -r--r--r-- 1 cpw 1381 Mar 18 14:38 EXAMPLES -r--r--r-- 1 cpw 6883 Mar 18 14:38 Makefile -r--r--r-- 1 cpw 2156 Mar 18 14:38 README -r--r--r-- 1 cpw 958 Mar 18 14:38 chargen.sh -r--r--r-- 1 cpw 4753 Mar 18 14:38 chargend.c -r--r--r-- 1 cpw 922 Mar 18 14:38 daytime.sh -r--r--r-- 1 cpw 952 Mar 18 14:38 discard.sh -r--r--r-- 1 cpw 3420 Mar 18 14:38 discardd.c -r--r--r-- 1 cpw 4152 Mar 18 14:38 echod.c -r--r--r-- 1 cpw 924 Mar 18 14:38 ecko.sh -r--r--r-- 1 cpw 954 Mar 18 14:38 finger.sh -r--r--r-- 1 cpw 1177 Mar 18 14:38 getclientname.c -r--r--r-- 1 cpw 966 Mar 18 14:38 hostname.sh -r--r--r-- 1 cpw 3979 Mar 18 14:38 hostnamed.c -r--r--r-- 1 cpw 2073 Mar 18 14:38 icmp.sh -r--r--r-- 1 cpw 2659 Mar 18 14:38 inaddr.c -r--r--r-- 1 cpw 3890 Mar 18 14:38 inet.8 -r--r--r-- 1 cpw 10460 Mar 18 14:38 inet.c -r--r--r-- 1 cpw 88960 Mar 18 14:41 inet.shar -r--r--r-- 1 cpw 1757 Mar 18 14:38 lsrr.sh -r--r--r-- 1 cpw 954 Mar 18 14:38 nicname.sh -r--r--r-- 1 cpw 15075 Mar 18 14:53 ping.c -r--r--r-- 1 cpw 947 Mar 18 14:38 quote.sh -r--r--r-- 1 cpw 969 Mar 18 14:38 rdate.sh -r--r--r-- 1 cpw 2047 Mar 18 14:38 settod.c -r--r--r-- 1 cpw 1442 Mar 18 14:38 so.sh -r--r--r-- 1 cpw 1758 Mar 18 14:38 ssrr.sh -r--r--r-- 1 cpw 1493 Mar 18 14:38 xdr.c Producer: Cornett Philip Wood Affiliation: Los Alamos National Laboratory
-----------[000198][next][prev][last][first]---------------------------------------------------- Date: 18 Mar 88 22:05:00 GMT From: Houde@HIS-PHOENIX-MULTICS.ARPA To: comp.protocols.tcp-ip Subject: Sun servers
Does anybody know whether or not a server for a Sun workstation based network
HAS to be a Sun product? Will Sun allow for this and has anybody done this?
Please direct any responses to Houde at pco.
Thanks,
Mike Houde
-----------[000199][next][prev][last][first]---------------------------------------------------- Date: Sat, 19 Mar 88 08:53:35 EST From: Frank Kastenholz <KASTEN@MITVMA.MIT.EDU> To: tcp-ip@sri-nic.arpa Subject: Re: Rumors about the death of the ARPANET
When the ARPANET was built, 56Kb lines were used - the leading edge of technology of the day. The "New and Improved" network is proposed to use 1.5Mbit lines (I assume T1). In keeping with the leading edge philosophy of yore, the just erupting 45Mbit/sec technology (T3?) comes to mind. Any thoughts given to T3? After all, current experience with the ARPANET tends to indicate that applications expand to fill the available bandwidth. This is not a flame! merely a true question. Frank Kastenholz Atex Inc. All opinions are mine and mine alone. My employer has no idea I am even saying this.
-----------[000200][next][prev][last][first]---------------------------------------------------- Date: Sat, 19 Mar 88 09:03:33 EST From: Frank Kastenholz <KASTEN@MITVMA.MIT.EDU> To: tcp-ip@sri-nic.arpa Cc: Hal Peterson <hrp%windsor.CRAY.COM@uc.msc.umn.edu> Subject: Re: offloading the protocols
More importantly than devising protocols with OP's in mind is to
move data directly from the users space to the processor -
it should not go through some central network application.
A second (equally important issue) is to trust your local I/O
channel.
The things that really kill the protocol processing are checksums
and "adminstrative" I/O (separate ack's, etc).
By trusting the local I/O channel, you do not need to checksum packets
going between the OP and the host, ack them, etc, etc.
A very empirical model that I have dreamed up for a TCP file
transfer for a non-kernal TCP implementation (e.g. Wollongong, KNET
etc) is:
The cost of moving the data from disk to user is X, from user
to network application is X, running the TCP checksum is X and
then moving the data from the network application to the I/O
adaptor is X. The total cost is 4X and X seems to be O(n).
This model is not proven, but seems to be borne out by some empirical
testing for running file transfers through a VAX using TCP and UDP
(both had about the same throughput, but TCP took 100% and UDP
about 75% of the CPU - the transfers were done by FTP/TCP and NFS/RPC/
UDP - the only effective difference was the TCP checksum).
Moral of the story, if you can not move the data from the user's space
to the OP directly (i.e. need to go to an application level network
process first) you only save about 25%.
Remember, this is all empirical! real testing needs to be done.
Frank Kastenholz
Atex Inc.
All opinions are mine - not my employers.....
-----------[000201][next][prev][last][first]---------------------------------------------------- Date: Sat, 19 Mar 88 09:38:16 EST From: Frank Kastenholz <KASTEN@MITVMA.MIT.EDU> To: TCP/IP List <TCP-IP@SRI-NIC.ARPA> Subject: Re: offloading the protocols
More importantly than devising protocols with OP's in mind is to
move data directly from the users space to the processor -
it should not go through some central network application.
A second (equally important issue) is to trust your local I/O
channel.
The things that really kill the protocol processing are checksums
and "adminstrative" I/O (separate ack's, etc).
By trusting the local I/O channel, you do not need to checksum packets
going between the OP and the host, ack them, etc, etc.
A very empirical model that I have dreamed up for a TCP file
transfer for a non-kernal TCP implementation (e.g. Wollongong, KNET
etc) is:
The cost of moving the data from disk to user is X, from user
to network application is X, running the TCP checksum is X and
then moving the data from the network application to the I/O
adaptor is X. The total cost is 4X and X seems to be O(n).
This model is not proven, but seems to be borne out by some empirical
testing for running file transfers through a VAX using TCP and UDP
(both had about the same throughput, but TCP took 100% and UDP
about 75% of the CPU - the transfers were done by FTP/TCP and NFS/RPC/
UDP - the only effective difference was the TCP checksum).
Moral of the story, if you can not move the data from the user's space
to the OP directly (i.e. need to go to an application level network
process first) you only save about 25%.
Remember, this is all empirical! real testing needs to be done.
Frank Kastenholz
Atex Inc.
All opinions are mine - not my employers.....
-----------[000202][next][prev][last][first]---------------------------------------------------- Date: 19 Mar 88 08:16:03 GMT From: GRAVES@MATHOM.CISCO.COM (Bill Graves) To: comp.protocols.tcp-ip Subject: Re: IP options crash our Sun gateway
IP options are not optional for IP Gateways! -------
-----------[000203][next][prev][last][first]---------------------------------------------------- Date: 19 Mar 88 12:44:32 GMT From: barmar@think.COM (Barry Margolin) To: comp.protocols.tcp-ip Subject: Re: rsh equivalent
In article <722@kaos.UUCP> romkey@kaos.UUCP (John Romkey) writes: >"Trusted ports" (when port numbers less than 1024 can only be used by >a trusted user) exist only in the world of the Berkeley UNIX TCP. >Virtually no TCP/IP implementations that are not derived from BSD >UNIX have the concept of "trusted ports"; they will allow any user >program to open a connection on any port that isn't already in use. This is why the Unix RSH server also checks the host against a .rhosts file. Presumably you would only list machines that implement the trusted port rule. Barry Margolin Thinking Machines Corp. barmar@think.com uunet!think!barmar
-----------[000204][next][prev][last][first]---------------------------------------------------- Date: 19 Mar 88 13:53:35 GMT From: KASTEN@MITVMA.MIT.EDU (Frank Kastenholz) To: comp.protocols.tcp-ip Subject: Re: Rumors about the death of the ARPANET
When the ARPANET was built, 56Kb lines were used - the leading edge of technology of the day. The "New and Improved" network is proposed to use 1.5Mbit lines (I assume T1). In keeping with the leading edge philosophy of yore, the just erupting 45Mbit/sec technology (T3?) comes to mind. Any thoughts given to T3? After all, current experience with the ARPANET tends to indicate that applications expand to fill the available bandwidth. This is not a flame! merely a true question. Frank Kastenholz Atex Inc. All opinions are mine and mine alone. My employer has no idea I am even saying this.
-----------[000205][next][prev][last][first]---------------------------------------------------- Date: 19 Mar 88 14:03:33 GMT From: KASTEN@MITVMA.MIT.EDU (Frank Kastenholz) To: comp.protocols.tcp-ip Subject: Re: offloading the protocols
More importantly than devising protocols with OP's in mind is to
move data directly from the users space to the processor -
it should not go through some central network application.
A second (equally important issue) is to trust your local I/O
channel.
The things that really kill the protocol processing are checksums
and "adminstrative" I/O (separate ack's, etc).
By trusting the local I/O channel, you do not need to checksum packets
going between the OP and the host, ack them, etc, etc.
A very empirical model that I have dreamed up for a TCP file
transfer for a non-kernal TCP implementation (e.g. Wollongong, KNET
etc) is:
The cost of moving the data from disk to user is X, from user
to network application is X, running the TCP checksum is X and
then moving the data from the network application to the I/O
adaptor is X. The total cost is 4X and X seems to be O(n).
This model is not proven, but seems to be borne out by some empirical
testing for running file transfers through a VAX using TCP and UDP
(both had about the same throughput, but TCP took 100% and UDP
about 75% of the CPU - the transfers were done by FTP/TCP and NFS/RPC/
UDP - the only effective difference was the TCP checksum).
Moral of the story, if you can not move the data from the user's space
to the OP directly (i.e. need to go to an application level network
process first) you only save about 25%.
Remember, this is all empirical! real testing needs to be done.
Frank Kastenholz
Atex Inc.
All opinions are mine - not my employers.....
-----------[000206][next][prev][last][first]---------------------------------------------------- Date: 19 Mar 88 14:38:16 GMT From: KASTEN@MITVMA.MIT.EDU (Frank Kastenholz) To: comp.protocols.tcp-ip Subject: Re: offloading the protocols
More importantly than devising protocols with OP's in mind is to
move data directly from the users space to the processor -
it should not go through some central network application.
A second (equally important issue) is to trust your local I/O
channel.
The things that really kill the protocol processing are checksums
and "adminstrative" I/O (separate ack's, etc).
By trusting the local I/O channel, you do not need to checksum packets
going between the OP and the host, ack them, etc, etc.
A very empirical model that I have dreamed up for a TCP file
transfer for a non-kernal TCP implementation (e.g. Wollongong, KNET
etc) is:
The cost of moving the data from disk to user is X, from user
to network application is X, running the TCP checksum is X and
then moving the data from the network application to the I/O
adaptor is X. The total cost is 4X and X seems to be O(n).
This model is not proven, but seems to be borne out by some empirical
testing for running file transfers through a VAX using TCP and UDP
(both had about the same throughput, but TCP took 100% and UDP
about 75% of the CPU - the transfers were done by FTP/TCP and NFS/RPC/
UDP - the only effective difference was the TCP checksum).
Moral of the story, if you can not move the data from the user's space
to the OP directly (i.e. need to go to an application level network
process first) you only save about 25%.
Remember, this is all empirical! real testing needs to be done.
Frank Kastenholz
Atex Inc.
All opinions are mine - not my employers.....
-----------[000207][next][prev][last][first]---------------------------------------------------- Date: 19 Mar 88 18:18:09 GMT From: auerbach@hercules.csl.sri.com (Karl Auerbach) To: comp.protocols.tcp-ip Subject: Re: Off loading the protocol
Just curious: How does the shared memory paradigm handle the case where the machines are of different memory architectures with different data representations? PS -- I would like a copy of the full article. Thanks, --karl--
-----------[000208][next][prev][last][first]---------------------------------------------------- Date: 19 Mar 88 19:47:42 GMT From: phil@EAST.BERKELEY.EDU (Phil Lapsley) To: comp.protocols.tcp-ip Subject: Who uses directed broadcasts?
RFC 1009 defines an IP directed broadcast as a datagram with a destination of an IP (sub)network broadcast address. The packet is forwarded normally until it reaches a gateway of the destination (sub)net, at which point the gateway "bursts" the packet into a media broadcast on the local (sub)net. RFC 1009 also gives gateways the option of "protecting" their local networks by dropping directed broadcasts on the floor. Be default, a 4.3 BSD gateway machine that is final hop of a directed broadcast packet will accept the packet as if it was destined for itself, but it will not burst the packet into a media level broadcast. If DIRECTED_BROADCAST is defined when the 4.3 kernel is made, this bursting will actually occur. My question is: what gateway implementations actually use directed broadcasts in the RFC 1009 sense, and why? Phil
-----------[000209][next][prev][last][first]---------------------------------------------------- Date: 19 Mar 88 21:56:13 GMT From: Mills@UDEL.EDU To: comp.protocols.tcp-ip Subject: NTP timewarp
Folks, At the moment both the ISI and NCAR radio clocks have failed, while the UDel radio clock is down for repair. This leaves only the UMd and Ford radio clocks online. Unfortunately, sometime since Friday evening the NTP primary time-server network, which usually thrives when one or more radio clocks fail, went nuts and may have delivered bogus time. I believe I have found and fixed the bug, which turned out to be subtle indeed and bit only in an interesting and unusual scenario involving broken spanning trees. As of now (Saturday afternoon) all primary servers ISI, NCAR, UDel, UMd, Ford and DECWRL have been fixed. Note that all except UMd and Ford are running at stratum two, since they have automatically resynchronized to the remaining radio clocks. Secondary servers at Linkabit and Rice, now operating at their usual stratum two, have also been fixed. There is at least one Unix site that crashed due the broken time. Since the bug was due to my own error and not due to the protocol design or Mike Petry's NTP daemon, I do apologize for any inconvenience. When a new NTP daemon conforming to the latest protocol revision becomes available, even this latest bug will not cause timewarps, should something like it ever happen again. Dave
-----------[000210][next][prev][last][first]---------------------------------------------------- Date: 20 Mar 88 05:12:58 GMT From: HANK@BARILVM.BITNET (Henry Nussbacher) To: comp.protocols.tcp-ip Subject: Re: ISN
>Seems like a reasonable concept. The bridge guys work very hard to >keep the overhead low enough to handle back-to-back Ethernet packets; >can the REB guys do as well, with the extra protocol processing? The stated rate is 2500 packets per second (forwarding). Falls between a bridge (10,000 pps) and a router (1000 pps). Hank
-----------[000211][next][prev][last][first]---------------------------------------------------- Date: 20 Mar 88 05:15:14 GMT From: HANK@BARILVM.BITNET (Henry Nussbacher) To: comp.protocols.tcp-ip Subject: Re: ISN
>If it is acting as a router it should use the TTL field in the IP >header. It seems, from your message, that another field may be used >possibly from a REB-REB protocol. It is not acting as a router. It is a bridge which has adopted "router concepts" at the level II. It does not look at the protocol so it can't possibly use TTL. It uses its own concept of stopping packets from travelling in the network forever, all within the definition of 803.2 D - Management specs. Hank
-----------[000212][next][prev][last][first]---------------------------------------------------- Date: Sun, 20 Mar 88 08:12:58 P From: Henry Nussbacher <HANK%BARILVM.BITNET@CUNYVM.CUNY.EDU> To: TCP-IP@SRI-NIC.ARPA Subject: Re: ISN
>Seems like a reasonable concept. The bridge guys work very hard to >keep the overhead low enough to handle back-to-back Ethernet packets; >can the REB guys do as well, with the extra protocol processing? The stated rate is 2500 packets per second (forwarding). Falls between a bridge (10,000 pps) and a router (1000 pps). Hank
-----------[000213][next][prev][last][first]---------------------------------------------------- Date: Sun, 20 Mar 88 08:15:14 P From: Henry Nussbacher <HANK%BARILVM.BITNET@CUNYVM.CUNY.EDU> To: TCP-IP@SRI-NIC.ARPA Subject: Re: ISN
>If it is acting as a router it should use the TTL field in the IP >header. It seems, from your message, that another field may be used >possibly from a REB-REB protocol. It is not acting as a router. It is a bridge which has adopted "router concepts" at the level II. It does not look at the protocol so it can't possibly use TTL. It uses its own concept of stopping packets from travelling in the network forever, all within the definition of 803.2 D - Management specs. Hank
-----------[000214][next][prev][last][first]---------------------------------------------------- Date: 20 Mar 88 15:32:21 GMT From: cpw%sneezy@LANL.GOV (C. Philip Wood) To: comp.protocols.tcp-ip Subject: Re: LSRR and RR IP options
I have a fix for that fragmentation of IP options problem. I sent it to berkeley as well as this list. Can you use it? cornett philip wood (cpw@lanl.gov)
-----------[000215][next][prev][last][first]---------------------------------------------------- Date: 20 Mar 1988 22:28-EST From: CERF@A.ISI.EDU To: KASTEN@MITVMA.MIT.EDU Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: Rumors about the death of the ARPANET
Frank, DS-3 is a reality for many people who either mux it down to manageable bandwidth channels or build special interfaces that can push/pull data at 45 Mbit/sec. About your earlier messages concerning trusting local I/O and not doing checksums end to end (by implication) - we have tried that in the past and been burned - what is different today? Fiber? The problem is that the end to end channel may still contain some weakness in terms of S/N and bit error rate. I'd rather see silicon checksums to speed them up than doing away with them because they take time... Vint
-----------[000216][next][prev][last][first]---------------------------------------------------- Date: 20 Mar 88 20:35:00 GMT From: chris@ACC-SB-UNIX.ARPA (Chris VandenBerg) To: comp.protocols.tcp-ip Subject: Re: who posted the delni summary? (enet in a can)
To Robert Miller(he who posted the plug for Micom/Interlan's Delni killer), Sounds like the same thing that the Cabletron Multiport has been doing for TWO YEARS...I also have no affiliation with these people other than using their equipment. Chris VandenBerg chris@acc-sb-unix.arpa
-----------[000217][next][prev][last][first]---------------------------------------------------- Date: 20 Mar 88 23:12:13 GMT From: xiaohe@tybalt.caltech.edu (Xiao-He Zhang) To: comp.protocols.tcp-ip,comp.mail.misc Subject: How can I leave telnet temporarily?
I am not sure if this is the right group, and I am sorry if this has been discussed recently. Can anyone tell me how I can escape back to local host from "telnet" temporarily and how I can supply a login file for "telnet"? More specificly, 1. I see a "z" in telnet commands and it returns me back to my local host. If I am using a Unix machine, "fg" gets me back to telnet prompt. But I don't know how to reconnect to the remote machine except logout the remote machine and login again. Is there any way to reconnect me back to the remote machine without logout first? If I am using a VMS machine, I even don't know how to resume the telnet process. 2. To log in to a remote machine using telnet, I must say who I am, my password (of course) and the terminal type. Is it possible to put these information in a login file and automate the login procedure so that the first thing I'll see is the shell prompt of the remote machine? Better yet, can I use a crypted file to protect my password in other systems? Thank you in advance. xiao-He Zhang || xiaohe@tybalt.caltech.edu | xiaohe@caltech.bitnet
-----------[000218][next][prev][last][first]---------------------------------------------------- Date: 21 Mar 88 11:17:00 PST From: "Jerry Scott" <jerry@twg.com> To: "kasten" <kasten@mitvma.mit.edu> Cc: <tcp-ip@sri-nic.arpa> Subject: RE: offloading the protocols
Frank, That is not the way that data flows inside the Wollongong software at all. The same style used by 4.3BSD is the case here. First data is sent from the user into the kernel where it is placed into network buffers call mbufs. Mbufs can and are chained to build packets (IP headers, TCP headers, data, etc). The mbuf chains are passed between protocols, thus no data is moved at all just the pointers to the data. Plus once the data is in the kernel, it never has to take a hop back to an application for any further processing. We are well aware of the overhead of moving data between the kernel level and user level, that is why we have done considerable work in preventing this from happening (eg. Telnet server is kernel resident, sharing DEC ethernet controllers using ALTSTART interface). We have also been eagerly tracking the good work by Van Jacobson and Mike Karels in the TCP area. Our implementation allows us to use there public domain code without modification. I do agree with your assessment of the on-board TCP solutions. The overhead in the host must be minimal. Data must be moved from the user into a DMA area where the smart controller can access it. You must trust the data integrity between the host and the controller performing the network functions. Now if you can get Van's and Mike's code down onto these controllers... Jerry
-----------[000219][next][prev][last][first]---------------------------------------------------- Date: 21 Mar 88 03:28:00 GMT From: CERF@A.ISI.EDU To: comp.protocols.tcp-ip Subject: Re: Rumors about the death of the ARPANET
Frank, DS-3 is a reality for many people who either mux it down to manageable bandwidth channels or build special interfaces that can push/pull data at 45 Mbit/sec. About your earlier messages concerning trusting local I/O and not doing checksums end to end (by implication) - we have tried that in the past and been burned - what is different today? Fiber? The problem is that the end to end channel may still contain some weakness in terms of S/N and bit error rate. I'd rather see silicon checksums to speed them up than doing away with them because they take time... Vint
-----------[000220][next][prev][last][first]---------------------------------------------------- Date: Mon, 21 Mar 88 12:01:26 -0500 From: haverty@CCV.BBN.COM To: CERF@A.ISI.EDU Cc: KASTEN@MITVMA.MIT.EDU, tcp-ip@SRI-NIC.ARPA, haverty@CCV.BBN.COM Subject: Re: Rumors about the death of the ARPANET
Vint/Frank - my recollection of some of the conflagrations around checksumming is that the end-end checksum is valuable even if the piecewise error control is perfect (10 to however many you like); what the end-end often catches are plain and simple bugs deep down in the middle of the path, e.g., a pointer off-by-one in a packet switch buffer under some obscure condition and the like. Since software is never debugged fully until you retire it, such situations will crop up, and according to Murphy will happen at the worst time. What would be interesting is to see if there is a way to design a simple end-end "checksum" designed to catch errors which are not like those in communications media, i.e., result from bugs, configuration mistakes, etc., rather than line noise and the like. Jack
-----------[000221][next][prev][last][first]---------------------------------------------------- Date: 21 Mar 1988 10:01-EST From: GBELING@A.ISI.EDU To: tcp-ip@SRI-NIC.ARPA Subject: ?we have the future?
to whom it may be of interest, in an announcement of a (at least in Germany) well known computer company - name with a lot of letters but not more than seven - for the great German computer show Cebit in Hannover I found the following: "MultiNET-Sonderschau Optische und elektronische CSMA/CD- Netzkomponenten nach ISO-Standard TCP/IP" roughly translated: "optical and electronical CSMA/CD net components according to ISO-standards TCP/IP" (whatever that could mean) Those people have really moved to the front of internetworking regards gerd beling west germanyr
-----------[000222][next][prev][last][first]---------------------------------------------------- Date: Mon, 21 Mar 88 11:23:54 EST From: Jim Petty <PETTY@MITVMA.MIT.EDU> To: TCP-IP@SRI-NIC.ARPA Subject: GATE-D
If anyone out there knows who to contact about the GATE-D gateway software please drop me a note. I believe it was written at Cornell. Thanks in advance Jim
-----------[000223][next][prev][last][first]---------------------------------------------------- Date: 21 Mar 88 08:40:21 GMT From: hedrick@athos.rutgers.edu (Charles Hedrick) To: comp.protocols.tcp-ip Subject: Re: Who uses directed broadcasts?
We use directed broadcasts for at least two purposes: 1) Our kinetics Appletalk gateways use them to keep track of each other or of some hosts that provide services for them. (I'm a bit vague, since I'm not an expert with Kinetics. I support the main IP gateways, and I know I had to get directed broadcasts working properly in order to satisfy our Mac guys.) 2) The cisco gateways that we use have a concept of helper address. If a net doesn't have any servers on it, you can get a gateway to forward all requests of a certain class (those that would normally be used for booting: TFTP, bootp, timed, and named) to a specified address. FOr reliability reasons, we don't to provide several servers, so we use a subnet with lots of servers, and use directed broadcast onto that subnet. I have also done some experiments with sending messges warning of gateway reboots etc. by doing rwall to a broadcast addresss for each of the subnets affected. It seems to work. In general, I'd say the directed broadcast mechanism is useful, and that gateways should implement it. Note that the way you know whether to absorb the packet yourself or forward it onto the subnet is by whether it arrived as a physical broadcast or not. If it did, then it has already been broadcast, and you should process it as a host. If it arrives as a non-broadcast, then the sender wants you to put it out on the subnet as a broadcast. This must be implemented properly, or disaster will ensue.
-----------[000224][next][prev][last][first]---------------------------------------------------- Date: 21 Mar 88 08:47:00 GMT From: YEHAVI@HUJIVMS.BITNET (Yehavi Bourvine +972-2-584279) To: comp.protocols.tcp-ip Subject: Wollogong TcpIp for VMS and Cisco AGS routers interaction.
We are considering connecting VAX/VMS systems to the TcpIp net via X-25.
We are thinking of using the Wollogong with ACC-6250 cards which will talk
with Cisco AGS routers. The question is: Will this work?
Cisco people say that the VC connection should be initiated from the VAX
side without DDN standard facility (Basic service) and the first byte of
the data field of CALL USER is 0xCC; Can the Wollogong software do it?
Please answer directly to me, since we experience some problems receiving
the distribution lists here.
Thanks in advance, __Yehavi:
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Yehavi Bourvine, Phones: +972-2-584279, H
Computation Center, +972-2-521574 H
The Hebrew University of Jerusalem, H
Givat-Ram, Jerusalem 91904 H H H
Fax: +972-2-527349 HH H
BITnet: YEHAVI@HUJIVMS H H
InterNet: YEHAVI@VMS.HUJI.AC.IL H
H
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-----------[000225][next][prev][last][first]---------------------------------------------------- Date: Mon, 21 Mar 88 15:47:44 EST From: Mark Bodenstein <MAB@CORNELLC.CCS.CORNELL.EDU> To: TCP-IP@SRI-NIC.ARPA Subject: Conversion to ISO - Number of NCP Hosts
Network World, in their March 14 issue, published an article about GOSIP, and the conversion from TCP/IP to ISO protocols. In brief, they say that ISO OSI is in the process of becoming a government standard, supplanting TCP/IP, but that the conversion may take a very long time. At the end of the article, they give an analogy to the conversion from NCP to TCP, from Kevin Ebel of DCA, and say, in effect, that the difference between the two conversions is only one of scale. Let's assume, for the purpose of non-argument, that the analogy is apt. (I don't think it is.) Does anyone know what the difference in scale is, between these two conversions? How many NCP hosts and routers/gateways/ imps were there at the time of conversion to TCP? And how many TCP hosts and routers/gateways/imps are there now and/or will there be two years from now (assuming that to be the time of the beginning of the TCP->OSI conversion)? Mark Bodenstein (mab@cornellc.ccs.cornell.edu) Cornell University
-----------[000226][next][prev][last][first]---------------------------------------------------- Date: Mon, 21 Mar 88 10:47 +0200 From: Yehavi Bourvine +972-2-584279 <YEHAVI%HUJIVMS.BITNET@CUNYVM.CUNY.EDU> To: TCP-IP@SRI-NIC.ARPA, INFO-VAX@KL.SRI.COM Subject: Wollogong TcpIp for VMS and Cisco AGS routers interaction.
We are considering connecting VAX/VMS systems to the TcpIp net via X-25.
We are thinking of using the Wollogong with ACC-6250 cards which will talk
with Cisco AGS routers. The question is: Will this work?
Cisco people say that the VC connection should be initiated from the VAX
side without DDN standard facility (Basic service) and the first byte of
the data field of CALL USER is 0xCC; Can the Wollogong software do it?
Please answer directly to me, since we experience some problems receiving
the distribution lists here.
Thanks in advance, __Yehavi:
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Yehavi Bourvine, Phones: +972-2-584279, H
Computation Center, +972-2-521574 H
The Hebrew University of Jerusalem, H
Givat-Ram, Jerusalem 91904 H H H
Fax: +972-2-527349 HH H
BITnet: YEHAVI@HUJIVMS H H
InterNet: YEHAVI@VMS.HUJI.AC.IL H
H
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-----------[000227][next][prev][last][first]---------------------------------------------------- Date: 21 Mar 88 15:01:00 GMT From: GBELING@A.ISI.EDU To: comp.protocols.tcp-ip Subject: ?we have the future?
to whom it may be of interest, in an announcement of a (at least in Germany) well known computer company - name with a lot of letters but not more than seven - for the great German computer show Cebit in Hannover I found the following: "MultiNET-Sonderschau Optische und elektronische CSMA/CD- Netzkomponenten nach ISO-Standard TCP/IP" roughly translated: "optical and electronical CSMA/CD net components according to ISO-standards TCP/IP" (whatever that could mean) Those people have really moved to the front of internetworking regards gerd beling west germanyr
-----------[000228][next][prev][last][first]---------------------------------------------------- Date: 21 Mar 88 15:41:19 GMT From: relkins@vax1.acs.udel.EDU (Rob Elkins) To: comp.protocols.tcp-ip,comp.mail.misc Subject: Re: How can I leave telnet temporarily?
In article <5854@cit-vax.Caltech.Edu> xiaohe@tybalt.caltech.edu (Xiao-He Zhang) writes: > > I am not sure if this is the right group, and I am sorry if this has been >discussed recently. Can anyone tell me how I can escape back to local host >from "telnet" temporarily and how I can supply a login file for "telnet"? Assuming you are using telnet on unic, when you are logged on to the remote host, you can enter the escape ^] (thats control right bracket) , that should take you back to the telnet> prompt, which you can enter ^z to stop the job to return to the local machine. To get back, you type fg to bring the stopeed job back to the foreground, hit return and you should be back on the remote machine. Good Luck Rob Elkins -- ARPA: relkins@vax1.acs.udel.edu BITNET: FFO04688@UDACSVM UUCP: ...!sun!vax1.acs.udel.edu Live Long and Prosper! Damn it Jim, I'm a doctor not a <Insert Occupation Here>
-----------[000229][next][prev][last][first]---------------------------------------------------- Date: 21 Mar 88 15:48:43 GMT From: kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) To: comp.protocols.tcp-ip Subject: Re: Rumors about the death of the ARPANET
In article <8803210118.AA19481@ucbvax.Berkeley.EDU> KASTEN@MITVMA.MIT.EDU (Frank Kastenholz) writes:
>
>When the ARPANET was built, 56Kb lines were used - the leading edge
>of technology of the day. The "New and Improved" network is proposed
>to use 1.5Mbit lines (I assume T1). In keeping with the leading edge
>philosophy of yore, the just erupting 45Mbit/sec technology (T3?) comes
>to mind.
>
>Any thoughts given to T3?
There is the FCCSET [fixit!] committee of the President's
Office of Science and Technology which has done studies and set up
subcommittee's on supercomputing, networking, and technology
development, etc. Gordon Bell is the chairman of the subcommittee on
networking. He recently wrote an article [with an unfortunate
derogatory leading remark on BU networking!] in the February issue of
IEEE Spectrum about the need for a new national research and education
network. He proposes a series of steps upgrading the internet,
leading eventually to a T3 link to every major university and research
center. He discusses some costs associated with upgrading to T1, but
says nothing about the cost of T3, which may be appropriate given the
lead time to deployment, except to say that the institutions served
should pay (telephone analogy). I wonder if this is reasonable?
Paying for T3 would be dear compared to paying for today's
services. I think the telephone companies rates, based on message
units and not cost-to-provide, are probably too high.
Bell says it's up to us to take the lead since our government
probably won't. Anybody want AT&T to provide T3 service for a new
super-internet? Anybody up to building our own private network? The
providers of supercomputer services (like, but not necessarily,
Boeing) already have complained about unfair competition from the NSF
supercomputer centers. Wonder what the telecommunications vendors
will say when someone puts Bell's proposal before the Congress, if
ever?
Oh, well, I think I'll get our network users used to paying
for service now on a recurring basis. Soften them up for the $5k to
$30k per month the super-internet will cost. :-)
As Bell says, technology is not the issue. We can build T3
networks and we can build super-routers and we can fix TCP {VJ can,
anyway}... The problem is figuring out how to do it cooperatively.
Kent England
Boston University (which does have the networks the Medical
Center doesn't have. [read the article])
-----------[000230][next][prev][last][first]---------------------------------------------------- Date: Mon, 21 Mar 88 21:06:57 EST From: Frank Kastenholz <KASTEN@MITVMA.MIT.EDU> To: TCP/IP List <TCP-IP@SRI-NIC.ARPA>, Jack Haverty <HAVERTY@CCV.BBN.COM>, Vint Cerf <CERF@A.ISI.EDU> Subject: Re: Rumors about the death of the ARPANET
Jack, Vint, and friends, By trusting the local I/O channel I had in mind just the transfer of data from the hosts main storage to the protocol processor. For example, the Block Multiplexer channel on an IBM mainframe provides a guaranteed transfer - if the application issues a write to the channel, the final status of the operation indicates success or failure. Also, the channel will transfer data intact, or reports an error to the application. There is little need (other than paranoia?) to provide an application level checksum on the transferred data, or a high level ack mechanism across the channel. End to End checksums, acks, etc are needed. Nolo Contendre. But they can be between intelligent control units. (This whole argument also assumes that the protocol processor has a reasonably powerful CPU and amount of memory - imagine a IBM 3090 dumping data into a 8 Mhz 68000 with 512 Kb of memory!!! :-) Frank
-----------[000231][next][prev][last][first]---------------------------------------------------- Date: 21 Mar 88 16:23:54 GMT From: PETTY@MITVMA.MIT.EDU (Jim Petty) To: comp.protocols.tcp-ip Subject: GATE-D
If anyone out there knows who to contact about the GATE-D gateway software please drop me a note. I believe it was written at Cornell. Thanks in advance Jim
-----------[000232][next][prev][last][first]---------------------------------------------------- Date: 21 Mar 88 17:01:26 GMT From: haverty@CCV.BBN.COM To: comp.protocols.tcp-ip Subject: Re: Rumors about the death of the ARPANET
Vint/Frank - my recollection of some of the conflagrations around checksumming is that the end-end checksum is valuable even if the piecewise error control is perfect (10 to however many you like); what the end-end often catches are plain and simple bugs deep down in the middle of the path, e.g., a pointer off-by-one in a packet switch buffer under some obscure condition and the like. Since software is never debugged fully until you retire it, such situations will crop up, and according to Murphy will happen at the worst time. What would be interesting is to see if there is a way to design a simple end-end "checksum" designed to catch errors which are not like those in communications media, i.e., result from bugs, configuration mistakes, etc., rather than line noise and the like. Jack
-----------[000233][next][prev][last][first]---------------------------------------------------- Date: 21 Mar 88 18:43:00 GMT From: Houde@HIS-PHOENIX-MULTICS.ARPA To: comp.protocols.tcp-ip Subject: Re: Sun servers
Sorry, but I never specified my address. I wanted to know whether or not I
could use a standard Unix box as a server for Sun workstations. Please direct
any responses to Houde at PCO-MULTICS.ARPA.
Thanks again,
Mike Houde
-----------[000234][next][prev][last][first]---------------------------------------------------- Date: 21 Mar 88 19:14:04 GMT From: tsudik@MALIBU.USC.EDU (Gene Tsudik) To: comp.protocols.tcp-ip Subject: Re: LSRR and RR IP options
Yes, your fix for the fragmentation/options problem worked very well and was easy to inject into IP code. Thank you very much. Gene Tsudik Networks and Distributed Systems Lab USC
-----------[000235][next][prev][last][first]----------------------------------------------------
Date: 21 Mar 88 19:17:00 GMT
From: jerry@twg.COM ("Jerry Scott")
To: comp.protocols.tcp-ip
Subject: RE: offloading the protocolsFrank, That is not the way that data flows inside the Wollongong software at all. The same style used by 4.3BSD is the case here. First data is sent from the user into the kernel where it is placed into network buffers call mbufs. Mbufs can and are chained to build packets (IP headers, TCP headers, data, etc). The mbuf chains are passed between protocols, thus no data is moved at all just the pointers to the data. Plus once the data is in the kernel, it never has to take a hop back to an application for any further processing. We are well aware of the overhead of moving data between the kernel level and user level, that is why we have done considerable work in preventing this from happening (eg. Telnet server is kernel resident, sharing DEC ethernet controllers using ALTSTART interface). We have also been eagerly tracking the good work by Van Jacobson and Mike Karels in the TCP area. Our implementation allows us to use there public domain code without modification. I do agree with your assessment of the on-board TCP solutions. The overhead in the host must be minimal. Data must be moved from the user into a DMA area where the smart controller can access it. You must trust the data integrity between the host and the controller performing the network functions. Now if you can get Van's and Mike's code down onto these controllers... Jerry
-----------[000236][next][prev][last][first]---------------------------------------------------- Date: 21 Mar 88 20:29:19 GMT From: jeremy@swatsun.uucp (Jeremy Brest) To: comp.protocols.tcp-ip,comp.os.vms Subject: Information request: DECnet, tcp/ip
I am interested in connecting a bunch of MicroVAXen running DECnet to a tcp/ip network. Any information about this would be appreciated. In particular, I am interested in people's experiences with the CMU software v. Wollongong (sp?). Also, if anyone knows an address for information about the CMU software, please send it. Please send by mail unless you think your reply of general interest. Thank you, Jeremy Brest Swarthmore College uucp: ...seismo!bpa!swatsun!jeremy CSnet: jeremy@swatsun.swarthmore.edu ARPA: jeremy%swatsun.swarthmore.edu@relay.cs.net
-----------[000237][next][prev][last][first]---------------------------------------------------- Date: 21 Mar 88 20:40:00 GMT From: DCP@QUABBIN.SCRC.Symbolics.COM (David C. Plummer) To: comp.protocols.tcp-ip Subject: Re: TCP Keep-alives, also push bit
This seems to come up once a year. When I was implementing the Symbolics TCP implementation some 3 or 4 years ago, I asked about active connection sensing. The UNANIMOUS answer I got were that such things were 100% against the spec. Therefore, BSD is in error. [Philosophically, sending a garbage byte is disgusting.] What IS allowed, as far as I know, is to send a zero length IN ORDER TO ELICIT A RESET if the connection absolutely doesn't exist. This is what we do. Yes, it will cause packet traffic. If the link or remote host is down, the connection will not go away until active data is sent or the host comes up and IT declares that the connection doesn't exist. This will surely come up again in 10 to 14 months...
-----------[000238][next][prev][last][first]---------------------------------------------------- Date: 21 Mar 88 20:47:44 GMT From: MAB@CORNELLC.CCS.CORNELL.EDU (Mark Bodenstein) To: comp.protocols.tcp-ip Subject: Conversion to ISO - Number of NCP Hosts
Network World, in their March 14 issue, published an article about GOSIP, and the conversion from TCP/IP to ISO protocols. In brief, they say that ISO OSI is in the process of becoming a government standard, supplanting TCP/IP, but that the conversion may take a very long time. At the end of the article, they give an analogy to the conversion from NCP to TCP, from Kevin Ebel of DCA, and say, in effect, that the difference between the two conversions is only one of scale. Let's assume, for the purpose of non-argument, that the analogy is apt. (I don't think it is.) Does anyone know what the difference in scale is, between these two conversions? How many NCP hosts and routers/gateways/ imps were there at the time of conversion to TCP? And how many TCP hosts and routers/gateways/imps are there now and/or will there be two years from now (assuming that to be the time of the beginning of the TCP->OSI conversion)? Mark Bodenstein (mab@cornellc.ccs.cornell.edu) Cornell University
-----------[000239][next][prev][last][first]---------------------------------------------------- Date: 21 Mar 88 23:04:22 GMT From: phil@BRL.ARPA (Phil Dykstra) To: comp.protocols.tcp-ip Subject: Re: Ping, checksum algorithm?
Ping.c as found in Berkeley Unix was originally written by Mike Muuss at the U.S.Army Ballistic Research Laboratory <mike@brl.arpa>. It is public domain distribution unlimited. Berkeley made some modifications to it but maintained its public domain status. Recently we at BRL modified it to do RECORD_ROUTE, provide more detailed ICMP messages (read subcodes), dump the fields of returned IP headers in ICMP messages, etc. Our version does not yet do LSRR or SSRR (though since I heard that the core gateways honor it, it will almost certainly be added). [Note: record route can not be done on a SunOS <= 3.4 since the IP_OPTIONS socket option does not exist - the rest of the code works fine on the Sun however.] Anticipating a possible high demand, I have made the source code publicly FTP'able from VGR.BRL.MIL [192.5.23.5 or 128.63.4.4] in pub/ping.tar. Man page included. - Phil <phil@brl.arpa> ps: warning - our main gateway was having hardware problems today.
-----------[000240][next][prev][last][first]---------------------------------------------------- Date: 22 Mar 88 02:06:57 GMT From: KASTEN@MITVMA.MIT.EDU (Frank Kastenholz) To: comp.protocols.tcp-ip Subject: Re: Rumors about the death of the ARPANET
Jack, Vint, and friends, By trusting the local I/O channel I had in mind just the transfer of data from the hosts main storage to the protocol processor. For example, the Block Multiplexer channel on an IBM mainframe provides a guaranteed transfer - if the application issues a write to the channel, the final status of the operation indicates success or failure. Also, the channel will transfer data intact, or reports an error to the application. There is little need (other than paranoia?) to provide an application level checksum on the transferred data, or a high level ack mechanism across the channel. End to End checksums, acks, etc are needed. Nolo Contendre. But they can be between intelligent control units. (This whole argument also assumes that the protocol processor has a reasonably powerful CPU and amount of memory - imagine a IBM 3090 dumping data into a 8 Mhz 68000 with 512 Kb of memory!!! :-) Frank
-----------[000241][next][prev][last][first]---------------------------------------------------- Date: 22 Mar 88 14:06:00 PST From: "Jerry Scott" <jerry@twg.com> To: "chris" <chris@gyre.umd.edu> Cc: <kasten@mitvma.mit.edu>,<tcp-ip@sri-nic.arpa> Subject: RE: offloading the protocols
Chris, Agreed, the cpu on the board will definitely come into play in terms of performance. We see that here at TWG when our host resident software is compared against on-board software on VAX 86xx or 88xx hardware. The host resident runs circles around the on-board in these cases. I think the Jacobson/Karels code has more to offer than blazing performance. The code that I am distributing does not yet have the performance hooks that Van explained in some of his mail messages. But it does have improved congestion control that allows my connections to adapt to line speeds during the life of the connection rather than at the beginning. Not only does this code save the net the overhead of unnecessary retransmissions, but prevents timeouts of connections as well. The big improvement I have seen is with Arpanet mail. It used to be the case that I would try to send mail to another host, make the connection, and then lose the connection because of timeouts before the mail could be transferred. Now, even at peak packet times, mail delivery is reliable. Jerry
-----------[000242][next][prev][last][first]---------------------------------------------------- Date: 22 Mar 88 06:16:34 GMT From: chris@gyre.umd.EDU (Chris Torek) To: comp.protocols.tcp-ip Subject: RE: offloading the protocols
On the other hand, putting the Jacobson/Karels TCP into the board may produce something significantly slower than what you get when you run the protocol on a Sun-3. Even if the interface is right. Even if you have a good DMA path. No matter how low the overhead is. The problem, you see, is that the Sun-3 CPU may be significantly faster than the one on your protocol card. That 68020 runs rings around the 80x8x in some of those external protocol boards. The latest Ethernet chips from Intel and AMD are fast, but they are not CPUs. There may be some protocol boards that use fast hardware ---if they do not exist now they probably will soon---but I have never seen one myself. Chris
-----------[000243][next][prev][last][first]---------------------------------------------------- Date: 22 Mar 88 12:00:00 CDT From: "HRL780::DN06" <longra@bafb-ddnvax.arpa> To: "tcp-ip" <tcp-ip@sri-nic.arpa> Subject: deletion from mailing list
From: DDNVAX::SYSTEM 21-MAR-1988 16:28 To: LONGRA Subj: Undeliverable mail ----Reason for mail failure follows---- Sending mail to host sri-nic.arpa : Fatal reply code to command 'RCPT TO:<tcp-ip-requests@sri-nic.arpa>': 550 No such local mailbox as "tcp-ip-requests", recipient rejected ----Partial transcript of message follows---- Date: 21 Mar 88 16:09:00 CDT From: "Rick A Long" <longra@bafb-ddnvax.arpa> Subject: mailing list To: "tcp-ip-requests" <tcp-ip-requests@sri-nic.arpa> cc: longra Reply-To: "Rick A Long" <longra@bafb-ddnvax.arpa> Please remove me from your mailing list. Rick Long ------ ------
-----------[000244][next][prev][last][first]---------------------------------------------------- Date: Tue, 22 Mar 88 15:39:04 -0500 From: haverty@CCV.BBN.COM To: braden@VENERA.ISI.EDU Cc: haverty@CCV.BBN.COM, tcp-ip@SRI-NIC.ARPA, haverty@CCV.BBN.COM Subject: Re: Rumors about the death of the ARPANET
Hi Bob,
Yes, good observation. Actually it's not so much the weakness of the
TCP algorithm, it's the fact that so much has to remain intact for the
bad packet to make it to the destination at all to be checksummed!
The other thing to note is that error-correcting codes are related to
checksumming and to fault isolation - they detect, isolate the cause,
and repair all at the same time (but they DON'T usually report the
event to someone who might, for example, dispatch service to fix a
flaky component.
Here's part of an exchange from Vint commenting on checksums that
would have a bit that is set for 'pointer-off', and another for
'count-off-by-one', etc. that you might find interesting:
Vint - You've touched on an interesting point. Right now, checksums
are almost alway binary, i.e., the data is either intact to some high
probability, or it's bad in some undefined way. Thus checksums become
good fault detection tools, but lousy fault isolation tools. If we
could design a checksum algorithm that produced more than a yes/no
output, it could be a useful network management tool; e.g., even if it
could differentiate between a single-bit error in a packet, which
might be a 'normal' behavior of certain lines, and a totally clobbered
packet, e.g., all bytes zeroed, which might indicate a major hardware
or software failure, it would be very useful. The former would be
ignored unless it happens a lot; the latter could trigger alarms,
memory snapshots, datascope traces, etc.
Of course the ultimate such algorithm would set bit 1 for off-by-one,
bit 2 for pointer problem, etc. It may sound crazy, but I think it's
not so farfetched. From lots of hours looking over people's shoulders
as they debug problems (and doing it myself), the key principle is to
look for something 'unusual' in the behavior. If that test could be
converted into an AI-ish algorithm, it could become part of the
network technology itself. Deja vu - we talked about this kind ofd
thing when getting the original Automated Network Managemet prmoject
off the ground. Maybe we should get the academic community to try to
invent a new branch of science and engineering focussed around 'checksums'?
-----------[000245][next][prev][last][first]---------------------------------------------------- Date: 22 Mar 88 14:15:44 GMT From: thompson@dalcs.UUCP (Michael A. Thompson) To: comp.protocols.tcp-ip,comp.dcom.lans Subject: Re: ARP hardware field
In article <135@ftp.COM> nancy@ftp.COM (Nancy Connor) writes: >I don't believe that this is true. I know that Proteon uses a >different set of codes from the Ethernet list I sent out a while ago. Does this make Proteon non-standard? I was quoting from rfc1010, and I must admit some confusion over the status of rfc's, I know that rfc stands for Request For Comment, but everyone seems to treat them as standards, so what are they? Standards or Drafts of proposed standards, and if they are drafts what are the final standards (if any exist) called? -- Michael A. Thompson, Dept. Math, Stats, & C.S., Dalhousie U., Halifax, N.S. thompson@dalcs.uucp From Bitnet or Uucp thompson@cs.dal.cdn From Bitnet or Cdn thompson%dalcs.uucp@uunet.uu.net From Arpa
-----------[000246][next][prev][last][first]---------------------------------------------------- Date: 22 Mar 1988 20:04 EST From: Charles Jerian <cpj@citi.umich.edu> To: tcp-ip@sri-nic.arpa Subject: brl ping
The brl ping only records 6 routes and the documentation says that only 6 will fit into the ip header, however the one I wrote last year has 9 routes brl's gives ./ping -R umda.umd.edu PING umda.umd.edu (128.8.10.10): 56 data bytes 64 bytes from 128.8.10.10: icmp_seq=1 time=1880 ms citi->cntr (35.1.17.2) cntr.pgw (35.1.1.12) umich->cleveland (128.182.18.2) cleveland->psc (128.182.16.2) psc->sura (128.167.31.2) sura->umdbogon (128.167.1.3) while mine gives /etc/ping -r umda.umd.edu options 7==7(RR) 39 40 citi->cntr cntr.pgw umich->cleveland cleveland->psc psc->sura sura->umdbogon 129.2.1.5 bogon-gw.umd.edu terp.umd.edu umda.umd.edu is alive
-----------[000247][next][prev][last][first]---------------------------------------------------- Date: 22 Mar 88 16:33:00 GMT From: Dickson@HIS-PHOENIX-MULTICS.ARPA (Paul Dickson) To: comp.protocols.tcp-ip Subject: Re: Sun servers
PCO-MULTICS.ARPA isn't currently on the Internet. All responses to that
address should be sent to "user-name%pco @ BCO-Multics.ARPA".
-Paul Dickson
Dickson%pco @ BCO-Multics.ARPA
-----------[000248][next][prev][last][first]----------------------------------------------------
Date: 22 Mar 88 17:00:00 GMT
From: longra@BAFB-DDNVAX.ARPA ("HRL780::DN06")
To: comp.protocols.tcp-ip
Subject: deletion from mailing listFrom: DDNVAX::SYSTEM 21-MAR-1988 16:28 To: LONGRA Subj: Undeliverable mail ----Reason for mail failure follows---- Sending mail to host sri-nic.arpa : Fatal reply code to command 'RCPT TO:<tcp-ip-requests@sri-nic.arpa>': 550 No such local mailbox as "tcp-ip-requests", recipient rejected ----Partial transcript of message follows---- Date: 21 Mar 88 16:09:00 CDT From: "Rick A Long" <longra@bafb-ddnvax.arpa> Subject: mailing list To: "tcp-ip-requests" <tcp-ip-requests@sri-nic.arpa> cc: longra Reply-To: "Rick A Long" <longra@bafb-ddnvax.arpa> Please remove me from your mailing list. Rick Long ------ ------
-----------[000249][next][prev][last][first]---------------------------------------------------- Date: 22 Mar 88 17:20:36 GMT From: braden@VENERA.ISI.EDU To: comp.protocols.tcp-ip Subject: Re: Rumors about the death of the ARPANET
What would be interesting is to see if there is a way to design a simple end-end "checksum" designed to catch errors which are not like those in communications media, i.e., result from bugs, configuration mistakes, etc., rather than line noise and the like. Jack Actually, Jack, I think that is what you (as part of the TCP WG) did. The TCP checksum is probably too weak for communications media, but it DOES, as you point out, catch subtle host software errors! Bob Braden
-----------[000250][next][prev][last][first]---------------------------------------------------- Date: 22 Mar 88 17:54:58 GMT From: deschon@VENERA.ISI.EDU (Annette DeSchon) To: comp.protocols.tcp-ip Subject: Re: GATE-D
Jim, A person to contact regarding "gated" is Mark Fedor <fedor@NISC.NYSER.NET> --Annette
-----------[000251][next][prev][last][first]---------------------------------------------------- Date: 22 Mar 88 20:20:04 GMT From: swb@DEVVAX.TN.CORNELL.EDU (Scott Brim) To: comp.protocols.tcp-ip Subject: Re: Conversion to ISO - Number of NCP Hosts
You know, NCP is still alive and well in certain sheltered parts of the world.
-----------[000252][next][prev][last][first]---------------------------------------------------- Date: 22 Mar 88 20:20:24 GMT From: BILLW@MATHOM.CISCO.COM (William Westfield) To: comp.protocols.tcp-ip Subject: Re: Conversion to ISO - Number of NCP Hosts
Does anyone know what the difference in scale is, between these
two conversions? How many NCP hosts and routers/gateways/ imps
were there at the time of conversion to TCP? And how many TCP
hosts and routers/gateways/imps are there now and/or will there
be two years from now (assuming that to be the time of the
beginning of the TCP->OSI conversion)?
I still have an "I Survived the TCP Transition" button somewhere, so
Ill take a shot at this...
The conversion from NCP to TCP took place on 1-Jan-1983. It was about
6 months after that that most hosts could communicate with each other.
As of the cut-over data, most vendor software wasn't quite ready...
My March, 1982 Arpanet directory shows 96 imps, and about 300 hosts.
(And there were more DEC-20s than there were vaxen.)
NCP didn't incorporate ideas like "routers" or "internet". There was
just the ARPAnet. If you had a local area network, it was probably a
Xerox "experimental" 3Mb ethernet, and it probably spoke PUP protocols.
The current NIC host table has 854 Networks, 456 gateways (routers),
and 5719 hosts in it. This, of course, does not include isolated
places that have set up IP networks without being assigned network
numbers by the NIC. It probably does not include gateways that aren't
involved with talking to the arpanet. It does not include subnet
gateways used within an autonomous system. It does not include hosts
whose names are only obtainable only via the domain system. I think
current estimates are that one new network is added to the Internet
every working day (eg 250/year).
Hopefully, there will be a several year period during which ISO
protocols and TCP/IP will co-exist, and eventually, one of them will
become unused.
Bill Westfield
cisco Systems.
-------
-----------[000253][next][prev][last][first]---------------------------------------------------- Date: 22 Mar 88 20:39:04 GMT From: haverty@CCV.BBN.COM To: comp.protocols.tcp-ip Subject: Re: Rumors about the death of the ARPANET
Hi Bob,
Yes, good observation. Actually it's not so much the weakness of the
TCP algorithm, it's the fact that so much has to remain intact for the
bad packet to make it to the destination at all to be checksummed!
The other thing to note is that error-correcting codes are related to
checksumming and to fault isolation - they detect, isolate the cause,
and repair all at the same time (but they DON'T usually report the
event to someone who might, for example, dispatch service to fix a
flaky component.
Here's part of an exchange from Vint commenting on checksums that
would have a bit that is set for 'pointer-off', and another for
'count-off-by-one', etc. that you might find interesting:
Vint - You've touched on an interesting point. Right now, checksums
are almost alway binary, i.e., the data is either intact to some high
probability, or it's bad in some undefined way. Thus checksums become
good fault detection tools, but lousy fault isolation tools. If we
could design a checksum algorithm that produced more than a yes/no
output, it could be a useful network management tool; e.g., even if it
could differentiate between a single-bit error in a packet, which
might be a 'normal' behavior of certain lines, and a totally clobbered
packet, e.g., all bytes zeroed, which might indicate a major hardware
or software failure, it would be very useful. The former would be
ignored unless it happens a lot; the latter could trigger alarms,
memory snapshots, datascope traces, etc.
Of course the ultimate such algorithm would set bit 1 for off-by-one,
bit 2 for pointer problem, etc. It may sound crazy, but I think it's
not so farfetched. From lots of hours looking over people's shoulders
as they debug problems (and doing it myself), the key principle is to
look for something 'unusual' in the behavior. If that test could be
converted into an AI-ish algorithm, it could become part of the
network technology itself. Deja vu - we talked about this kind ofd
thing when getting the original Automated Network Managemet prmoject
off the ground. Maybe we should get the academic community to try to
invent a new branch of science and engineering focussed around 'checksums'?
-----------[000254][next][prev][last][first]----------------------------------------------------
Date: 22 Mar 88 22:06:00 GMT
From: jerry@TWG.COM ("Jerry Scott")
To: comp.protocols.tcp-ip
Subject: RE: offloading the protocolsChris, Agreed, the cpu on the board will definitely come into play in terms of performance. We see that here at TWG when our host resident software is compared against on-board software on VAX 86xx or 88xx hardware. The host resident runs circles around the on-board in these cases. I think the Jacobson/Karels code has more to offer than blazing performance. The code that I am distributing does not yet have the performance hooks that Van explained in some of his mail messages. But it does have improved congestion control that allows my connections to adapt to line speeds during the life of the connection rather than at the beginning. Not only does this code save the net the overhead of unnecessary retransmissions, but prevents timeouts of connections as well. The big improvement I have seen is with Arpanet mail. It used to be the case that I would try to send mail to another host, make the connection, and then lose the connection because of timeouts before the mail could be transferred. Now, even at peak packet times, mail delivery is reliable. Jerry
-----------[000255][next][prev][last][first]---------------------------------------------------- Date: 22 Mar 88 22:15:39 GMT From: jeff@tc.fluke.COM (Jeff Stearns) To: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: ethernet monitor needed?
In article <3447@cbmvax.UUCP>, grr@cbmvax.UUCP (George Robbins) writes
about his search for Ethernet test gear.
I'll put in a plug for the Cabletron LAN-MD. It's a suitcase-sized box that
can thoroughly test cables and transceivers. A pair of LAN-MD's can exercise
transceivers in place and tell you things that you'll never otherwise know.
Which of your transceivers have broken or out-of-spec collision detect
circuitry? How will you find them? Hint: Can a computer tell if its
transceiver has this problem?
Now that we're in the age of level I vs level II vs 802.3, we have abundant
opportunities to pair up Ethernet controllers with the wrong kind of
transceiver, multiplexor, or cable. Physical and link-level problems like
this are often inscrutable to higher-level tools.
Imagine a chart of the ISO reference model. Stick a pushpin in it for every
Ethernet problem you've had. Here's a starter drawn from recent memory:
Controllers that don't conform to the Ethernet spec, wrong cable type for
transceiver level, out-of-spec transceivers, defective transceivers,
broken Ethernet controllers, buggy controllers, buggy device drivers,
improperly-installed vampire taps, noise-sensitive transceivers, loose
transceiver cables, bugs in TCP/IP, NFS, ND, and ftp.
That puts a lot of pins down at the bottom of the chart, below the level of
monitors and protocol analyzers. The LAN-MD works well down there.
I wouldn't be surprised if Cabletron were working on something newer than
the LAN-MD; you might also want to ask 'em that.
--
Jeff Stearns
Domain: jeff@tc.fluke.COM
Voice: +1 206 356 5064
If you must: {uw-beaver,microsoft,sun}!fluke!jeff
USPS: John Fluke Mfg. Co. / P.O. Box C9090 / Everett WA 98206
-----------[000256][next][prev][last][first]---------------------------------------------------- Date: 23 Mar 88 01:03:47 GMT From: gordan@maccs.UUCP (gordan) To: comp.protocols.tcp-ip Subject: Checksums (was Re: Ping, checksum algorithm?)
In article <123@heart-of-gold> jc@heart-of-gold (John M Chambers x7780 1E342) writes:
-Does anyone have a PD version of ping? How about a C-coded routine that
-does the IP checksum calculation? We have one that is written in VAX
-assembly language, which is OK for a VAX, but it doesn't work too well
-on a 68020....
--------------------------------------------------------------------------
-- One's complement of the one's complement sum checksum in TCP/IP --
In the RFC documents, the "one's complement of the one's complement sum"
checksums are mentioned in a single paragraph, and are never even
described, an omission that seems incredible.
Although the algorithm must be well known to many people, a written
description seems to be lacking. So here's an attempt to provide a
short description (with examples). The only authority I can cite for
the following is myself (but it seems to work, judging from actual
TCP/IP packets). Someone kindly let me know if this is horribly wrong.
Basically, IP, TCP, and UDP require doing one's complement sums of
16-bit words. That is, you must take a bunch of 16-bit words and sum
them (ignoring overflows) _as if their bit patterns represented one's
complement numbers_. The trick, then, is doing one's complement
arithmetic on a two's complement machine.
Without going into any arithmetical justification, here's how to do a
one's complement sum on a two's complement machine, in pseudocode:
INT16 sum;
INT16 *word; /* pointer to start of 16-bit words to be summed */
sum = 0;
for (i = 0; i < `number of 16-bit words to be summed'; i++)
{
`byte-swap word[i], if necessary (see comment on byte-order)'
sum += word[i]; /* do NOT combine these two lines ... */
sum += `CARRY'; /* ... into sum += word[i] + CARRY !!!! */
}
where CARRY is the value of the hardware carry bit (0 or 1), as set by
the addition in the previous line (note you mustn't do sum += word[i] +
CARRY as one line, since a high-level language could rearrange the order
of addition and add the value of the carry bit before it was set).
Of course, the value of the carry bit is not accessible from a
higher-level language like C. A perfectly equivalent method (very
suitable if your machine has 32-bit integers) is:
INT32 sum32, word32
INT16 *word; /* pointer to start of 16-bit words to be summed */
sum32 = 0;
for (i = 0; i < `number of 16-bit words to be summed'; i++)
{
`byte-swap word[i], if necessary (see comments on byte-order)'
`copy word[i] to word32, zero-extended (NOT sign-extended)'
/* (e.g., 0xedcb -> 0x0000edcb, not 0xffffedcb) */
sum32 += word32;
}
sum = `add the two 16-bit halves of sum32 to each other'
This works, since the carry bit values for 16-bit addition of the least
significant 16-bit word accumulate in the most significant 16-bit word
of the 32-bit sum. (This is probably what you would use on a 68020 --
and you can forget about byte-swapping on a 68020 as well).
After calculating a one's complement sum, you have to take its one's
complement (invert all the bits) to get the actual checksum used in IP,
TCP, and UDP (but note that UDP treats a calculated checksum of 0x0000
as a special case -- see the RFC).
It is of course necessary to take byte-order into account.
(Byte-order: if adjacent memory locations on a machine contain the
following bytes:
X : 0x12
X+1 : 0x34
then what is the value of the 16-bit word whose address is X?
(assuming a byte-addressable machine and valid alignment for X to be
read as a 16-bit value).
If the 16-bit value is 0x1234, the machine is said to be
``big-endian;'' if it is 0x3412, the machine is ``little-endian.''
Some machine architectures (Motorola 680x0, etc.) are big-endian, others
(Intel 80x86, VAX) are little-endian. TCP/IP headers use big-endian
byte-order. Thus, life is easier on a Sun than on a VAX.
Some examples follow, using actual packets (see the appropriate RFC docs
for IP, UDP, and TCP, and ignore the Ethernet stuff). In case anyone's
curious, the IP addresses here are used on a LAN unconnected to any
outside network (they do not respect the class A/B/C Internet naming
scheme).
An Ethernet UDP/IP packet
---------------------------------------------------
1: ff-ff-ff-ff-ff-ff 02-60-8c-09-58-97 08-00
2: 45 00
3: 00-24 00-01 00-00 ff 11 61-31 01-00-58-97 01-00-
4: -00-00
5: 09-46 00-2a 00-10 c9-ca
6: 01 06 4a 48 45 56
7: 41 58
8: 00 00 00 00 00 00 00 00 00 00
---------------------------------------------------
Line 1: Ethernet header
Lines 2-8: Ethernet data
Lines 2-4: IP header
Lines 5-7: IP data
Line 5: UDP header
Lines 6-7: UDP data
Line 8: Garbage padding to satisfy Ethernet minimum packet size
(Ethernet header + data >= 60 bytes).
---------------------------------------------------
An Ethernet TCP/IP packet
----------------------------------------------------
1: 08-00-2b-02-d2-67 08-00-02-00-51-23 08-00
2: 45 00
3: 00-4b 44-46 00-00 1e 06 56-3a 01-00-00-0b 01-00-
4: -00-23
5: 00-17 07-a8 06-14-56-f0 d3-1d-aa-a4 50 18
6: 00-68 b1-d0 00-00
7: 0d 0a 0d 0a 4d 63 4d 61 73 74
8: 65 72 20 55 6e 69 76 65 72 73 69 74 79 20 56 41
9: 58 20 38 36 30 30 0d 0a 0d
10: 00
---------------------------------------------------
Line 1: Ethernet header
Lines 2-10: Ethernet data
Lines 2-4: IP header
Lines 5-9: IP data
Lines 5-6: TCP header
Lines 7-9: TCP data
Line 10: Garbage Ethernet padding (to send an even number of bytes)
----------------------------------------------------
In the first packet, the IP Checksum field is 0x6131 (in the middle of
line 3). The IP checksum is calculated over all 16-bit words in the
header (except the checksum field itself is taken to be zero, prior to
actually calculating it). Thus the 16-bit words that go into
calculating the IP checksum are (from lines 2,3,4): 0x4500, 0x0024,
0x0001, 0x0000, 0xff11, 0x0000, 0x0100, 0x5897, 0x0100, 0x0000.
The 32-bit sum of zero-extended words is 0x 0001 9ecd, so the one's
complement sum is 0x9ece. The one's complement of this is the checksum,
0x6131.
The UDP Checksum field in the same packet is 0xc9ca (at the end of line
5). Unlike IP, the UDP checksum is calculated not only over the UDP
header, but also over the UDP data, and over a pseudo-header consisting
of the IP source and destination addresses, the IP Protocol field
zero-extended to 16-bits, and a UDP length word. Again the checksum
field itself is taken to be zero during the actual calculation, since we
can't know its value before actually computing it.
Thus the 16-bit words that go into calculating the UDP checksum are
(from lines 5,6,7): 0x0946, 0x002a, 0x0010, 0x0000, 0x0106, 0x4a48,
0x4556, 0x4158; (and from the pseudo-header): 0x0100, 0x5897, 0x0100,
0x0000, 0x0011 (UDP protocol number = 0x11 or 17 decimal), and 0x0010
(the UDP length). The 32-bit sum of zero-extended words is 0x 0001
3634, so the 16-bit one's complement sum is 0x3635 and the checksum is
0xc9ca as required.
In the second packet shown, the IP checksum is 0x563a (in the middle of
line 3). The 16-bit words that go into calculating the IP checksum are
(from lines 2,3,4): 0x4500, 0x004b, 0x4446, 0x0000, 0x1e06, 0x0000,
0x0100, 0x000b, 0x0100, 0x0023.
The 32-bit sum of zero-extended words is 0x 0000 a9c5, so the one's
complement sum is 0xa9c5. The one's complement of this is the checksum,
0x563a.
The TCP Checksum field in the same packet is 0xb1d0 (the second word in
line 6). Just as for UDP, the TCP checksum is calculated over all 16-bit
words in the TCP header, data, and pseudo-header. The 16-bit words that
go into calculating the checksum are:
From the TCP header:
0x0017, 0x07a8, 0x0614, 0x56f0, 0xd31d, 0xaaa4,
0x5018, 0x0068, 0x0000 (checksum field itself is initially zero),
0x0000.
From the TCP data:
0x0d0a, 0x0d0a, 0x4d63, 0x4d61, 0x7374, 0x6572,
0x2055, 0x6e69, 0x7665, 0x7273, 0x6974, 0x7920, 0x5641, 0x5820,
0x3836, 0x3030, 0x0d0a, 0x0d00 (we have an odd number of data bytes,
so the last byte is zero-filled on the right to form a 16-bit word).
From the pseudo-header:
0x0100, 0x000b (from the source IP address),
0x0100, 0x0023 (from the destination IP address),
0x0006 (zero-extended IP Protocol word, 0x6 = TCP),
0x0037 (the TCP Length, i.e. the length of the TCP header and data).
Here, the 32-bit sum of zero-extended words is 0x 0007 4e28, so the
16-bit one's complement sum is 0x4e2f and the checksum is 0xb1d0, as
required.
Note the TCP length must be calculated as the total IP Length (0x4b in
this case) minus the length of the IP header (5 32-bit words in this
case, or 0x14 (decimal 20) bytes). The TCP header itself does not store
the number of bytes of TCP data, so the TCP layer relies on the IP layer
to supply it with this information.
This describes how the sender of a packet calculates the checksum. The
receiver, on the other hand, can verify the checksum quickly in the
following manner: it simply one's complement sums the 16-bit words and
checks if the result is 0xffff (except UDP's special case behavior must
again be taken into account) -- if it is, the checksum is correct and
the packet data is valid.
A moment's thought should show why this works. Recall that when the
sender calculated the checksum, the checksum field itself was zero; when
the receiver looks at the header, however, the field has been filled in.
The checksum is the one's complement of the one's complement sum, and
whenever a number and its one's complement are added together, the
result is 0xffff.
--
Many Americans work side by side with space
aliens who look human -- but you can spot
these visitors by looking for certain Gordan Palameta
tip-offs, say experts. mnetor!maccs!gordan
-----------[000257][next][prev][last][first]---------------------------------------------------- Date: 23 Mar 88 01:04:00 GMT From: cpj@CITI.UMICH.EDU (Charles Jerian) To: comp.protocols.tcp-ip Subject: brl ping
The brl ping only records 6 routes and the documentation says that only 6 will fit into the ip header, however the one I wrote last year has 9 routes brl's gives ./ping -R umda.umd.edu PING umda.umd.edu (128.8.10.10): 56 data bytes 64 bytes from 128.8.10.10: icmp_seq=1 time=1880 ms citi->cntr (35.1.17.2) cntr.pgw (35.1.1.12) umich->cleveland (128.182.18.2) cleveland->psc (128.182.16.2) psc->sura (128.167.31.2) sura->umdbogon (128.167.1.3) while mine gives /etc/ping -r umda.umd.edu options 7==7(RR) 39 40 citi->cntr cntr.pgw umich->cleveland cleveland->psc psc->sura sura->umdbogon 129.2.1.5 bogon-gw.umd.edu terp.umd.edu umda.umd.edu is alive
-----------[000258][next][prev][last][first]---------------------------------------------------- Date: 23 Mar 88 09:12:00 PST From: Dave Crocker <dcrocker@TWG.COM> To: tcp-ip <tcp-ip@sri-nic.arpa> Subject: on-/off-board protocol processing
As with most technical choices, each alternative has its appropriate uses. The concern about reliability of processing, expressed by Vint, seems not to apply to many of the current "intelligent-board" solutions. Their interface to the host is essentially -- often exactly -- like accessing standard primary memory. So, if you don't trust your primary memory, you probably have more serious architectural fish to fry that where you put your protocol processing. When the interface is more channel-oriented, then reliability becomes factor. That is, if you need a serious protocol, to access your protocols, there is a reasonable chance that the access protocol has bugs, so that you have a step in the networking chain truly exposed to problems, and not detectable by the end-to-end safety mechanism of the transport protocol. On the other hand, There is some interesting mythology about the benefits of moving your protocols to an intelligent board. Having a slow board and a fast host has become a very significant issue, as discussed in some messages, already. My only comment is that when making a choice, you should pay close attention to this issue. Less well-understood are some beliefs that the intelligent board makes the host less complex and relieves the host of substantial overhead. This is true only sometimes. The only factor that is always nicer about intelligent boards is that they do the checksum calculation. On the other hand, They significantly increase the cost of networking hardware. They tend to limit the number of virtual circuits that you can have, due to memory limitations on the board -- a factor that is becoming less of a problem, with 512K and 1M boards. They tend to make multiple-interface configurations a problem, since you then have to add complexity to the host, anyhow, to coordinate the cards. That is, when you move the protocols to the board, then multiple boards become multiple protocol implementations. Coordinating IP routing, UDP and TCP Port number allocation, etc, becomes a real hassle. Worse, customers seem to be inclined to try to do this with implementations from different vendors(!) The idea that intelligent boards reduce interrupt overhead sounds appealing, but often does not prove out. Most incoming packets have their data handed immediately to the receiving application, so that the network interrupt, caused when the packet arrives, still causes the o/s device driver -- yup, you still need such a beast when you have intelligent boards -- to interrupt and you still have the kernel/user context switch. In the case of heavy traffic with small packets, the intelligent board does have an edge. Otherwise, the host-based solution seems to be a much more efficient use of resources. Now, suppose that you have a host that is tending towards saturation and you believe that the extra processing on the board will relieve the problem. At one level of analysis, you would be correct. On the other hand, It is a very short-sighted way to solve a system congestion problem. If your host has a problem at that level, you probably have only bought yourself relief for a short time. In all likelihood, you need to get yourself another host. Given that most machines are in the micro-computer and small-minicomputer range, this expense is not necessarily onerous. Now, about the idea of having a non-networking-oriented access model for the software, such as the view of fitting the network in as a portion of a process's address space, so that the software need not be aware of networking; it simply thinks that it is doing memory transfers, and the underlying hardware/software handle the rest... For general, "distributed processing" types of activities, this will, no doubt, prove very, very useful. In essence, it is the natural evolution down the path that includes the remote procedure call model, since you are integrating networking into increasingly "natural" computing models. This, also, is its problem. While it often is very nice to hide networking issues, it often is necessary to manipulate them directly. Allowing a program to ignore the issues is great. Preventing it from paying attention is terrible.
-----------[000259][next][prev][last][first]---------------------------------------------------- Date: Wed, 23 Mar 88 10:02:48 -0500 From: Craig Partridge <craig@NNSC.NSF.NET> To: wb6rqn!brian@uunet.uu.net Cc: tcp-ip@sri-nic.ARPA Subject: re: Network management ...
Brian,
On the network management side of the question, here's the recommended
reading list:
- The March Issue of IEEE Network (a special issue on network management
protocols). Reportedly on its way to you now, although I have yet
to receive my copy.
- RFCs 1021-1024 on the High-Level Entity Management System (HEMS).
- RFC 1028 on the Simple Gateway Monitoring Protocol (SGMP). (A proposed
revision either has been or will shortly be released as an IDEA)
- Other work of interest is the still-in-progress work by the NETMAN
working group of the Internet Engineering Task Force (IETF) on a
TCP-IP version of the Common Management Information Protocol (CMIP).
Contact the chairman of that group (Lee LaBarre, cel@mitre-bedford.arpa)
for current drafts.
Finally -- there is an Internet mailing list on network management. Mail
to gwmon-request@sh.cs.net to join.
Craig
-----------[000260][next][prev][last][first]---------------------------------------------------- Date: 23 Mar 88 02:15:40 GMT From: swb@DEVVAX.TN.CORNELL.EDU (Scott Brim) To: comp.protocols.tcp-ip Subject: Re: GATE-D
Posted-Date: Tue, 22 Mar 88 09:54:58 PST Date: Tue, 22 Mar 88 09:54:58 PST From: Annette DeSchon <deschon@venera.isi.edu> Jim, A person to contact regarding "gated" is Mark Fedor <fedor@NISC.NYSER.NET> --Annette Actually, Annette, Mark left Cornell last year. The prime developer is Jeff Honig, jch@devvax.tn.cornell.edu. The gatedaemon is supported by the Network Systems group at the Cornell Theory Center. Scott
-----------[000261][next][prev][last][first]---------------------------------------------------- Date: 23 Mar 1988 07:39-EST From: CERF@A.ISI.EDU To: MAB@CORNELLC.CCS.CORNELL.EDU Cc: TCP-IP@SRI-NIC.ARPA Subject: Re: Conversion to ISO - Number of NCP Hosts
I can't give firm numbers but there were on the order of 20-25 different operating system implementations of NCP and somewhat fewer for TCP at the time the conversion was done - some hosts never made the change and were simply retired (good excuse...). The NCP/TCP and TCP/ISO analogies are not exact. For one thing, NCPwas never a commercial product. TCP is. For another, only ARPANET hosts did NCP because that was NOT an internet protocol, so a single administration could insist on the conversion and was even able to turn off NCP capability within the subnet as a forcing function. This is not possible for TCP/ISO except perhaps at the gateways (and maybe for the subnets if packet types for ISO IP and DoD IP are distinct, as I suppose they are likely to be). There must be literally tens of thousands of TCP/IP hosts by now compared to at most a couple of hundred NCP hosts in Jan 83. Somehow I think the analogy is not very apt. Vint
-----------[000262][next][prev][last][first]---------------------------------------------------- Date: 23 Mar 1988 07:47-EST From: CERF@A.ISI.EDU To: kwe@BU-CS.BU.EDU Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: Rumors about the death of the ARPANET
The FCCSET committees, the NSF, the EDUCOM Network Forum, and a number of other individuals, groups, organizations, random parties, etc. all are interested in seeing a high speed network emerge which could benefit the research community and ultimately the entire business population. Serious work is going on in industry and in the research labs on very high speed switching capble of operating in excess of 45 Mbps. A SONET swiitch (circuit) was demonstrated recently at 135 Mb/s; a packet mode switching fabric is under development at Bellcore which will operate at 100-200 Mb/s per channel (packet mode). Cost is an important consideration and it does seem as if various forms of subsidy will be needed in the early stages, just as the ARPANET was subsidized fully by the R&D funding activity of DARPA. In the longer term, though, there are services which will dmeand the bandwidth and make it far less expensive on average. To give a trivial example, once ISDN emerges, 64 kb/s will be the standard rate for voice - so you get to use it for data, too, without the cost of a modem. This isn't to say everything will happen easily or even very quickly, but there are enough forces in motion that I believe the will and the therewithall to make high speed nets a reality will be available. Vint
-----------[000263][next][prev][last][first]---------------------------------------------------- Date: 23 Mar 88 03:00:36 GMT From: brian@wb6rqn.UUCP (Brian Lloyd) To: comp.protocols.tcp-ip Subject: Network management, routing algorithms
Can someone give me a pointer to work being done in network management
and automatic routing algorithms for the internet protocol suite? I
would like pointers to papers if any exist that can be readily accessed.
Thanks.
Brian Lloyd, President
Sirius Systems, Inc.
(301) 540-2066
{bellcore, syscad, cp1, irs3, n3dmc}!wb6rqn!brian
Share and enjoy!
-----------[000264][next][prev][last][first]---------------------------------------------------- Date: Wed, 23 Mar 88 8:55:08 EST From: Alex McKenzie <mckenzie@LABS-N.BBN.COM> To: tcp-ip@SRI-NIC.ARPA Subject: A network you can trust
During the past few days there have been several messages about "off loading
the protocol processing" from one's processor to an outboard box. It appears
that networking ideas are coming full circle. In a paper presented in May
1970, Larry Roberts of ARPA wrote:
"In this paper a computer network is defined to be a set of autonomous,
independent computer systems, interconnected so as to permit active
resource sharing... The goal of the computer network is for each
computer to make every local resource available to any computer in the
net in such a way that any program available to local users can be
used remotely without degradation....The communication pipelines
offered by the carriers would probably have to be a components of
that service but were clearly inadequate by themselves. What was
needed was a message service where any computer and be sure it would be
delivered promptly and correctly...The distributed store and forward
system was chosen, after careful study, as the ARPA Network
communications system."
A companion paper, by several BBN authors, provided more detail:
"The network is thus a store and forward system and as such must
deal with problems of routing, buffering, synchronization, error
control, reliability, and other related issues. To insulate the
computer centers from these problems, and to insulate the network
from the problems of the computer centers, ARPA decided to place
identical small processors at each network node, to interconnect
these small processors with leased common-carrier circuits to form
a subnet, and to connect each research computer center into the
net via the local small processor.... The subnet should function
as a communications system whose essential task is to transfer bits
reliably from a source location to a specified destination. Bit
transmission should be sufficiently reliable and error free to
obviate the need for special precautions (such as storage for
retransmission) on the part of the Hosts."
In fact, the ARPANET met these specifications so well that NCP, the original
"Layer 4" protocol used until the end of 1982, had essentially no error
checking, retransmission, etc. The protocol processing of Hosts using NCP
was largely off-loaded, into the subnetwork's Interface Message Processor.
---
During the mid-1970's however, there arose body of opinion that subnetwork
should provide only datagram service, and that the hosts should do the protocol
processing themselves. There were 3 primary supporting arguments for this
viewpoint:
1) Some bugs in the code of the ARPANET packet switches caused two
or three network "lockups" in the first few years. A datagram-
only network would not be subject to such events.
2) A packet switch which didn't do all that work would be cheaper to
build and maintain.
3) Since no network can absolutely guarantee perfect service (it was
obligatory to mention the X.25 "Reset" here), any host that cares
about reliability will have to provide its own end-to-end
reliability mechanisms. Since all hosts will probably care about
reliability some time, all hosts will need to implement end-to-end
reliability mechanisms. Since all Hosts have to do this, the
network shouldn't bother to try.
In fact, a number of the networks which became components of the Internet were
built according to this minimalist philosophy, thereby insuring that all hosts
would often have to care about reliability.
It seems to me that as we begin to work on the next generation of networks we
ought to re-examine the datagram basis of the current Internet architecture. I
think we've thrown the baby out with the bathwater. I believe that a carefully
designed network can provide enough reliability for almost all host needs, and
this is the best way to offload protocol processing. It is best because it
puts the responsibility for doing it right, fixing it when it breaks, and
improving it when research produces a better way, in the hands of a single
identifiable organization. This is far superior to having each host procuring
yet another box to go between itself and the communication network with no one
(in many cases) responsible for the care, diagnosis, repair, or improvement of
the box.
Cheers,
Alex
-----------[000265][next][prev][last][first]---------------------------------------------------- Date: 23 Mar 88 12:04:00 PST From: Mike Anello <mja@TWG.COM> To: tcp-ip <tcp-ip@sri-nic.arpa> Subject: RE: (TLI HELP)
In reply to Gil Widdowson note about TLI HELP: In both socket and tli calls sockaddr_in structure is used to specify an internet address. Since sin_zero element of this structure does not contain any usefull data, only the first three elements (the first 8 bytes) should be passed to buffers used in tli calls. Two constants UDP_BINDADDRLEN in udp.h and TCP_BINDADDRLEN in tcp.h may be used for this purpose. When using t_bind(fd, req, ret) call, you will get back in ret.addr.buf the address assigned by the transport provider. This address is 8 bytes long and represents the first three elements of sockaddr_in structure. In t_bind(fd, NULL, &ret) call, transport provider will assign INADDR_ANY address, and the next available port number to the end point. Mohsen Mortazavi The Wollongong Group
-----------[000266][next][prev][last][first]---------------------------------------------------- Date: Wed, 23 Mar 88 14:52:42 PST From: "David Cheriton" <cheriton@pescadero.stanford.edu> To: mckenzie@labs-n.bbn.com, tcp-ip@sri-nic.arpa Subject: Re: A network you can trust
There's a major difference between the offloading my group is working on now and what was done in the ARPAnet days, namely: Our protocol processor implements a reliable transport (process-to-process) service whereas the ARPAnet did/does reliable host-to-host communication. There is a fundamental flaw in trying to put multiplexing on top of a reliable communication layer because of its interaction with flow control and error control. Anyone who puts a host-to-host reliable protocol in a separate comm. processor has indeed gone a full circle and deserves all the 1970's problems that will ensue. However, because TCP and TP 4 and VMTP are all proces-to-process, I think we are likely to see "the right thing being used in the right way" as opposed to "the wrong way", which is a significant step forward. David Cheriton
-----------[000267][next][prev][last][first]---------------------------------------------------- Date: Wed, 23 Mar 88 12:02:57 est From: scottr@csc-lons.ARPA (Scott W. Rogers) To: tcp-ip@sri-nic.arpa Subject: Ping for Excelan (4.1C BSD) ?
Does anyone out there have, or have any information reguarding, ping based on the EXCELAN Software (8011 or 8051) for their TCP/IP board. It is based on the Berkeley 4.1C (yeach ...) socket library. Please, if posiible respond directly to me, I will summarize to the Net. Thanks in advance, Scott W. Rogers <scottr@CSC-LONS.ARPA> Computer Sciences Corporation ---
-----------[000268][next][prev][last][first]---------------------------------------------------- Date: Wed, 23 Mar 88 12:09:37 EST From: fedor@nisc.nyser.net (Mark Fedor) To: PETTY@mitvma.mit.edu, deschon@venera.isi.edu Cc: TCP-IP@sri-nic.arpa Subject: Re: GATE-D
> >Subject: Re: GATE-D >Date: Tue, 22 Mar 88 09:54:58 PST >From: Annette DeSchon <deschon@venera.isi.edu> > >Jim, > >A person to contact regarding "gated" is > > Mark Fedor <fedor@NISC.NYSER.NET> > >--Annette >>> Actually, I left Cornell last year and although I put my two cents in every now and then like everyone else, the main developer is now Jeff Honig at Cornell (jch@devvax.tn.cornell.edu). So please contact him, but.. if anyone out there wants to play softball this summer in Albany, contact me. :^) see ya! Mark
-----------[000269][next][prev][last][first]---------------------------------------------------- Date: Wed, 23 Mar 88 12:30:01 EST From: Mills@UDEL.EDU To: CERF@a.isi.edu Cc: kwe@bu-cs.bu.edu, tcp-ip@sri-nic.arpa Subject: Re: Rumors about the death of the ARPANET
My recent message left out a fine point. ISDN may in fact provide 64-kbps ubiquitous interface, but a significant fraction of interoffice transport will still be anaolg, with conversion where required. This means you can ask (using the D channel) for 64-kbps data service, but the network may tell you thanks, but no anyway. You may ask for 9.6-kbps data and the network may be happy to oblidge you, then depreciate the modems at ratepayer expense. Hang on to your Telebits for awhile, at least. Dave
-----------[000270][next][prev][last][first]---------------------------------------------------- Date: 23 Mar 88 07:50:55 GMT From: phil@BRL.ARPA (Phil Dykstra) To: comp.protocols.tcp-ip Subject: Re: brl ping
You are correct in that up to 9 routes can fit in an IP header if record route is the only option. I'm not sure how ours ended up set to six (the documentation just laments the max IP header size). You can simply change the "#define NROUTES" from 6 to 9. I have done so to VGR's copy. - Phil
-----------[000271][next][prev][last][first]---------------------------------------------------- Date: Wed, 23 Mar 88 13:22:09 EST From: perry@MCL.UNISYS.COM (Dennis Perry) To: cerf@isi.edu, farber@cis.upenn.edu Cc: perry@mcl.unisys.com, tcp-ip@sri-nic.arpa Subject: Re: Off loading the protocol
Dave, we had this type of discussion often at Los Alamos, namely, how long is YOUR network (keep you evil thoughts to yourself!). Teh comparison was between 19inch rack or 10 miles out to the remote canyon site. But you are right, networking is just an extended case of interprocess communication, with the processes spread over a varying distance. That distance can have an affect, if the time required to travel that distance affects what the processes are doing. At very high speed, the effect can be small to non-existant. dennis
-----------[000272][next][prev][last][first]---------------------------------------------------- Date: Wed, 23 Mar 88 13:34:07 EST From: perry@MCL.UNISYS.COM (Dennis Perry) To: KASTEN@mitvma.mit.edu, tcp-ip@sri-nic.arpa Cc: perry@mcl.unisys.com Subject: Re: Rumors about the death of the ARPANET
Frank, yes the Government is thinking about and looking at DS3. One of the main questions at this point is cost and how it can be shared among the agencies in ways other than multiplexing the DS# down to T1s. I think we will see DS3 before too long, unfortunately it will be a while longer before we see a dark DS3 and can multiplex at the packet level. dennis
-----------[000273][next][prev][last][first]---------------------------------------------------- Date: Wed, 23 Mar 88 16:34:16 PST From: ultra!ted@ames.arc.nasa.gov (Ted Schroeder) To: tcp-ip@sri-nic.arpa Subject: Add to mailing list
Please add the following mail alias to the tcp-ip mailing list.
ultra!tcp-ip@Ames.ARPA
Ultra Network Technologies
2140 Bering drive with a domain server:
San Jose, CA 95131 tcp-ip@Ultra.COM
408-922-0100
-----------[000274][next][prev][last][first]---------------------------------------------------- Date: Wed, 23 Mar 88 17:13:11 PST From: Jon Peha <peha@spam.istc.sri.com> To: tcp-ip@sri-nic.arpa Subject: precedence
I note in the RFC's that TCP and IP have three bits reserved for precedence, but UDP does not. I have a number of questions about this. The obvious place to start: is precedence really implemented? I can see many obvious fairness problems. One user could effectively shut out other users until their TCP connections start timing out. If they are allowed to, every one will want to send high precedence packets. How are these problems resolved? Why doesn't UDP hace precedence as well? My questions arise from a desire to send packets over a token ring. The 802.5 spec allows packets to have different priorities, but I can't figure out how you would use this feature with the TCP suite. Has any one out there ever done this? This particular application is voice, so I want a connectionaless transport (UDP). Thanks. Jon Peha
-----------[000275][next][prev][last][first]---------------------------------------------------- Date: 23 Mar 88 12:39:00 GMT From: CERF@A.ISI.EDU To: comp.protocols.tcp-ip Subject: Re: Conversion to ISO - Number of NCP Hosts
I can't give firm numbers but there were on the order of 20-25 different operating system implementations of NCP and somewhat fewer for TCP at the time the conversion was done - some hosts never made the change and were simply retired (good excuse...). The NCP/TCP and TCP/ISO analogies are not exact. For one thing, NCPwas never a commercial product. TCP is. For another, only ARPANET hosts did NCP because that was NOT an internet protocol, so a single administration could insist on the conversion and was even able to turn off NCP capability within the subnet as a forcing function. This is not possible for TCP/ISO except perhaps at the gateways (and maybe for the subnets if packet types for ISO IP and DoD IP are distinct, as I suppose they are likely to be). There must be literally tens of thousands of TCP/IP hosts by now compared to at most a couple of hundred NCP hosts in Jan 83. Somehow I think the analogy is not very apt. Vint
-----------[000276][next][prev][last][first]---------------------------------------------------- Date: 23 Mar 88 12:47:00 GMT From: CERF@A.ISI.EDU To: comp.protocols.tcp-ip Subject: Re: Rumors about the death of the ARPANET
The FCCSET committees, the NSF, the EDUCOM Network Forum, and a number of other individuals, groups, organizations, random parties, etc. all are interested in seeing a high speed network emerge which could benefit the research community and ultimately the entire business population. Serious work is going on in industry and in the research labs on very high speed switching capble of operating in excess of 45 Mbps. A SONET swiitch (circuit) was demonstrated recently at 135 Mb/s; a packet mode switching fabric is under development at Bellcore which will operate at 100-200 Mb/s per channel (packet mode). Cost is an important consideration and it does seem as if various forms of subsidy will be needed in the early stages, just as the ARPANET was subsidized fully by the R&D funding activity of DARPA. In the longer term, though, there are services which will dmeand the bandwidth and make it far less expensive on average. To give a trivial example, once ISDN emerges, 64 kb/s will be the standard rate for voice - so you get to use it for data, too, without the cost of a modem. This isn't to say everything will happen easily or even very quickly, but there are enough forces in motion that I believe the will and the therewithall to make high speed nets a reality will be available. Vint
-----------[000277][next][prev][last][first]---------------------------------------------------- Date: 23 Mar 88 14:37:25 GMT From: brian@wb6rqn.UUCP (Brian Lloyd) To: comp.protocols.tcp-ip Subject: Checksums
The advantage to using checksums with tcp and ip is that generating a
checksum is a relatively low-cost operation (the addition instruction in
most processors requires relatively few t-cycles). When you begin to
talk about extracting pattern information from a bit stream you begin to
talk about an increase in processing overhead that is several orders of
magnitude greater.
To me the greatest feature of the Internet Protocol Suite is that it
tends to espouse the KISS principle: elegant simplicity. I would be
loath to bog down the protocol with a lot of additional algorithmic
baggage. I can see the point that it would be nice to determine that
someone is using an off-by-1 counter or has a pointer misalignment
problem, but that is not what goes on most of the time. The things you
really want to know in an operational network are link quality,
throughput, packet loss rate, and delays. What we REALLY need is a
protocol that allows us to gather information from the LLPs for
transmission so a network control center (either centralized or
distributed). We may also want to discuss the use of forward error
correction over some links so that you can extract additional
information from the bitstream but we would probably want to do that at
the link layer where it would be sensible to put it in a front-end
processor.
I guess that I am responding to a suggestion that smacks of making
things more complex. What we really need to do is to make things
simpler so that we can make things faster and more reliable. Additional
complexity should be compartmentalized in such a way that it can be
safely ignored :-).
Brian Lloyd, President
Sirius Systems, Inc.
(301) 540-2066
{bellcore, syscad, cp1, irs3, n3dmc}!wb6rqn!brian
Share and enjoy!
-----------[000278][next][prev][last][first]---------------------------------------------------- Date: 23 Mar 88 15:41:21 GMT From: LYNCH@A.ISI.EDU (Dan Lynch) To: comp.protocols.tcp-ip Subject: Re: Conversion to ISO - Number of NCP Hosts
Scott, You missed the chance to say "NCP is still alive in a well..." Yes, NCP is still running in some classified environments where once you get something to run that you (somehow) trust, you leave it alone. As for the larger issue raised by Mark, moving from NCP tp TCP/IP was a large task, but it was ameliorated by the relatively small number of hosts affected. In those days there were probably only a thousand hosts and ten system types to deal with. It took a good amount of coordination to get those hosts to all bring their software "forward" to permit testing before we threw the switch on jan 1, 1983. When we go to make the change to OSI there will be a few million hosts on hundreds of system types out there and there will be no "authority" to tell everyone to switch. So, Mark, you are quite right to be "worried" that a conversion might take longer, be harder, etc. Dan -------
-----------[000279][next][prev][last][first]---------------------------------------------------- Date: 23 Mar 88 17:12:00 GMT From: dcrocker@TWG.COM (Dave Crocker) To: comp.protocols.tcp-ip Subject: on-/off-board protocol processing
As with most technical choices, each alternative has its appropriate uses. The concern about reliability of processing, expressed by Vint, seems not to apply to many of the current "intelligent-board" solutions. Their interface to the host is essentially -- often exactly -- like accessing standard primary memory. So, if you don't trust your primary memory, you probably have more serious architectural fish to fry that where you put your protocol processing. When the interface is more channel-oriented, then reliability becomes factor. That is, if you need a serious protocol, to access your protocols, there is a reasonable chance that the access protocol has bugs, so that you have a step in the networking chain truly exposed to problems, and not detectable by the end-to-end safety mechanism of the transport protocol. On the other hand, There is some interesting mythology about the benefits of moving your protocols to an intelligent board. Having a slow board and a fast host has become a very significant issue, as discussed in some messages, already. My only comment is that when making a choice, you should pay close attention to this issue. Less well-understood are some beliefs that the intelligent board makes the host less complex and relieves the host of substantial overhead. This is true only sometimes. The only factor that is always nicer about intelligent boards is that they do the checksum calculation. On the other hand, They significantly increase the cost of networking hardware. They tend to limit the number of virtual circuits that you can have, due to memory limitations on the board -- a factor that is becoming less of a problem, with 512K and 1M boards. They tend to make multiple-interface configurations a problem, since you then have to add complexity to the host, anyhow, to coordinate the cards. That is, when you move the protocols to the board, then multiple boards become multiple protocol implementations. Coordinating IP routing, UDP and TCP Port number allocation, etc, becomes a real hassle. Worse, customers seem to be inclined to try to do this with implementations from different vendors(!) The idea that intelligent boards reduce interrupt overhead sounds appealing, but often does not prove out. Most incoming packets have their data handed immediately to the receiving application, so that the network interrupt, caused when the packet arrives, still causes the o/s device driver -- yup, you still need such a beast when you have intelligent boards -- to interrupt and you still have the kernel/user context switch. In the case of heavy traffic with small packets, the intelligent board does have an edge. Otherwise, the host-based solution seems to be a much more efficient use of resources. Now, suppose that you have a host that is tending towards saturation and you believe that the extra processing on the board will relieve the problem. At one level of analysis, you would be correct. On the other hand, It is a very short-sighted way to solve a system congestion problem. If your host has a problem at that level, you probably have only bought yourself relief for a short time. In all likelihood, you need to get yourself another host. Given that most machines are in the micro-computer and small-minicomputer range, this expense is not necessarily onerous. Now, about the idea of having a non-networking-oriented access model for the software, such as the view of fitting the network in as a portion of a process's address space, so that the software need not be aware of networking; it simply thinks that it is doing memory transfers, and the underlying hardware/software handle the rest... For general, "distributed processing" types of activities, this will, no doubt, prove very, very useful. In essence, it is the natural evolution down the path that includes the remote procedure call model, since you are integrating networking into increasingly "natural" computing models. This, also, is its problem. While it often is very nice to hide networking issues, it often is necessary to manipulate them directly. Allowing a program to ignore the issues is great. Preventing it from paying attention is terrible.
-----------[000280][next][prev][last][first]---------------------------------------------------- Date: 23 Mar 88 17:18:49 GMT From: Mills@UDEL.EDU To: comp.protocols.tcp-ip Subject: Re: Rumors about the death of the ARPANET
Vint, Your suggestino that, once we get ISDN, we will have ubiquitous 64-kbps digital service tripped me up. While making much the same comment at a recent meeting, carrier representatives were quick to point out that 2B + D (two 64-kbps bearer plus 16 kbps data/control) might well be ubiquitous in the feeder and distribution plants, but it may take much longer for this to occur in the interexchange plant. What may happen for many years is that 64-kbps data may not be ubiquitous outside your local area. In fact, I was told the 16-kbps data/control channel would not be end-to-end for a long time. Why don't we chuck the whole thing and move to B-ISDN and SONET? The general consensus of the carrier's R&D guys is that this would really be the best course. Are you ready for 51.84 Mbps? You gete 125 microseconds to make up your mind. Dave
-----------[000281][next][prev][last][first]---------------------------------------------------- Date: 23 Mar 88 18:56:26 GMT From: cracraft@venera.isi.edu (Stuart Cracraft) To: comp.protocols.tcp-ip Subject: Re: Bridge Communications TCP/IP 20000
In article <1035@uni2.bcm.tmc.edu> sob@bcm.tmc.edu (Stan Barber) writes: >Until recently, I was only marginally satisfied with the Bridge product. Now, >I am quite pleased with it. My only major remaining complaint is the lack >of support for a non-proprietary system logging function. I have suggested >that they make their log information available to the unix syslog function. >I hope they will. > >Stan Barber, Baylor College of Medicine > I'll second the kudo for Bridge. It's a good, solid product. We've had smooth operation from it. Stuart
-----------[000282][next][prev][last][first]---------------------------------------------------- Date: 23 Mar 88 18:59:59 GMT From: lamaster@ames.arpa (Hugh LaMaster) To: comp.protocols.tcp-ip Subject: Re: offloading the protocols
In article <8803160106.AA05728@Pescadero> cheriton@PESCADERO.STANFORD.EDU ("David Cheriton") writes:
>VMTP (RFC 1045) is specifically designed to work well with hardware support
I find it interesting to note that while some people are worrying about
the necessity for offloading protocol processing, Van Jacobson and Mike
Karels have contributed algorithms that together will push 10Mbits/sec
from a CPU with less than 2 MIPS. In any reasonable model of the rates
of computation versus network traffic for any non-gateway host, it isn't
clear that there is any benefit at all to offloading protocol processing.
In fact, recent history seems to confirm that using a general purpose CPU
is a better way to go- easier to install new algorithms and bug fixes. If
more processing power is needed, multiple (general purpose) CPU's seems
to be a much more cost effective way to go. I note that Ardent Computer
seems to be applying the same principle to Graphics processing - instead
of special purpose graphics engines, build the system with multiple CPU's.
-----------[000283][next][prev][last][first]---------------------------------------------------- Date: 23 Mar 88 20:04:00 GMT From: mja@TWG.COM (Mike Anello) To: comp.protocols.tcp-ip Subject: RE: (TLI HELP)
In reply to Gil Widdowson note about TLI HELP: In both socket and tli calls sockaddr_in structure is used to specify an internet address. Since sin_zero element of this structure does not contain any usefull data, only the first three elements (the first 8 bytes) should be passed to buffers used in tli calls. Two constants UDP_BINDADDRLEN in udp.h and TCP_BINDADDRLEN in tcp.h may be used for this purpose. When using t_bind(fd, req, ret) call, you will get back in ret.addr.buf the address assigned by the transport provider. This address is 8 bytes long and represents the first three elements of sockaddr_in structure. In t_bind(fd, NULL, &ret) call, transport provider will assign INADDR_ANY address, and the next available port number to the end point. Mohsen Mortazavi The Wollongong Group
-----------[000284][next][prev][last][first]---------------------------------------------------- Date: 23 Mar 88 21:41:36 GMT From: cpw%sneezy@LANL.GOV (C. Philip Wood) To: comp.protocols.tcp-ip Subject: Re: IP Options and ICMP Messages
To all those who picked up the network exercising stuff from
lambda.lanl.gov.
I gave you a bum [ls]srr.sh. Due to my lack of understanding how
BSD4.3 handles the loose/strict source route option on output, the lsrr
and ssrr scripts are in error. It is not intuitive that BSD UNIX will
strip off the first address in the option to use as a destination,
ignoring the destination requested via an open system call. I have another
script 'sr' which takes the above into account. For example:
sr loose 192.5.16.33 26.3.0.103 26.0.0.90
ships an icmp echo packet to the lanl gateway via gateways 192.5.16.33 and
26.3.0.103. What the heck, here's the script (BTW, the ping is a modified
Muuse ping):
#! /bin/sh
#
# Los Alamos National Laboratory
#
# Copyright, 1988. The Regents of the University of California. This software
# was produced under a U.S. Government contract (W-7405-ENG-36) by Los Alamos
# National Laboratory, which is operated by the University of
# California for the U.S. Department of Energy. The U.S. Government is
# licensed to use, reproduce, and distribute this software. Permission is
# granted to the public to copy and use this software without charge, provided
# that this Notice and any statement of authorship are reproduced on all
# copies. Neither the Government nor the University makes any warranty,
# express or implied, or assumes any liability or responsibility for the use
# of this software.
#
# ICMP ECHO with IP Loose/Strict Source and Record Route
#
# "@(#)sr.sh 1.1 (LANL) 3/23/88"
#
Usage="
Usage: sr {loose,strict} destination(1), destination(2) ... destination(n)
"
NOP=1
SRPOINTER="4"
PING=/usr/local/etc/ping
TYPE=-v
list=""
if [ $# -lt 3 ] ; then
echo "$Usage"
exit 1
fi
if [ $1 = loose ]; then
SR=131
elif [ $1 = strict ]; then
SR=137
else
echo "$Usage"
exit 1
fi
shift
SRLEN=`expr 3 + \( $# \* 4 \)`
GW1=$1 # it dont matter what host you "open a connection to"
for i
do
list="$list -o d$i"
done
$PING $TYPE \
-o d${NOP} \
-o d${SR} \
-o d${SRLEN}.${SRPOINTER} \
$list \
$GW1 12 1
-----------[000285][next][prev][last][first]---------------------------------------------------- Date: 23 Mar 88 22:30:56 GMT From: digi@megalon.UUCP (Klaus Altenburg) To: comp.protocols.tcp-ip,comp.windows.misc Subject: Re: Sun servers
In article <880321184301.105983@HIS-PHOENIX-MULTICS.ARPA> Houde@HIS-PHOENIX-MULTICS.ARPA writes:
>Sorry, but I never specified my address. I wanted to know whether or not I
>could use a standard Unix box as a server for Sun workstations. Please direct
>any responses to Houde at PCO-MULTICS.ARPA.
My company is also interrested in using workstations (like sun's) for CASE.
Here in Germany a reasonable sun-server costs about 35.000 - 40.000 DM.
So here some questions about CASE, workstations, NFS, RFS and
graphic environments on un*x :
- Is it right, that we need only a unix-machine with a working
NFS to run diskless sun-workstations ?
- Are the sun's bootable via the nfs of a non-sun-server ?
- What about workstations based on RFS ?
- is there software to use 386-based systems as workstations for CASE ?
Thanx in advance
-------
Klaus Altenburg, (Keywords: 'C', UN*X)
W.-Germany, 4100 Duisburg 46, An den Siffen 12, +49-2151-404087
Email: digi@megalon.{UUCP,?DE?}; Fido 2:507/777
-----------[000286][next][prev][last][first]---------------------------------------------------- Date: 24 Mar 1988 03:37-EST From: CERF@A.ISI.EDU To: Mills@LOUIE.UDEL.EDU Cc: kwe@BU-CS.BU.EDU, tcp-ip@SRI-NIC.ARPA Subject: Re: Rumors about the death of the ARPANET
Dave, I'm sure not holding my breath for ISDN or B-ISDN, but I would not mind having them both! The local loop is the last part and the one which will take the longest, but for many city-based systems, the pairs are short enough that there are no loading coils, so the switchover requires only CPE and CO equipment. It is probably 1996-2000 before we see 65% business penetration and 35% residential, but your guess is as good as mine. Vint
-----------[000287][next][prev][last][first]---------------------------------------------------- Date: 24 Mar 1988 04:01-EST From: CERF@A.ISI.EDU To: mckenzie@LABS-N.BBN.COM Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: A network you can trust
Alex, "a carefully designed network..." A network? But won't there be thousands of them? Will they ALL be as reliable as you'd like? I'm less persuaded that somehow datagrams are wrong and virtual circuits are right, if that was what you meant in your note, than I am persuaded that we need mechanisms which make apparent memory sharing a reality. Since we need reliability mechanisms to do this SOMEWHERE in the design, I certainly agree that if they aren't in the host, they must be in the off-loaded part. Vint
-----------[000288][next][prev][last][first]---------------------------------------------------- Date: 23 Mar 88 23:20:32 GMT From: jeremy@swatsun.uucp (Jeremy Brest) To: comp.dcom.lans,comp.os.vms,comp.protocols.tcp-ip Subject: Request for information: NFS, Vax/VMS, tcp/ip
I would like to know about people's experiences using NFS under VMS to connect to Suns. How is the interface from the VMS side? Unix? Is mounting supported in both directions? How difficult is it to administer? Please mail replies, unless your response is of general interest. Jeremy Brest Swarthmore College uucp: ...seismo!bpa!swatsun!jeremy CSnet: jeremy@swatsun.swarthmore.edu Arpa: jeremy%swatsun.swarthmore.edu@relay.cs.net
-----------[000289][next][prev][last][first]---------------------------------------------------- Date: 24 Mar 88 02:02:57 GMT From: stev@ftp.COM (Stev Knowles) To: comp.protocols.tcp-ip Subject: Re: SLIP for Ultrix
Posting-Front-End: GNU Emacs 18.47.2 of Thu Aug 13 1987 on ftp (berkeley-unix) **> In article <8802060858.AA08978@ucbvax.Berkeley.EDU> AFDDN.TCP-IP@GUNTER-ADAM.ARPA writes: **>> We have a uVAX running Ultrix that I would "like" to have SLIP on. ** **> I took a look at an Ultrix system at one time and kind of came to the **> conclusion that trying to do it yourself to a binary Ultrix **> distribution was no fun. ** **Trying to do anything to a binary distribution is no fun. I hold the **view that if you don't have source, you shouldn't even consider using **it. ** der Mouse ** ** uucp: mouse@mcgill-vision.uucp ** arpa: mouse@larry.mcrcim.mcgill.edu ** ftp to ftp.com (128.127.25.100), user = anonymous, password = your name, and get the file BUGLIX.SLIP.TAR. this is a distribution of slip for a binary only ULTRIX 2.0 site. there is a readme file there to explain how it should be done. if you have not rebuilt your kernel before, here is not the place to start. if you have, this will get you running. if you have problems with it, you can e-mail me questions. (i dont get paid to support *this* code). stev knowles ftp software stev@ftp.com
-----------[000290][next][prev][last][first]---------------------------------------------------- Date: 24 Mar 88 04:36:06 GMT From: Mills@UDEL.EDU To: comp.protocols.tcp-ip Subject: Some Internet gateway performance data
Folks, You might be interested in the following summary of data on NSFNET Backbone Fuzzball performance, as well as a comparison with the ARPANET/MILNET gateways, which operate in a similar state of massive traffic insult. These data update those reported in the SIGCOMM 87 paper and include the period since the source-quench policy described previously (and in a paper just submitted) was implemented. In July 1987 after the Fuzzball selective-preemption policy was installed, but before the source-quench policy was implemented, the throughput per trunk ranged from 0.3 to 4.0 packets per second, with a mean of 2.0. At that time the total trunk throughput was 31 pps with drop rate due all causes of .09 percent. In March 1988, several months after quench was installed, the trunk throughput ranges from 2.6 to 9.2 packets per second, with a mean of 4.7. At this time the total trunk throughput is 71 pps with drop rate 0.48 percent and with 0.27 percent of all trunk packets resulting in a quench. The following table shows the performance of the NSFNET Backbone Fuzzballs for periods ending on 21 March. These numbers include Ethernets as well as all 56-kbps trunks. Node Mpkt UpHr PPS Drop Quench ---------------------------------------------- 1 3.49 100 9.75 0.17 0.04 2 18.48 260 19.72 0.38 0.39 3 6.33 102 17.33 0.16 0.17 4 15.08 262 15.99 0.31 0.45 5 19.36 266 20.20 0.85 0.18 6 2.97 48 17.35 0.17 0.14 7 7.02 262 7.44 0.71 0.04 ---------------------------------------------- Total 72.74 1299 15.55 0.34 0.18 The "Mpkt" column shows the aggregate throughput in megapackets for all output queues, including serial lines and Ethernet. The "UpHr" column shows the aggregation interval in hours. The "PPS" column down through the "Total" row shows the resulting throughput, which is the "Mpkt" column divided by the "UpHr" column adjusted to the proper units. The "Drop" and "Quench" columns show the percentage of packets dropped and quenched respectively. The value shown in the "Total" row for these columns is the average of the column itself. The existing NSFNET Backbone clearly meets the performance objective of less than one percent drop rate. For comparison the following table shows the performance of the ARPANET/MILNET gateways for the week ending 21 March. So far as can be determined, each gateway is connected to two 56-kbps data paths. ID Mpkt UpHr PPS Drop ------------------------------------- 1 4.83 144 9.32 7.26 2 6.15 144 11.86 8.18 3 7.06 146 13.48 7.40 4 7.03 139 14.08 12.87 5 3.14 145 6.00 0.83 6 3.75 109 9.54 3.23 7 5.07 146 9.66 2.85 8 2.76 129 5.95 3.65 ------------------------------------- Total 39.79 1101 10.04 5.78 As evident from these figures, the NSFNET Backbone Fuzzballs carry a throughput over fifty percent greater per node than the ARPANET/MILNET gateways with a drop rate of over ninety percent less. Note that this comparison may not be fair in two ways: first, the ARPANET/MILNET gateways are connected to networks, not trunks, which can have large dispersive delays; second, the NSFNET Backbone Fuzzballs are connected to Ethernets, which provide no insulation against unruly traffic generators. From measurements made last July and reported in the SIGCOMM paper last year, the selective-preemption policy made a whale of a difference. The case for the source-quench policy installed recently is less clear, although there is recent evidence that it is in fact effective for those hosts that respond to quench messages. However, even if the crafted policies and Fuzzball implementations may be suboptimal and change next Monday, the data above should be convincing beyond doubt that fairness policies and queue disciplines similar to these will be necessary for future generations of connectionless packet switches and gateways. Dave
-----------[000291][next][prev][last][first]---------------------------------------------------- Date: 24 Mar 88 07:07:53 GMT From: karn@thumper.bellcore.com (Phil R. Karn) To: comp.protocols.tcp-ip Subject: Re: Checksums (was Re: Ping, checksum algorithm?)
Thanks for an excellent tutorial on checksumming. Some additional notes: The Internet checksum algorithm has an interesting property that is very useful when working on little-endian machines: the sum of the byte-swapped words is equal to the byte-swapped sum of the words. In other words, there is no need to byteswap each word on a little-endian machine before summing it; you can sum the words in machine order and then byteswap the result. If you write an "assist" routine in assembler you can exploit the "add with carry" instruction found in many machines. E.g., on the 808x family, you can accumulate a sum as follows: doit: lodsw adc dx,ax loop doit (once you've set everything up, of course). This can speed up checksumming enormously on 16-bit machines like the PC since the long (32-bit) arithmetic you would normally use to accumulate the carries is much slower. The actual code I use goes further, in that I unwound the loop and used "Duff's Device" to handle blocks that are not integral multiples of the loop length. Phil
-----------[000292][next][prev][last][first]---------------------------------------------------- Date: 24 Mar 88 07:12:00 GMT From: karn@thumper.bellcore.com (Phil R. Karn) To: comp.protocols.tcp-ip Subject: Re: offloading the protocols
I would like to draw extra attention to the fact that Van and Mike were able to do what they did WITHOUT cheating, i.e., turning off TCP checksums. Somebody should tell Sun that this puts the final nail in the coffin of their argument that NFS can't tolerate UDP checksums for "performance" reasons... :-) Phil
-----------[000293][next][prev][last][first]---------------------------------------------------- Date: 24 Mar 88 08:37:00 GMT From: CERF@A.ISI.EDU To: comp.protocols.tcp-ip Subject: Re: Rumors about the death of the ARPANET
Dave, I'm sure not holding my breath for ISDN or B-ISDN, but I would not mind having them both! The local loop is the last part and the one which will take the longest, but for many city-based systems, the pairs are short enough that there are no loading coils, so the switchover requires only CPE and CO equipment. It is probably 1996-2000 before we see 65% business penetration and 35% residential, but your guess is as good as mine. Vint
-----------[000294][next][prev][last][first]---------------------------------------------------- Date: 24 Mar 88 08:49:32 GMT From: henk@hcsrnd.UUCP (Henk Willems) To: comp.protocols.tcp-ip Subject: Tandems connected to SUN systems
Question: We want to connect SUN systems to a TANDEM machine, preferably using ethernet. Is there somebody that has experiences with such a configuration ? The SUN must be used as a colour-graphics workstation and for terminal emulation to the TANDEM system. Please reply by Email. Henk Willems mcvax!hcsrnd!henk@uunet.UU.NET HCS Industrial Automation BV. Landdrostlaan 51 PO Box 20020 7302 HA Apeldoorn. The Netherlands
-----------[000295][next][prev][last][first]---------------------------------------------------- Date: 24 Mar 88 09:01:00 GMT From: CERF@A.ISI.EDU To: comp.protocols.tcp-ip Subject: Re: A network you can trust
Alex, "a carefully designed network..." A network? But won't there be thousands of them? Will they ALL be as reliable as you'd like? I'm less persuaded that somehow datagrams are wrong and virtual circuits are right, if that was what you meant in your note, than I am persuaded that we need mechanisms which make apparent memory sharing a reality. Since we need reliability mechanisms to do this SOMEWHERE in the design, I certainly agree that if they aren't in the host, they must be in the off-loaded part. Vint
-----------[000296][next][prev][last][first]---------------------------------------------------- Date: 24 Mar 88 13:26:39 GMT From: johnl@n3dmc.UUCP (John Limpert) To: comp.protocols.tcp-ip Subject: Re: precedence
>I note in the RFC's that TCP and IP have three bits reserved >for precedence, but UDP does not. I have a number of questions >about this. The obvious place to start: is precedence really implemented? I don't know about the arpanet, but many other DOD voice/data networks implement precedence. >I can see many obvious fairness problems. One user could >effectively shut out other users until their TCP connections >start timing out. If they are allowed to, every one will >want to send high precedence packets. How are these problems >resolved? Precedence is supposed to be unfair :-). The idea is to reduce delays for high priority traffic, seizing resources from lower priority traffic if necessary. You need to have prior authorization for the use of the higher precedence levels. You shouldn't be able to use precedence levels higher than ROUTINE without authority and need. The requirement for authorization can be enforced in a switch. The switch can check a table of maximum user precedence levels. Just because you mark something with 'FLASH OVERRIDE' doesn't mean the switch will believe you. In a circuit switched environment, the switch will preempt (drop) lower priority connections if it runs out of resources. I would expect packet switches to sort queues by precedence. By the way, this is one use of the 4 extra/missing DTMF (touch tone TM) buttons on your telephone. Some phones have 16 buttons, with 4 buttons assigned to precedence. John Limpert johnl@n3dmc.UUCP bellcore!wb6rqn!n3dmc!johnl
-----------[000297][next][prev][last][first]---------------------------------------------------- Date: Thu, 24 Mar 88 19:07:39 EST From: Frank Kastenholz <KASTEN@MITVMA.MIT.EDU> To: TCP/IP List <TCP-IP@SRI-NIC.ARPA> Subject: ReChoosing gateways
A question.... Suppose a host is connected to a network which has two gateways on it (G1 and G2) both of which have valid paths to some destination network (the "cost" of those paths is irrelevant). The host is using G1 to communicate with a host on the destination network and G1 dies with no warning (e.g. the power supply blows up) so that G1 can not send any kind of "I'm Dying" message (This death is NOT an overload due to too many packets that can be fixed with a ICMP Source Quench or Redirect). Are there any rules/guidelines/standards/... as to how the host can "find" G2? Thanks In Advance Frank Kastenholz Atex Inc.
-----------[000298][next][prev][last][first]---------------------------------------------------- Date: 24 Mar 88 15:00:06 GMT From: cpw%sneezy@LANL.GOV (C. Philip Wood) To: comp.protocols.tcp-ip Subject: Re: Checksums
> What we REALLY need is a ... What we could have used was complience, by the many "rush to networking" Vendor's out there, with the Internet IP / ICMP protocol suite. Using the IP options, and various ICMP functions, it could be possible to figure out: > "...link quality, throughput, packet loss rate, and delays..." One can get a glimmer about the above now, cause 'some' gateways and hosts provide 'some' of the features, that work 'some' of the time. So, before you/we go off an' invent another protocol which any number of universities will jump on as a weekend project, and then any number of vendors will grab at sometime in its life cycle and purvey to the public as there own with out support, ... FIX IP AND ICMP! Cornett Philip Wood cpw@lanl.gov Los Alamos National Laboratory
-----------[000299][next][prev][last][first]---------------------------------------------------- Date: 24 Mar 88 15:00:41 GMT From: dab@ALLSPICE.LCS.MIT.EDU To: comp.protocols.tcp-ip Subject: Re: ARP hardware field
Does this make Proteon non-standard? I was quoting from rfc1010,
and I must admit some confusion over the status of rfc's, I know that rfc
stands for Request For Comment, but everyone seems to treat them as
standards, so what are they? Standards or Drafts of proposed standards,
and if they are drafts what are the final standards (if any exist) called?
The confusion comes from the fact that Assigned Numbers (RFC1010) and the
ARP RFC (RFC826) say slightly differing things. Assigned numbers says that
protocol types are taken from the list of ethernet protocol types (as you
quoted). The ARP RFC says (last paragraph on page 5):
"Generalization: The ar$hrd and the ar$hln fields allow this protocol
and packet format to be used for non-10Mbit Ethernets. For the
10Mbit Ethernet <ar$hrd, ar$hln> takes on the value <1, 6>. For
other hardware networks, the ar$pro field may no longer
correspond to the Ethernet type field, but it should be
associated with the protocol whose address resolution is being
sought."
The people who implemented ARP for the ProNet-10 (CMU I believe)
implemented it from the ARP RFC instead of from Assigned Numbers. They
therefore used protocol numbers from the protocol type field used on the
ProNet-10.
In a recent conversation with Postel and Reynolds, I was informed that
Assigned Numbers is now correct and all future implementations should use
Ethernet protocol types.
David Bridgham
-----------[000300][next][prev][last][first]---------------------------------------------------- Date: 24 Mar 88 16:47:01 GMT From: wayne@petruchio.UUCP (Wayne Hathaway) To: comp.protocols.tcp-ip Subject: Re: on-/off-board protocol processing
One problem with offloading protocols which has not yet been mentioned
has to do with the "locked-up" nature of commercial on-board protocol
implementations. A specific example from a place I used to be
associated with: They used intelligent Ethernet cards (brand name
irrelevant) quite successfully -- until they extended their Ethernet
to the East Coast with a satellite link. Needless to say, the
on-board Ethernet software was hardly tuned to the extra delay, and
the throughput was abysmal. But since the on-board software was
proprietary there was nothing the host administrator could do, and
while the card manufacturer was sympathetic, tuning his software for
such a "strange" environment was very low priority. The solution?
The satellite link was replaced with a slower (bandwidth) but faster
(throughput) land line!
Of course, this is nothing unique to network protocols; any
"intelligent controller" could have the same problem. In the case of
something like a disk controller, however, one is considerably less
likely to suddenly add some 40,000 miles to the length of the cable!
Wayne Hathaway ultra!wayne@Ames.ARPA
Ultra Network Technologies
2140 Bering drive with a domain server:
San Jose, CA 95131 wayne@Ultra.COM
408-922-0100
-----------[000301][next][prev][last][first]---------------------------------------------------- Date: 24 Mar 88 16:47:17 GMT From: jas@MONK.PROTEON.COM (John A. Shriver) To: comp.protocols.tcp-ip Subject: ARP protocol address space field on ProNET
Well, being as someone is calling my implmentation of ARP non-standard, I will speak to the issue of the Protocol Address Space in ARP for ProNET. The first implementation of ARP on ProNET was done at Carnegie-Mellon University, for the IP protocols. (IP normally does not use ARP on ProNET, but CMU's routing scheme at the time was based on ARP subnet routing, so they needed ARP.) At that time, the table of ARP Hardware Address Space types were not in the current version of Assigned Numbers, since the only value was 1 (Ethernet), which is specified in ARP. As we read RFC 826 (ARP), it only claimed that the Protocol Address Space field was chosen from the field of Ethernet types if the Hardware Address Space was Ethernet. We decided (by default, really) that it was obvious that we should use the space of ProNET types for ProNET. Aside from reasons of symmetry, the more important reason is that there might well be protocols on ProNET which do not have Ethernet types, but do need to use ARP. Indeed, this is currently the case for some protocols on ProNET. The versions of assigned numbers that stated that Protocol Address Space would always be Ethernet types came long after our ARPs were in the field. I have noted this discrepancy to the NIC before. Currently, three protocols have been used with ARP on ProNET: 1. IP (only at CMU, between 32 bit IP addresses and 8 nit node addresses) 14. XNS (between 48 bit XNS host addresses and 8 bit node addresses) 20. DECnet (between 48 bit DECnet/Ethernet addresses and 8 bit node addresses) Yes, writing a multi-hardware multi-protocol implementation of ARP is interesting, since there are all these variable-sized peices, and different Protocol Address spaces. Oh yes, the "standardness" level of an RFC depends on how and whether it is cited in the current version of the "Official Internet Protocols" RFC. The current version of this RFC can be considered the top of the tree. Also, there will always be interpretation issues with standards. ProNET ARP is just one example.
-----------[000302][next][prev][last][first]---------------------------------------------------- Date: 24 Mar 88 16:56:13 GMT From: lars@ACC-SB-UNIX.ARPA (Lars Poulsen) To: comp.protocols.tcp-ip Subject: Re: Wollongong TCP/IP for VMS and Cisco AGS routers interaction
To: enger@bluto.scc.com, info-vax@kl.sri.com, jerry@twg.com, tcp-ip@sri-nic.arpa, yehavi%hujivms.bitnet@cunyvm.cuny.edu [Re-sent, due to typo in TCP-IP address] Jerry Scott of the Wollongong Group forwarded me a copy of an INFO-VAX message from Yehavi Bourvine asking about running TCP/IP over commercial X.25 nets using WIN/TCP and ACC's ACP6250. The driver for the ACP6250 (which Wollongong provides for WIN/TCP and which ACC provides for 4.xBSD and Ultrix-32) allows the use of a commercial X.25 network as the subnet carrier vehicle. Two flags control the differences between this application and the "DDN Standard Mode" application: - the "service" flag is set to "basic" to make the X.25 connection be host-to-host rather than host-to-PSN as in the DDN. This produces call requests packets with protocol type 'CC'hex (in the user call data field) and no "standard mode" facility request. - the "PDN mode" flag is set to obtain X.25 addresses by table lookup rather than by algorithm from the IP address. The "basic PDN" configuration should be interoperable with the CSNET driver for the old INcard, but for mostly political reasons, this has not to my knowledge been tested. / Lars Poulsen ACC Customer Service
-----------[000303][next][prev][last][first]---------------------------------------------------- Date: 24 Mar 88 17:01:05 GMT From: matthews@vax1.acs.udel.EDU (John,Iii Matthews) To: comp.protocols.tcp-ip Subject: Makefile for KA9Q BSD?
Does anyone out there know where I can get a makefile that will
successfully build the BSD version of KA9Q. The makefile in the
ka9q archives on louie.udel.edu says to change a few CFLAGS defines
but there aren't even any references to any of the BSD specific modules
that appear in the archive.
--
John Matthews
4801 Plum Run Court ARPA: matthews@udel.edu
Wilmington, DE 19808 BITNET: FFO18429 AT UDACSVM
(302) 454-1735 CSNET: matthews%udel.edu@relay.cs.net
UUCP: ... !uunet!udel.edu!matthews
-----------[000304][next][prev][last][first]---------------------------------------------------- Date: 24 Mar 88 20:46:00 GMT From: DCP@QUABBIN.SCRC.Symbolics.COM (David C. Plummer) To: comp.protocols.tcp-ip Subject: ARP protocol address space field on ProNET
Date: Thu, 24 Mar 88 11:47:17 EST
From: jas@monk.proteon.com (John A. Shriver)
Being the author of ARP...
...
As we read RFC 826 (ARP), it only claimed that the Protocol Address
Space field was chosen from the field of Ethernet types if the
Hardware Address Space was Ethernet. We decided (by default, really)
that it was obvious that we should use the space of ProNET types for
ProNET. Aside from reasons of symmetry, the more important reason is
that there might well be protocols on ProNET which do not have
Ethernet types, but do need to use ARP. Indeed, this is currently the
case for some protocols on ProNET.
... this was certainly the intention. When I heard the ProNet did not
use Ethernet types for their protocol dispatching field, I found that
"unfortunate." The reasons they chose to be different may be good or
bad; I'm not concerned about that here.
The versions of assigned numbers that stated that Protocol Address
Space would always be Ethernet types came long after our ARPs were in
the field. I have noted this discrepancy to the NIC before.
The NIC is wrong, both by the intent and by the literal reading of the
RFC. The fact that some other hardware types (e.g., packet radio,
certain serial links, etc) also use the 10MBit Ethernet hardware type
for ar$pro is a perfectly reasonable design convenience, but that's
where it stops: it is a convenience.
Summary: The NIC overstepped its authority by asserting that ar$pro is
always taken from the set of ethernet types. Proteon did a reasonable
and valid thing in defining ar$pro to come from a different and rational
set of types.
-----------[000305][next][prev][last][first]---------------------------------------------------- Date: 25 Mar 88 00:00:54 GMT From: nelson@sun.soe.clarkson.edu (Russ Nelson) To: comp.protocols.tcp-ip Subject: SLIP working group?
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?
-----------[000306][next][prev][last][first]---------------------------------------------------- Date: 25 Mar 88 00:07:39 GMT From: KASTEN@MITVMA.MIT.EDU (Frank Kastenholz) To: comp.protocols.tcp-ip Subject: ReChoosing gateways
A question.... Suppose a host is connected to a network which has two gateways on it (G1 and G2) both of which have valid paths to some destination network (the "cost" of those paths is irrelevant). The host is using G1 to communicate with a host on the destination network and G1 dies with no warning (e.g. the power supply blows up) so that G1 can not send any kind of "I'm Dying" message (This death is NOT an overload due to too many packets that can be fixed with a ICMP Source Quench or Redirect). Are there any rules/guidelines/standards/... as to how the host can "find" G2? Thanks In Advance Frank Kastenholz Atex Inc.
-----------[000307][next][prev][last][first]---------------------------------------------------- Date: 25 Mar 88 00:55:23 GMT From: budden@tetra.NOSC.MIL (Ray A. Buddenberg) To: comp.protocols.tcp-ip Subject: Re: Rumors about the death of the ARPANET
Maybe I'm missing something, but: - we are getting 10-20 km between repeaters on fiber links these days, perhaps somewhat more with high clarity and laser transmitters. - FDDI rings accomodate 512 nodes before we have to split the net. - FDDI starts life at 100 Mbits. Looks to me that 500 nodes times 20 km multiplies out to a pretty decent regional backbone -- internet a half dozen of these and you've got the country covered. Why are we fiddling around with ISDN? Rex Buddenberg
-----------[000308][next][prev][last][first]---------------------------------------------------- Date: Fri, 25 Mar 88 09:41:19 -0500 From: Mike Brescia <brescia@PARK-STREET.BBN.COM> To: Frank Kastenholz <KASTEN@MITVMA.MIT.EDU> Cc: TCP/IP List <TCP-IP@SRI-NIC.ARPA> Subject: Re: ReChoosing gateways
host is using G1 to communicate with a host on the destination
...
Are there any rules/guidelines/standards/... as to how the host can "find"
G2?
Please don't take this as an oversimplification. The general rule should be
'find G2 the same way you found G1'. In the current state of affairs, both G1
and G2 are listed in some gateway initialization file. If you are using G1
and are dissatisfied with the service, drop it from consideration and try all
other gateways you know about.
Perhaps unix wizards can talk about multiple default gateways.
On a network which has logical addressing (ethernet, arpanet) you could
arrange to have an address which will 'always' be a gateway. On the arpanet,
the gateway joins the group when it is up, and is removed by the PSN when it
is down. On an ethernet, you can use IP multicast, or be a bit kluge-y and
have G2 detect that G1 is down, and begin spoofing for G1 (answering G1 ARP
as well as its own). (WARNING: This is all "blue sky". I have NOT tried it.)
Mike
-----------[000309][next][prev][last][first]---------------------------------------------------- Date: 25 Mar 88 01:47:59 GMT From: brian@wb6rqn.UUCP (Brian Lloyd) To: comp.protocols.tcp-ip Subject: Re: A network you can trust
Alex,
I think that I will opt for datagrams too. The only part of the network
that you can really trust is that which you control. It is the only
part of the network that exists to serve YOUR needs. For this reason I
am going to want some sort of reliable transport service sitting on top
of the network. Sure the network may seem reliable but can you always
be sure? At least a reliable transport service can keep trying even
though the underlying virtual circuit network has done a reset on your
logical channel.
Brian Lloyd, President
Sirius Systems, Inc.
(301) 540-2066
{bellcore, syscad, cp1, irs3, n3dmc}!wb6rqn!brian
Share and enjoy!
-----------[000310][next][prev][last][first]---------------------------------------------------- Date: 25 Mar 88 01:57:09 GMT From: brian@wb6rqn.UUCP (Brian Lloyd) To: comp.protocols.tcp-ip Subject: What we REALLY need ...
>So, before you/we go off an' invent another protocol which any number of
>universities will jump on as a weekend project ...
No, I was not suggesting that we invent a new protocol. I believe in
the KISS principle that espouses simplicity over complexity. If it can
be done with IP and ICMP (I don't really see how since IP and ICMP were
written to be totally independent of the underlying subnet) sobeit.
Next choice would be to use something that exists. Better to fight the
enemy you know than the enemy you don't. Last on the list would be to
roll a new protocol.
Brian Lloyd, President
Sirius Systems, Inc.
(301) 540-2066
{bellcore, syscad, cp1, irs3, n3dmc}!wb6rqn!brian
Share and enjoy!
-----------[000311][next][prev][last][first]---------------------------------------------------- Date: 25 Mar 88 10:45:00 PST From: <art@acc.arpa> To: "tcp-ip" <tcp-ip@sri-nic.arpa> Subject: RE: TCP/IP Checksums
In <1080@maccs.UUCP> Gordan Palameta provides a discussion of TCP/IP checksums:
>Of course, the value of the carry bit is not accessible from a
>higher-level language like C. A perfectly equivalent method (very
>suitable if your machine has 32-bit integers) is:
>
> INT32 sum32, word32
> INT16 *word; /* pointer to start of 16-bit words to be summed */
>
> sum32 = 0;
>
> for (i = 0; i < `number of 16-bit words to be summed'; i++)
> {
> `byte-swap word[i], if necessary (see comments on byte-order)'
> `copy word[i] to word32, zero-extended (NOT sign-extended)'
> /* (e.g., 0xedcb -> 0x0000edcb, not 0xffffedcb) */
> sum32 += word32;
> }
>
> sum = `add the two 16-bit halves of sum32 to each other'
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
THIS ADDITION CAN RESULT IN YET ANOTHER CARRY THAT MUST BE ADDED BACK IN IF
IT OCCURS! This simplest way to do this is to make sure that the upper 16
bits of the accumulator are zeroed before adding carries back in and performing
the carry addition twice. (Another carry cannot happen with the second addition)
>This works, since the carry bit values for 16-bit addition of the least
>significant 16-bit word accumulate in the most significant 16-bit word
>of the 32-bit sum. (This is probably what you would use on a 68020 --
>and you can forget about byte-swapping on a 68020 as well).
It also helps that addition is commutative :-).
>After calculating a one's complement sum, you have to take its one's
>complement (invert all the bits) to get the actual checksum used in IP,
>TCP, and UDP (but note that UDP treats a calculated checksum of 0x0000
>as a special case -- see the RFC).
Art Berggreen
art@acc.arpa
------
-----------[000312][next][prev][last][first]---------------------------------------------------- Date: 25 Mar 88 09:54:17 GMT From: dannyb@kulcs.uucp (Danny Backx) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.ibm.pc.rt Subject: socket library on top of TLI wanted
A few months ago, there was a discussion in comp.protocols.tcp-ip.ibmpc about
TLI versus Berkeley sockets.
Somebody said that there is a library for offering a socket interface, provided
you have TLI.
We now have TLI as a part of AIX on IBM PC RT's, and we would like to keep
using sockets - as we do on all of the other systems (4.3 and SunOS 3.4).
Can anybody tell me where to get this library (or maybe mail it to me) ?
Thanks,
Danny
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Danny Backx | mail: Katholieke Universiteit Leuven
Tel: +32 16 200656 x 3058 | Dept. Computer Science
E-mail: dannyb@kulcs.UUCP | Celestijnenlaan 200 A
... mcvax!prlb2!kulcs!dannyb | B-3030 Leuven
dannyb@blekul60.BITNET | Belgium
-----------[000313][next][prev][last][first]---------------------------------------------------- Date: 25 Mar 88 12:52:27 GMT From: tsuchiya@GATEWAY.MITRE.ORG (Paul Tsuchiya) To: comp.protocols.tcp-ip Subject: Re: ReChoosing gateways
We once did a thing where we picked an Internet Address that all gateways would respond to. When a host did an ARP, several gateways would respond, and the host would pick one of them (I imagine the last, but it rather depends on the host). If the chosen gateway died, then subsequent ARPs would find a living one. In ISO (by the way), we have a host to gateway configuration protocol (called ES-IS) that has a LAN multicast addresses that means "all gateways" or "all hosts". When a hosts hears "all gateways", then he gets the packet, and records the internet level address (Network Entity Title, in ISOese). _________________________________________________________________ Paul F. Tsuchiya The MITRE Corp. tsuchiya@gateway.mitre.org 7525 Colshire Dr. 703-883-7352 McLean, VA 22102 USA _________________________________________________________________
-----------[000314][next][prev][last][first]---------------------------------------------------- Date: 25 Mar 88 13:08:29 GMT From: tsuchiya@GATEWAY.MITRE.ORG (Paul Tsuchiya) To: comp.protocols.tcp-ip Subject: Re: A network you can trust
There are really two issues with regards to this VC/datagram discussion. One is what the network does, and the other is what the host does. It seems to me obvious that the host wants to protect itself and provide itself good service regardless of what the network claims to provide, and so should run a strong transport like TCP. It is silly to argue that one of the virtues of VCs is that it requires less work on the part of the host. Ignoring hosts, however, and just considering the network layer, the discussion is still interesting. I like datagram in the sense that the network isn't obligated to do sequence and guarenteed delivery and so on, and can squash packets if it has to. However, I like some of the "set up" notions of VC. These days, there are many things that one might want to "set up" (or more appropriately, cache) in the gateways along the path. These include routing information, address information (like a Landmark Address, for instance), VISA information. All of these things can be done without destroying the "datagram" aspect of the network. Some people are thinking of more sophisticated network "setup", like rate request and assignment. This is not datagram in the sense that the network tells you roughly how fast you can go, but it is not VC in that the network is happy to squash packets if it needs to. _________________________________________________________________ Paul F. Tsuchiya The MITRE Corp. tsuchiya@gateway.mitre.org 7525 Colshire Dr. 703-883-7352 McLean, VA 22102 USA _________________________________________________________________
-----------[000315][next][prev][last][first]---------------------------------------------------- Date: 25 Mar 88 16:13:38 GMT From: backman@interlan.UUCP (Larry Backman) To: comp.protocols.tcp-ip Subject: TCP/UDP Checksum algorithms
[] There was a discussion a while back about clever checksum algorithms. Does anyone have references, examples, whatnot, for some speedy algorithms. Please reply directly to me rather than rehashing the discussion over the network again. Larry Backman Micom - Interlan backman@interlan
-----------[000316][next][prev][last][first]---------------------------------------------------- Date: 25 Mar 88 16:29:00 GMT From: DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer) To: comp.protocols.tcp-ip Subject: Re: ReChoosing gateways
Date: Fri, 25 Mar 88 07:52:27 EST
From: tsuchiya@gateway.mitre.org (Paul Tsuchiya)
We once did a thing where we picked an Internet Address that all gateways
would respond to. When a host did an ARP, several gateways would respond,
and the host would pick one of them (I imagine the last, but it rather
depends on the host). If the chosen gateway died, then subsequent ARPs
would find a living one.
Why would you need to ARP again? You already have the protocol address
to hardware address translation, so why do you need to get it again?
Maybe you have a very, VERY small ARP cache timeout?
This doesn't answer the poser's question though, since I think the poser
wanted to know how to rechoose at the IP level, not at the link level.
-----------[000317][next][prev][last][first]---------------------------------------------------- Date: 25 Mar 88 17:49:32 GMT From: dab@oliver.CRAY.COM (Dave Borman) To: comp.protocols.tcp-ip Subject: Re: Checksums (was Re: Ping, checksum algorithm?)
I feel compelled to respond to the recent explanation of the TCP/IP checksum algorithm, because the explanation makes things harder than they really are. So how do you calculate the checksum? You add up all the 16 bit words over the data that you want to checksum, and add all the carrys back into the sum. When you are all done, you take the one's complement of the final sum. For outgoing packets, put 0 into the checksum field, calculate the checksum, and fill it in. For incoming packets, the checksum will calculate to 0 if the data is correct. That is it. Sweet and simple. What about machine byte order? You can ignore it. It doesn't matter. That's one of the great thing about this algorithm. Look at it this way: as you pull the words from memory, they get byte swapped into the register. So, all of our sum is done byte swapped. But when you write the sum back out to memory, it swaps it back for you. Another way of looking at the checksum: it sums up all the even bytes into one sum, and all the odd bytes into another. All of the carries from the even byte sum get added into the odd byte sum, and all of the carries from the odd byte sum get added into the even byte sum. The following table explicitly shows that the calculated checksum would be calculated the same by bytes, Big-endian, and Little-endian byte order, and in 16 bits or 32 bits at a time. Big-endian Little-endian byte 0/1 0x00 0x01 0x0001 0x0100 byte 2/3 0xf2 0x03 0xf203 0x03f2 byte 4/5 0xf4 0xf5 0xf4f5 0xf5f4 byte 6/7 0xf6 0xf7 0xf6f7 0xf7f6 ----- ----- ------- ------- sum1: 0x2dc 0x1f0 0x2ddf0 0x1F2DC 0xdc 0xf0 0xddf0 0xf2dc carrys: 1 2 2 1 ---- ---- ------ ------ sum2: 0xdd 0xf2 0xddf2 0xf2dd 1's comp: 0x22 0x0d 0x220d 0x0d22 cksum back to memory: 0x22 0x0d 0x22 0x0d 0x22 0x0d For doing it 32 bits at a time, (like 4.3BSD does): byte 0/1/2/3 0x0001f203 0x010003f2 byte 4/5/6/7 0xf4f5f6f7 0xf5f4f7f6 ---------- ---------- sum1: 0xf4f7e8fa 0xf6f4fbe8 top half: 0xf4f7 0xf6f4 bottom half: 0xe8fa 0xfbe8 ------- ------- sum2: 0x1ddf1 0x1f2dc 0xddf1 0xf2dc carrys: 1 1 ------ ------ sum3: 0xddf2 0xf2dd 1's comp: 0x220d 0x0d22 back to memory: 0x22 0x0d 0x22 0x0d Since I'm explaining all this, let me explain a tricky point for when your data is not contiguous. Assume your data that you are checksuming is in two pieces, and further that the the first chunk ends on an odd byte boundry, and the second chunk begins on an even byte boundry. You can calculate this in two pieces: one checksum for each piece of data. Then, you swap the bytes of the second piece, and add it into the first piece to get your final sum. (Or swap bytes on the first piece, do the sum, and swap the bytes again. Depending on the implementation, one or the other may be faster...) This gives you the speed of doing word aligned operations, and you only need to add a minimal amount of processing. (note: when the byte count is odd, you fill in the missing part with zeros) 0/1 0x00 0x01 0x0001 2/ 0xf2 0xf200 ------ sum1: 0xf201 4/5 0x03 0xf4 0x03f4 6/7 0xf5 0xf6 0xf5f6 8/ 0xf7 0xf700 ------- sum2: 0x1f0ea sum2: 0xf0ea carry: 1 ------ sum3: 0xf0eb sum1: 0xf201 sum3 byte swapped: 0xebf0 ------- sum4: 0x1ddf1 sum4: 0xddf1 carry: 1 sum5: 0xddf2 This got a little longer than I expected, but hopefully this should clear things up some more. -Dave Borman CRAY Research, Inc.
-----------[000318][next][prev][last][first]---------------------------------------------------- Date: 25 Mar 88 18:24:21 GMT From: karn@thumper.bellcore.com (Phil R. Karn) To: comp.protocols.tcp-ip Subject: Re: ARP protocol address space field on ProNET
It was pretty apparent to me when I did the ARP-on-AX.25 (amateur packet radio link protocol) implementation that I should use the universe of AX.25 packet types in the ARP protocol field. (The only one that is relevant is CC hex, which means "DoD IP"). Phil
-----------[000319][next][prev][last][first]---------------------------------------------------- Date: 25 Mar 88 18:45:00 GMT From: art@ACC.ARPA To: comp.protocols.tcp-ip Subject: RE: TCP/IP Checksums
In <1080@maccs.UUCP> Gordan Palameta provides a discussion of TCP/IP checksums:
>Of course, the value of the carry bit is not accessible from a
>higher-level language like C. A perfectly equivalent method (very
>suitable if your machine has 32-bit integers) is:
>
> INT32 sum32, word32
> INT16 *word; /* pointer to start of 16-bit words to be summed */
>
> sum32 = 0;
>
> for (i = 0; i < `number of 16-bit words to be summed'; i++)
> {
> `byte-swap word[i], if necessary (see comments on byte-order)'
> `copy word[i] to word32, zero-extended (NOT sign-extended)'
> /* (e.g., 0xedcb -> 0x0000edcb, not 0xffffedcb) */
> sum32 += word32;
> }
>
> sum = `add the two 16-bit halves of sum32 to each other'
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
THIS ADDITION CAN RESULT IN YET ANOTHER CARRY THAT MUST BE ADDED BACK IN IF
IT OCCURS! This simplest way to do this is to make sure that the upper 16
bits of the accumulator are zeroed before adding carries back in and performing
the carry addition twice. (Another carry cannot happen with the second addition)
>This works, since the carry bit values for 16-bit addition of the least
>significant 16-bit word accumulate in the most significant 16-bit word
>of the 32-bit sum. (This is probably what you would use on a 68020 --
>and you can forget about byte-swapping on a 68020 as well).
It also helps that addition is commutative :-).
>After calculating a one's complement sum, you have to take its one's
>complement (invert all the bits) to get the actual checksum used in IP,
>TCP, and UDP (but note that UDP treats a calculated checksum of 0x0000
>as a special case -- see the RFC).
Art Berggreen
art@acc.arpa
------
-----------[000320][next][prev][last][first]---------------------------------------------------- Date: 25 Mar 88 19:12:51 GMT From: heckard%FORD-COS1@FORD-WDL1.ARPA (Max A. Heckard) To: comp.protocols.tcp-ip Subject: (none)
****************************************************************************** 25 March 1988 Gentlepersons: Does anyone know of any TCP/IP product that will apply a security classification to an outgoing datagram? We are currently searching for an implementation that will run on a VAX 8600 cluster or a MicroVAX II (VMS). In general, we would like to become aware of vendors with an active interest in supporting the revised IP security option (RFC 1038) without charging an eighth of a megabuck "for access to source code to add the process." Your responses will be appreciated. Max Heckard heckard@ford-cos1.arpa Ford Aerospace Corporation 10550 State Hwy 83, N. Colorado Springs, CO 80921-3603 719-594-1379 ******************************************************************************
-----------[000321][next][prev][last][first]---------------------------------------------------- Date: 25 Mar 88 20:29:41 GMT From: jsa@GATEWAY.MITRE.ORG To: comp.protocols.tcp-ip Subject: A network you can trust
Is it really that "obvious that the host wants to protect itself and provide itself good service regardless of what the network claims to provide, and so should run a strong transport like TCP."? If this were true, wouldn't the Europeans be using TP4 over their PTT-provided X.25 nets instead of TP0? _________________________________________________________________ Jim Ackermann The MITRE Corp. jsa@gateway.mitre.org 7525 Colshire Dr. 703-883-5360 McLean, VA 22102 USA _________________________________________________________________
-----------[000322][next][prev][last][first]---------------------------------------------------- Date: 25 Mar 88 20:56:41 GMT From: tsuchiya@GATEWAY.MITRE.ORG (Paul Tsuchiya) To: comp.protocols.tcp-ip Subject: Re: A network you can trust
Sorry, what I really should have said is that it is obvious in an Internet environment that one needs a strong Transport. And in fact, the Europeans are quickly becoming TCP users. One can now buy TCP from something like 30 European computer manufacturers, and they have recently comandeered a large chunk of I think Class B space for the European Internet. _________________________________________________________________ Paul F. Tsuchiya The MITRE Corp. tsuchiya@gateway.mitre.org 7525 Colshire Dr. 703-883-7352 McLean, VA 22102 USA _________________________________________________________________
-----------[000323][next][prev][last][first]---------------------------------------------------- Date: 25 Mar 88 21:21:40 GMT From: braun@drivax.UUCP (Kral) To: comp.protocols.tcp-ip Subject: Re: Rumors about the death of the ARPANET
In article <8803141728.AA08682@sun46.darpa.mil> boesch@VAX.DARPA.MIL writes:
>
>The follow on network experiment will be called the Defense Research
>Internet (DRI). We are also working in conjunction with other Federal
>agencies, most notably National Science Foundation, to integrate our
>networking experiments with the new regional networks, the NSFNET
>project, and other agency networks.
>
Ahem. I would like to take this opportunity to point out that nodes in the
to-be implemented drinet.com domain will have nothing to do with the to-be
implemented Defense Research Internet :-).
--
kral 408/647-6112 ...{ism780|amdahl}!drivax!braun
DISCLAIMER: If DRI knew I was saying this stuff, they would shut me d~-~oxx
-----------[000324][next][prev][last][first]---------------------------------------------------- Date: 25 Mar 88 22:09:16 GMT From: braden@venera.isi.EDU To: comp.protocols.tcp-ip Subject: Re: Checksums (was Re: Ping, checksum algorithm?)
The TCP/IP checksum properties were discussed early in the TCP/IP development. See "TCP Checksum Function Design", IEN45, by Bill Plummer of BBN; the data was almost 10 years ago-- June 1978. Bob Braden
-----------[000325][next][prev][last][first]---------------------------------------------------- Date: 26 Mar 88 05:54:03 GMT From: jeremy@swatsun.uucp (Jeremy Brest) To: comp.protocols.tcp-ip,comp.os.vms Subject: Request for information: tcp/ip mail with vax/vms
If anyone has tried (successfully or not) to integrate Vax/VMS machines in a tcp/ip mail environment, please let me know. The specifics I am interested in are what mail software was used and what tcp/ip software. Related query: Does the CMU tcp/ip software allow DECnet to remain operational? Thanks, Jeremy Brest Swarthmore College uucp: ...seismo!bpa!swatsun!jeremy CSNet: jeremy@swatsun.swarthmore.edu ARPA: jeremy%swatsun.swarthmore.edu@relay.cs.net
-----------[000326][next][prev][last][first]---------------------------------------------------- Date: 26 Mar 1988 11:06-EST From: CERF@A.ISI.EDU To: dalcs!thompson@UUNET.UU.NET Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: ARP hardware field
Mr. Thompson, You may already have received other replies on the "status of RFCs" but just in case... These are indeed Requests for Comment. Only a few of the RFCs are adopted as Internet Standards; those that are will be identified by Jon Postel on the instruction of the Internet Activities Board which is chaired by Dave Clark (MIT Lab for Computer Science). There is an official documents list which is published as an RFC and updated periodically by Jon Postel. Perhaps Jon will be good enough to remind us of the RFC number of the most recent of these summaries. Vint Cerf
-----------[000327][next][prev][last][first]---------------------------------------------------- Date: 26 Mar 88 07:34:59 GMT From: SAPPHO@SRI-NIC.ARPA (Lynn Gazis) To: comp.protocols.tcp-ip Subject: Re: Add to mailing list
I have added tcp-ip@Ultra.COM to the tcp-ip mailing list. -------
-----------[000328][next][prev][last][first]---------------------------------------------------- Date: 26 Mar 88 09:34:38 GMT From: benoni@ssc-vax.UUCP (Charles L Ditzel) To: comp.protocols.tcp-ip,comp.windows.misc Subject: Re: Sun servers
In article <208@megalon.UUCP>, digi@megalon.UUCP (Klaus Altenburg) writes: > My company is also interrested in using workstations (like sun's) for CASE. > Here in Germany a reasonable sun-server costs about 35.000 - 40.000 DM. Usually it's the reverse. > > - Is it right, that we need only a unix-machine with a working > NFS to run diskless sun-workstations ? I believe their are now versions of NFS that allow diskless Sun's to boot off of Vaxes and other machines. I could be wrong...it might still be pending release. Naturally diskless Suns can boot off of low-end workstations like the Sun 3/60 (it's slower). > - is there software to use 386-based systems as workstations for CASE ? When Sun's 386 machine (see InfoWorld and ComputerWorld) comes out the answer is yes. Look at Sun's NSE package (it works with CADRE, Interleaf etc)
-----------[000329][next][prev][last][first]---------------------------------------------------- Date: 26 Mar 88 16:06:00 GMT From: CERF@A.ISI.EDU To: comp.protocols.tcp-ip Subject: Re: ARP hardware field
Mr. Thompson, You may already have received other replies on the "status of RFCs" but just in case... These are indeed Requests for Comment. Only a few of the RFCs are adopted as Internet Standards; those that are will be identified by Jon Postel on the instruction of the Internet Activities Board which is chaired by Dave Clark (MIT Lab for Computer Science). There is an official documents list which is published as an RFC and updated periodically by Jon Postel. Perhaps Jon will be good enough to remind us of the RFC number of the most recent of these summaries. Vint Cerf
-----------[000330][next][prev][last][first]---------------------------------------------------- Date: 26 Mar 88 16:19:26 GMT From: kohjin@marina.JUICE (Kohjin Yamada) To: comp.protocols.tcp-ip,comp.dcom.lans Subject: Re: PC/AT LANCE Card
In article <20842@amdcad.AMD.COM> toms@amdcad.AMD.COM (Tom Slykhouse) writes:
>
>Advanced Micro Devices has completed development on a Public Domain
>Ethernet board for the PC/AT's and Clones, based on our LANCE controller.
>Manuals, schematics and artwork are available for this product.
>
>We are additionally considering porting several of the common
>communications packages to this board. One possibility is KA9Q
>TCP/IP. If anyone on the net would like this package ported, or would
>prefer another package please respond to me with EMail.
Hi, Tom.
I'm really interested in your offer.
We've been looking for the Ethernet board for the XeniX use.
Would like to port it to KA9Q TCP/IP to communicate with Sun-3/50.
We have ported KA9Q TCP/IP package to XeniX and Sun-3 OS recentlly and operating
the net everyday.
Verry sorry that I don't have any chance to put a Email to you through this net
at present time.
Would you mind if I ask to send the detail to the following address?
Or would you mind to reply me how to reach you in an other way?
Mr. Kohjin Yamada
504-55 Shimo Yamaguchi, Hayama, Kanagawa, Japan
I've posted to reply to your offer before but ther're some chance of the lost
article, so I try once more.
Thanks in advance.
--
Kohjin Yamada, JR1EDE
*----/----* JUICE: kohjin%marina.juice@junet
Q-----S------T AMPR: kohjin@jr1ede.marina.ampr [44.129.20.128]
*------/|-------* AsiaNet: JR1EDE @ JR1EDE (SysOp @ AsiaNet.Tokyo)
-----------[000331][next][prev][last][first]---------------------------------------------------- Date: 26 Mar 88 19:55:35 GMT From: grr@cbmvax.UUCP (George Robbins) To: comp.protocols.tcp-ip Subject: Re: Rumors about the death of the ARPANET
In article <670@tetra.NOSC.MIL> budden@tetra.nosc.mil.UUCP (Rex A. Buddenberg) writes:
>
> Maybe I'm missing something, but:
...
> Looks to me that 500 nodes times 20 km multiplies out to a pretty
> decent regional backbone -- internet a half dozen of these and you've
> got the country covered. Why are we fiddling around with ISDN?
Yes, and who do you have lined up to pay for a little fiber cable
terminating at your residence? ISDN gives hopes of getting reasonable
bandwidth almost anywhere a reasonable cost, whereas fiber will
probably be limited to backbone applications and connecting super
computer ($$$) centers.
--
George Robbins - now working for, uucp: {uunet|ihnp4|rutgers}!cbmvax!grr
but no way officially representing arpa: cbmvax!grr@uunet.uu.net
Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
-----------[000332][next][prev][last][first]---------------------------------------------------- Date: 26 Mar 88 20:05:02 GMT From: brian@wb6rqn.UUCP (Brian Lloyd) To: comp.protocols.tcp-ip Subject: European interest in TCP
At a recent trade show where we (Sirius Systems) announced our
implementation of TCP/IP for the Convergent Technologies workstation
product line I was surprised at the level of interest exhibited by the
European attendees. The consensus was that OSI really wasn't happening
and that they were all planning to go the TCP/IP route. I guess that
the ISO/OSI hard-sell has created a market that only TCP can currently
fill.
Brian Lloyd, President
Sirius Systems, Inc.
(301) 540-2066
{bellcore, syscad, cp1, irs3, n3dmc}!wb6rqn!brian
Share and enjoy!
-----------[000333][next][prev][last][first]---------------------------------------------------- Date: 27 Mar 88 03:35:47 GMT From: sauer@auschs.UUCP (Charlie Sauer) To: comp.protocols.tcp-ip,comp.sys.apollo,comp.sys.ibm.pc.rt Subject: Re: SLIP on the IBM RT (w/AIX) or Apollo workstations
In article <55@hrsw2.UUCP>, bakken@hrsw2.UUCP (David E. Bakken) writes:
>
> Does anyone know of a port of SLIP to the IBM RT (running AIX) or
> the Apollo workstations? If so, please email me with the
> details. Thanks!!!!
SLIP is in AIX/RT 2.2. 2.2 is scheduled to be available in June.
--
Charlie Sauer Dept D18, Bldg 802 aesnet: sauer@auschs
IBM AES/ESD, Austin, TX vnet: SAUER at AUSVM6
(512) 823-3692 csnet: ibmaus!sauer@EMX.UTEXAS.EDU
uucp: ut-sally!ut-emx!ibmaus!sauer
-----------[000334][next][prev][last][first]---------------------------------------------------- Date: 27 Mar 88 04:49:20 GMT From: mshiels@watmath.waterloo.edu (Michael A. Shiels) To: comp.protocols.tcp-ip Subject: Re: ARP protocol address space field on ProNET
Is it possible to get the codes that PRONET does use?? -- Michael A. Shiels (MaS Network Software) mshiels@watmath.waterloo.EDU UUCP: ...path...!watmath!mshiels
-----------[000335][next][prev][last][first]---------------------------------------------------- Date: Sun, 27 Mar 88 10:53 From: John Laws (on UK.MOD.RSRE) <LAWS%rsre.mod.uk@relay.MOD.UK> To: jsa <@nss:jsa@gateway.mitre.org> Cc: tcp-ip <@relay.MOD.UK:tcp-ip@sri-nic.arpa> Subject: Re: A network you can trust
Speaking as a European who has access and is active in using both X25 nets and Internet - X25 service within the UK appears to be very satisfactory. That is to say the 'end-to-end' network service provided by BT on PSS is such that I really have no memory of corrupted info, slow response etc. It could be said that I am paying a 'price' for this, but I appear to have no difficulty in seeing the price for this quality of service as other than cost effective. International X25 to Europe again appears very satisfactory. Indeed I am using that as a means of extending the Internet from RSRE to my European partners. Again this appears to be cost effective for the level of our current requirement. Clearly there is a traffic level at which a leased line is more cost effective - what that level is with 'operational' traffic is part of the experiment. I have no direct experience of using X25 to the US (yet) but it is claimed to be less than satisfactory because it is necessary for BT to downgrade its facilities to match the lowest common facilities of US X25 service providers. Fastest line speed (I think) is 9.6kb, window of 2, cant extend packet size. The Internet works very well when lightly used, but standing here in Europe working via a satellite path shows that too many of the Internet solutions are local (CONUS) optimisations. These problems are now well recognised in the specific attention of individuals eg Van J and his TCP work, and a number of TF's. I note with great interest that some folks in BBN and Mitre (who I have great respect for the many scars they have acquired from years of front-line work) have some degree of the so called 'European' view. John Laws Distibuted Information Systems Div RSRE Malvern UK
-----------[000336][next][prev][last][first]---------------------------------------------------- Date: Sun, 27 Mar 88 11:25 From: John Laws (on UK.MOD.RSRE) <LAWS%rsre.mod.uk@relay.MOD.UK> To: Brian Lloyd <@nss:rochester!cci632!rlgvax!dolqci!irs3!wb6rqn!brian@rutgers.edu> Cc: tcp-ip <@relay.MOD.UK:tcp-ip@sri-nic.arpa> Subject: Re: European interest in TCP
OSI is very much happening in Europe. It is true that not all the 'layers' are complete in implementation or definition. But there is just as much faith in Europe that OSI will deliver as there is faith in the US that TCP/IP etc will deliver. Any company that ignores the momentum for OSI in Europe will not be well placed for an expanding market in the early 90's. Specifically within UK MOD, UK Other Government Departments, EEC and NATO the clear policy directive is to procure systems to the OSI standards. This policy was not undertaken lightly. Yes TCP/IP is readily available in many products. Yes it is selling. It is not selling because the buyer knows or cares that its TCP etc. The buyer is buying a product and facility. The fact that many of these TCP implementations are local optimisations will restrict their effective use to local communities. The experience will educate the buyer to better understand and define his requirement if his needs are more than local. John Laws Distributed Information Systems Div RSRE Malvern UK
-----------[000337][next][prev][last][first]---------------------------------------------------- Date: 27 Mar 1988 11:49-EST From: Alessandro.Forin@SPEECH2.CS.CMU.EDU To: csl!hercules!auerbach@spam.istc.sri.com (Karl Auerbach) Cc: tcp-ip@sri-nic.arpa Subject: Re: Off loading the protocol
> Date: 19 Mar 88 18:18:09 GMT > From: csl!hercules!auerbach@spam.istc.sri.com (Karl Auerbach) > Subject: Re: Off loading the protocol > Sender: tcp-ip-request@sri-nic.arpa > To: tcp-ip@sri-nic.arpa > > Just curious: How does the shared memory paradigm handle the case where > the machines are of different memory architectures with different > data representations? As far as I know, my system (Agora) is the only one that specifically addresses your question. A description of our work will appear in the August issue of IEEE Trans. Computer, and you can find also a paper now in the proceedings of the ASPLOS-II conference (it is in the list I posted earlier to the tcp-ip list). The answer is basically to keep around at runtime data type descriptors, so that you can translate a datum coming from an incompatible machine into the appropriate local representation. This is much the same problem you have with the description of data inside messages for any remote procedure call package (Sun, Apollo, Xerox, Mach-MiG, etc..). It is in no way specific to the shared memory paradigm. Sorry for the delay in answering... sandro-
-----------[000338][next][prev][last][first]---------------------------------------------------- Date: 27 Mar 88 16:49:00 GMT From: Alessandro.Forin@SPEECH2.CS.CMU.EDU To: comp.protocols.tcp-ip Subject: Re: Off loading the protocol
> Date: 19 Mar 88 18:18:09 GMT > From: csl!hercules!auerbach@spam.istc.sri.com (Karl Auerbach) > Subject: Re: Off loading the protocol > Sender: tcp-ip-request@sri-nic.arpa > To: tcp-ip@sri-nic.arpa > > Just curious: How does the shared memory paradigm handle the case where > the machines are of different memory architectures with different > data representations? As far as I know, my system (Agora) is the only one that specifically addresses your question. A description of our work will appear in the August issue of IEEE Trans. Computer, and you can find also a paper now in the proceedings of the ASPLOS-II conference (it is in the list I posted earlier to the tcp-ip list). The answer is basically to keep around at runtime data type descriptors, so that you can translate a datum coming from an incompatible machine into the appropriate local representation. This is much the same problem you have with the description of data inside messages for any remote procedure call package (Sun, Apollo, Xerox, Mach-MiG, etc..). It is in no way specific to the shared memory paradigm. Sorry for the delay in answering... sandro-
-----------[000339][next][prev][last][first]---------------------------------------------------- Date: 27 Mar 88 18:53:00 GMT From: LAWS@rsre.mod.UK (John Laws, on UK.MOD.RSRE) To: comp.protocols.tcp-ip Subject: Re: A network you can trust
Speaking as a European who has access and is active in using both X25 nets and Internet - X25 service within the UK appears to be very satisfactory. That is to say the 'end-to-end' network service provided by BT on PSS is such that I really have no memory of corrupted info, slow response etc. It could be said that I am paying a 'price' for this, but I appear to have no difficulty in seeing the price for this quality of service as other than cost effective. International X25 to Europe again appears very satisfactory. Indeed I am using that as a means of extending the Internet from RSRE to my European partners. Again this appears to be cost effective for the level of our current requirement. Clearly there is a traffic level at which a leased line is more cost effective - what that level is with 'operational' traffic is part of the experiment. I have no direct experience of using X25 to the US (yet) but it is claimed to be less than satisfactory because it is necessary for BT to downgrade its facilities to match the lowest common facilities of US X25 service providers. Fastest line speed (I think) is 9.6kb, window of 2, cant extend packet size. The Internet works very well when lightly used, but standing here in Europe working via a satellite path shows that too many of the Internet solutions are local (CONUS) optimisations. These problems are now well recognised in the specific attention of individuals eg Van J and his TCP work, and a number of TF's. I note with great interest that some folks in BBN and Mitre (who I have great respect for the many scars they have acquired from years of front-line work) have some degree of the so called 'European' view. John Laws Distibuted Information Systems Div RSRE Malvern UK
-----------[000340][next][prev][last][first]---------------------------------------------------- Date: 27 Mar 88 19:25:00 GMT From: LAWS@rsre.mod.UK (John Laws, on UK.MOD.RSRE) To: comp.protocols.tcp-ip Subject: Re: European interest in TCP
OSI is very much happening in Europe. It is true that not all the 'layers' are complete in implementation or definition. But there is just as much faith in Europe that OSI will deliver as there is faith in the US that TCP/IP etc will deliver. Any company that ignores the momentum for OSI in Europe will not be well placed for an expanding market in the early 90's. Specifically within UK MOD, UK Other Government Departments, EEC and NATO the clear policy directive is to procure systems to the OSI standards. This policy was not undertaken lightly. Yes TCP/IP is readily available in many products. Yes it is selling. It is not selling because the buyer knows or cares that its TCP etc. The buyer is buying a product and facility. The fact that many of these TCP implementations are local optimisations will restrict their effective use to local communities. The experience will educate the buyer to better understand and define his requirement if his needs are more than local. John Laws Distributed Information Systems Div RSRE Malvern UK
-----------[000341][next][prev][last][first]---------------------------------------------------- Date: 28 Mar 88 01:08:35 GMT From: bc@halley.UUCP (Bill Crews) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.ibm.pc.rt Subject: Re: socket library on top of TLI wanted
In article <1214@kulcs.kulcs.uucp> dannyb@kulcs.uucp (Danny Backx) writes: >Somebody said that there is a library for offering a socket interface, provided >you have TLI. >Can anybody tell me where to get this library (or maybe mail it to me) ? The one I am aware of was developed by Wollongong. I don't know if they offer this as a product. As far as I know, they do not. I don't know of any freebies out there. Anyone? -bc -- Bill Crews Tandem Computers bc@halley.UUCP Austin, Texas ..!rutgers!im4u!halley!bc (512) 244-8350
-----------[000342][next][prev][last][first]---------------------------------------------------- Date: 28 Mar 88 01:33:42 GMT From: att-cb!clyde!watmath!utgpu!utzoo!yunexus!maccs!gordan@ucbvax.Berkeley.EDU (gordan) To: tcp-ip@sri-nic.arpa Subject: Re: Checksums (was Re: Ping, checksum algorithm?)
In article <1080@maccs.UUCP> I wrote: [A verbose description of one's complement checksums] Thanks to Mike Brescia, Dave Borman, and Bill Westfield for setting me straight on this... Machine byte-order doesn't matter for purposes of doing one's complement checksums. The quickest way to see this is to note that carries from the least significant byte get added to the MSB (as in ordinary addition), and carries from the MSB get added to the LSB (since we add the hardware carry bit into the sum). Because of this symmetry, the exact same checksum algorithm can be used on both big-endian and little-endian machines. A concise definition of one's complement checksums (from Dave Borman): -- So how do you calculate the checksum? You add up all the 16 bit -- words over the data that you want to checksum, and add all the -- carrys back into the sum. When you are all done, you take the one's -- complement of the final sum. -- For outgoing packets, put 0 into the checksum field, calculate the -- checksum, and fill it in. -- For incoming packets, the checksum will calculate to 0 if the data -- is correct. -- That is it.