[c-nsp] traffic shaping inbound wan?

[Oliver Boehmer (oboehmer)]

Mikael Abrahamsson <> wrote on Friday, January 13, 2006 10:55 AM:

> On Fri, 13 Jan 2006, Oliver Boehmer (oboehmer) wrote:
> 
>> As Linn has already said: Once the packet has been received on an
>> interface, we cannot queue it as there are no suitable queues on
>> input. It just doesn't make sense.
> 
> Well, actually for an ISP it does. An ISP wants to be able to do
> queueing bidirectionally on the customer facing interface in the case
> where no dedicated CPE is available, ie when you do L2 aggregation
> directly into an PE router.

i.e. when the access speed is higher than the subscriber speed, right.

Not sure if this is a chicken & egg thing, but isn't the QoS/business
model in this case "Dear Mr. Customer, you can send me 20 Mbit over this
100Mbit connection, and I'll drop the egress, possibly taking some peak
into account. If you need some preferred treatment for certain traffic
(which is more than a policer, even a color-aware policer is able to
provide), you need to do this at your side.".

> I know hw manufacturers doesn't see it this way, which is sad. Having
> to purchase an expensive L3 CPE just to be able to do bidirectional
> shaping might sound good if you're an equipment manufacturer, but as
> an ISP I would rather not have a device that does a lot of critical
> things for my business, placed at the customer prem. The customer has
> no interest in my shaping them, 

"shaping" or "policing"?

> but I do. They have an interest in
> their connection working 

define "working"

> what so ever, so having something managable
> at their prem so I can monitor my connection to them makes perfect
> sense though. 

Hmm, not sure I follow. You say "don't want to buy L3 CPE" and "want to
have something managable on their prem" in the same paragraph? This
"something" could do the queuing.. did I miss the point?

	oli