Conference 7.286::fddi

1297.0. "Bridge Rate Limiting" by VNASWS::HONISCH (Guenter Honisch NSTC Austria) Tue Mar 29 1994 11:12

A recently found that there are big gaping holes in a bridged Network...

A MDF (BRS) Cluster Customer had a complete DOWN Situation for 4 Hrs
(down = EVERYTHING   =>  All Cluster Nodes, Management Stations etc...)

This Situation was most likely caused by a broken Ethernet IF in a VAXft
sending Multicast Frames like mad. (there are no traces, sorry...)

    
I know of some other Instances where a bridged Net was flooded by either
broadcast, multicast or unknown destination pkts.

The only control we have, is Rate Limiting in newer bridges and Gigaswitch.

However, Rate Limiting is difficult to use for multicast traffic
I have to setup each MC Address separately, default is NO limiting

So its somewhat easy to use it for Broadcasts, but there are numerous MC
Addresses in this world, and I can't cover them all.

I have no mechanism against unknown destination address pkts

I discussed this Subjects with collegues and one german customer
(F.A. Juelich Mr. Stoff) who built special HW/SW solutions to fight this
Problem area and therefore has a lot of experience

Here is the Wishlist:
=======================

1. Overall Ratelimit Parameter for combined Multicast/Broadcast Traffic 
where you can define a base value for all Protocols
But still have the ability to override this for certain Protocols

2. Ratelimit Parameter for unknown destination packets
(could even be default on)

3. Ratelimit Parameter for overall Pkt Rate (better would be Bandwidth...)
to get a throttling mechanism for special cases.

Why?
Increasingly often I need transparent Connectivity beween 2 Segments, but don't
want the possibility of anything in the other Lan to flood me.
(i.e. Mgt LAN which has to survive in all instances, but needs connectivity to
the generic LAN)



Question:
=========

How does Rate Limiting work today ?
i.e. what Interval is used to average?
I think about a Scenario :  400 Pkts/sec   1000 Pkts/sec arrive
does it mean cutoff after 400 Pkts for the rest of this second, or is there
a "soft" mechanism to do this 

AND Who used it in real life, I did not find one implementation...
    
						Guenter
    

Interesting idea.  On the 900 at least, some variant of this would not be
difficult to implement, but nothing of this sort is currently available.

One key limitation (that would NOT be easy to change) is that all rate
limiting is done using a common limit.  In other words, any traffic that
is subject to the rate limit is "charged" against the same limit.  So if
the limit is, say, 500 per second, then that means 500 of any combination of
enabled multicast packets.

As far as I know, all implementations do rate limiting over a 10 ms period.
So a specified limit of 500/s is translated to a limit of 5 per 10 ms period.
At the start of each period, a counter is set to 5.  During the period, each
time a multicast packet is seen that is subject to the rate limit, the
counter is decremented.  If the count reaches zero, the packet is discarded.

	paul

    GIGAswitch has no rate limit for unicast packets with a known DA.
    GIGAswitch has separate rate limits for multicast/broadcast and
    for unknown-DA packets.  So GIGAswitch already provides some of what
    note .0 requested.

    There is no possibility of adding known-unicast-DA limiting to
    GIGAswitch.  On the other hand, GIGAswitch has fair arbitration at
    the packet level between conflicting traffic streams.  So the bridge
    will run just fine on the remaining ports if there's one babbling
    FDDI link in the switched network.  Since the unlimited traffic would
    have to be a unicast DA, only the target of the babbling traffic is
    vulnerable to receiver overruns.  The rest of the network should survive.

    At Gigaswitch i have at least equal speeds on the lines
    
    The main Problem will be in the interconnect of highspeed backbones to
    low speed lan's
    We need the good performance for scott bradner, but it hurts very often
    in practical applications
    
    The Customer I mentioned told me that they had to remove the Alpha
    servers from the FDDI Backbone, because they drove the ethernets into
    saturation
    We need a throttle mechanism to control this !
    
    At ethernet I can only use 2 Vitalinks with a modem eliminator to
    limit the bandwidth...
    
    
    					Guenter