Subject: Basic questions about priority approach.

From: Muneyoshi Suzuki <[email-masked]>
Date: Fri, 07 Nov 1997 19:34:16 +0900

I have basic questions about priority approach.

The priority bits, such as the TOS field in the IPv4 packet,
identifies "relative" importance between packets, and priority
control is an indispensable function that enables QoS guarantee
communications. The priority mechanism may provide better
services compare with the best effort service. But QoS guarantee
communications can not be enabled only the priority mechanisms.
If all of packets in the network require highest priority,
it is same as the best effort service. The priority approach
provides services which are "better" than current service.
I think this is the design goal of the differential services.

In the commercial Internet backbone, a router must handle
IP packets from/to over 10,000 customer sites simultaneously.
In such environment, what is different 2-level priority approach 
and a few level priority approach?  The multi-level priority approach
increases the complexity and cost of the implementation. 
What type effect, that must justify the implementation
complexity and cost, does the multi-level approach provide?

Best Regards,

Muneyoshi Suzuki
NTT Multimedia Net. Labs.

---

From: Paul Ferguson <[email-masked]>
Date: Fri, 07 Nov 1997 08:04:53 -0500

>communications can not be enabled only the priority mechanisms.

Yes, that is very well understood. Use of relative indicator
bits is not meant, in any way, shape, or form, to provide any
sort of guarantee, but rather varying levels of best effort,
if you will. That's the whole point behind differentiated
services.

It appears to me that a lot of people seem to have a
problem understanding that there is a compromise that
needs to be made here -- if you want 'hard' guarantees
on maximal queuing delay, then RSVP with the guaranteed
service model is perhaps the best approach. Having said
that, you accept the fact that it will not scale infinitely.

The diff-serv work is geared towards providing 'softer'
mechanisms to provide varying levels of service
differentiation. The compromise here is that there are
no guarantees.

>I think this is the design goal of the differential services.

I think we agree here.

>increases the complexity and cost of the implementation. 

I would suggest that it is up to the organization to
determine the levels of granularity with which they
wish to differentiate -- this is not our decision to
make, in my opinion. I believe this would be an arrogant
assumption. We should focus on defining the mechanisms,
the semantics, and perhaps the architectural model, and
leave the choice on the granularity to the service
providers. They know better then we do how they will
want to deploy these tools.

>complexity and cost, does the multi-level approach provide?

I believe there is a minor relationship between complexity
and the number of levels of differentiation which is deployed,
but the operative word here is 'minor'.

$.02,

- paul

---

From: Jim Boyle <[email-masked]>
Date: Fri, 07 Nov 1997 13:12:32 -0800

>differentiation. The compromise here is that there are

I've heard it said by several, and for some time, that it might be possible
to put RSVP on top of differentiated services (though it would probably not
be the only service offered).  In that case you would have a guarantee, but
the backbone routers' classifiers wouldn't have to distinguish between you
and the other users with guarantees.

regards,

Jim

---

From: Muneyoshi Suzuki <[email-masked]>
Date: Mon, 10 Nov 1997 10:53:02 +0900

Dear Paul,

> but the operative word here is 'minor'.

I can't understand this point. It depends on the datalink media.

If we implement priority Q on the point-to-point link, implementation
costs of 2-level and multi-level are not so much different.

But if we implement priority Q on the current IEEE 802.3 ethernet,
it does not make sense. This is because current ethernet packet 
does not have priority field, so however the IP packet has the precedence
field on it, it does not have any effect. Of course, IEEE 802.1p will
enable priority control over ethernet, so if we implement 802.1p on
ethernet, it is feasible to implement priority Q on it. But, this 
approach require replacement current ehtenet media, so implementation
cost is expensive.

And if we implement 2-level priority Q on the ATM, it may be easy and
very cheap. This is because ATM has a 2-level priority field in the cell.
But, if we implement multi-level priority Q on the ATM, implementation
cost may be very expensive. This is because this approach requires
the multiple VCs which are correspond to the each priority level,
and it is also required a mechanism that synchronize packet sequence
between priority Q.

