craig@NNSC.NSF.NET.UUCP (07/09/87)
Here at the CSNET CIC we're collecting some statistics to help us
figure out why the CSNET relay is in the top-10 traffic list.
One of the things we've done is to start tracking the protocol
field in each IP header (to show us which protocols are causing most
of our traffic). And before I've even analyzed our data I've found a
small anomaly.
It clearly isn't causing our traffic problems, but we're receiving
packets with the IP protocol field set to 77 decimal. So far it is 21
packets in the past 16 hours). According to RFC 1010 that protocol number
is unassigned. Anyone have any guesses what these things are?
Craigchris@GYRE.UMD.EDU (Chris Torek) (07/12/87)
Protocol number 77 is Sun's ND (not to be confused with NFS, which uses UDP). None of these should ever appear on the Internet! Someone is leaking local traffic. Chris
hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick) (07/12/87)
77 is Sun's network disk protocol. This is the predecessor to NFS, and will be phased out near the end of the year. Apparently this number was not assigned by the number Czar, but will simply pulled out of a hat and used unofficially.
Mills@UDEL.EDU (07/13/87)
Chris, Is "protocol number 77" expressed in octal or decimal? Protocol number 63 (decimal) or 77 (octal) is reserved for local use, according to the assigned- numbers list. My interpretation of this is that gateways should not forward IPgrams carrying this number, so the NSFNET Backbone gateways, at least, do not; therefore, your traffic certianly did not rumble that way. Having said this, I am somewhat concerned about loopback and other things intended to have only local relevance and "never escape the local net." Some things, in particular local routing information and local broadcasts seem in tune with this notion, since they depend on addressing independent of local-network characteristics. However, some others (ND, NFS?) depend on the characteristics of the local net (delay, discard rate, etc.) as an intrinsic requirement for acceptable service. The use of addressing scope to delimit service range in such cases seems conuterproductive. What you really want is scope determined by maximum acceptable delay; in other words, some mapping of type-of-service plus maybe a new IP option. This is the same thing needed for packet speech and, in fact, implemented in those gateways supporting the Stream (ST) Protocol. Dave
hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick) (07/15/87)
You indicate that there is a maximum acceptable delay for NFS. That's not quite the case. NFS does not adjust its timeouts and retransmission times dynamically on a per-connection basis as TCP does. However you can set the constants as options in the mount. It should be possible to use NFS over connections with a long delay, as long as the system administrator is able to choose reasonable values. (A connection where values changed a lot would be a problem, of course.) This is obviously not the best way to design a protocol. On the other hand, they needed higher speed than is typical with TCP. The evidence from this mailing list is that the commonly-used techniques for choosing retransmission times and the like do not always lead to the best results. So I can understand a pragmatic decision to optimize for local Ethernets and let the administrator tune it for other connections.
Mills@UDEL.EDU (07/15/87)
Charles, Well, we might both be on a spinnaker run. In fact, pals of mine have mounted NFS over some interesting creeks in the NSF swamps, so what are we tacking about? I think the pertinent points have been butted and rebutted and thus would like to rest the case. We still need a type-of-service architecture independent of addressing and protocol specifications. Dave