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 *******************************************************
- Counting Send DE Frames for Frame Relay MIB Alan Bartky
- Re: Counting Send DE Frames for Frame Relay MIB Caralyn Brown
- Re: Counting Send DE Frames for Frame Relay MIB James Watt
- Re: Counting Send DE Frames for Frame Relay MIB Fred Baker
- Re: Counting Send DE Frames for Frame Relay MIB Alan Bartky
- Re: Counting Send DE Frames for Frame Relay MIB artb
- Re: Counting Send DE Frames for Frame Relay MIB James Watt
- Re: Counting Send DE Frames for Frame Relay MIB Fred Baker
- Re: Counting Send DE Frames for Frame Relay MIB Alan Bartky
- Re: Counting Send DE Frames for Frame Relay MIB Caralyn Brown