[j-nsp] Juniper Buffer Bloat

[Saku Ytti]

Hey Colton,

The RFC mentions that it's not good fit for high flow locations or
locations where flows shouldn't be treated fairly. Both are largely
true in SP.

a) you have lot of flows, much more than you have hardware queues
b) you don't actually want to be flow-fair you want to be
customer-fair Otherwise greedy customer just starts multiple TCP
session to transfer single file.

Backbone=>access seems solvable, if nothing else, you could use VLAN
to communicate to backbone which packet is for which customer, to give
customer-fair queueing. But Backbone=>Backbone and Backbone<=>Peering
would be rather challenging to be customer-fair, however as flow count
is massive, statistical per-packet based queueing tends to work
reasonably. Buffer bloat in backbone is configuration mistake, the
interfaces can have second of buffering, if it's also intended to
support network edges, and allowing all of that to be used in backbone
interface is just incorrect configuration, all vendors do allow you to
set buffer sizes and you should limit your backbone queueing to low
milliseconds 5-10ms is lot.



On Wed, 17 Oct 2018 at 23:49, Colton Conor <colton.conor at gmail.com> wrote:
>
> James,
>
> Thanks for the response. However, if you are just shaping at the CPE, then
> there could be bottlenecks between the CPE and core router causing the
> bufferbloat right? Example, if you have a wireless network, DSL network,
> CMTS network, etc you bottleneck is going to be that wireless accesses
> point, that DSLAM, or that CMTS, and not the CPE. Packets are going to
> build up on the access device not the CPE right?
>
>
>
>
>
> On Wed, Oct 17, 2018 at 3:06 PM James Bensley <jwbensley at gmail.com> wrote:
>
> >
> >
> > On 17 October 2018 20:53:44 CEST, Colton Conor <colton.conor at gmail.com>
> > wrote:
> > >I was wondering if Juniper supports anything like fq-codel to prevent
> > >buffer bloat? Specifically we would like to do rate shaping and
> > >subscriber
> > >management on core Juniper MX's. However, most network devices do
> > >simple
> > >buffers and queuing that does not work well compared to fq-codel and
> > >newer
> > >algorithms. Does anyone have advice when it comes to Juniper?
> >
> > Hi Colton,
> >
> > I'm pretty sure Juniper don't have anything like fq-codel in any of their
> > products however, the place to do that would be on the CPE or edge access
> > switch/router not your core.
> >
> > Normally one would rate limit the customer on CPE LAN ingress and egress
> > if you're doing multi-colour policing, or CPE WAN ingress and egress if
> > just hard policing, or CPE WAN egress and PE egress if doing shaping. You
> > don't want your customer to blast traffic into your network and this have
> > to carry those packets across your core only to them drop them on your
> > expensive  subscriber management box.
> >
> > One normally wants to drop excess packets as close to the source as
> > possiblr. So for that reason you want fq-codel on your CPE.
> >
> > Cheers,
> > James.
> >
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp



-- 
  ++ytti