🚀 go-pugleaf

In article <1990Apr10.030211.19691@uswmrg2.UUCP>, chrisf@uswmrg2.UUCP
(Chris Fedde) writes:

> My problem is this...  When someone fires off a file transfer (from
> appletalk or ftp/rcp) telnet sessions which go over a serial link
> become very sluggish.  

	This is a good reason for all of us to get interested in Van Jacobson's header
compression work.   Not only is it more efficient to compress tcp
headers, but VJ
has dealt with the telnet latency problem by looking at the proper MTU
for a slow
speed serial line.  I have read his Jan 90 report, but I think it is out now as
RFC1144 (Feb 90).  Header compression and a proper MTU will guarantee high line
utilization and good telnet response.

	I think that PPP will be able to be used to implement VJ's compression, but
of course, cisco could add the header compression to their "proprietary" serial
line protocol.  I think we should press all vendors to do PPP with
header compression
as a supported option.

> Also the transfer rate of an FTP copy never
> comes even close to 56kb. I had expected the transfer rate to exceed
> 56kb because of multiple routes.  When I look at the statistics from a
> 'show ip traffic' or 'show apple traffic' it seems that one link is
> not even used.  Is there a way to balance the load more evenly over
> the 56kb links?  Would x25 routing help?  If so, do you have any
> pointers for me on what I should be doing?  If not, where has my
> thinking gone wrong.
> 

	If you try to do load balancing the way you are thinking, it would
have to be based on delay or some other congestion-affected parameter. 
Experience
has shown that these congestion based routing dynamics are unstable.  (Some
will argue with that, but not cisco.)

	See the cisco manual for some discussion of load balancing and
their warnings about instability.

	I think that you would be happy with header compression and no
dynamic congestion-based multi-path load-balancing routing.

	Another area of difficulty is in the ftp implementation.  Your
ftp should implement VJ/et al 's TCP performance enhancements (slow start,
etc) in order to efficiently use a fair share of the 56k path.  I doubt
that the appletalk protocols are very efficient either.

	Of course, we can always throw a higher speed line at the problem.
That is a widely accepted technique in the Internet.    :-)

	Kent England, Boston University