From: johngibson1541@yahoo.com
Date: Sat Feb 17 2007 - 18:53:11 ART
OK, I think you are correct. The documentation is a bug.
But I don't understand why you use Be.
Yes, you make the "Target/Average" field "512000/300000" , but I think
the "Average" part, 300000, is not in use.
Also, no one says the policer on the other end of the cable uses Be. If
the policer is not using Be, those packet sent in Be bits are considered
excess. But no one says our packet should not be treated as excess.
I can not imagine how we configure a shaper without considering what
the policer is doing and be able to predict how our packets will be treated.
I think the peak rate shaping is always NOT written in the written contract
between the provider company and the cusumer company. I don't know how
such a contract look like. I don't read my home cable modem agreement. It
downloads pdf files at 200KB/s. I don't read bills. I use automatic bill pay.
I think the peak rate shaping is meant to be used to by the provider as a
treat to operators, administrators.
In the morning, the provider operator called and said "Hey, send as many
packets as you want, I don't policy you today". You ran the "shape peak"
command. At noon, his boss came in and questioned his practice. Soon, the
provider operator called and say "sorry, my boss came in, lets go back".
You run the "shape average".
So, to make those morning to noon and many times in between changes
, I think we should do "shape peak 512000 128000 0".
I found 2 bugs before where 224.0.0.18(VRRP) was mistaken as 244.0.0.18, and
BGP as-path originator _54$ was was mistaken as ^54_. They corrected
the as-path problem about half a year after I spotted it. Don't know when
they will fix the VRRP bug and this shape peak bug.
John
This archive was generated by hypermail 2.1.4 : Thu Mar 01 2007 - 07:38:47 ART