[c-nsp] traffic shaping inbound wan?

[Brett Frankenberger]

On Fri, Jan 13, 2006 at 06:18:03PM +0100, Gert Doering wrote:
> Hi,
> 
> On Fri, Jan 13, 2006 at 10:54:42AM +0100, Mikael Abrahamsson wrote:
> > business, placed at the customer prem. The customer has no interest in my 
> > shaping them, but I do. They have an interest in their connection working 
> > what so ever, so having something managable at their prem so I can monitor 
> > my connection to them makes perfect sense though.
> 
> Actually, the customer wants to do shaping, to make sure they can make
> best use out of their commited bandwidth.
> 
> *You* want to do policing.  
> 
> "Send me no more than X mbit, or I will just drop it, no mercy".

The problem with that is that if the customer doesn't shape, their
performance will be horrible.  (With shaping, TCP slows down as the
queue length builds and you get a graceful slowdown and only minimal
packet loss ... with raw policing, the dropped packets cause TCP to be
nearly continuously in slowstart.)

So, a customer has the option of implementing their own shaping and
using a provider that does policing, or outsoutcing the shaping
function to their provider.  It is, of coure, easier (and thus,
presumably, cheaper) for a provider to do policing, so the customer is
faced with deciding between paying more for service or paying to have
shaping implemented on their end (if they don't already have hardware
and engineering talent capable of doing it).

At the low end of the market, the perception is going to be that the
subrate service from "ISP that does policing" is slower than the
service from "ISP that does shaping" and the policing provider will be
at a disadvantage in the maerket.  At the higher end of the market, the
customers might understand the underlying issue and the tradeoffs
involved.

     -- Brett