ADSL QoS basics

Based on the ADSL reference model we’ve discussed last week, let’s try to figure out how you can influence the quality of service over your ADSL link (for example, you’d like to prioritize VoIP packets over web download). To understand the QoS issues, we need to analyze the congestion points; these are the points where a queue might form when the network is overloaded and where you can reorder the packets to give some applications a preferential treatment.

Remember: QoS is always a zero-sum game. If you prioritize some applications, you’re automatically penalizing all others.

The primary congestion point in the downstream path is the PPPoE virtual interface on the NAS router (marked with a red arrow in the diagram below), where the Service Provider usually performs traffic policing. It’s better from the SP perspective to police the traffic @ NAS than to send all the traffic to DSLAM where it would be dropped in the ATM hardware. Secondary congestion points might arise in the backhaul network (if the network is heavily oversubscribed) and in DSLAM (if the NAS policing does not match the QoS parameters of the ATM virtual circuit).

In the upstream direction, the congestion occurs on the DSL modem – the path between the CPE and the modem (Ethernet or Fast Ethernet) is much faster than the upstream ATM virtual circuit. Secondary congestions might occur in DSLAM or the backhaul network. NAS usually does not police inbound traffic, as it’s assumed the DSL access network already limits the user traffic to its contractual upstream speed.

Based on the congestion analysis, it’s obvious you cannot use queuing on the CPE (marked “2” in the diagrams) to influence the ADSL QoS as you don’t control a single congestion point. You have to use traffic shaping on the CPE to introduce artificial congestion points in which the queues will form. You can then use the usual queuing mechanisms to prioritize the application traffic.

The shaping configured on the PPPoE interface on the CPE router neatly removes the congestion on the DSL modem. The backhaul network is rarely congested in the upstream direction (unless your friendly neighbors are devoted fans of P2P protocols).

When configuring the upstream shaping rate, you just have to take in account the extra overhead introduced by the PPPoE framing, which is not yet present in packets shaped on the Dialer interface, and reduce the upstream shaping speed to a value slightly below your DSL upstream speed.

If your DSL configuration uses PPPoE Dialer interface, you have to shape the traffic on the Dialer interface, not the outside Ethernet interface. The outside Ethernet interface transmits PPPoE-encapsulated IP traffic on which you cannot use the IP-based queuing classifiers.outside Ethernet interface.

Assuming most of your traffic is TCP-based (or that all non-TCP traffic is prioritized), the shaping on the inside LAN interface will cause enough TCP delays to slow down the downstream TCP transmission. However, it’s harder to determine the correct shaping rate and optimize the shaping behavior when the high-priority traffic is not present; we’ll cover these issues in an upcoming post.

13 comments:

  1. QoS on ADSL is more than illusion only as those services are sold overbooked ...

    ReplyDelete
  2. totally agree!
    all the QoS is organized on the equipment provider (routers, switches, ...)

    IMS

    ReplyDelete
  3. "you have to shape traffic on the Dialer Interface, not the outside Ethernet Interface"

    This seems to conflict with this doco which I have been using and appears to work fine :

    http://tinyurl.com/msrbly

    When I try to applie a service policy to the Dialer interface I get an error along the lines of "GTS not supported on this interface"

    Can you shine some light on this Ivan?

    ReplyDelete
  4. OOPS ... could be I wrote aRealStupidity™ :(. Let me check and post an update.

    ReplyDelete
  5. If you are using PPPoA you need to shape on the Virtual circuit itself

    interface ATM0/0.1 point-to-point
    pvc 0/33
    vbr-nrt 320 320
    service-policy output llq

    ReplyDelete
  6. or you can put "ppp multilink" on the dialer,
    apply the service policy to the dialer
    and see it (at least apparently) doing
    stuff on virtual-access 4 in my case.

    ReplyDelete
  7. The biggest problem with ADSL QoS is basically that the uplink direction is where the congestion happens most of the times. Downstream rates are usually high enough to move the primary downstream congestion point to the oversubscribed provider network or the Internet.

    As for the upstream direction, we usually have a really painful mix: IP over PPP over Ethernet over ATM (AAL5SNAP). Here is the worst thing : even if you prioritize voice packets, you still can't do *interleaving* and thus large packets may block small voice packets (since most uplink rates are below 1Mbps).

    As we know, originally ATM was designed to used fixed size cells and make QoS nice and easy. But once you start using AALs you face numerous limitations: e.g. AAL5 does not allow you to reorder cells. Thus, ATM fragmentation is useless with respect to VoIP quality when using AAL5.

    Cisco's answer to that problem was using multilink PPP fragmenation and interleaving over ATM. (Man, isn't that crazy already?!). However, while this works for PPPoA it does not work for PPPoEoA. You may try it however much you want, but PPPoE just does not appear to be working righ with fragmentation. Too bad they didn't think of it ;)

    Thus, the only way to avoid high serializatio delays for voice, is by either making sure there are no high-bandwidth uploads (e.g. no P2P apps) OR by setting IP MTU in CPE router to a value matching the acceptable serialization delay. You may also use TCP adjust MSS for this task. This may lead to excessive IP fragmentation and TCP overheads, but still looks like the only viable solution.

    ReplyDelete
  8. I don't really undesrtand because IOS lets me put the service policy output on the dialer and the atm interface. But if i do si int atm 0 i see that 255/255 rx or tx is just on the physical int not the logical. So the question is
    where should I apply the service-policy output?

    kind regards, your podcast is great!

    ReplyDelete
  9. correct me if I'm wrong http://www.cisco.com/en/US/tech/tk543/tk545/technologies_tech_note09186a00800b2d29.shtml

    so if i apply qos on Dialer it will work per-session basis, so is the same using just one dialer, if I have two it will be two queues from two dialers, am I wright? so or I have just one dialer or I apply it to the physical interface.
    And the bandwidt commands I guess to the phycial too isn't it?

    Kind regards

    ReplyDelete
  10. Ivan Pepelnjak12 July, 2010 18:21

    IOS allows you to apply service policy on any interface ... it just might not work. You'll find hints as to where you need to apply the service policy in the Cisco's document you've quoted and in the other comments.

    ReplyDelete
  11. What if I use an ADSL or VDSL WAN interface in the Cisco, does that put the congestion point in the Cisco? Can QoS be achieved without the traffic shaping on the PPPoE session then?

    ReplyDelete
    Replies
    1. See the comment from Anonymous (you shape with VBR on ATM VC).

      Delete
    2. The comment from Anonymous refers to PPPoA. Does it apply to PPPoEoA as well?

      Some ISPs using MSANs are rolling out PPPoE access without ATM now. I do not think that Cisco has a WAN interface for it at this time, but it would be interesting, because if the modem was integrated in the Cisco, the WAN interface would know the actual bandwidth, and one could possibly apply fancy queueing.

      Shaping requires that one knows the actual bandwidth. On the downlink, and possibly even on the uplink, this might change occasionally due to the DSL Rate Adaptive Mode.

      Delete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.