Can newer CISCO routers throttle IP in response to Frame Relay BECNs?

Can newer CISCO routers throttle IP in response to Frame Relay BECNs?

Post by Mike Berkl » Wed, 29 Nov 1995 04:00:00



We're experiencing some congestion problems on a Frame Relay line from
Victoria to Montreal and wondered whether any of CISCO's newer routers
could throttle IP in response to Frame Relay BECNs.

Our local access to FR is faster than our CIR (why else use FR :-),
which is normally very good.  Unfortunately, when the frame relay line
between Vancouver and Toronto becomes congested, our CISCO IGS router
continues to send information at 400% of our CIR even though BECNs are
being sent.  Because of the congestion, frame relay then drops 3/4 of
our packets, causing delays and retransmissions, which further degrade
`real' performance.

According to the service provider, it appears that the problem is
related to CISCO routers not using Frame Relay BECNs (Backward
Explicit Congestion Notifications) to throttle IP traffic.  Instead
the CISCO router continues to send IP data to the frame relay system
at the local connect rate of 256 Kps until the frame relay switch's
input buffer (64K bits) is full.  When the buffer is full and
congestion control is in effect, the frame relay switch drops all new
packets.

Note that this problem has nothing to do with how many applications
are using the line.  A single FTP session is sufficient to trigger
congestion related problems when congestion control is in effect on
the frame relay network.

I have attempted to fix FTP to not swamp the frame relay switch by
reducing the TCP window size (in wu-ftpd).  This seems to have the
desired effect on congestion situations, but seriously reduces
non-congested performance due to turnaround time.  Furthermore,
limiting the TCP window size for individual FTP sessions will have no
effect other protocols nor on multiple FTP sessions.

Does anybody have any suggestions on how to fix this problem?

(And if I manage to find a solution for the congestion problem, does
anybody have a suggestion on how to calculate a good TCP socket buffer
size for WAN connections?)

Thanks

Mike Berkley
-------------------------------------------------------------------------
Canadian Centre for Climate Modelling and Analysis
Atmospheric Environment Service
University of Victoria
P.O. Box 1700
Victoria, BC  V8W 2Y2
CANADA


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

 
 
 

Can newer CISCO routers throttle IP in response to Frame Relay BECNs?

Post by Paul Blakesl » Thu, 30 Nov 1995 04:00:00


On 28 Nov 1995 in article <Can newer CISCO routers throttle IP in response


Quote:>Does anybody have any suggestions on how to fix this problem?

More bandwidth should do it.
Playing priority queuing games (11.0) will help some, but with the extent
of the problems you described it would most likely only serve as an
exercise to convince your boss to shell out the bucks for an increased port
speed and CIR.

Good luck

PRB

 
 
 

Can newer CISCO routers throttle IP in response to Frame Relay BECNs?

Post by Andersen, Jen » Thu, 30 Nov 1995 04:00:00


Paul,

Can wieghted fair queueing be applied to subinterfaces ?

We have a hub site with access speed of 256 Kbps to the frame-relay network.
Several of the remote sites have CIR values of 16  Kbytes
A lot of PC's runs with window size of 16 K bytes

This means that a window of 16Kbytes can be send to the frame-relay switch
with 256 Kbps for each TCP session. From here it is send accross the network
at 16 Kbps.
All interactive traffic entering the switch after this window, will have to
wait for it
to be transfered to the remote site.

I have seen ping response times of 5 to 10 seconds !
(At which time all communications dies of course)

Normal custom queueing have no effect, because the 16 Kbyte is buffered in
the frame-relay switch, which seems to have a hughe buffer for each PVC.

Best regards

Jens Elmo Andersen / BT France


 ----------
From: cisco-forw
To: Mike Berkley
Cc: cisco
Subject: Re: Can newer CISCO routers throttle IP in response to Frame Relay
BECNs?
Date: Wednesday 29 November 1995 07:45


Quote:>We're experiencing some congestion problems on a Frame Relay line from
>Victoria to Montreal and wondered whether any of CISCO's newer routers
>could throttle IP in response to Frame Relay BECNs.

The answer to your question is, currently, no. If you have
a Sevice Level Agreement (SLA), I would suggest pidgeon-hole'ing
your frame-relay provider to provide an explicit explanation on
why you are discarding traffic, regardless of CIR.

The only protocols which respond to frame-relay congestion information
in a routed network environment are DECnet IV and CLNS. If you are using
either of these protocols in your network, then yes, they will respond
frame-relay congestion info.

I would suggest, in your case, that you consider Weighted Fair Queuing,
which will allow resource-intensive applications (such as FTP) not
to squelch other more sensitive applications (such as TELNET).

Weighted Fair Queuing is a traffic priority management algorithm
introduced in IOS 11.0 that identifies traffic streams and then breaks
up the trains of packets belonging to each stream to ensure that the
capacity is shared fairly between individual traffic streams.

 - paul

>Our local access to FR is faster than our CIR (why else use FR :-),
>which is normally very good.  Unfortunately, when the frame relay line
>between Vancouver and Toronto becomes congested, our CISCO IGS router
>continues to send information at 400% of our CIR even though BECNs are
>being sent.  Because of the congestion, frame relay then drops 3/4 of
>our packets, causing delays and retransmissions, which further degrade
>`real' performance.

>According to the service provider, it appears that the problem is
>related to CISCO routers not using Frame Relay BECNs (Backward
>Explicit Congestion Notifications) to throttle IP traffic.  Instead
>the CISCO router continues to send IP data to the frame relay system
>at the local connect rate of 256 Kps until the frame relay switch's
>input buffer (64K bits) is full.  When the buffer is full and
>congestion control is in effect, the frame relay switch drops all new
>packets.

>Note that this problem has nothing to do with how many applications
>are using the line.  A single FTP session is sufficient to trigger
>congestion related problems when congestion control is in effect on
>the frame relay network.

>I have attempted to fix FTP to not swamp the frame relay switch by
>reducing the TCP window size (in wu-ftpd).  This seems to have the
>desired effect on congestion situations, but seriously reduces
>non-congested performance due to turnaround time.  Furthermore,
>limiting the TCP window size for individual FTP sessions will have no
>effect other protocols nor on multiple FTP sessions.

>Does anybody have any suggestions on how to fix this problem?

>(And if I manage to find a solution for the congestion problem, does
>anybody have a suggestion on how to calculate a good TCP socket buffer
>size for WAN connections?)

>Thanks

>Mike Berkley
>-------------------------------------------------------------------------
>Canadian Centre for Climate Modelling and Analysis
>Atmospheric Environment Service
>University of Victoria
>P.O. Box 1700
>Victoria, BC  V8W 2Y2
>CANADA


>-------------------------------------------------------------------------

 --
Paul Ferguson                                           ||        ||
Consulting Engineering                                  ||        ||
Reston, *ia   USA                                 ||||      ||||
tel: +1.703.716.9538                               ..:||||||:..:||||||:..