QoS section

My solution is a bit different then what's in solution guide. I am interested if i would loose point if i did it this way in the lab.

For example, the task was to prioritize voice packets, but there is no mentioning as to what amount of bandwidth that relates to. Task before that specificaly asked to make sure users in vlan 11 get 80% bandwidth of CIR = 307kbps. This leaves 77 kbps for shaper queue. I decided to give voice packets enough BW for 5 compressed G.729 calls which is exactly 58 kbps. And while shaper is configured for 512kbps, i made sure it drops to minCir if there are packets in LLQ.

This is common sense, but i need to know if this extra config will make me loose points. It technically doesn't break any requirements unless i missed something.

 

class-map match-all VOICE
 match ip rtp 16384 16383

map-class frame-relay DLCI_501
 frame-relay fragment 640
 service-policy output SHAPER

policy-map LLQ
 class VOICE
  priority 58
 class HTTP
  bandwidth percent 80
 class class-default
  fair-queue
  random-detect


policy-map SHAPER
 class class-default
  shape average 512000 5120 0
  shape adaptive 384000
  shape fr-voice-adapt deactivation 30
  service-policy LLQ

interface Serial1/0.501 point-to-point
 ip address 139.1.15.5 255.255.255.0
 frame-relay interface-dlci 501  
  class DLCI_501
 frame-relay ip tcp header-compression
 frame-relay ip rtp header-compression
end

 

Comments

  • Would really like to know answer to this one!

  • Hi jkdrouter,

    With all respect, I think that your solution was wrong!

    Let's look at the 3rd line in the Task 8.5, the wording says that "Voice traffic should also be fragmented when sent across the Frame Relay cloud", which means that we cannot use LLQ because we implemented FRTS with FRF.12 previously in the Task 8.3, If LLQ is used in the Shaping Queue of FRTS/FRF.12 system, the Voice traffic will NOT be fragmented because they will fall into the High Priority queue of the Dual FIFO queueing system which stands after Shaping Queue. :)

  • For the IP RTP Header-Compression, I think it doesn't truly meet the requirement of the task which states "lowest possible latency". I think RTP Header-Compression is a bogus optimizing feature for VoIP transmission delay because if we compress the header, of course the packet length is shorter and we could send more traffic than if there's no compression, but the trade-off here it's that we will lose some router's resources for executing compressing algorithm. For RTP Header-Compression I think that we could only conclude that it will help to increase the available bandwidth of the connection.

  • Hi,
    Only good can come out from discussion! ;)

    RTP header compression reduces the overhead and because of it total transmition delay, significantly. Generaly, IP header compression saves lots of bandwidth (whether or not this is important for this lab or not), it provides overall reduction in packet loss and improved response time.

    So header compression is definately not a bogus optimization across slow links!


    Your first comment - Voice packets are not fragmented due to their size. They should only be mixed with other fragmented non-real-time non-priority packets thanks to interleaving queue and some priority scheduling mechanism such as LLQ.



  • Very nice analysis, jkdrouter!!!

    But why the SG uses for rtp the whole  bandwidth 512??

    In that way, the nonpriority packets will starved of bandwidth.

     

    Also, in my opinion your solution is not wrong:

    This example is from the DocCD version 12.4T:



    Configuring Class-Based Weighted Fair Queueing with Fragmentation Example


    The following example provides a sample configuration for CBWFQ and
    fragmentation with FRTS. This configuration example is exactly the same
    as the example shown in the section "Configuring Class-Based Weighted Fair Queueing Example", with the addition of the frame-relay fragment command to configure fragmentation.


    class-map voice


     match ip dscp ef


    policy-map llq


     class voice


      priority 32


    policy-map shape-policy-map


     class class-default


      shape average 64000


      shape adaptive 32000


      service-policy llq




    map-class frame-relay shape-map-class


     frame-relay fragment 80


     service-policy output shape-policy-map




    interface serial 0/0


     encapsulation frame-relay




    interface serial 0/0.1 point-to-point


     ip address 192.168.1.1 255.255.255.0


     frame-relay interface-dlci 100


      class shape-map-class

Sign In or Register to comment.