Michael,

My comments are inline with **:

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Michael L. Williams
Sent: Monday, June 25, 2001 9:02 PM
To: [EMAIL PROTECTED]
Subject: Re: Frame Relay acceptable DE packets [7:9746]


Kent..... I have some questions........ they're inline....

"Kent Hundley"  wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> Symon,
>
> Unfortunately, its not as simple as looking at the DE packets.  Simply
> looking at DE packets alone doesn't tell you anything really.  The reason
is
> that if the FR cloud doesn't experience congestion, those DE packets will
> get there just as well as the non-DE packets.  Some carriers encourage
their
> customers to use 0K CIR because "we don't oversubscribe our network", so
> _all_ packets are marked DE. (Sprint used to do this, don't know if they
> still do or not)

This is good...... I often heard that people would suggest 0 CIR so that
they could oversubscribe the #*&$  out of their network =)
Then when people's traffic didn't go through they could go "well we agreed
to carry 0"


** Can't speak to that, the only carrier I have seen that recommended 0 CIR
is 
** Sprint, and it seemed to work fairly well at the time, this is circa
1997.  
** They always claimed that they didn't over-subscribe they're network, so
no 
** reason to pay for CIR. Course, they're pricing for 0 CIR was inline with
buying ** CIR from other carriers, so in the end from a cost point it was a
bit of a 
** wash. 


> If you see the FECN's spike without a corresponding spike in the DE, that
> means your provider is experiencing congestion, but its on a backbone link
> and not your link.  This means the provider's links are over-subscribed
and
> your packets are likely getting dropped without being marked DE.

If this happens, and you sniff both sides and show that you're sending more
than you're receiving  (i.e. you prove that you have packets being lost
without being marked DE), isn't that a violation of your CIR agreement
(assuming it's > 0)?  Since nothing should get marked DE except for packets
over CIR, I can see how the logic makes sense, but does this happen often?

** Yes, and no.  It depends on how the carriers SLA's are written.  A lot of

** SLA's are written such that you could lose quite a bit of traffic for
very
** short periods of time and they would still be well within their SLA's.
For 
** example, if they guarantee %99.99 packet delivery and you transfer 1
Terabyte
** of data per month, they could still drop 10 Mbytes of traffic, which
could
** cause problems depending on how much was dropped in a given period.
** CIR is "guaranteed" only if the subscriber is not over-subscribed, but
even
** then if the carrier has an outage its probable that they will be 
** over-subscribed for the duration of the outage.  When the bits fill the 
** queues, a switch must drop traffic, DE or not.
**
** IME, you usually only see consistent congestion on international links.  
** Due to cost, it seems that every carrier is over-subscribed on the
** international links and some even mark every packet going across the link
** as DE regardless of CIR. (yes, I've seen it happen)  This sort of thing
** is obviously not in keeping with the spirit of the CIR agreement, but
again
** one needs to read SLA contracts very carefully as there are usually a lot
** of "weasel words" that benefit the carrier.
**
** In practice, FR seems to continue to work well and be cost effective, but

** it needs to be understood that sometimes packets will get dropped even if
** you don't exceed CIR.  If this happens consistently, its definitely an
issue
** to take up with the carrier.  With the exception of outages, its
definitely
** violating the spirit of agreements for a provider to oversubscribe their
CIR.
** 
** Regards,
** Kent




Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=10091&t=9746
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

Reply via email to