A very short response as I’ve beaten this issue to the ground
many times before. If you know enough to define Q and S then you have an
intelligent network that knows the meaning of the bits. Useful but not the
Internet
The question is not whether there are circumstances in which you
want to apply intelligence – it’s a question of whether that’s
the Internet. As per (my interpretation) David Reed’s talk, the protocols
are indifferent to the intentions of the bits and responds to congestion
without favoritism.
I’ve cc’ed John who can provide references to
referred papers on (failed) attempts to do QoS on Internet2 and elsewhere.
From: nnsquad-bounces+nnsquad=bobf.frankston.com@nnsquad.org
[mailto:nnsquad-bounces+nnsquad=bobf.frankston.com@nnsquad.org] On Behalf Of
Fred Reimer
Sent: Sunday, March 02, 2008 22:21
To: Kevin McArthur
Cc: nnsquad@nnsquad.org
Subject: [ NNSquad ] Re: INTELLIGENT network management? (far from IP)
My specialty is not voice, but I do know QoS and the company I
work for is one of the top technically as far as VoIP capabilities.
However, I am not a spokesperson for my company and anything I contribute to
NNSquad is my personal opinion and does not reflect the opinion of my company.
With respect to what you say about QoS, it is true only if you
assume certain things about the network. First and foremost is the
bandwidth (link speed) available end-to-end. Often the largest component
of the delay between two points is the serialization delay on a particular
link. For the typical enterprise network, this has historically been WAN
links. Now even this is changing, with the availability of affordable
high-speed links such as NLMI and Metro-E. However, at a certain point,
slow link speed can cause major problems when the speed falls below a certain
level and there is data traffic that is composed of large sized packets.
The serialization delay at low-speed links can cause a significant delay if the
voice packet is not queued first (low latency queuing) and technologies such as
link fragmentation and interleaving (LFI) is not deployed. The speed of
broadband Internet connectivity does not have this problem, so what are we left
with?
What we are left with is packet loss and jitter. Jitter
should not be a problem if you don’t have a queuing or link speed
problem. If there is a link speed problem then there could be significant
jitter, as packets take different amounts of time to traverse the network and
can cause problems if the jitter buffer of the end-stations are exceeded
(causing end-station packet drops, as the packet is no longer useful from a
voice perspective as far as using the data contained in the packet to recreate
the voice stream). So, we are down to packet loss.
Packet loss is the primary concern. And it is only a
concern if any links between end-stations are so congested that packets are
dropped. The major problem we are discussing here is network neutrality
and the behavior of ISP’s in attempting to reduce the upstream traffic
(primarily) due to its relative scarcity. This may or may not be true
depending on the last-mile connectivity, as wireless is different from FiOS
which is different than cable. However, let’s go with cable as an
example. Cable has much greater downstream bandwidth as compared to
upstream bandwidth. P2P technologies actually use upstream bandwidth in a
much more “even” manner than tradition protocols used on the
Internet. Traditionally, Internet communications has been heavy on the
download side and slim on the upload side.
So, we are left with certain circumstances, or possible
scenarios, in which the upstream bandwidth is congested, and packets will
necessarily be dropped. That may not actually be accurate at this point,
yet. However, it is certainly a concern of ISP’s, and I believe a
major reason why they exhibit such behavior. I do not believe it is some
altruistic desire to be the police of the Internet. If there were no
bandwidth problems I don’t believe the ISP’s would be particularly
concerned about interfering in P2P traffic. They may not believe it is
ethical or legal, but I doubt they would take it upon themselves to police
their customers if it was not affecting their bottom line. However, it is
an issue in certain locations / communities, and ISP’s are probably attempting
to avoid issues in the majority of locations. So this is evidence that
there is a bandwidth problem >somewhere< on their networks, and upstream
seems to be the culprit.
Brett says himself that “I do have control over my local network and over my interface to my backbone provider. And when I prioritize VoIP on those, it helps tremendously.” I think this is an indication that there is, in fact, an issue.
So, what traffic do you drop? Drop more than two or three VoIP packet, depending on the encoding and other configuration issues, and you will notice voice effects. So QoS, while it may NOT have been required in Internet communications in the past, is becoming MORE important than it has ever been in the past. In the past, when low-speed connections (dial-up) were only possible, VoIP communications itself was not possible. Then there was a time of high-speed communications, with no contention. Now we are entering a time of high speed communications (no delay issue), but with contention (packet loss issues). To overlook this, or to allow the ISP’s to come up with their own solutions without input from others, is not in the best interest of anyone but the ISP’s.
From: Kevin McArthur
[mailto:kevin@stormtide.ca]
Sent: Sunday, March 02, 2008 9:35 PM
To: Fred Reimer
Cc: nnsquad@nnsquad.org
Subject: Re: [ NNSquad ] Re: INTELLIGENT network management? (far from
IP)
Fred,
I have to take exception to your suggestion that QoS is "definitely
required" for proper VoIP operation. Most VoIP today operates without any
specific QoS support -- even ISPs that offer this 'thinly veiled VoIP tax' have
carried VoIP successfully without traffic management for years. I have worked
as a VoIP software architect and can state unequivocally that QoS is not
required for VoIP operation -- in fact, its not even close to the top
reliability concern -- which is actually 'traffic management' of inbound ports.
VoIP doesn't need QoS, and this is just another mechanism ISPs are using to
leverage their own 'digital phone' offerings at the expense of the free market.
For more details refer to Vonage Canada's filing about Shaw Cable to the CRTC
that was made about Shaw's $10/mo VoIP QoS "service". Maybe we should
let the VoIP companies, not the incumbent competitors tell us what type of
traffic management is required. From my perspective, they already have, and are
against these types of anti competitive services.
>From my perspective, QoS is totally unnecessary on public links, and ample
alternative business models exist to the carriers plans of radical
over-subscription.
$0.02
Kevin McArthur
Fred Reimer wrote:
Hmm. I have to agree with Brett on most of his comments. QoS is definitely
part of the IETF RFC's. And QoS is definitely required for VoIP, in any
network, for it to work properly. The problem is that there is no common
global, or for that matter national, agreement as to how classifications and
markings are done. Without that there would be little reason for the
various network owners to trust each other. There may be one-off agreements
between two ISP's or an ISP and a backbone carrier. However, unless there
is a national/global standard then we would never get to the point where
end-users can mark their own traffic as they see fit, and have those
markings honored throughout the Internet as long as they complied with their
agreement with their ISP.
I disagree when it comes to the intelligence of the network, and whether
network owners should be able to make policy as to what types of content is
appropriate just because the routers and other network infrastructure
devices have "intelligence." The Internet is an end-to-end network, not a
client-server network.
Fred Reimer
-----Original Message-----
From: nnsquad-bounces+freimer=ctiusa.com@nnsquad.org
[mailto:nnsquad-bounces+freimer=ctiusa.com@nnsquad.org] On Behalf Of Brett
Glass
Sent: Friday, February 29, 2008 3:04 PM
To: Bob Frankston; nnsquad@nnsquad.org
Subject: [ NNSquad ] Re: INTELLIGENT network management? (far from IP)
At 12:28 PM 2/29/2008, Bob Frankston wrote:
If you require QoS for VoIP then you have the PSTN not the Internet.
Period.
QoS was (and is) part of the original design of the Internet. Note the
"Type of Service" fields in both IPv4 and IPv6, as well as the "push"
bit. (Interestingly, there's no "shove" bit. Don't know why. ;-) )
VoIP cannot rely on QoS because you don't have enough control over the
network.
I do have control over my local network and over my interface to my
backbone provider. And when I prioritize VoIP on those, it helps
tremendously.
And VoIP does not rely on QoS -- I verified this with Tom Evslin
who supplied much of the backbone for VoIP.
VoIP becomes nearly unusable in times of heavy loads without QoS. In
fact, it becomes unusable when someone on the same node runs
unthrottled BitTorrent. That's why we prioritize and do P2P mitigation.
Let's not base policies on misconceptions.
I agree. Hopefully the above will clear up some of those misconceptions.
Yes you can build your own
intelligent network but let's not confuse it with the Internet.
The Internet was never meant to be unintelligent. By design, it relies upon
routers which have tremendous computing power and very large amounts of
memory. (And it must. It can't scale or have redundancy without these
things.)
What's more, every end node is ITSELF a router and devotes intelligence to
that. It is unreasonable to attempt to exile technology, innovation, or
intelligence from any part of the Internet.
If VoIP fails it fails.
You may be able to say that, but we can't. We lose the customer if he or
she can't do VoIP.
And if you require real time HD streaming that may fail to. So what?
I believe that it was you who, in a previous message, were voicing
discontent with the performance of HD streaming on your FiOS connection.
We can't support HD streaming on the typical residential connection, but
we DO want to support it if the customer is buying sufficient bandwidth.
If we don't, again, we're out of business. Or someone goes to the FCC
and complains that we're not supporting that medium and must be
regulated....
--Brett Glass