… updated on Monday, December 7, 2020 17:17 UTC
ADSL QoS Basics
Based on the ADSL reference model, 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 the 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, 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.
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.
all the QoS is organized on the equipment provider (routers, switches, ...)
This seems to conflict with this doco which I have been using and appears to work fine :
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?
interface ATM0/0.1 point-to-point
vbr-nrt 320 320
service-policy output llq
apply the service policy to the dialer
and see it (at least apparently) doing
stuff on virtual-access 4 in my case.
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.
where should I apply the service-policy output?
kind regards, your podcast is great!
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?
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.