Subject: Why We Need (Delay) Priority

From: Ed Ellesson <[email-masked]>
Date: Fri, 22 Aug 1997 18:33:33 -0400

Kalevi, 

I think we need delay preference for more than just streaming audio and
video.  Customers of ours want to use the Internet to support transaction
processing applications for which they have traditionally used a
leased-line private network.  The needs of these very different
applications argue for greater than two values (1 bit) to indicate delay
preference.  

You wrote: 
>My
>belief is that two classes is in practice enough, but if more is needed,
>they could be implemented quite straigthforwardly by adding parallel
>buffers. With 2 bit we obtain 4 classes. Anyway, there must really
>significant difference between buffer sizes in order to get enough
>difference in the "feeling" of different service classes. My proposal is
>not to specify any strict delay limit for the real-ti
e service, because
>it obviously depends on the network technology used. But in order to be a
>practical the service must meet the actual requirements of IP-phone, I
>think.

In order to be practical, I think the service must meet the needs of
today's corporate transaction processing applications, which will compete
with many other traffic types on the same links.  

As I mentioned in my talk in Munich, network administrators for large
corporate networks sign Service Level Agreements with their clients, who
are the business unit or department managers responsible for business
performance.  The example I gave in the talk was that of a branch brank,
where the objective is to keep the lines short at the bank teller windows.
To help ensure this result, the branch bank manager signs an agreement with
the corporate network administrator that (for some large percentage of the
time) the response time for transaction processing on the teller's
terminals will be less than some value, usually ranging from a half second
to 2 seconds, depending on the desired service level.  (Not all of this is
network delay.  Priority is also managed within the transaction processing
server via work load management.)  There are other parameters involved in
these SLA's, including availability and expected traffic load.  

My point in bringing this up again, is that the characteristics and delay
requirements of transaction processing traffic are sufficiently  different
than that of IP Telephony,  to argue for more than just "Premium" and
"Normal" delay preference treatment.  

The objective for  IP Telephony traffic is round trip delays in the
neighborhood of 200 - 400 milliseconds, including the jitter buffer in the
receiving end system.  The round trip delay objective for transaction
processing is in the range of 500 ms to 2 seconds, depending on the service
level desired, and the associated business tradeoffs.   If both types of
traffic are present on the same network, I would argue that at least two
premium level queues are required, in addition to the "best effort" queue,
in order for the network administrator to be able to manage the network to
meet the desired level of service.  

In fact, many corporate networks are already managed today with multiple
queuing delay preferences, including, but not limited to,  SNA networks.
SNA networks enable preferential delay queuing at five levels: 

-network control
-high priority
-medium priority
-low priority 
-routine

I should also point out that this approach is used on networks which have
traditionally carried traffic loads which are far more predictable than the
traffic on today's Internet.
   
Since these networks have been up and running for many years, and meet the
customer need for delay management, I would argue that three bits be set
aside for queuing preference [unless someone can talk me out of it  ;-)  ],
so that existing customer applications and the associated management
techniques continue to work, as we migrate these apps to running over
Internet backbones,  using the standardized approach that we will develop
in the working group that follows up on the differential services BOF.      

As I mentioned in Munich, the simulation work, which Wu-chang Feng also
mentioned in his earlier post to this list, reveals that marking packets
for drop preference can be very effective in managing bandwidth allocation.
 However, delay  management by traffic class is also required, especially
since achieving the desired bandwidth allocation behavior with dropping
preference  may require larger buffers, and therefore introduce greater
queueing delay.    

Within each queue, however, dropping preference could be used to allocate
bandwidth at that service level.  This would argue for separate fields for
delay management and dropping management in the IP header. 

By the way, indicating a queueing delay preference in the precedence field
does not, to my mind, imply that every router in the path has to support
multiple CBQ queues.  I am told that there is very little queuing delay at
high speed interfaces in the core of the Internet.  Providing multiple
queues here probably makes little sense, since we are talking about a
queuing delay difference of a few milliseconds between a premium service
queue and a normal service queue.  

