|
|
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: