Subject: RE: differential services tos octet

From: [email-masked] (Kilkki Kalevi NRC/Hki)
Date: Fri, 17 Oct 1997 12:04:54 +0200

One comment:

If routers try to manage a congestion situation by delaying all flows,   
the network cannot support real-time flows. Therefore, the delay   
indication, separately from drop preference, is definitely needed.  But   
then the congestion control of these flows must be based on drop   
preference.

So, the best choice (or, in my opinion, the only reasonable solution) is   
that routers are able to combine these discard and delay approaches.   
Discarding of packets shall be based on DP bits and the selection of   
queue shall be based delay indication bit(s). Or as Juha expressed it   
"the idea is that you have a queue per tos and different thresholds to   
each queue based on dp", where tos actually means delay indication.

 --- Kalevi
[email-masked]

 ----------
From:  Fred Baker
Sent:  16. Octoberta 1997 11:45 AM
To:  Juha Heinanen
Cc:  esc; int-serv
Subject:  Re: differential services tos octet

Sender: [email-masked]
Precedence: bulk

At 8:16 PM +0300 10/16/97, Juha Heinanen wrote:
>a network manager of a customer estimates that normally he has, lets
>say, at most 20 simultaneous 8 kbps voice over ip calls from his office.

First comment - I have yet to see a VoIP stream that was actually 8 KBPS.   
I
probably have seen 8 KBPS of voice go by, but inside RTP, UDP, IP, and
something lik-layerish, it becomes more like 40 KBPS. 20 of them is 800
KBPS.

>what i tried to say with the above example is that i need SIMULTANEOUSLY
>both dp and delay indication in the packet header.

OK, I would suggest that this is that what you are asking for in the case
is not a certain drop preference and a certain delay preference. They all
have the same delay preference - whatever delay they encounter, they want
it to be consistent. What's different is the drop preference - you take   
the
janitor's phone call and make it the thing to drop if anything is going   
to
get dropped, and by the way, if there's many drops, you'd like to drop   
the
whole call.

However, I'll argue again that the sender in each case has no idea what
algorithms are being implemented on the interfaces en route. Some routers
or switches will manage congestion by drops, and some will manage it by
delay. Hence, I claim that in your example, the matter is better served   
by
taking the three precedence bits as already defined, and on the access
T-1/E-1 link that will be managed using queuing (higher precedence   
implies
less imposed delay), and on the higher speed links in the ISP network it
will be treated as drop preference (higher precedence implies lower
probability of loss). You differentiate between the boss and the janitor   
by
(at the user end) taking one bit of precedence and setting it on the   
boss's
call but not on the janitor's call. You use the other two (more
significant) bits of precedence and encode them as

 11 - network control (routing, etc)
 10 - reserved flow (RSVP or whatever)
 01 - standard contract, within bounds
 00 - reserved flow or standard contract, not within relevant bound

I submit that your example helps make my point. Treating the existing
precedence bits, with the single bit of user priority, in this way lets   
you
gracefully deal with the situation proposed.

The one place that seems to me to need some thought is - what bit is the
user's precedence bit? most significant or least? I tend to say "least",
for policy reasons, but in this case I'd be more prone to say "most". Or   
to
say that the user precedence should be set by the reservation algorithm,
and beccomes a reserved flow.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-  
=
  "A beautiful idea has a much greater chance of being a correct idea
   than an ugly one."
                     -- Roger Penrose, "The Emperor's New Mind", 1989

---

From: Fred Baker <[email-masked]>
Date: Fri, 17 Oct 1997 10:57:39 -0700

>each queue based on dp", where tos actually means delay indication.

hmmm. If you look at the existing protocols (OSPF, IS-IS, RFCs 1122, 1349,
and 1812), you'll find that DTRC are expected to be used in routing, not
queuing. Agreed that we are discussing changing that, but someone really
ought to tell the routing folks.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  "A beautiful idea has a much greater chance of being a correct idea
   than an ugly one."
                     -- Roger Penrose, "The Emperor's New Mind", 1989

---

From: Juha Heinanen <[email-masked]>
Date: Sat, 18 Oct 1997 10:30:10 +0300

tell me, what does it help, if you use the d bit only for selecting a
low delay router, but don't use it to for selecting a low delay queue
inside the routers when the packets try to use that route?  you need to
do both in order to guarantee low delay.

but in the end, the only thing that really matters is low delay.  it is
not up to standards to tell how packets are queued inside a box.  if
cisco box can do magic and can guarantee low delay only with one queue,
then that is fine with me.  but cisco should not try to prevent another
vendor from implementing two queues and assigning packets into them
based on the d bit.

also, there is no way for cisco nor ietf to prevent an isp from agreeing
with its customers about two profiles (low and normal delay ones) based
on the d bit, since the bit is there and according to all the rfcs it is
the delay bit.

the only thing we actually need to agree on is which bit(s) are the dp
bit(s).

-- juha