Does the TSE work with topologies other than Ethernet?

No.  The TSE only works with versions of Ethernet such as standard, Fast, Gigabit, 10G Ethernet.  

Can the TSE be used with protocols other than IPX and IP?

Yes.  The TSE is aware of IPX and IP protocol headers for various frame types.  However, the TSE is designed to be non protocol specific.  Protocol identification can be accomplished in a variety of ways, including direct access to ECB data structures, which indicate protocol ID which can uniquely identify combinations of frame type and protocol.  For custom protocols, you have the ability to develop rules that match any data in the frame and the ECB. 

What is an ECB?

The Event Control Block.  It is an internal data structure used by the Netware OS to keep track of network traffic as it passes through the server.  The ECB often contains information useful in identifying frame types and protocols of the associated frame.

Do I need to handle ARP traffic as a special case?

Depends.  If you are dropping or filtering traffic, ensure your rule set takes into account the ARP traffic TCP/IP relies on.  This traffic is of protocol type 0806 ( rather than 0800 for IP ).  

Are sent frames processed differently from received frames?

Yes.  From the TSE's perspective, a received frames contains the raw frame including MAC and protocol headers.  Frames sent by the server, as seen by the TSE, do not.  This is because the raw frame has yet to be constructed by the protocol and frame type code just prior to being sent.   For common protocols and frame types, the TSE is "protocol aware" and will construct a facsimile of the raw outgoing frame from the send ECB.  This process allows you to create a single set of rules that test raw frames irrespective of if it is incoming or outgoing.

For custom protocols, or protocol and frame type combinations unfamiliar to the TSE, this process cannot be completed.  You must make two sets of rules to handle the send and receive cases separately. However, this is normally not a big deal.

Can the TSE Manage wire speed LAN traffic?

Yes.  The TSE has been tested with bursts of over 40000 frames a second, 10 times the rate expected even on busy servers. 

Exactly what do you mean by traffic shaping?  Can you elaborate?

Yes.  Traffic shaping was a term used to describe a specific process by which the rate of connection oriented traffic could be regulated.  This process manipulated the window size for connection oriented protocols.  Under this strict usage, a traffic shaper can manipulate the data rate of windowed, connection oriented protocols such as TCP and SPX.  This method results in no loss of frames, but generates additional ACK traffic and cannot be used to help with connectionless protocols such as IPX and UDP.   Extremely persistent hosts will still be able to exceed the desired rates resulting in ineffective management and additional network traffic.  Being protocol specific, it must be protocol aware and so is not a generic solution.

The TSE implements a different, commonly used, rate limiting mechanism that relies on queuing.  By queuing up excessive traffic and releasing it at a slower rate, the throughput is varied to any desired level.  Excess traffic that cannot be queued is dropped, however this happens only as a last resort.  The TSE can queue up to 8 seconds of network traffic for a given connection or traffic group.  This results in very low packet loss and encourages the protocol specific back off and TTL algorithms on hosts involved to assist in regulating the traffic.  Neither method is really "better" or "worse" they are just different.  However, as queuing can be applied to any protocol, as well as connectionless traffic, it can be fashioned into a more generic solution than can window size manipulation schemes.

Does the TSE implement load sharing?

No.  The TSE does not include the ability to load balance internet usage between two internet links, nor load balance requests to internal web servers, etc.   These functions typically require a layer 4-7 switch or dedicated load balancer.   You can, however, implement rate limits on multiple flows or multiple interfaces as well as handle DiffServ / TOS tagging, which may help you use the routing / switching equipment more effectively.  

Does the TSE manage traffic based on NDS user, group, container?

No.  While the TSE can, in conjunction with MAC2USER.NLM, provide a NDS user name in audit logs, web status pages, etc. - it does not allow you to directly specify rates based on NDS objects, group membership, etc.   Provided there is enough interest to justify further development of this functionallity, it is the next project on our list now that the TSE is is essentially "finished".  

Yes. with some minor modification. This issue has been partially resolved for the Open Beta release.  If you participated in the closed Beta or obtained an Early Access release, you will receive the latest NLM which will partially elevate the high rate accuracy issues.  The resolution of the queuing mechanism has been reduced to approximately 50 microseconds.    This should allow effective rate limiting to any arbitrarily high value up to 1 MB per second with less than a 10% discrepancy between the desired data rate and the actual throughput.  Data rates as high as 10 MB per seconds can be assigned, though with larger discrepancies.  In any event, the discrepancies do not represent a loss of data, only that the actual resultant data rate differs from the number you enter.

