Re: Counting Send DE Frames for Frame Relay MIB

[Alan Bartky <[e-mail]>]

Fellow Frame Relay Mibbers -

I have some comments/responses to James Watt's and Fred Baker's comments
on DTE DE Frames Sent MIB object.  Also some additional comments after
that.

**********************************
Comments on James Watt's comments
***********************************

James Watt of Newbridge writes

>I would suggest that if we absolutely must add this object, we add
>text that reminds the implementor/user that the network will classify
>the traffic as normal or excess based on CIR/Bc/Be and _not_ the DE bit
>although it may still use the DE bit to determine discard preference.

My point was exactly that there are DTEs that do indicate DE as a
discard preference.  I don't think we need clarification on CIR/Bc/Be
as this is a "DTE MIB" and we only need document what the DTE uses
the DE bit for.


**********************************
Comments on Fred Baker's comments
***********************************


Fred Baker at Cisco writes:
>
>This is a DTE MIB.
>

DTEs may set the DE bit as an indication of discard preference.  It
is true that if a router is only running IP, there probably is not
much need in setting DE.  If a router is running IP and other protocols
using RFC 1490, using DE is the only way to tell the network preference
of one protocol over another as far as which to discard first when the
network gets congested.

>If the switch is correctly implemented, when the DTE sets DE, the switch is
>very likely to simply discard the traffic, due to the way excess burst is
>usually configured. Therefore, setting DE is, in most cases, asking the
>switch to discard the traffic.

My experience with several switch vendors and real networks is the
big problem with "unregulated flow" DTE Frame Relay Implementations
(those that can't set DE and/or regulate the flow below Be+Bc) is
that the blindly send frames to the network and do not pace the flow.
Once the switch receives data greater than Be+Bc it throws away the 
data.  When I was working for Sync Research, our implementation had
flow regulation,  setting of DE, and priority based on protocol (i.e.
IPX, IP, SNA/LLC etc.)

The combination of the three gave a very effective mechanism to
prevent data loss.  And setting DE worked very well in giving preference
to the traffic the user wanted (usually they would set SNA/LLC to not
set DE and IP/IPX to set DE).
  
>
>Therefore, I can think of very few good reasons for the DTE to ever set DE.
>I can think of (have heard) a few that sound good until you think through
>the traffic timing, but none that (a) actually prioritize traffic and (b)
>do not cause it to be lost in the network.

As stated above, the Sync Research implementation worked fine.  DE was
used as an effective mechanism to indicate discard preference without
data loss (unless the network was congested, in which case the DE bit
did it's job).


*************************************
Additional comments
*************************************

1) For implementations that support setting of DE, it is useful to
determine how many frames are set with DE versus those that are not.
By having the manager get statistics from both DTEs you can also
get an estimate of the how many frames are getting though with 
or without the DE bit set (e.g. If the count of DE bits is higher
on the receiving side than the transmitting, then the flow is
going above Bc and the network is setting DE on frames
that the DTE did not set it on).

2) One problem in diagnosing networks is correlating the counts
between two devices.  RFC 1604 for switches has a count of
frames received with the DE bit set.  The DTE MIB would correlate
this if you compare the DTE counts with the DCE counts.  The MIB object
in RFC 1604 is:

 frPVCEndptInDEFrames OBJECT-TYPE
     SYNTAX  Counter32
     MAX-ACCESS  read-only
     STATUS  current
     DESCRIPTION
             "The number of frames received by the network
             (ingress) with the DE bit set to (1) for this PVC
             end-point."
     ::= { frPVCEndptEntry 15 }

3) For implentations with priority that use the DE bit, it
gives a quick indication of frames sent by the Frame Relay
DTE that are perceived as less important (versus the ones
that are sent with the DE bit reset).

4) For implementations that can't set the DE bit, this statistic
is an easy one to implement (always return 0).  


Regards,

Alan

**********************************************************
Alan K. Bartky                       Email:[e-mail]
Principal Software Engineer          Voice:[phone]
XYLAN Corporation                    FAX:  [phone]
15707 Rockfield Avenue Suite 155F
Irvine CA. 92718
**********************************************************