[j-nsp] Junos CoS - ingress hierarchical policer

[Saku Ytti]

Hey Marcin,

I'm skeptical if you can do this with policing at all. But this
request aligns really well with scheduler + shaping.

So something like this:
[edit class-of-service]
+  traffic-control-profiles {
+      10M:30-20-20-30 {
+          scheduler-map 30-20-20-30;
+          shaping-rate 10m burst-size 1;
+          guaranteed-rate 10m burst-size 1;
+      }
+  }
[edit class-of-service interfaces]
+    xe-0/1/2 {
+        unit 34 {
+            input-traffic-control-profile 10M:30-20-20-30;
+        }
+    }
[edit class-of-service scheduler-maps]
+       forwarding-class EF scheduler EF:30;
+       forwarding-class AF1 scheduler AF1:20;
+       forwarding-class AF2 scheduler AF2:20;
+       forwarding-class BE scheduler BE:30;
+   }
[edit class-of-service schedulers]
    class-default { ... }
+   EF:30 {
+       transmit-rate {
+           percent 30;
+           exact;
+       }
+       buffer-size temporal 25k;
+       priority high;
+   }
+   AF1:20 {
+       transmit-rate percent 20;
+       buffer-size temporal 50k
+       priority medium-high;
+   }
+   AF2:20 {
+       transmit-rate percent 20;
+       buffer-size temporal 50k;
+       priority medium-high;
+   }
+   BE:30 {
+       transmit-rate percent 30;
+       buffer-size temporal 100k;
+       priority low;
+   }



You in addition need
a) classifying the traffic to EF, AF1, AF2, BE (feel free to rename
them toi voice, data1, data2, and best-effort)
b) rewrite-rules to tell what 802.1p, EXP/TC, DSCP/PREC values to use
for each class on egress
c) firewall rule to recolour AF1+AF2 to BE when exceeding 20% (why do
you want the recolouring, i don't think you need it, if you don't want
BE to out-compete AF, then just  give BE percent 1, and increase
AF1/AF2). Recolouring is fully supported, but I'm not sure I see the
point.
d) decide how long you wanna buffer the traffic:
        - know how much demand in each class there _USUALLY_
        - know how many millisecond, at worst, you're gonna introduce
latency before dropping (don't buffer bloat....):
             Assume we want to have no more than 30ms of latency to
BE, but we know that BE is in excess normally, and that normally BE
will use 60% of capacity. So you'd want to have10Mbps*0.6*0.03 =
22.5kB of buffer. So then we solve 10Mbps * 0.3 * X = 22.5kB to find
what temporal value to use, to get 22.5kB of buffering. I.e. 22.5kB /
(100Mbps*0.3) = 0.06s. So we want temporal 60k.


On 18 May 2017 at 10:33, Marcin Kurek <md.kurek at gmail.com> wrote:
> Hi all,
>
> I'm new to Junos CoS and struggling with creating ingress policer for a
> customer so they are allowed to send traffic belonging to 4 different
> classes:
> - voice (30%)
> - data-1 (20%)
> - data-2 (20%)
> - best effort (30%)
>
> It should meet following objectives:
>
> - at parent level police customer traffic to let's say 10 Mbps
> - each traffic type goes to its own forwarding-class, which is then
> mapped to different queues on egress
> - voice traffic should be policed to 30%, excess traffic should be
> discarded
> - data-1 and data-2 should be policed to 20%, but they can use
> additional bandwidth up to parent level (10 Mbps) if it's available.
> Once it gets above contract it should get remarked to forwarding-class BE.
>
> My idea was to create MF classifier, where I match certain traffic and
> assign appropriate forwarding-class. Also, traffic in data-1 and data-2
> would be policed here.
> Depending if it's in-contract or out-of-contract, it would get assigned
> appropriate forwarding-class.
> Also, I'd use hierarchical-policer with aggregate set to 10 Mbps and
> premium to 3 Mbps.
>
> Does it sound right, or I got it totally wrong? I'm having some
> implementation issues, but before I get into this I wanted to make sure
> the idea is right.
>
> Thanks a lot!
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp



-- 
  ++ytti