What is "bandwidth banking" and how does it work?

A means of allowing unused bandwidth to be banked up for use later.     Bandwidth banking can be enabled for a given data rate.  If enabled, the TSE will allow up to 60 minutes of unused bandwidth to be "banked up" for future use.  Suppose a 100K per second rate was specified, but only 50K per second was used, bandwidth banking allows future bursts of traffic to use the unused portion of the bandwidth quota.  To users, this seems a "more fair" way to enforce bandwidth limitations.  Frames which make withdrawals against the banked bandwidth are forwarded without delay until the banked bandwidth is withdrawn. 

The TSE queues traffic.  Do I need to tune my server parameters?

Possibly.  The TSE will "smooth" bursts of traffic and queue traffic that exceeds the traffic's data rate limits.  Windowing protocols such as SPX and TCP are "designed" to defeat latency by sending a train of frames requiring only a single acknwledgement.  The TSE will be forced to queue all but the first few frames of such a transmission.  You will typically need to tune the Minimum Packet Receive Buffers and Maximum Packet Receive Buffers to handle the number of frames the TSE will have to queue at any given time. 

The Minimum Packet Receive Buffers value sets the number of receive buffers allocated by the OS when it boots.  These are always available to be consumed.  Should the TSE queue more frames that this, the server will allocate additional buffers as needed, though very slowly, until the count reaches Maximum Packet Receive Buffers.  A good value for Minimum Packet Receive Buffers is 4 times the number of active clients using the server.  So for a server with 300 client connections, a value of 1200 will more than likely be OK.   You may notice that this has already been set very high by the configuration utilities for Border Manager or Novell's Web Servers. 

You only need to increase these values if the actual Packet Receive Buffers value in Monitor goes above the Minimum - meaning the server ran out and had to allocate additional buffers.  While the server is allocating new buffers, traffic may be lost and server performance will suffer temporarily until the  server allocated enough new buffers to meet the current demands.  This is a "normal" process for Netware - but it will be exaggerated by use of the TSE.
 

Has a price been set?

Yes.  See the Purchase link above for more information.

This information is subject to change at any time without notice. 

Does the TSE impact system performance?

No.    Obviously anything "extra" running on your server is going to use CPU time.  The TSE running on a Pentium / 133 based server can easily handle 2000 frames a second with only a 5% CPU load...  On faster servers the load is proportionally lower.  The CPU time used by the TSE is negligible.  Using connection oriented rates does increase the CPU load slightly because of additional housekeeping associated with maintaining connection information.  However this work is done during CPU idle time, which is wasted anyway.

My server's utilization has crept up a bit, did you just lie?

No.    Much of the TSE's work is done during the OS' IDLE loop, the perpetual loop the server runs when there is nothing else to do.  This utilization is not easily measurable by the CPU load calculations used by MONITOR.  Monitor looks at the amount of time spent in the IDLE loop rather than the amount of time spend running server processes, which takes a lot more effort.  The TSE uses idle time, reducing the time spent in the IDLE loop - which makes MONITOR think the server is busier than it really is.  Unloading and reloading MONITOR or unloading and reloading any NLM will trigger MONITOR to calculate a new baseline which makes the utilization calculation temporarily more "accurate."  The only good measure of CPU load is to use the Processor Utilization or Kernel  menu option.  Netware 5.x shows CPU load properly and Netware 4.xx shows the proper load indirectly by showing the correct percentage of CPU idle.   NetWare 5.x and 6.x report server utilization more accurately.

Does the TSE require much RAM?

No.   Considering what it does, it uses surpassingly little RAM.  The TSE asks for a single large memory allocation when it loads, typically from 300K to 3MB.  The TSE then manages this memory itself.  The memory is divided into 64 byte "nodes" which are used internally to store information.  The TSE will start with 3000 to 30000 of these nodes.  2 nodes are used for each managed connection and 1 node is used for each currently queued frame.   The bare minimum RAM configuration, requiring only about 400K of RAM, can be used to manage 1000 persistent connections.  The TSE has been run on Netware 4.2 with only 20MB of RAM, though this is obviously not a recommended configuration!

