I'm not sure if this is relevant, but we have just
moved to a new FrameRelay solution. We have based the
traffic as .75k per user.

Through the routers we have also prioritised the HP
traffic over all others(Quality of Service). We have
also moved processes such as file transfers and other
network traffic to a different queue.

The theory is that the users require an instant(ish)
response from their typing as opposed to E-mail and
Web-browsing which does not need such a quick
response.

Regards

Steve
--- Jeff Kell <[log in to unmask]> wrote: > Art Bahrs
wrote:
>
> > First, we can't get these PC's to bring up a web
> page without
> > hanging!!!
>
> >    We have 32kb CIR on a 56k circuit for the Frame
> Relay.
>
> > Secondly, the connections to Milo (our 979)
> shutdown .... now
> > Windows is still able to work.... just that the
> user is apparently
> > logged off of our 979 because of no data seems to
> going between the
> > PC and Milo...
>
> > Any Ideas?  Do we need to get a bigger circuit? Is
> there Router
> > Black Magic that needs to be performed?
>
> Frame Relay, unless properly configured, is like
> gambling -- ya pays yer
> money, ya takes yer chances.  Anything over your CIR
> is going to
> be flagged as "discard eligible" (a bit in the FR
> header).  If your
> provider's FR cloud is congested, it starts dropping
> DE packets as long
> as there are any to drop.  And your local router, if
> presented with more
> than your burst rate of data, is going to drop
> packets before they ever
> get to the cloud.  In your case, you can burst to
> 56kbps, but 24kbps of
> that *can* be dropped on the floor by your FR
> provider.  This applies in
> both directions too.
>
> Web traffic is the worst over FR.  It does many many
> connection opens in
> the course of loading a page (one for each imbedded
> image, etc).  While
> TCP is rather robust once connected, it is very
> sensitive to packet loss
> during connection opens.  If any packet of the 3-way
> open handshake get
> dropped, no connection (some but not many will
> retry).
>
> The 3000 is particularly sensitive to dropped
> packets (I repeat this ad
> infinitum but nobody listens).  Even on established
> connections.  That
> explains your 3000 problems.
>
> Yes, you can do router magic depending on your
> router.  You could set
> rate-limiting on outbound traffic to avoid exceeding
> your CIR too much.
> Or you could use custom queueing or traffic shaping
> to give priority to
> certain types of traffic coming into your router
> from the inside
> (likewise for rate limiting traffic going to the FR
> circuit).  There is
> even an "adaptive" rate limiting feature in Cisco
> that will allow the
> pipe to expand up to the burst rate until it
> receives notification from
> the FR switch that there is congestion (most FR
> provider switches
> provide FECN/BECN [Front-End/Back-End Congestion
> Notification]) and they
> will throttle your traffic when the likelihood of
> congestion is known to
> be high.  In the absence of FECN/BECN notices, it
> will let you burst
> away.
>
> But obviously, I don't want to bore everyone here
> with any further
> details of the situation, but hopefully that gives
> you the idea.
>
> Jeff (not plugging Cisco, just the only one I know)
> Kell
>
> * To join/leave the list, search archives, change
> list settings, *
> * etc., please visit
> http://raven.utc.edu/archives/hp3000-l.html *


____________________________________________________________
Do You Yahoo!?
Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk
or your free @yahoo.ie address at http://mail.yahoo.ie

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *