Re: OT: Juniper Shaping TC, Odd Spirent Results

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