In real life a NW 4.xx server with 32MB RAM or Netware 5.x with 64MB RAM will suffice.  The recommended configuration is 64MB for NW 4.x and 128MB for NW 5.x.  Remember that packet receive buffers will also be necessary, and these consume lots of RAM.  The TSE has a small footprint, but for it to work properly, Netware must be healthy - make sure it meets Novell's recommended RAM requirements.

Does The TSE "like" or "dislike" certain NICs?

No.  So far there have not been any real issues regarding the make, model, speed, or bus type when it comes to the Network Interface.  The TSE rides on top of the Link Support Layer, LSL, which communicates through ODI drivers to the network hardware.  Cards from Boca, Intel, Novell, SMC, BayNetwork, have been used and all have worked without issue.  This includes embedded  NIC's in IBM hardware as well as old and cruddy 16-bit ISA cards.

Can the TSE "exactly" apply any desired data rate?

No.  The internal calculations for computing the data rate are performed down to nanosecond or microsecond resolutions, yes nanoseconds!   The TSE can accurately handle data rates >> 1MB/sec  / 10 Mbps.   The accuracy is somewhat dependant on server utilization.

If the queuing resolution of only .1 ms, is frame sequence preserved?

Yes.  Despite the fact that the queuing mechanism sees a .10 to .19 millisecond delay as being "the same." the delivery of frames for a given connection or traffic group is maintained as a FIFO queue.  What is not guaranteed is that traffic from different connections is FIFO relative to each other - since that is what a traffic shaper does, it prioritizes and manages traffic by retarding or advancing frames for one purpose over another.

Under TSE Beta 3 and TSE 3.1.0 and higher the TSE's accuracy is limited only by server utilization and the resolution of NetWare's own high resolution timer functions, typically < 50 microseconds.

Can the TSE desequence "similar" frames?

Yes.  But you have to do it on purpose. You can use a "Fixed, By Bytes" rate which literally imposes a variable delay based only on the size of the frame.  This is not a traffic shaping data rate, but rather a "fixed delay" which is not aware of the ETA of the last frame.  Under certain circumstances, a smaller frame would be delivered before a larger one, even if the larger one came off the wire first.  However, while a possible configuration, it is a case of you telling the TSE to do something undesirable and it following your instructions.  This is the only option combination which, by its very nature, can cause non FIFO behavior on selected traffic.

Does the TSE perform logging?

Well, kind of.  The TSE's logging capabilities are still focused around debugging.  There are an extensive list of debugging commands which dump rather unfriendly looking information about the internal working of the TSE.  This will be improved upon as the TSE is developed.  The TSE has the ability to dump all managed frames in ASCII format, dump information on the queuing process, the desired and actual queuing timing, connection identification.  However, all of these are extremely disk intensive on production systems and are designed only for debugging purposes.  Verbose versions of these logs can grow several MB per second!

Does the TSE show status information?

Well, kind of.  The TSE's monitoring capabilities are very rudimentary, as these capabilities will be developed through NDS.  The NLM's console screen shows several lines of information, most of which are debugging information, however it is pretty easy to see the volume of traffic managed by the TSE, the average depth of the TSE queues, and the current memory utilization.  Various debugging commands can dump semi-human-readable status information to the server console about rules and rates as well as the condition and status of bindings.  However it is all rather non friendly.

Is the TSE Novell "Yes" Tested and Approved ?

No.    Novell's "Yes" certification is available for certain classes of NLM applications, each with predefined testing procedures.  The Beta NLM has not been submitted for "Yes" testing as it is not the final release and approval on a beta release is not conferred upon derivative future production releases.  In addition, the TSE does not fall neatly into the predefined categories established by the testing center.  "Yes" certification will be sought on the first production release of the TSE.  It may not be possible to obtain "Yes" certification because of the lack of established testing criteria for NLM based bandwidth management software. 

Can I unload the NLM under load?

Yes.  This has been tested thoroughly.  The NLM does shutdown properly, even when requested to do so under severe load.   The TSE will try to deliver any queued frames prior to exiting.  This has been tested with over 1300 queued frames.  It is possible, under extreme conditions, that some frames will fail to be forwarded.

I get Resource error messages after unloading. Is this normal?

