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

[Matt Bentley]

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!