Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!rochester!rutgers!att!ulysses!sfsup!aeh
From: aeh@sfsup.UUCP (+Herzog A.)
Newsgroups: comp.mail.uucp
Subject: Re: other uucp proto's
Summary: Warning and protocol changes...HDB
Message-ID: <4950@sfsup.UUCP>
Date: 13 Mar 89 17:52:01 GMT
References: <1766@gould.UUCP>
Distribution: usa
Organization: AT&T-BL, Summit N.J. USA 07901
Lines: 70

In article <1766@gould.UUCP>, jfraser@gould.UUCP (Jonathan Fraser) writes:
>
> 	1) 'g' protocol must remain intact at it is.  I think

Absolutely! Or at least it must be compatible with the maximum
(implementation imposed) packet size of 128. Is this different for
anyone else out there?

> 	2) the major problem with throughput is packet size.

This appears to be true, at least with devices I've seen, although
I have also seen window size play a big role, especially on
error-prone connections.

> 		g proto is supposed to negotiate packet size but does not.

Actually, 'g' protocol does not negotiate packet size. The 'receiver'
simply states the packet size to be used, and the 'transmitter' is expected
to comply. The same is true in the other direction of data flow.

> 		This is not just a matter of data buffer sizes and #defines.
> 		It only works if boths sides have the same max packet size
> 		and only negotiates to the max.  You can't have
> 		one side with 64 bytes packets and another with
> 		256 bytes packets.

This does not seem to be true. The #define was definitely a problem.
But now we have 64 byte packet uucicos talking with 256 byte packet
uucicos. The protocol is designed to allow this. This lets one direction
be optimized for data transfer, and the other for message transfer.

> 	3) It may not be impossible to fix packet size negotiation 
>	... 
> 	What I've done is invent 5 'new' protocols.  These are

The 'd' protocol is reserved in HDB, and so is 'e'. If you talk to other
machines which know these, don't expect much. Don't forget the
'f'. Any others out there we should worry about?

> 		proto	size
> 		 a		256
> 		 b		512
> 		 c		1024
> 		 d	    2048
> 		 e		4096
> 		 g		 64		(unmodified)

In SVR4, so will 'G'. The 'G' will be the SAME as 'g' with the
maximum allowable packet size permitted by the protocol (4096).

> 	In effect, you are negotiating packet size when you negotiate the proto.

Better to negotiate a protocol, and then let it handle the internals?!
The only trick is to set the parameters (packet and window size) at
run time. This can easily be done by using the ",eg" protocol subfield
of the device type field of the Devices (and/or Systems) file.

> 	Why bother with more than one packet size?  Is bigger not better?

Apparently not. Even with very fast media, there are other limitations
which cause this to not be true. The key is to make the implementation
flexible enough so the administrator can make the decision at run time.

With the right combination of parameter settings, the throughput can be
increased significantly. Of couse, choose the wrong values, and all
bets are off.

--------------------

/* As usual, what I said is what I said: nothing more, nothing less. */