![Radware Alteon Application Manual Download Page 769](http://html.mh-extra.com/html/radware/alteon/alteon_application-manual_781134769.webp)
Alteon Application Switch Operating System Application Guide
Bandwidth Management
Document ID: RDWR-ALOS-V2900_AG1302
769
Application session capping is especially relevant in today's world of peer-to-peer applications that
require a large amount of network bandwidth. It enables the administrator to cap the number of
sessions of an application assigned to each user. In this way, peer-to-peer (and other such non-
business applications) can be limited or completely eliminated on the network.
Note:
For the purposes of this feature, a user is defined as a unique source IP address and the
application is identified based on a bandwidth contract
Application session capping functions by creating an entry in the session table that designates the
contract/user combination. Whenever a new session is created, this entry is checked against
existing sessions in the session table and, if a match is made, the maximum sessions value is
queried. If the maximum sessions value has been reached, the new session is dropped. If the value
has not been reached, the session count is incremented and the session is allowed to continue.
Notes
•
Application session capping is not supported when a contract is assigned to a port, VLAN, trunk,
or virtual service.
•
Application session capping does not support an iplimit contract based on DIP. It does, however,
support an iplimit contract based on SIP.
Rate Limiting Timeslots
For rate limiting contracts, metering of individual traffic flows is done using several timeslots per
second. The timeslot traffic limit is the traffic that is sent for a particular contract for every timeslot
corresponding to the contract's rate limit, or the hard limit as initially calculated.
For any contract there is one timeslot traffic limit for each egress port. The timeslot traffic limit is
calculated from the hard limit. The timeslot traffic limit is the amount of traffic that corresponds to
the hard limit per second, divided by the number of timeslots per second.
Traffic is transmitted for every timeslot as long as the traffic is below the timeslot traffic limit for the
contract. Any traffic that exceeds the timeslot traffic is discarded.
Traffic Shaping
A traffic shaping contract establishes queues and schedules when frames are sent from each queue.
Traffic is shaped by pacing the packets according to the hard, soft, and reserve limits. Each frame is
put into a managed buffer and placed on a contract queue. The time that the next frame is supposed
to be transmitted for the contract queue is calculated according to the configured rate of the
contract, the current egress rate of the ports, and the buffer size set for the contract queue. The
scheduler then organizes all the frames to be sent according to their time-based ordering and
meters them out to the port.
When packets in a contract queue have not yet been sent and the buffer size set for the queue is
full, any new frames attempting to be placed in the queue are discarded.
For traffic shaping contracts, a queue depth is also associated with a policy. A queue depth is the
size of the queue that holds the data. It can be adjusted to accommodate delay-sensitive traffic
(such as audio) versus drop-sensitive traffic (such as FTP).