🚀 go-pugleaf

In article <40h492$n0u@news.sprintlink.net>, <paul@hawksbill.sprintmrn.com> 
writes:

> Tony Weasler (tweasler@vt.edu) wrote:
> 
Tony> > I would stay away from frame relay for TCP/IP communications
Tony> > because of it's tendency to deliver frames out of order.  A
Tony> > few frames can be easily corrected with a small buffer and
Tony> > little speed degradation, but if you are saturating bandwidth
Tony> > at peak hours, you will need some heavy buffering to keep TCP/IP
Tony> > from requesting retransmits.

Paul> Huh? We've built thousands of frame-relay networks and they can 
Paul> certainly be solid, well-performing networks. 

Paul> Stay away from frame-relay if you like, but you're certainly being
Paul> somewhat short-sighted in your overview of frame-relay and TCP/IP.

True, but lately some folks at my provider have seen problems where our local
telco has bandwidth problems, and when they get saturated your ping times
can go WAAAY up, like on the order of several seconds.  So rather than just
losing the packet, and letting TCP re-transmit (and shorten it's window size),
the packets arrive very disjointed & out of order.  Bottom line is that it
can confuse the sliding window algorithm of many TCP implimentations.  

So, frame relay is not bad (most of the local connections work perfect),
provided your local telco has not overloaded the fabric, or created serious
bottlenecks in/out of the fabric.

dct