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

[Matt Bentley]

I'm also asking JTAC, but have so far gotten the runaround.  May need to go
to advanced JTAC.

On Thu, Dec 20, 2012 at 1:18 PM, John Neiberger <jneiberger at gmail.com>wrote:

> 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
>>
>
>