Re: OT: Juniper Shaping TC, Odd Spirent Results

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
Received on Tue Dec 18 2012 - 15:05:47 ART