chrisf@uswmrg2.UUCP (Chris Fedde) (04/10/90)
Pardon me if this seems naive but... I manage a network which
incorporates three MGS routers connected in in a triangle via 56kb
serials. There is a single ethernet port on each of the routers from
which the host equipment hangs. Maybe a picture would help:
+------+ +------+
----ether------| MGS1 |---56kb-----| MGS2 |----ether-----
| | | |
+------+ +------+
\ /
5 5
6 6
k k
b b
\ /
+------+
| MGS3 |----ether-----
| |
+------+
The IP addressing scheme has the three serial links and one of the
ether LANs subnetted out of one class C network and the remaining two
ethernets as separate class C networks. The gateways are routing
appletalk and tcp/ip with SYSV hosts, macs on ethernet and macs gated
in to ethernet via kenetics fastpaths.
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. 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.
Please email responses to ...boulder!uswat!uswmrg2!chrisf since this
is the only reliable path I know to me. Or go ahead and post if
you think the issue has broad enough interest.
Thanks
Chris Fedde
uswmrg2!chrisf@uswat.uswest.comkwe@bu-it.bu.edu (Kent England) (04/11/90)
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