Subject: RE: [Ieprep] access links

From: "King, Kimberly S." <[email-masked]>
Date: Thu, 14 Nov 2002 13:36:32 -0500

Kimberly said:
> > I read this statement as best effort transport is 
> sufficient due to the
> > infeasibility of providing anything different.
> >
> > Those apposing the statement, please provide a feasible alternative.
> 
> 
Henning said:
> It is pretty clear that there are alternatives. 

Let me remind you of the chain of events.  I suggested:

"Problem statement????  Everyone at the ETS location wants to make calls at
the same time and the access link can't handle all that voice traffic so
conversations degrade so much as to be unusable. "

and 

"Potential solutions for problem...define the appropriate codecs, get a big
enough access link, provision QoS on CPE or more drastically pay for QoS to
be deployed on ISP router that faces the customer site, etc."

I was then informed that this was not an acceptable problem statement by An
and Steve.
An stated:
>The problem with this is that you don't know the locations where emergency
>occurs  in advance. You can't provision your access links everywhere around
>the country. And that is not at all cost effective. If there is no way of
>differentiating traffic, then the best effort traffic is best effort."

What this does is say that the access link in question is one that can not
be determined in advance.  This means one can't count on your CPE router
being provisioned for DiffServ or other QoS.  You can't even count on
knowing who the ISP is on the other end of that access link and whether they
provide any QoS.  Thus, I repeat my question about finding a feasible
alternative to layer 3 QoS besides best effort transport over an arbitrary
access link.

Something has happened here that is true in general.  Each constraint
(requirement) likely narrows the solution space.  If you ask for everything
under all conditions, the solutions space is likely to be nil.  

Kimberly
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 14 Nov 2002 20:11:14 -0500

On Thursday, Nov 14, 2002, at 13:36 America/Montreal, King, Kimberly S. 
wrote:
> being provisioned for DiffServ or other QoS.

or even whether that CPE router has implemented *any* form of QoS that
could be enabled or whether the person with the privileged/config 
password
and appropriate clue is around to reconfigure it.

Most access routers are selected on the basis of lowest price.  This 
normally
means that they are implemented in a general purpose CPU (not ASIC, not 
NP).
CPU-based routers are the ones that are most likely to have forwarding
performance drops when more features (e.g. DiffServ, ACLs, RMON) are 
enabled.
One widely deployed T1 access router cannot forward at T1 line-rate once
QoS and ACLs and stuff are enabled.  It can forward at T1 line-rate if 
those
things are turned off.  Most users don't test for this before 
purchasing.

So the access routers are the ones MOST LIKELY to have degraded 
performance
(see Bill Woodcock's example) when QoS is enabled.[1]

Ran

[1] The two kinds of equipment LEAST likely to have degraded performance
with QoS enabled are core routers and gigabit switches -- because those
are most often (not always) built out of custom ASICs...