Subject: RE: [Ieprep] identification of packets

From: "King, Kimberly S." <[email-masked]>
Date: Thu, 5 Dec 2002 08:38:19 -0500

Bill said:
>The CPE routers aren't capable of manipulating anything or doing any QoS 
>or anything like that.

I'm not following you here.  Are you saying you don't believe a CPE router
can make a decision about how to queue packets moving from the LAN to the
tail circuit?  I know a lot depends upon the definition of "manipulating
anything" or "doing any QoS" but can't some such routers set DSCP based upon
a variety of information such as protocol, etc.  Can't such routers support
a low latency queue and perhaps other queues served in round-robin fashion
with a scheduler that tells what goes when or something of that form?  Of
course, this doesn't come standard -- one has to set it up this way -- but
I'm not following what you mean by CPE router not being able to manipulate
or do any QoS, etc.  Am I missing something?

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

---

From: Bill Woodcock <[email-masked]>
Date: Thu, 5 Dec 2002 05:41:55 -0800 (PST)

On Thu, 5 Dec 2002, King, Kimberly  S. wrote:
    > tail circuit?

I'm making a generalization...  While it's quite possible to put a capable
router in the CPE role, and to have a capable person responsible for
configuring it and maintaining it, that combination is so rare as to be
negligible, because it would be three orders of magnitude more expensive,
with too small a return on that investment to be worthwhile for the vast
majority of customers.

CPE routers used to be a lot more similar to access and core routers than
they are today.  At that time, they ran similar operating systems, and had
similar, if slower, processors, and were configured similarly, if more
simply.  And the amortization period on CPE is typically a lot longer than
on infrastructure, so some of those still exist out there.  However,
they're typically on older lines, ADNs and frac T1s and so forth, and
generally going out of service over time.

Newer CPE routers don't have these capabilities, and don't have fast
enough processors, or operating systems with legacy QoS support, and
they're not designed to be configured by operators, anyway.  Everything
gets more efficient over time, so excess feature support goes away, and
new vendors don't bother to support old stuff like IPX or X.25 or QoS.
They need to keep prices down, so they won't go out of business so
quickly.

                                -Bill

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 6 Dec 2002 08:52:50 -0500

On Thursday, Dec 5, 2002, at 08:38 America/Montreal, King, Kimberly S. 
wrote:
>  Can't such routers support
> with a scheduler that tells what goes when or something of that form?

Many COTS routers can do that today.  And since it is not intrinsically
an "over the wire" feature, that sort of class-based-queuing isn't 
something
that IETF would standardise.  The most common scheduling algorithms are
WFQ, RED, and hybrids/variations on those two.

Ran

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 6 Dec 2002 09:03:09 -0500

On Thursday, Dec 5, 2002, at 08:41 America/Montreal, Bill Woodcock 
wrote:
> they're not designed to be configured by operators, anyway.

I'm not sure I really believe this is as common today as the above 
suggests.
At least several vendors still make/sell CPE routers that have those
capabilities.  (I don't want to get into vendor-specific conversations
on list, but will happily chat in more detail in private email.)

> Everything gets more efficient over time, so excess feature support 
> goes away,
> and new vendors don't bother to support old stuff like IPX or X.25 or 
> QoS.

Some vendors find that the best way to reduce costs is to build custom
ASICs or use commodity ASICs.  In either case, implementing QoS queuing
and filtering in a custom ASIC is straight-forward if the vendor thinks
about it.  At least some commodity ASICs have the necessary support 
already.
And at least one vendor chose not to rip out IPX support in later 
chipsets
simply because cost of removal exceeded cost of leaving it in place.

Now this is not to say that "all vendors" have any particular feature 
set
that one might need, just that some/many likely do have it and that the 
ability
to buy economical products with those features does not appear to be 
disappearing
for now (as near as I can tell).

Ran
[email-masked]

---

From: Bill Woodcock <[email-masked]>
Date: Fri, 6 Dec 2002 21:42:57 -0800 (PST)

On Fri, 6 Dec 2002, RJ Atkinson wrote:
    > capabilities.

Oh, no argument there...  Lots of vendors are still designing and building
high-end equipment which they're trying to sell as CPE...  The issue is
that fewer and fewer customers are buying it as such.  More and more are
getting Ethernet-to-Ethernet or DSL-to-Ethernet devices instead.

                                -Bill