Subject: Diff-services in Intranets

From: [email-masked] (Konstantinos Dovrolis)
Date: Wed, 12 Nov 1997 22:57:23 -0600 (CST)

I remember that somebody mentioned a couple of months
back in this list that the precedence bits of the
IP header are already used for providing differentiated
services in some private Intranets. Unfortunately
he did not give any more information (and I cannot recall
who he was).

Does anybody know anything more on this? Perhaps
there are already some experiences from such Intranets
that it would be useful to be known. 

Thanks,

Constantinos

---

From: Ed Ellesson <[email-masked]>
Date: Thu, 13 Nov 1997 16:41:36 -0500

Constantinos,

>that it would be useful to be known. 

<bigger>You may have been referring to my posting that followed up my
presentation at the diff serv BOF in Munich, wherein I was trying to
justify multiple bits for delay preference.  Let me try again:  

The networks to which I was referring are corporate intranets, as well as
corporate SNA networks.  These networks have not typically used the tos
octet to indicate delay preference; however, my proposal was to begin
using this octet to do so, since IPSEC encryption will mask the
traditional means of packet classification, which has been the TCP and
UDP port numbers.  (More on IPSEC, in a separate post).  

Customers of ours want to use the Internet (or an intranet)  to support
transaction processing applications for which they have traditionally
used a leased-line private network, plus they want to eventually support
the emerging real time apps.  The needs of these very different
applications argue for greater than two values (1 bit) to indicate delay
preference.

SNA networks enable preferential delay queuing at FOUR levels: 

-network control

-high priority

-medium priority

-low priority

This approach has been proven successful for many years on SNA networks,
and should stand as an existence proof for the effectiveness of more than
two values for delay preference.  

These networks have traditionally carried traffic loads which are far
more predictable than the traffic on today's Internet.  Since the
predictability and variability of the traffic loads on the Internet are
greater, I think this argues for more delay control bits for the
Internet, not less.  My reasoning goes as follows: 

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 four, in order to distinguish between:

1. Voice over IP, and similar realtime human-to-human (or
human-to-simulated-environment) interaction, which requires the tightest
delay constraints.

2. IP-encapsulated SNA and SNA-like transaction processing  (commercially
significant human-to-machine interaction).  

3. Traffic which has a lower priority than commercially significant
transaction processing and file transfers, which have lower delay
constraints, or none at all, and can live with "worse than best-effort"
treatment.     

Please notice that I did not say "simple priority".  IMO, it is up to the
box vendor to implement their own version of  what delay priority means,
and whether or not CBQ, WFQ, USD or something else is used to instantiate
the multiple queue management, so that starvation is not an issue.  We
could even limit the standardized semantic to simply define that a higher
value in the delay precedence field means a lower delay queue.   This is
a simple way to start, which leaves box vendors,  ISP's, and corporate
net administrators with the maximum flexibility to implement what best
meets their customers' amd subscribers' needs, and gives us time to
figure out what works best at various interface speeds, etc.    

Since SNA networks have been up and running for many years, and since
they meet the customer need for delay management, I argue that THREE bits
be set aside for queuing preference so that existing customer
applications and the associated management techniques continue to work,
as we migrate these apps to running over Internet backbones, while at the
same time supporting newer apps, such as realtime.        

If it turns out that in some networks, the three bits (eight values) get
mapped to four queues, or to two, that is ok...that is up to the ISP or
private corporate network administrator.  If we do not allow at least
three bits (eight values); however, I think some networks will have a
problem accomodating existing apps that already use four values, within
the context of the larger set of apps with more varying characteristics
and needs in the Internet/Intranet environment.  It may also be useful to
map some apps that use UDP, with their own application-specific means of
congestion control other than TCP-windowing, to their own queue(s) in
some environments.  Having a few extra values to play with, allows
network administrators to do this.  

The main thing is to get a delay precedence field defined with at least 3
bits in it, and an order of queueing preference defined for the values in
this field.  Once we have that, we can work on the means of administering
the mapping of traffic type to precedence field value in a large network,
which is probably a topic for another working group.    

</bigger>

Regards, 

Ed Ellesson

Sr. Engineer, TCP/IP Technology Management

IBM Networking Software Products

Research Triangle Park, NC 

[email-masked]

919-254-4115