Re: OT: Juniper Shaping TC, Odd Spirent Results

I love Juniper! And not just the berries or drinks made from the berries.
 lol The Juniper CLI is vastly superior to Cisco IOS and often superior to
IOS-XR. It is so much more user friendly and feature-rich. I wish there
were good video training for Juniper on par with the Cisco training we get
from the likes of IP Expert and INE.

On Tue, Dec 18, 2012 at 4:11 PM, Marko Milivojevic <markom_at_ipexpert.com>wrote:

> As John said, j-nsp is probably a better resource. Since today seems
> to be QoS (CoS in case of Juniper ~sigh~) day on GroupStudy, let me
> just say that what you're seeing is not totally unexpected.
>
> Traffic flow in routers is not a uniform stream of bits, rather they
> are packetized and encapsulated in frames. With larger bytes, you have
> lesser overhad on frames for the same amount of data payload you try
> to send. With smaller packets, you get more overhead. Since you
> changed packet size by 50%, your overhead increased by 50% and that
> can skew the results. Also, keep in mind that queueing and scheduling
> on routers is done on a per-packet basis, not per-byte basis. The real
> question is - was your PPS rate changed, or it remained constant?
> There are so many factors to consider...
>
> Last but not the least... remember that the only good thing to ever
> come out of juniper was gin. ;-)
>
> --
> Marko Milivojevic - CCIE #18427 (SP R&S)
> Senior CCIE Instructor - IPexpert
>
> On Tue, Dec 18, 2012 at 2:05 PM, John Neiberger <jneiberger_at_gmail.com>
> wrote:
> > I would recommend asking this over on the juniper-nsp mailing list, as
> > well. There are quite a few superb engineers over there who might know
> the
> > answer to this question.
> >
> > John
> >
> >
> > On Tue, Dec 18, 2012 at 3:00 PM, Matt Bentley <mattdbentley_at_gmail.com
> >wrote:
> >
> >> Hi All:
> >>
> >> We have a 200Mbps ethernet service delivered via EoSDH. We have GigE
> >> handoffs to the carrier on either side. We've been seeing a chronic
> trace
> >> amount of packet loss for some time. After a lot of soul-searching, I
> >> think we've identified that the inbound buffers on the carrier equipment
> >> are smaller than what our allowable burst is. And, apparently, the
> ability
> >> to set BC/BE on a Juniper shaper is a brand new feature, not supported
> in
> >> our current code. We're using traffic-control profile, and so can't
> use a
> >> policer. Although I'm guessing the policer would then just begin
> dropping
> >> packets regardless of what class they're in. Has anyone encountered
> this
> >> before? Any workarounds? This seems like it should be a very serious
> >> problem since I can't imagine we're the only person who orders a high
> speed
> >> circuit over a higher speed interface, like GigE.
> >>
> >> I've used a traffic-generator to attempt to identify what the default BC
> >> value which Juniper doesn't allow someone to set is, and am seeing some
> >> oddities - or perhaps my testing is inconsistent.
> >>
> >> What I do is set my shaping rate to whatever (say 200Mbps), and then
> pump
> >> 1250 byte packets through it. 1250 bytes = 10,000 bits, so it makes the
> >> math easy. Then, my idea is to identify how many 1250 bytes packets I
> can
> >> send in a single burst at 1Gbps speeds prior to seeing drop. If I can
> >> transmit say 900 1250 byte packets, that means a BC of 9Mbps
> (900x1250x8),
> >> correct? However, assuming that's correct, I'd expect that if I reduced
> >> the packet size to 625 bytes (cut in half), I'd be able to send exactly
> >> double the number of frames (1800). Same number of bits, just double
> the
> >> number of frames. However, I've found that not be the case.
> Correlation
> >> is not linear.
> >>
> >> To make things even more complicated, if I identify 900 frames as the
> >> threshold at which drop begins, I'd expect that if I sent 1200 frames,
> I'd
> >> still only see 900 frames get through. However, this also does not
> appear
> >> to be linear. More frames will get through when the number sent is
> bigger.
> >> I suspect this has something to do with tokens being replenished - but
> if
> >> that's correct, then why are my BC values inconsistent, depending on
> packet
> >> size?
> >>
> >> I've opened a JTAC case, but am not getting much of anywhere.
> >>
> >> Any suggestions or comments would be greatly appreciated.
> >>
> >> Thanks!
> >>
> >>
> >> Blogs and organic groups at http://www.ccie.net
> >>
> >> _______________________________________________________________________
> >> Subscription information may be found at:
> >> http://www.groupstudy.com/list/CCIELab.html
> >
> >
> > Blogs and organic groups at http://www.ccie.net
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Tue Dec 18 2012 - 16:23:45 ART