Conference 7.286::fddi

You should search this notes file for the info you are looking for. There is 
a lot of info regarding your subject.

See note 972, reply 1 for starters...

	paul

    re .1
    
    I don't feel like getting into a bit of name calling but before someone   
    makes a "suggestion" that there are lots of topics relating to void   
    frames in this conference, perhaps he/she should do a DIR/title=void (3   
    entries, 1251.2 was the only thing close) or show keyword/all (one   
    entry under void_frames (1251.2) and see how really few entries there   
    in fact are.
    
    If searching by title or keyword is an inappropriate way to search out
    information, too bad.  I DO NOT HAVE TIME TO READ EACH AND EVERY NOTE
    with titles like "WHY DO WE DO THESE THINGS".  Perhaps people who make
    entries here could spend a little more time to use descriptive titles.
    
    re .2
    
    Paul, thanks for the tip

>    If searching by title or keyword is an inappropriate way to search out
>    information, too bad.  I DO NOT HAVE TIME TO READ EACH AND EVERY NOTE
>    with titles like "WHY DO WE DO THESE THINGS".

Another technique I use is the VAXnotes SEARCH command.  You could have used:
	Notes> SEARCH "VOID FRAMES"
to get a search started.  Then enter:
	Notes> SEARCH
without an argument to find the next note with that same string.

This is slower than a directory or keyword lookup, but much faster than
scanning notes visually.

re .3

I wasn't making s smug reply, I was simply stating all you have to do is a 
little research. Not only you don't have time, but other people don't have time
to search through the notesfile for your questions. It was nice of paul that 
he had a pointer to the correct note to give you.

I added a keyword on the note in question.  Which brings me to a lesson
learned: it's a good idea to put a keyword on when you write a note that
has a detailed explanation of something and is likely to be useful for
reference much later.

	paul

    In order to understand the utilization issue at JP Morgan, I have been
    reading an article by Henry Yang and KK Ramakrishman of Digital titled
    "A Ring Purger for the FDDI Token Ring" (published 90 or 91, I have a
    very dog-earred copy" with no publication information) and it states: 
    "In the worst case, with the minimum value of TTRT and the value of D
    -> 0, the percentage loss in the maximum available bandwidth of 0.22%. 
    For a typical ring, with 20 stations, and a 4 millisecond TTRT, the
    reduction in the maximum available bandwidth is of the order of
    0.135%".
    
    Since Chung Szeto is seeing a utilization increase of 6 to 8% with a
    Network General Sniffer; I need to ask two things:
    
    Are we implementing Ring purging in the DB900's and the GIGAswitch the
    same way we did for the DB620's (in other words according to the
    paper)? or do we have a problem here?  (I'm trying to get hold of
    someone in GS engineering and the DB900 group who could clarify this,
    Anil Rijsinghani is pretty confident that we have done things properly).
    
    Is the sniffer broken?   (I read that tekalec has problems too)
    
    Have a good weekend!
    
    Tom Herendeen

	First, all DEC FDDI products use the same Ring Purger.

	Second, 6-8% used by voids DOESN'T mean that you have only 92-94%
	left for non-void frames.  As the amount of "real" (non-void) traffic
	increases, the number of void frames will decrease.

	Luc

There's more to this than one number can summarize, and you also have to keep
in mind that increased utilization, or increased packet rate, does not 
equal lost capacity.  There's a lot more detail in that paper, but let me
summarize here:

The purpose of the ring purger is to remove "no owner" frames (and other
extraneous junk) from the ring.  No owner frames can cause a high load 
on end systems, and may persist for a long time in the absence of the purger.
They are generated by bit errors on the wire, and also appear to be created
(in large numbers) by certain bad FDDI implementations (not ours).

The mechanism: each time the ring purger sees a token, it sends two void
frames with its own SA/DA in them, followed by the token.  It then strips
all packets until it receives its void frames or a token.  This removes any
circulating (no owner) frames from the ring.  The result is that any no-owner
frame will live for at most ONE additional rotation around the ring, i.e.,
no packet will ever travel around the ring more than twice even if its owner
failed to strip it.

The performance impact on the ring:

1. The token is replaced by two voids plus token.  So the token arrival at
   downstream stations is delayed by the time it takes to transmit two void
   frames, which is 4.48 �s.  (Henry and KK use 5.08 �s; I'm not sure why.)

2. If the ring is 100% busy (i.e., as busy as the protocol allows it to be)
   THEN AND ONLY THEN does the space occupied by those two void frames reduce
   the ring capacity.  On each token rotation (which is once per TTRT on average),
   4.48 �s is taken away.  On each token rotation, TTRT-D (D = ring latency)
   can be sent.  If you set TTRT to the minimum, and D = DMax (i.e., an
   enormously big ring with minimum TTRT) then you get 2.227 ms of traffic
   per token rotation.  So losing 4.48 �s means a capacity loss of 0.2%.

3. If the ring is less than 100% busy, then some of the time the ring is
   carrying idles rather than data.  Suppose that the ring is 99% busy.  That
   means that you have TTRT/100 idle after each token; for TTRT = 4 ms that
   means 40 �s of idles after the token.  If you now turn on the ring purger,
   you replace the pattern "Token, 40 �s idle" by "Void, Void, Token, 35.52 �s
   idle".  In other words, at any load below 99.8%, there is NO, repeat, NO,
   loss in throughput.  All that happened is that 4.48 �s of idles are replaced
   by a Void (and of course the token was delayed by that amount, as stated
   in (1) above).

The behavior observed by a network analyzer: each time the token passes by,
the analyzer will see two voids followed by the token.  Now remember how
the timed-token FDDI MAC protocol works: if the ring is completely idle, no
station is capturing the token, so the token rotates once per D (D = ring
latency).  So every D, the analyzer will see two voids.  For example, if you
have a ring with a 100 �s latency -- a nice modest size ring -- the analyzer
would report 20,000 voids per second.  If you look at the number of bytes
in a Void frame, and the raw capacity of the ring, you might conclude that
the ring has 2% utilitization.  But that is an incorrect conclusion, since
the Void frames are really no different from idles.  (It would make as much,
or rather as little, sense to count the "traffic" of tokens as "utilization".)

As you increase the load, the token rotates more slowly, since it is captured
and held while a data packet is sent.  For example, at 50% load, the token
rotates once per 2D.  So the analyzer will see void frames occurring at 1/2
the rate it saw when the ring was idle.  But again, that is not "utilization"
in any sense.

In summary:

1. The purger will clean up no-owner frames and improve your network
   reliability and performance.
2. The presence of the purger increases your transmit latency by less than
   5 microseconds.
3. The presence of the purger has ZERO effect on throughput unless the ring
   load is greater than 99.8%.
4. At ring loads greater than 99.8%, the purger reduces the capacity of the
   ring by at most 0.2% (in a very extreme configuration) and by under 0.1%
   in any reasonable configuration.

For more details, see the original paper, in Proceedings of the 16th Conference
on Local Computer Networks, 1991, IEEE;  ISBN 0-8186-2370-0.

	paul

    Paul-
    Thanks for the EXCELLENT synopsis!  and for your time too!
    
    The pointer to the original doc is appreciated too, my copy has several
    unreadable sections.
    
    Tom H.