Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!decwrl!sgi!vjs@rhyolite.wpd.sgi.com From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Newsgroups: comp.protocols.misc Subject: Re: Realtime Protocols Message-ID: <71126@sgi.sgi.com> Date: 4 Oct 90 06:47:23 GMT References: <24594@uflorida.cis.ufl.EDU> <32683@sparkyfs.istc.sri.com> <59769@bbn.BBN.COM> Sender: guest@sgi.sgi.com Organization: Silicon Graphics, Inc., Mountain View, CA Lines: 71 In article <59769@bbn.BBN.COM>, craig@bbn.com (Craig Partridge) writes: > > Raj Jain did a nice analysis of TTRT and access time bounds for FDDI > in a paper he gave at SIGCOMM '90. The gist of his talk is that if > you set TTRT to 8 milliseconds, you get good response even with large > numbers of stations and high load, and don't give up too much of the > bandwidth. Without disagreeing or agreeing with his paper (I've read it), I must disagree with the conclusions you draw from it. It is true that if you set TRT=8, then the worst case latency goes down by about 165/8. This means that with the maximal 500 stations, you have around 10 seconds of worst case latency. I work for a graphics workstation company and hear from customers who build simulators, and many of those customers worry about keeping screens up to date and synchronized. Latency guarantees for them of seconds are funny, not just useless. There might be applications that coud use guaranteed latencies of large parts of seconds, and I would like to hear about them. Only they would care about the FDDI token ring guanrantees. Setting TRT=8 has a large cost, in my opinion. If you have a network consisting of a zillion PC's and remote terminals, each of which offers a load of a few KBytes/second, then you do not care about this cost. If you are shipping workstations today that can send or receive more than 1,000KBytes/second on a single TCP connection over ethernet and expect, hope, and are required to do much better soon, you might think FDDI is not very fast, and reducing it from around 10MBytes/sec to about 8MBytes/sec is too much to pay. (Please forgive me. I did not wish to advertise, although I'm not ashamed our numbers. There are others who are doing as well, but I can't use them to illustrate my point.) In practice, the latencies of a correctly sized and operating FDDI ring will be like the latencies of a correctly sized and operating Ethernet. They will be a small number of milliseconds. The blarney is only in the "guarantee." --- Speaking of TRT=8, is anyone bothered by the reaction to Raj Jain's paper? I know of two vendors who have decided to set their default T_Neg to 8msec and 7.xxx msec, respectively. The latter builds bridges and concentrators. Consider the result on the large rings you are building with these boxes. If you decide you prefer TRT=10msec, you will be out of luck. Yes, in principle, you could convince each of those boxes on your ring to use 10. In practice, with power failures and equipment changes, it is impossible. If TRT=8 is the right answer, it need and should be set on only one station. No, MAC level SMT management, PMF's, and so forth are not now and never will be the answer to this problem, because: -there is no broadcast PMF -there are no authorization facilities defined in SMT (Contrary to the statements of one SMT software vendor, the holes labeled "authorization" in the standard are still "TBD.") -there are no authentication even mentioned in the standard. -you don't want Joe College Student reaching out from a lab workstation, in the absence of A&A, and telling your Kerboros server to shut down, so he can take over its MAC address. -if there were a broadcast PMF, then Joe could send an orphan broadcast frame telling all stations to disconnect, just to brighten those dreary days before finals. -in a bridged bunch of rings, you might not have an Official SMT Network Management station on every ring that needs to be managed. Vernon Schryver Silicon Graphics vjs@sgi.com