Re: Counting Send DE Frames for Frame Relay MIB

artb@xylan.com Tue, 22 August 1995 21:14 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21315; 22 Aug 95 17:14 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa21298; 22 Aug 95 17:14 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa20781; 22 Aug 95 17:14 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21237; 22 Aug 95 17:14 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa21231; 22 Aug 95 17:13 EDT
Received: from xylan.XYLAN.COM by CNRI.Reston.VA.US id aa20736; 22 Aug 95 17:13 EDT
Received: from omni.xylan.com by xylan.com (4.1/SMI-4.1 (xylan-mgw 1.0)) id AA18141; Tue, 22 Aug 95 14:14:01 PDT
Received: from bluejay.UUCP by omni.xylan.com (4.1/SMI-4.1 (omni 1.1)) id AA11072; Tue, 22 Aug 95 14:13:58 PDT
Received: from xidc2.xidc by irvine.XYLAN.COM (4.1/SMI-4.1) id AA03376; Tue, 22 Aug 95 14:15:23 PDT
Date: Tue, 22 Aug 1995 14:08:08 -0700
X-Orig-Sender: iplpdn-request@IETF.CNRI.Reston.VA.US
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: artb@xylan.com
Subject: Re: Counting Send DE Frames for Frame Relay MIB
To: iplpdn@CNRI.Reston.VA.US
X-Mailer: Chameleon - TCP/IP for Windows by NetManage, Inc.
Message-Id: <Chameleon.4.01.4.950822140914.artb@xidc2.xidc>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"

> Caralyn wrote:
> As for the following suggestion, how would a network manager make use of this?
> Personally, I would like not to add this, but if there is good reason to add
> it and others like it, what the heck.

I think the object is useful, from the basic perspective that if you are/can
set the bit, its nice to know how many.  Also, if you are setting the bit
you can determine the percentage of traffic your sending with the DE bit set
(ie, how often you're exceeding CIR).


> James wrote:
> 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.

I don't agree with this.  At least according to the standards, when the end-user
sets the DE bit, the traffic should be accounted for in EIR/Be and not CIR/Bc.
(reference ANSI T1.606 Addendum 1 and ITU I.370).


> Fred wrote:
> This is a DTE MIB.
>
> 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.
>
> 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.

I don't agree that the switch is very likely to discard the traffic.  Certainly
there's a likelihood, and, if the switch is implemented correctly, a greater
likelihood than for non-DE traffic but there are other factors involved.  The
switch should discard the DE traffic if it is congested, but before it gets that bad
it should be generating some ECNs which should lower or stop the flow of DE stuff.
I've seen this work well in the lab and on some private networks where global policies
can be enforced, but I've also seen disasters on some public networks where its
not usually clear whats going on.

The most benefit I've seen from the DTE setting the DE bit is when its combined
with filters or some other mechanism to prioritize traffic.  When bandwidth
management is used to enforce CIR/EIRs the higher priority traffic is always placed
in CIR.  Another point is that if the network is setting DE bits, then this allows
the DTE to greatly influence what traffic is committed and what is excess.
Otherwise, its totally up to the network.  If there's a chance of traffic getting
discarded, its nice to try and influence the outcome so that for example routing
protocol traffic has a better chance of getting through.

Art

*******************************************************
Art Biesiada                       08/22/95 10:26:19
artb@xylan.com                     Voice:(714) 597-8042
Principal Software Engineer        FAX:  (714) 597-8342
XYLAN Corporation
15707 Rockfield  Suite 155F
Irvine CA. 92718
*******************************************************



*******************************************************
Art Biesiada                       08/22/95 14:08:08
artb@xylan.com                     Voice:(714) 597-8042
Principal Software Engineer        FAX:  (714) 597-8342
XYLAN Corporation
15707 Rockfield  Suite 155F
Irvine CA. 92718
*******************************************************