A big difference in queuing delay is experienced is on relatively low speed
access lines to the Internet (56kbps and less).  Many of our customers use
these types of lines from their branch offices to their corporate backbones
today.  (When the Internet, in the form of a VPN, replaces a corporate
backbone, I do not expect the speed of the access lines to change
significantly.)  A single 1500 byte low priority packet at the head of the
queue, can significantly delay higher priority packets on these low speed
lines, such that the desired service level is not achieved. 

Therefore, it is quite reasonable and necessary to use multiple queues at
the edge of the network, over low speed access lines, and then to use
single queues with dropping preference in the backbone, where delay
preference makes little difference.  Indicating delay preference via a
field in the IP header should not dictate that multiple queues must be used
on links where such an approach adds little or no value.  

I think we can come up with a semantic definition for the use of the TOS
byte bits that supports all of these objectives.          

Regards, 

Ed Ellesson
Sr. Engineer, TCP/IP Technology Management
IBM Networking Software Products
Research Triangle Park, NC 
[email-masked]
919-254-4115

---

From: Ed Ellesson <[email-masked]>
Date: Fri, 22 Aug 1997 19:11:21 -0400

Kalevi, 

Ooops! 

>SNA networks enable preferential delay queuing at five levels: 

I should have said that SNA networks enable preferential delay queuing at
FOUR levels: 

-network control
-high priority
-medium priority
-low priority

In mixed networks of SNA traffic and non-SNA traffic, all running over an
IP backbone, I expect that customers will want the flexibility to assign
more delay priorities than this, in order to distinguish between
transaction processing and batch file transfers which characterize much of
the SNA traffic, and traffic such as Voice over IP, which requires tighter
delay constraints, and traffic which has a lower priority than commercially
significant file transfers, which would have lower delay constraints, or
none at all (hence the "routine" classification, in my first list).  Again,
maybe someone can talk me out of this position, once I understand the
affect of the dropping priority management.  

Regards, 

Ed Ellesson

---

From: [email-masked] (Kilkki Kalevi NRC/Hki)
Date: Mon, 25 Aug 1997 16:34:47 +0200

Ed,

You have good reasons for using more than one bit for delay preference.   
However, the difference in our opinions seems to arise from different   
viewpoints.

Firstly, my target is more on Internet side rather than Intranet with   
strict service agreements, and my opinion is that we should concentrate   
on the Internet with millions of users rather than Intranet where a   
limited number of customers have some level of knowledge about technical   
issues. But, of course, it would be very useful to cover all possible   
applications with one basic service.

Secondly, from application viewpoint there certainly are different   
requirements for delay - there may well be more than 4 different   
categories. What I try to do is design as feasible network as possible,   
and especially, I try to avoid any complexity if not really necessary.

Even though I have called the other service class "non-real-time", my   
personal feeling is that the end-to-end delay shall be limited, say,   
usually less than 1 s. I think that this is quite reasonable target if we   
take into account the high bit rates in the future core network   
(non-real-time buffers could be quite large before this limit will be   
exceeded). The target for the maximum delay of real-time service could be   
in order of 50 ms. If the difference between real-time and non-real-time   
services is perhaps 1:10, I believe that it is not reasonable to   
determine any delay class between these two classes - there is no   
significant advantage to be attained from the network operator point of   
view. For any service which tolerates more than 1 s delay, the most   
reasonable solution is to use as large buffers outside the network as   
needed, and adapt the used bit rate according to the available bandwidth   
in the network.

With typical Internet traffic (web-surfing, file transfer, IP-phone etc.)   
I do not believe that there is real need for several delay classes,   
whereas the priority bits are needed in order to make possible service   
differentiation also when users have no idea what is their traffic   
parameters or what means 100 ms delay etc. If you pay more you get more   
capacity (or higher quality). A customer is perhaps ready to pay   
20$/month and he supposes to get better service than from other ISPs.   
With 3 priority bits + 1 delay bit we can do that (this solution is   
perhaps not optimize for all the business cases, but it can handle them,   
as there are available service classes with high quality and small   
delay).

