LLQ QoS question for Mark

Mark on page 249 of the solutions pdf for lab six you show that 

class-map match-any RTP
match dscp ef
class-map match-any SIG
match ip dscp cs3
match ip dscp af31
!
policy-map LLQ
class RTP
priority percent 35
class SIG
bandwidth percent 1
class class-default
fair-queue
!
policy-map ClassBased-FRTS
class class-default
shape average 364800 3648 0
service-policy LLQ
!
map-class frame-relay FR-Frag
frame-relay fragment 480
service-policy output ClassBased-FRTS

 

task states

Configure LLQ for the link between SiteA and SiteC based on the number of calls
above, but express these values in percentages, rather than in kbps

Configure this for the link from SiteA to SiteC for 12 calls

 

if i do the math

25.6 k for 1 g729 call * 12 calls gives you 307.2 k

this a 384 k interface and shaped to 95% is 364.8 k

307.2 / 364.8 = 84.2%

 

Is this typo on the PDF or am I wrong?

Trent

 

 

 

 

Comments

  • Does it say anything about compressed RTP? But even so it should be around 39%.


  • It does say to use "both L2 specific mechanisms for a slow speed link", and the math comes out to 0.34210526315789 or 35%

    20 bytes G279 payload

    2 byte cRTP header

    4 byte FR header

    --

    26 * 8 (bits in bytes) * 50 (pps) = 10400 bps * 12 (calls) = 124800 or 125kbps. 

    124800 / 364800 = 0.34210526315789 or 35%

     

    HTH!

  • Shouldn't we be using 8 bytes for FR header since we have fragmentation FRF.12 here?

    From QOS SRND:

    The amount of overhead per VoIP call depends on the Layer 2 technology used:

    • Frame Relay adds 4 bytes of Layer 2 overhead; Frame Relay with FRF.12 adds 8 bytes.

    20 bytes G279 payload

    2 byte cRTP header

    8 byte FR header

    12calls =>144000

    14400/36480 = 0.394 or 40%


  • Nope. The entire idea of fragmentation is to fragment large data packets down to the same size as the smaller voice packets. You *never* want to fragment your voice packets - and using the fragmentation calc in the QoS SRND will ensure that. 

     

    So for data, yes, that would be the FR header size. However for voice, 4 bytes is still the FR header size.

     

    HTH!


  • Nope. The entire idea of fragmentation is to fragment large data packets down to the same size as the smaller voice packets. You *never* want to fragment your voice packets - and using the fragmentation calc in the QoS SRND will ensure that. 

    So for data, yes, that would be the FR header size. However for voice, 4 bytes is still the FR header size.

    HTH!

  • I totally agree on the logic. What throws me off is this: "The amount of overhead per VoIP call depends on the Layer 2" From this I understand that the frame header in which we have the voice packet actually is 8 bytes even though the voice packet was not fragmented.

    It doesn't say that regardless if we use fragmentation or not, the header is the same for VoIP.

    It's very confusing and I believe that we could lose the whole WAN QoS section if we don't put the right value in.

  • Agreed with the Win! I understand Marks logic but also understand mine/thewins ;) I guess Marks logic beats us somewhat!

    On a different note -

    the task asks us to shape to cisco recommended value which is 95%. Then again, we are basing the bandwidth for the priority queue on the physical interface speed (384) instead of the shaped one (364). Does this really make sense?

    I would have assumed to base the queue on the effective available bandwidth, not the physical one.

  • What do you mean we are basing on the physical interface bandwidth?

    144000/364800 (this is the shaped value - cir=mincir=95%of PVC speed) =>40%

     

    Also one thing I would like to add is that in the qos (regardless of the wording and interpretation) we have that table where we can see the BW consumed by one g729 call wFRF.12 and that is 28kbps. Going in reverse:

    28000/8/50 = 70bytes/packet  => 10bytes FR header. It's actually 8 bytes but they rounded up from 27,2kbps to 28kbps

     

    Table 1-3Voice Bandwidth (Including Layer 2 Overhead)


    Bandwidth Consumption 802.1Q Ethernet  PPP          MLP         Frame-Relay   w/FRF.12      ATM

    G.729A at 50 pps           37 kbps             28 kbps    30 kbps    28 kbps                           43 kbps

  • Im talking about the Solution6 PDF - i quote

    (RTP bandwidth would be 33% of link bandwidth

    So he is basing the 33% of the actual pvc or link bandwidth instead of the shaped bandwidth. Now my question - is that really best practice? :)

  • thanks for all the good replys!

    Where do i apply rtp header compression for Frame relay

    when I apply it the policy map in the LLQ i see it in the show policy map interface but it's not showing any header being compressed.

    do i enable it on the frame relay interface?

  • Nope. The entire idea of fragmentation is to fragment large data packets down to the same size as the smaller voice packets. You *never* want to fragment your voice packets - and using the fragmentation calc in the QoS SRND will ensure that. 

    So for data, yes, that would be the FR header size. However for voice, 4 bytes is still the FR header size.

    HTH!


    Kind Regards,

    Mark Snow
    CCIE #14073
    (Voice, Security)
    Instructor

    - docendo discitur

    On Nov 5, 2012, at 10:11 AM, inforthewin <[email protected]> wrote:

    Shouldn't we be using 8 bytes for FR header since we have fragmentation FRF.12 here?

    From QOS SRND:

    The amount of overhead per VoIP call depends on the Layer 2 technology used:

    • Frame Relay adds 4 bytes of Layer 2 overhead; Frame Relay with FRF.12 adds 8 bytes.

    20 bytes G279 payload

    2 byte cRTP header

    8 byte FR header

    12calls =>144000

    14400/36480 = 0.394 or 40%




    INE - The Industry Leader in CCIE Preparation
    http://www.INE.com

    Subscription information may be found at:
    http://www.ieoc.com/forums/ForumSubscriptions.aspx

Sign In or Register to comment.