Subject: Don't let Delay eat up all TOS bits.

From: Dae Young KIM <[email-masked]>
Date: Mon, 17 Nov 1997 20:15:08 +0900

Current discussions on defining the semantics of TOS bits, especially
along with the document, 'draft-ferguson-delay-drop-00.txt', are more or
less exclusively on the delay parameter(DI: Delay Indicator)(As someone
pointed it out, DP(drop preference) may not be totally orthogonal to
DI.)

Although the delay seems to be the concern of most people in IETF today,
there may be other QoS parameters that might soon merge as important and
implementable metrics in the future Internet.

To be more specific, other parameters in the current assignment,
T(Throughput), M(Monetary), and R(Reliability), are not totally
meaningless. Although not seen immediately, the possibility that some of
them might soon or suddenly become important and implementable is not
out of the question.

One example is reliability. As all we know, a lot of people are working
on the issue of reliable multicast. Although most of the schemes operate
purely on end hosts, some of the new schemes suggest some related
functionality within the network, whether or not the functionaliy should
reside in the Internet layer. It might happen, in some near future, that
some ISP will pop up and say, "Hey, I can provide you reliability to
your multicast traffic. You just ask me and pay more. Don't ask me how
I'm doing that, but just feel it. In some good conditions, you might
well dispense with your special and cumbersome RM(reliable multicast)
transport protocol."

Another example of reliability related with IP multicast is a
military-like situation: "I want my network do multicast for me, but I
want to know who exacly are receiving my packets. I don't want my
enemies to get my packets. IPsec is not enough; I just don't want my
packet ever to reach the vicinity of my enemies. What I want is
multicast to the "known population".

Similar examples could be quoted for T and M, too.

My suggestion is that, if we are about to redefine the use of TOS bits,
let's do it with enough room for yet-unknown future (connectionless-)QoS
requirements. One way of doing that might be a hierarchical encoding of
TOS. Divide the TOS bits in two fields, 'If-selected' and 'then'.

        IF-Selected               THEN

        Delay                     Highest sensitivity
                                  .....

　　　　　　　　　　　　　　　　　.....
　　　　　　　　　　　　　　　　　Lowest sensitivity

        Reliability               Highest
                                  .....
                                  .....
                                  Lowest

        (Other examples)

In this sense, the definition of RFC1349 is not too bad; they can be
used as 'If-Selected' bits; T, D, R, M. Then the precedence bits can be
used as priority bits within the selected QoS parameter. Perhaps, this
is just what some network providers are doing already. If so, just turn
them on.

If such simple use (If-selcted, then) will not serve all, let us propose
more sophiscated hieararchy.

To put my concern in few words: "Don't let the Delay parameter eat up
all the TOS bits."

---

From: Jon Crowcroft <[email-masked]>
Date: Mon, 17 Nov 1997 12:01:05 +0000

In missive <[email-masked]>, Dae Young KIM exclaimed:

one of the goals of diffserv is to get better scaling than intserv so,
with that in mind.....

 >them might soon or suddenly become important and implementable is not

diffserv moves all Throughput into profiles....it doesn't move them to
invisibility.....

it can also move costs to profile+monitoring....

if people want to ask for "most expesnive", then surely they just send
with a rate (or delay preferenvce) mathcing the most expensive
profile?

 >well dispense with your special and cumbersome RM(reliable multicast)

there are end2end reasons (stricly, end2end2end2end2end... reasons)
why you can't do network-centric reliability.....though you might be
able to help

if we can help in a scalable way (a way that doesn't make switch or
router complexity untenable) why would you ever want to turn such a
service OFF?????

 >multicast to the "known population".

surely this is done best by sending your data encrypted - this acts as
a denial of service attack on your enemy sinec they
a) have to pay for the traffic
b) have even more to decrypt than they can cope with....

while i'd agree than policy routes for multicast (c.f. BGMP discussion
on the IDMR list) are useful, things that allow yo uto specify who
CANNOT get your traffic scale exactly as badly for people who really
care about recipients as things that allow a sender to specify an
exact receiver list.....i.e. not well at all:-)

 >To put my concern in few words: "Don't let the Delay parameter eat up

agree with the sentiment....one might be able to use other bitspaces
to achieve some of this though.....

 cheers

   jon

---

From: Paul Ferguson <[email-masked]>
Date: Mon, 17 Nov 1997 07:57:20 -0500

>to achieve some of this though.....

Earlier this month, I had mentioned that if it were a major concern
that all of the 4 bit TOS field not be used for delay indication,
that in the interest of minimal code, we might consider a minor
modification to draft-ferguson-delay-drop-00.txt:

[snip]

>      Bit            Delay
>     Value           Indication
>
>      __11           Highest delay sensitivity
>      __10             .
>      __01           Lowest delay sensitivity
>      __00           No delay sensitivity
>

[snip]

This would, at least, leave the high-order 2 bits free.

I am still of the opinion, however, that all of the 3 bit
precedence field can (and should) be used to indicate drop
preference.

- paul

---

From: Dae Young KIM <[email-masked]>
Date: Wed, 19 Nov 1997 09:57:31 +0900

> precedence field can (and should) be used to indicate drop

Could be a solution. We have then four alternatives (with 2 high-order
bits) to define QoS parameters, though I personally would prefer more
room for uncertainty.

BTW, are we all convinced that the drop preference do deserve those
precious three bits for its exclusive use in our pursuit for diff-serv?

--
Regards,

Dae Young
--------------------
http://ccl.chungnam.ac.kr/~dykim/

---

From: [email-masked] (Hyogon Kim)
Date: Wed, 19 Nov 1997 10:45:53 -0500 (EST)

Hello,

>precious three bits for its exclusive use in our pursuit for diff-serv?

Not at all. I think people just got tired of reiterating themselves
after a while because (almost) none of us could substantiate their
claims with experimental results, numbers, analyses or whatever.
Hopefully, like it or not, the 'rough consensus' in upcoming IETF will 
resolve the conflicts between our beliefs and get us started with a bit 
allocation.  Having said that, I will reiterate what I have been saying for one
last time. I haven't seen ANY technical reasoning why we need more than 1
delay priority bit in soft-guarantee Diff-Serv when hard-guarantee 
Int-Serv failed to come up with even 3 different "feels" of delay
guarantees (see earlier posting by Dave Clark). As for drop preference, 
cisco might have vested interest in their WRED products that use 3 
bits of IP precedence for 6(8?) classes ;-), but I have yet to hear a
convincing technical argument for so many classes (used as drop 
preference levels). So I like 1+1 approach with a possibility open for
later addition of more bits as necessary. I think bit 3 and 7 can be
a good start for 1st generation (2x2)* Diff-Serv routers.
 
*: 2x2  = 2 delay priorities and 2 drop preference levels

And now I will _really_ shut up as far as the bit allocation is
concerned ;-).

-- Hyogon
------------------------------------------------------------------------------
Hyogon Kim ([email-masked])	       		       |        (201) 829-4728
Research Scientist				       |           MCC 1B-225B
Internet Architecture Research Laboratory	       |      445 South Street 
Bell Communications Research			       |  Morristown, NJ 07960
------------------------------------------------------------------------------