Re: State of QoS peering in Nanog

2011-04-04 Thread Jim Gettys
On 04/03/2011 12:50 PM, Stefan Fouant wrote: -Original Message- From: Leo Bicknell [mailto:bickn...@ufp.org] Sent: Saturday, April 02, 2011 10:24 PM But it also only affects priority queue traffic. I realize I'm making a value judgment, but many customers under DDoS would find things va

RE: State of QoS peering in Nanog

2011-04-03 Thread Stefan Fouant
> -Original Message- > From: Leo Bicknell [mailto:bickn...@ufp.org] > Sent: Saturday, April 02, 2011 10:24 PM > > But it also only affects priority queue traffic. I realize I'm making > a value judgment, but many customers under DDoS would find things > vastly improved if their video conf

RE: State of QoS peering in Nanog

2011-04-03 Thread Stefan Fouant
> -Original Message- > From: Leo Bicknell [mailto:bickn...@ufp.org] > Sent: Saturday, April 02, 2011 5:56 PM > > In an IP network, the bandwidth constraints are almost always across an > administrative boundary. This means in the majority of the case across > transit circuits, not peering

Re: State of QoS peering in Nanog

2011-04-02 Thread Leo Bicknell
In a message written on Sat, Apr 02, 2011 at 07:00:52PM -0400, Jeff Wheeler wrote: > I don't agree with this. IMO all DDoS traffic would suddenly be > marked into the highest priority forwarding class that doesn't have an > absurdly low policer for the DDoS source's access port, and as a > result

Re: State of QoS peering in Nanog

2011-04-02 Thread Jeff Wheeler
On Sat, Apr 2, 2011 at 5:56 PM, Leo Bicknell wrote: > The PSTN "features" fixed, known bandwidth.  QoS isn't really the > right term.  When I nail up a BRI, I know I have 128kb of bandwidth, > never more, never less.  There is no function on that channel similar > to IP QoS. The PSTN also has exa

Re: State of QoS peering in Nanog

2011-04-02 Thread Leo Bicknell
In a message written on Sat, Apr 02, 2011 at 04:00:30PM -0400, Francois Menard wrote: > One of the postulates that I intend to defend, is that in the > PSTN today, in addition to interconnecting for the purpose of > exchanging voice calls, it is possible to LOCALLY (at the Local > Interconnection