Nevertheless, if there is real need to have more than 2 delay categories,   
it is not any big technical problem (at least SIMA concept can be quite   
simple be generalized to use 4 classes).

... Kalevi

 --------------------------------------------
Kalevi Kilkki
[email-masked]
Nokia Research Center
Helsinki Finland
 --------------------------------------------

 ----------
From:  Ed Ellesson
Sent:  22. Augustta 1997 6:33 PM
To:  kalevi.kilkki
Cc:  int-serv
Subject:  Why We Need (Delay) Priority

Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Kalevi,

You wrote:
>not to specify any strict delay limit for the real-time service, because

As I mentioned in my talk in Munich, network administrators for large
corporate networks sign Service Level Agreements with their clients, who
are the business unit or department managers responsible for business
performance.  The example I gave in the talk was that of a branch brank,
where the objective is to keep the lines short at the bank teller   
windows.
To help ensure this result, the branch bank manager signs an agreement   
with
the corporate network administrator that (for some large percentage of   
the
time) the response time for transaction processing on the teller's
terminals will be less than some value, usually ranging from a half   
second
to 2 seconds, depending on the desired service level.  (Not all of this   
is
network delay.  Priority is also managed within the transaction   
processing
server via work load management.)  There are other parameters involved in
these SLA's, including availability and expected traffic load.

My point in bringing this up again, is that the characteristics and delay
requirements of transaction processing traffic are sufficiently   
 different
than that of IP Telephony,  to argue for more than just "Premium" and
"Normal" delay preference treatment.

The objective for  IP Telephony traffic is round trip delays in the
neighborhood of 200 - 400 milliseconds, including the jitter buffer in   
the
receiving end system.  The round trip delay objective for transaction
processing is in the range of 500 ms to 2 seconds, depending on the   
service
level desired, and the associated business tradeoffs.   If both types of
traffic are present on the same network, I would argue that at least two
premium level queues are required, in addition to the "best effort"   
queue,
in order for the network administrator to be able to manage the network   
to
meet the desired level of service.

 -network control
 -high priority
 -medium priority
 -low priority
 -routine

I should also point out that this approach is used on networks which have
traditionally carried traffic loads which are far more predictable than   
the
traffic on today's Internet.

Since these networks have been up and running for many years, and meet   
the
customer need for delay management, I would argue that three bits be set
aside for queuing preference [unless someone can talk me out of it  ;-)   
 ],
so that existing customer applications and the associated management
techniques continue to work, as we migrate these apps to running over
Internet backbones,  using the standardized approach that we will develop
in the working group that follows up on the differential services BOF.   

for drop preference can be very effective in managing bandwidth   
allocation.

Within each queue, however, dropping preference could be used to allocate
bandwidth at that service level.  This would argue for separate fields   
for
delay management and dropping management in the IP header.

By the way, indicating a queueing delay preference in the precedence   
field
does not, to my mind, imply that every router in the path has to support
multiple CBQ queues.  I am told that there is very little queuing delay   
at
high speed interfaces in the core of the Internet.  Providing multiple
queues here probably makes little sense, since we are talking about a
queuing delay difference of a few milliseconds between a premium service
queue and a normal service queue.

A big difference in queuing delay is experienced is on relatively low   
speed
access lines to the Internet (56kbps and less).  Many of our customers   
use
these types of lines from their branch offices to their corporate   
backbones
today.  (When the Internet, in the form of a VPN, replaces a corporate
backbone, I do not expect the speed of the access lines to change
significantly.)  A single 1500 byte low priority packet at the head of   
the
queue, can significantly delay higher priority packets on these low speed
lines, such that the desired service level is not achieved.

field in the IP header should not dictate that multiple queues must be   
used

Regards,

Ed Ellesson