I would like to suggest to carefully survey and consider datalink media
characteristics before we decide level of the priority.

Best Regards,

Muneyoshi Suzuki

---

From: Paul Ferguson <[email-masked]>
Date: Sun, 09 Nov 1997 21:19:33 -0500

>characteristics before we decide level of the priority.

I believe this is unnecessary in a simplistic diff-serv approach,
since if you are mapping 'delay-indicated' packets to a non-FIFO
transmission queuing system, then you are simply prioritizing
transmission servicing. Packets with a lower delay-indication
will (should) be transmitted before those with higher (or no)
delay indication. All things being equal (or unequal, as the
case may be), we should not consider the underlying media at
all.

There are already other proposals which have been submitted
within the intserv framework which suggest methods to map
relative priority to link-layer semantics, but I believe
this is beyond the immediate scope of the diff-serv effort.

Of course, I don;t pretend to speak for anyone other than
myself, so take my comments at face value.

- paul

---

From: Muneyoshi Suzuki <[email-masked]>
Date: Mon, 10 Nov 1997 11:53:32 +0900

Thank you for your prompt reply.

> case may be), we should not consider the underlying media at

Why ??????? This is incomprehensive for me.

We assume there are two packet senders in a shared subnet that is implemented
by the IEEE 802.3 ethrenet, one sender transmit high priority packets to
the subnet, and another one transmit low priority packets to the subnet.
When these two senders transmit packets simultaneously, there are 
50% probability that the low priority packet suppress high priority packet.
At all, in this environment, priority control is equivalent to the nothing.

We can define priority field semantics on the IP packet, however if
the datalink media does not support it, it completely does not make sense.
The IP layer can "specify" priority level, but it is responsible
for the datalink layer to "enable" priority control. So, we should
definitely consider the data link media characteristics.

Best Regards,

Muneyohsi Suzuki

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 10 Nov 97 12:55:03 JST

> that, you accept the fact that it will not scale infinitely.

Here is the fundamental misunderstanding.

The network with RSVP is not requested to scale infinitely.

The network with or without RSVP with or without DP bit(s)
should scale to support (most of the time) the number of
flows used by the users and to satisfy (most of the time)
the bandwidth requirements of the users.

Give that requirement, RSVP, procesing load of which is
proportional to the number of flows, which, then, is proportional
to the bandwidth requirement, has just necessary scalability.

On the other hand, RED (or FRED) does not scale for a large number
of flows. Having a longer buffer means longer delay and is no
solution.

						Masataka Ohta

---

From: Juha Heinanen <[email-masked]>
Date: Mon, 10 Nov 1997 08:01:17 +0200

And if we implement 2-level priority Q on the ATM, it may be easy and
   very cheap. This is because ATM has a 2-level priority field in the
   cell.

clp bit in the atm header is drop preference bit according to diff-serv
terminology.

each delay class requires its own atm vc, but there is no need to
synchronize packet sequences between the vcs.

-- juha

---

From: Muneyoshi Suzuki <[email-masked]>
Date: Mon, 10 Nov 1997 19:31:26 +0900

Dear Juha,

> clp bit in the atm header is drop preference bit according to diff-serv

Yes. I agree this point.

> each delay class requires its own atm vc,

Yes.

> but there is no need to

I can't understand this point. It seems we are discussing different model.

If the same values are assigned to the TOS field in each packets,
which are correspond to a session, there is no need to synchronize
packet sequences. But your draft does not specify this point explicitly.

We can assign another values to the TOS field in each packets,
which are correspond to a session. In this case, I believe the packet
sequences synchronization is needed. This is because, however there are
VCs whose sources and destinations are the same, the ATM network
can not guarantee routes of the VCs are the same. If the network does
not support packet sequences synchronization in such environment, 
the application need to synchronize the sequences, at all. 

Best Regards,

