State of QoS peering in Nanog

Sat Apr 2 23:00:52 UTC 2011

On Sat, Apr 2, 2011 at 5:56 PM, Leo Bicknell <bicknell at ufp.org> wrote:
> The PSTN "features" fixed, known bandwidth.  QoS isn't really the
> right term.  When I nail up a BRI, I know I have 128kb of bandwidth,
> never more, never less.  There is no function on that channel similar
> to IP QoS.

The PSTN also has exactly one unidirectional flow per access port.
This is not true of IP networks, where an end-user access port may
have dozens of flows going at once for common web browsing, and
perhaps hundreds of flows when using P2P file sharing applications,
etc.  The lifetime of these flows may be several hours (streaming
movie) or under a second (web browser.)

Where the PSTN has channels between two access ports (which might be
packetized within the backbone) and a relatively complex control plane
for establishing flows, the IP network has little or no knowledge of
flows, and if it does have any knowledge of them, it's not because a
control plane exists to establish them, it's because punting from the
data plane to the control plane allows flow state to be established
for things like NAT.

> Basically, you could mandate QoS on every peering link in the
> Internet and I suspect 99% of the end users would never notice any
> change.

I don't agree with this.  IMO all DDoS traffic would suddenly be
marked into the highest priority forwarding class that doesn't have an
absurdly low policer for the DDoS source's access port, and as a
result, DDoS would more easily cripple the network, either from
hitting policers on the higher-priority traffic and killing streaming
movies/voip/etc, or in the absence of policers, it would more easily
cause significant packet loss to best-effort traffic.

I think end-users would notice because their ISP would suddenly grind
to a halt anytime a clever DDoS was directed their way.

We will no sooner see a practical solution to this than we will one
for large-scale multicast in backbone and subscriber access networks.
The limitations are similar: to be effective, you need a lot more
state for multicast.  For a truly good QoS implementation, you need a
lot more hardware counters and policers (more state.)  If you don't
have this, all your QoS setup will do, deployed across a large
Internet subscriber access network, is work a little better under
ideal conditions, and probably a lot worse when subjected to malicious
traffic.

> 2) Get access ISPs to offer QoS on customer access ports, ideally in
>   some user configurable way.

I do agree that QoS should be available to end-users across access
links, but I don't agree with pushing it further towards the core
unless per-subscriber policers are available beyond those on access
routers.  Otherwise, all someone has to do to be mean to Netflix is
send a short-term, high-volume DoS attack that looks like Netflix
traffic towards an end-user IP, which would interrupt movie-viewing
for a potentially larger number of users, or at least as many
end-users as the same DoS would in the absence of any QoS.  The case
of per-subscriber policers pushed further towards the ISP core fares
better.

-- 
Jeff S Wheeler <jsw at inconcepts.biz>
Sr Network Operator  /  Innovative Network Concepts