[139321] in North American Network Operators' Group
Re: State of QoS peering in Nanog
daemon@ATHENA.MIT.EDU (Leo Bicknell)
Sat Apr 2 17:57:02 2011
Date: Sat, 2 Apr 2011 14:56:07 -0700
From: Leo Bicknell <bicknell@ufp.org>
To: NANOG list <nanog@nanog.org>
Mail-Followup-To: NANOG list <nanog@nanog.org>
In-Reply-To: <BB249960-E273-49EB-BCB9-59B9D991FDE7@menards.ca>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--PEIAKu/WMn1b1Hv9
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In a message written on Sat, Apr 02, 2011 at 04:00:30PM -0400, Francois Men=
ard 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.
>=20
> 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-bufferbloa=
t-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.
--=20
Leo Bicknell - bicknell@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
--PEIAKu/WMn1b1Hv9
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.13 (FreeBSD)
iQIVAwUBTZebdrN3O8aJIdTMAQItLRAAhcQI50rx4nt8lpLlRSg/H2xqCPeyPuXY
1avJfGhVjUjHNNK4brhbjd8TJL90jyONEGTPu8dmN9qPS6JuqZ+5i8wB1+EwbmkV
RacMw7LdQjj3v3BAgpwfp1AA/BDWSBRpp/U43qzHR/k1Tfx1AxmwFs9dovnXhXCu
hUSbfj4UDIN3pZrfUBBsjRs36PQdiH/MTSqaKxMrIJYA9H3WH8RhvmIPlTSA42wO
XJTRJkIaFIsNJtEzJl+glCxlzt+gLld9K9NHzHCNcZ2/l/ph/klPkMtrEgZoQFSN
94yWHNygJbwRDepPh8aZQqeV4YWsC7n+hCiyipcX/NSicMoNst12/73Bk8BO7gVu
qmEyDnpuUEwkTrPa7eC5sJsVSTveUAdPUKeB+QheqGC/fB/sHevpxzJ1u9Rr5uXz
TAQK3vbM5Gn+tR/KNbL1JQGedTxx7/sgf2I7yynATFCgUCeYe5UtPwdZAlhoAPq9
OrgZlFr9IOhAZqmJx0AppzMwlUeK+MFSG3dzczzxOCr0A4k861ejzCw/OpgfMqIz
2vS9UBmgZfq6TyfbKOLTdXdfAcfuCDx+B2jyy1VQz7FQZn/FYIjOehrvCvMEQEhH
Ivo4mQHWBY8wshLJV+iruf0Ka7RPTEkG62pA83+FcvJm/hZ6U8Wf5zI0miT7UPIN
PnBNYHo1auo=
=dVSz
-----END PGP SIGNATURE-----
--PEIAKu/WMn1b1Hv9--