Yes.  Netware will display a message indicating the NLM failed to release resources.  The NLM waits a few seconds for the queue to empty, thus releasing all queued frames back to the OS.  For various reasons this state may never be achieved and the NLM unloads anyway.  This is not a "real" problem, as the Netware OS reclaims these resources unilaterally after the NLM unloads.  Under normal to severe loading conditions the NLM will cleanly exit. Most of these issues are resolved in the current version.

I loaded the TSE and see strange problems.  What do I do first?

Unload the NLM.  Type SHAPER DEBUG ALL, which will scroll various parameters to the screen ( which get captured by CONLOG ).  Then type SHAPER DUMP MEMORY to get a diagnostic memory dump.  Then use the SHAPER UNLOAD command to start a controlled shutdown of the NLM.  This method of unloading is preferable to using the UNLOAD command since it will not lock the server console while the NLM unloads.  Once unloaded, things should return to normal.  If not, you have a different issue unrelated to the TSE to address.  There should be no persistent effects of the TSE once it is unloaded.

I loaded the TSE and see strange problems.  What do I do next?

Look at your configuration and binds.  It is likely you inadvertently told the TSE to do bad things to your traffic.  Like accidentally rate limiting an entire interface's throughput rather than individual connections.  These misconfigurations can cause severe symptoms.  You may have bound the TSE to the wrong frame type so that your rules deal with the traffic incorrectly.  There may also be a bug in the TSE which you have exercised.

The TSE automatically unloads right after I load it.  Why?

There are various causes.  The TSE will bail out if certain conditions are not met or if some part of the initialization fails.  If an invalid command line option has been specified, the TSE will unload.  See the console for messages.  Most often there is a failure to allocate enough RAM.  The NLM tries to initiate a system wide garbage collection when it starts, this may not complete before the memory allocation request is made.  Loading the NLM again may resolve this problem - usually indicative of a lack of adequate RAM.  Other causes are resource tag allocation issues or an inability to obtain certain information from LSL.  In any event, the console should show messages indicating the source of the problem.  Future releases will be more resilient with respect to memory allocation issues.

The TSE unloads itself after running fine for quite some time.  Why?

There are various causes. The TSE performs consistency checks 18 times a second, during the clock tick interrupt.  Consistency checks of the queue are performed several thousand times a second during server idle.  These checks include monitoring the growth of the number of queued frames, overall memory usage, error conditions detected while processing connection tables, etc.

Any of these conditions will trigger the NLM to stop processing all frames and enter "bypass" mode - where all frames are processed by the server as if the TSE were not loaded.  The queue will be emptied as normal and in a few seconds will be empty.  Once "bypass" mode has been entered, the NLM may trigger a dump of its memory block, often capturing a snapshot of the offending data.  After the memory dump is completed, the NLM may unload.  When ever this happens, after the NLM is unloaded, you should make copies of the SYS:SHAPER.MAP, .MEM, and .LOG files prior to restarting the NLM.

Common causes for this include the queue growing to rapidly or when the NLM is running low on memory nodes, generally an indicator of an impending failure.  In the case of memory corruption, the NLM may be at fault because of the program bug, or another loaded NLM may have modified the TSE's RAM.  This mechanism protects the server from a catastrophic failure.

Oh great !    It AbEnd, now what?

Don't Panic.  First you have my apologies - which I am sure are of little consolation.  First, make sure the server is actually dead and no longer servicing user requests.  The server may actually be operating if the abend was recoverable.  If this is the case, it is safe to wait till users can be notified and the server taken down.  The sooner the better, though!

There are a few major threads of execution started by the TSE.  Most of these perform logging and monitoring functions which do not impact the actual management of the traffic, which happens outside of a standard NLM thread.  If the server suspends one of these, the NLM may still be managing traffic.  Do NOT try and unload the NLM after a recoverable abend... you will typically lock the console as the server perpetually waits for everything to exit cleanly - which never happens.  It is best to wait until a convenient time and DOWN the server.

After reboot, be sure to get a copy of the SYS:SYSTEM\ABEND.LOG, it is necessary for troubleshooting the AbEnd.

Oh great !    It spontaneously rebooted my server, now what?

Oh My!  First, you really have my apologies - which I am sure are of little consolation.  If the server spontaneously reboots without an AbEnd message there has been a problem executing the TSE's interrupt service routines.  On a Netware 5.x and sometimes on a Netware 4.11 or 4.2 server the ABEND.LOG may indicate the state of the server just prior to reboot.