Fractional Fast-E and QoS

Hello everyone.

I have a question regarding Fractional Fast-E and QoS. If you have a router subscribed to say a 20Mb MPLS circuit, it is advisable (even necesary) to use a FE interface for connectivity versus GE interface when you are running VoIP or any delay-sensitive apps. It seems that QoS is not enough to combat the discrepancy between the higher clock-rate  that GE sends traffic on the wire in  spite of a QoS/Shaping policy applied to the WAN interface. I have  run into this situation in the past where VoIP quality was very poor until I switched the WAN interface to FE. My rule of thumb was if you subscribe to 100Mb or less, use FE ports.

 

If someone can point me to a URL/resource on CCO that explains/confirms this I would be very grateful for your help.

Thanks in advance,

Mike G.

Comments

  • That’s a really interesting question.  My initial instinct says no, that it shouldn’t matter either way, because the traffic is getting serialized so fast on either Fast or GigE that the serialization delay should be negligible.

     

    Some quick math on both:

     

    A FastEthernet is clocked at 100,000,000 bits per second.  With 8 bits per Byte and 1000ms per second we get:

     

    (8 bits / 1 byte) * (1 sec / 100,000,000 bits) * (1000ms / 1 sec) = .00008 ms / Byte Serialization delay on FastE

     

    GigE is clocked 10 times as fast, so the serialization delay is 10 times less, or specifically .000008 ms / Byte Serialization delay on GigE

     

    If a VoIP packet comes in at 64 Bytes, and a 1500 Byte packet is in front of it in the queue about to be serialized, the worst case delay it would wait is:

     

    FastE = 1500 Bytes *  .00008 ms / Byte = .12 ms worst case delay

    GigE = 1500 Bytes *  .000008 ms / Byte = .012 ms worst case delay

     

    The actual time to serialize the VoIP packet would be:

     

    FastE = 64 Bytes *  .00008 ms / Byte = .00512 ms worst case delay

    GigE = 64 Bytes *  .000008 ms / Byte = .000512 ms worst case delay

     

    In other words FastE potentially could incur ~ .1ms more of queuing delay and ~ .0005ms more of serialization delay

     

    What’s the VoIP SRRT budget though? 100ms end-to-end delay?  Even at 50ms conservatively, the added serialization of FastE vs. GigE should be negligible.

     

    I think one thing you would have to account for though is how often is the shaper running vs. how often the SP’s policer is running.  Whatever the Tc that the SP uses inbound ideally should be equal to the Tc that your shaper uses outbound, this way you wouldn’t release traffic from the shaping queue faster than the SP inbound side is policing it at.

     

    Does that make any sense, or is that not what you were asking?

     

    Brian McGahan, 4 x CCIE #8593 (R&S/SP/SC/DC), CCDE #2013::13
    [email protected]
     
    Internetwork Expert, Inc.
    http://www.INE.com

     

    From: [email protected] [mailto:[email protected]] On Behalf Of mgrann
    Sent: Wednesday, April 30, 2014 9:13 PM
    To: Brian McGahan
    Subject: [CCIE R&S] Fractional Fast-E and QoS

     

    Hello everyone.

    I have a question regarding Fractional Fast-E and QoS. If you have a router subscribed to say a 20Mb MPLS circuit, it is advisable (even necesary) to use a FE interface for connectivity versus GE interface when you are running VoIP or any delay-sensitive apps. It seems that QoS is not enough to combat the discrepancy between the higher clock-rate  that GE sends traffic on the wire in  spite of a QoS/Shaping policy applied to the WAN interface. I have  run into this situation in the past where VoIP quality was very poor until I switched the WAN interface to FE. My rule of thumb was if you subscribe to 100Mb or less, use FE ports.

     

    If someone can point me to a URL/resource on CCO that explains/confirms this I would be very grateful for your help.

    Thanks in advance,

    Mike G.




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

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

  • peetypeety ✭✭✭


    I think one thing you would have to account for though is how often is the shaper running vs. how often the SP’s policer is running.  Whatever the Tc that the SP uses inbound ideally should be equal to the Tc that your shaper uses outbound, this way you wouldn’t release traffic from the shaping queue faster than the SP inbound side is policing it at.

    Ding ding ding...this is exactly what I was thinking.

    In an FE world, if your shaper operates on 1/8th second intervals, it essentially allows 2.5Mb to drain 8 times per second.  If the carrier operates on 1/50th second intervals, they'll essentially accept 400kb 50 times per second (and trash up to 1.6Mb of excess for each of those increments).  Your 2.5Mb drain would send 400k in 2ms, lose 1600k in 8ms, send 400k in 2ms, lose 100k in 0.5ms, then wait idle for another 112.5ms.  Obviously I'm guessing at numbers, and honestly I haven't verified my math, but I think it's right.

    In a GE world, your ability to outrun the carrier's policer is 10x higher.

  • mgrannmgrann ✭✭

    Brian, as always, your brilliant mind never ceases to amaze us! Thank you for your comments.

    MikeG

  • mgrannmgrann ✭✭

    Mr. Peety, thank you once more for clearing up my understanding on this nagging topic.

    MikeG

  • mgrannmgrann ✭✭

    Follow-up question - in a common MPLS enterprise scenario you have a wide range of contracted sub-rate circuits. Say you have 100 sites ranging from 10Mbps to full 1Gig circuits from the same SP. Obviously sites that are high-speed circuits can easily overrun those at the lower end. How would you design your QoS policy to accomodate the varying circuits? The only thing I know of that can dynamically configured per-site QoS is FlexVPN. Manually configuring shaping/policing/etc for each peer would not be feasible as you scale.

    Thanks in advacne for your comments.

    Michael

  • Normally you just prioritize your real time traffic, e.g. VoIP, reserve some bandwidth for your key apps, and then let the rest of it just fight it out in the scavenger class.  This isn’t a design problem of MPLS, it’s the same classic WAN provisioning rate issue that Frame Relay and ATM also faced for years.

     

    Brian McGahan, 4 x CCIE #8593 (R&S/SP/SC/DC), CCDE #2013::13

    [email protected]

     

    Internetwork Expert, Inc.

    http://www.INE.com

     

    From: [email protected] [mailto:[email protected]] On Behalf Of mgrann
    Sent: Tuesday, May 06, 2014 9:07 AM
    To: Brian McGahan
    Subject: Re: [CCIE R&S] RE: Fractional Fast-E and QoS

     

    Follow-up question - in a common MPLS enterprise scenario you have a wide range of contracted sub-rate circuits. Say you have 100 sites ranging from 10Mbps to full 1Gig circuits from the same SP. Obviously sites that are high-speed circuits can easily overrun those at the lower end. How would you design your QoS policy to accomodate the varying circuits? The only thing I know of that can dynamically configured per-site QoS is FlexVPN. Manually configuring shaping/policing/etc for each peer would not be feasible as you scale.

    Thanks in advacne for your comments.

    Michael




    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.