Subject: (IPng 6947) Quality of Service (rather long)

From: Ernst Lopes Cardozo <[email-masked]>
Date: Tue, 22 Dec 1998 00:02:20 +0100

Hi All,

QoS and all that - let me try to chip in my 0.009 Euro (that will be about 
US$ 0.02).

After reading RFC 2460 I got the feeling we are moving backward: Priority 
turned Traffic Type with no apparent semantics and Flow ID is now a field 
who's usage is being studied. It seems QoS is a hard nut to crack. Why is 
that?

Firstly, defining the problem seems very difficult. It is about economics - 
but the relative costs of things like bandwidth, processing/routing power, 
as well as the business model for the networks are all changing violently.

If the network is lightly loaded (say < 20%), a very coarse priority system 
would probably suffice to provide acceptable behavior for all applications. 
On the other hand, if we would have a very intelligent QoS system, we might 
be able to load the network up to 80%. This means the value of a 'very 
intelligent QoS system' over a coarse priority system is a factor 4 in 
transmission costs. Transmission costs are decreasing at a fantastic rate; 
a lot faster, it seems, than routing/switching costs. Soon only the very 
long haul links may be expensive enough to warrant a 'very intelligent QoS 
system'.
[I think we already see the same effect in local and campus networks, where 
bandwidth is too cheap to make ATM really viable.]

Scaling. With the increase of transmission *speed*, applications that were 
difficult yesterday will be easy tomorrow. Today, a histogram of pings from 
The Netherlands to the US shows an average roundtrip of 320 ms, with a 
spread of about 70 ms (and up to 5% timeouts). If in 12 month time every 
link in the network would have 10 times today's speed, a ping histogram 
would show about 77 ms average with a spread of 8 ms. In each case, about 
50 ms of the total delay is propagation delay. That means that the queuing, 
routing and packetization delay would be less than the propagation delay - 
even for a priority-less network as today's Internet! This, of course, will 
not happen.

The main reason it will not happen is that, with the increase of the 
network speed, the relative load on the network will increase. In fact, I 
firmly believe that today's Internet follows a Rule of Constant Network 
Delay. Let me explain.

For a large number of users and usage's, the Internet has a constant cost. 
If a user sits down for a surfing session, there is no real economic 
feedback that determines whether he clicks another link, pulls another 
clip, etc. Far more important is his waiting time. Sometimes, it takes 15 
minutes to consume the first megabyte, at other moments he may have pulled 
ten times as much in the same amount of time. So the response time of the 
network has a large influence on the amount of bits a user pulls through 
the net. This constitutes a feedback loop that insures that the net is 
always filled up to the point where we start complaining. What else can 
explain that the often predicted meltdown has never occurred and that, 
despite huge and sudden increments in capacity, the net seems to be about 
as slow as it was a year ago, and two years ago, etc.

[From measurements using fixed-size transfers it has been reported that the 
net has gained 60% in speed over the last two years. This is not in 
contradiction to the above: in the two years, the average transfer 
(webpage) has increased 60% in size, so the network had to become faster to 
yield the same apparent response time for the users: yes, the net grows 
faster when the applications grow fatter!]

Back to priority. Actually, 'priority' seems to imply 'importance'. This is 
not always what we need. A voice packet is not more 'important' than a ftp 
segment, the voice packet just has to be delivered within a bounded time. 
While the ftp user actually gains from having his packets delivered faster, 
the voice listener has but one desire: to receive the packet before it is 
too late. A truly 'very intelligent QoS system' would sort it's queues 
based on the 'urgend-ness' of each packet. A voice packet that still has 10 
ms time and is almost at its destination might be queued behind an ftp 
packet.

In practice, this is probably very difficult. It would mean time stamping 
voice-like (real-time) packets and routers would need an estimate of the 
remaining travel time for each destination. Synchronizing clocks down to 
milliseconds in a large network is tricky.

For some other traffic types we may want to implement 'importance'. Let's 
look at an Intranet. Some users are running transaction-type applications. 
The amount of traffic they generate depends on the number of invoices, 
orders, etc. that need to be process, which in turn depends of the 
business. If the network is slow, the users and hence the business waist 
time waiting for the network. Telling these users to slow down to relieve 
the networks is hardly an option.

Some other users are using more 'optional' type applications. They are 
browsing the intranet servers, looking a the CEO's last peptalk, reading 
the latest company press releases, etc. While each of these applications is 
useful in itself, the company would probably rather slow down these users 
than their transaction-processing colleagues. Here 'importance' seems to be 
the factor that should steer the queuing algorithm. Actually, we may even 
want to give the browsing user a busy-tone at times: "sorry, the network is 
currently to busy, please try later".

Another angle: the cost of QoS. When the ATM folks started to implement 
QoS, it seems they had the average telephone call in mind: 4 minutes in 
Europe, 6 minutes in the US. Now I try to imagine how a QoS-enabled network 
deals with a simple HTTP session. The DNS queries are clearly too short to 
set up and tear down a connection, let alone a QoS routed session. Then the 
browser pulls a page from the web server: 15k text and scripts, 7 figures 
ranging from 400 bytes to 70k, 30 seconds background sound (streaming, of 
course). The next mouse click starts a 100 second video clip. Frankly, I 
don't see how a network could give each of these sessions is own QoS 
treatment. The signaling necessary would be a multiple of the application 
traffic and the "call processing" capacity in the network would be 
enormous. Does anybody have a figure for the average duration (or number of 
bytes) of TCP sessions in the Internet? Remember, once we have that 1 Mb 
local loop, downloading a page will be a matter of milliseconds...

Today, interactive voice seems the most delay-sensitive large-scale 
application; in the future, we may have applications that require 'tactile 
feedback' over the net, bringing the delay requirement down by another 
order of magnitude. Whether that will require very special handling or just 
a little help at the queues is anybody's guess.

Conclusion: we should look for a structure that allows fairly simple, 
localized prioritization with room for extensions. Choosing a QoS scheme 
that will carry us for years seems a big gamble.

Ernst Lopes Cardozo			Tel. +31-(0)73-646.1660
Aranea Consult				[email-masked]
Principal Consultant			http://www.aranea.nl

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 22 Dec 1998 11:02:42 +0000

Ernst,

The Traffic Class field is defined by the Differentiated Services
working group. See RFC 2474 and 2475.

The sort of issues you raise are extensively discussed in that
working group and in the various groups associated with
Integrated Services and RSVP. They are largely independent
of IPv4 versus IPv6.

It's a matter of fact that more work is needed on the Flow ID field,
although some people will tell you that they know how to use it
today.

   Brian Carpenter (Co-chair, diffserv WG)

---

From: [email-masked]
Date: Tue, 22 Dec 1998 10:24:06 -0500

>although some people will tell you that they know how to use it

For sure.  We can use it today for RSVP per the flowspec and it works
fine as long as it is enclosed by an Intranet.  Folks Intranets using
RSVP for IPv4 work like a champ and with IPv6 even better because of the
flow ID.  Yes it is being used.

/jim