[j-nsp] Juniper Shaping TC, Odd Spirent Results

[John Neiberger]

I hope someone tackles this question soon. I'm pretty interested to find
out what the answer is, too.

John


On Wed, Dec 19, 2012 at 11:45 AM, 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!
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>