State of QoS peering in Nanog

Sat Apr 2 21:56:07 UTC 2011

In a message written on Sat, Apr 02, 2011 at 04:00:30PM -0400, Francois Menard wrote:
> One of the postulates that I intend to defend, is that in the
> PSTN today, in addition to interconnecting for the purpose of
> exchanging voice calls, it is possible to LOCALLY (at the Local
> Interconnection Region, roughly a US LATA) interconnect with
> guaranteed QoS for ISDN video conferencing.

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.

When talking about IP QoS people like to talk about guaranteed, or
reserved bandwidth for particular applications.  The reality is
though that's not how IP QoS works.  IP QoS is really about identifying
which traffic can be thrown away first in th face of congestion.
Guaranteeing 128kb for a video call really means making sure all
other traffic is thrown away first, in the face of congestion.

> In other words, there is more to PSTN interconnection than the
> support of the G.711 CODEC.  Other CODECs are supported, such as
> H.320.
> 
> This brings me to a point. Why should we loose this important
> feature of the PSTN, support for multiple CODECs, as we carelessly
> bottom level IP-IP interconnection to G.711 only.

IP networks can't tell the difference between G.711, H.320, and the
SMTP packets used to deliver this e-mail.  IP networks know nothing
about CODECs, and operate entirely on IP address and port information.

> B) I also want to understand what is going on, insofar as enabling
> guaranteed QoS peering across BGP-4 interconnections in the Nanog
> community.

You're looking at the wrong point in the network.  In my experience,
full peering circuits are very much the exception, not the rule.
While almost all the exceptions hit NANOG and are the subject of
fun and lively discussion, the reality is they are rare.

When there is no congestion, there is no reason to drop a packet.
A QoS policy would go unused, or if you want to look from the other
direction everything has 100% bandwidth across that link.

In an IP network, the bandwidth constraints are almost always across
an administrative boundary.  This means in the majority of the case
across transit circuits, not peering.  80-90% of the packet loss
in the network happens at the end user access port, inbound or
outbound.  Another 5-10% occurs where regional or non-transit free
providers buy transit.  Lastly, 3-5% occurs where there are geographic
or geopolitical issues (oceans to cross, country boarders with
restrictive governments to cross).

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.

If you want to advocate for useful changes to end users that provide a
better network experience, you need to focus your efforts in three
areas:

1) Fight bufferbloat.  http://en.wikipedia.org/wiki/Bufferbloat
   http://arstechnica.com/tech-policy/news/2011/01/understanding-bufferbloat-and-the-network-buffer-arms-race.ars
   http://www.bufferbloat.net/

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

3) Get ISP's who purchase transit further up the line to implement QoS
   with their transit provider for their customers traffic, if they are
   going to run those links at full.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110402/988c10b9/attachment.sig>