Muneyoshi Suzuki
NTT Multimedia Network Labs.

---

From: Paul Ferguson <[email-masked]>
Date: Mon, 10 Nov 1997 06:46:38 -0500

>clp bit in the atm header is drop preference bit according to diff-serv

Before we launch in to a firestorm debate on whether diff-serv
semantics (if and when we ever get around to discussing them),
allow me to point out that we shouldn't necessarily be concerning
ourselves with how to map them to link-layer mechanisms, at least
not immediately.

Again, I think we need to cement the IP-layer semantics first,
and then worry about alternative complementary implementation
issues later.

Of course there is nothing to prohibit us from examining
methods to map IP-layer diff-serv semantics to complementary
link-layer hooks (e.g. ATM CLP, Frame Relay DE, IEEE 802.1p),
but let's not put the cart before the horse.

- paul

---

From: Paul Ferguson <[email-masked]>
Date: Mon, 10 Nov 1997 07:07:01 -0500

>Why ??????? This is incomprehensive for me.

Our first order of business, as far as I'm concerned, is to
define the IP-layer semantics. This is why these discussions
are taking place within intserv and not issll.

- paul

---

From: Muneyoshi Suzuki <[email-masked]>
Date: Mon, 10 Nov 1997 21:14:54 +0900

Dear Paul,

> define the IP-layer semantics.

Disagree.

Of course, we can define and shoud define IP layer semantics
that is independent of under layers, but the implementation
tightly depends on datalink media characteristics.

The upper layer protocol is just an abstract of the lower layer protocols.
We can not ignore lower layer characteristics.
And the priority approach is tightly depends on the datalink.

We should survey and consider many datalink layer characteristics,
extract common part from them, (I think we may abandon to support
some media), and abstract IP layer semantics from the common part.

Otherwise, however we define "ideal" semantics of the IP layer,
we can not implement it.

Best Regards,

Muneyoshi Suzuki

---

From: Paul Ferguson <[email-masked]>
Date: Mon, 10 Nov 1997 07:22:36 -0500

>tightly depends on datalink media characteristics.

I'm sorry, but this is a ridiculous assertion. A diff-serv
approach must indeed be devoid of reliance on link-layer
knobs, since there is *no way* of assuring that any particular
link-layer will be present in any particular network.

- paul

---

From: Jon Crowcroft <[email-masked]>
Date: Mon, 10 Nov 1997 12:34:52 +0000

>tightly depends on datalink media characteristics.

um, i think i have to agree with paul - we can define a level 2 free
IP behaviour and TOS bit API semantics, JUST LIKE INT-SERV did for
controlled load and guaranteed service, based in a model of routers
interconnected by point-to-point serial lines ONLY for a start....and
its a succesful formula, since in MANY cases, the ISSLL work that
follows can say "...but on a lightly loaded link of type x" where
frequently x is a fast lan (switched 100baseT ether ) where the
effects are negligable...

in fact i would go so far as to say that this makes even more sense
and is MORE likely to work with diff serv than int-serv
since we are not  specifiyting numerical absolutel values for qos
parameters, but relative (differential) services.....

by definition....

cheers
jon

---

From: "Alessio Casati" <[email-masked]>
Date: Mon, 10 Nov 1997 15:55:53 +0100

> link-layer will be present in any particular network.

I would not use words such as *ridicoulous* when replying to people raising
legitimate problems. It's a matter of taste.

Let it aside, You would make the INTERNET a NET. Don't think we are
in a NETF WG yet ;-)

Alessio

---

From: Juha Heinanen <[email-masked]>
Date: Mon, 10 Nov 1997 19:41:02 +0200

if you assign different tos values to different packets of your tcp/udp
or whatever session, then your packets will be reordered by the network
at a high propability and it is you task at the transport or whatever
layer ABOVE the network layer to take care of it.

on the other hand, if a session is sending packets with the same tos
value, then the network does not reorder them as long as the packets
take the same path and that is a very desirable property.

-- juha