Subject: Number of DP bits?

From: [email-masked]
Date: Thu, 30 Oct 1997 11:05:29 -0600

As most of the threads seemed to have petered out, I wanted to confirm my 
observations:

1. It appears that most on the list are looking at a single DP bit as opposed to
several. 

2. It also appears that there is list support to use the precedence bits for 
traffic prioritization.

3. As DP bits are being looked at, it implies that profiles are also "in" right 
now.

I understand the arguments. I'm looking to get some consensus. Is anyone working
on a draft that incorporates these features yet?
Ken

---

From: Wu-chang Feng <[email-masked]>
Date: Thu, 30 Oct 1997 14:12:00 -0500

> 3. As DP bits are being looked at, it implies that profiles are also "in" right now.

I don't think this has been agreed on.  Marking "in-profile" packetsis one way to use the bit.  Another way is to adaptively
use
the bit to meet a specified application level bandwidth requirement.
When the network is uncongested, no packets will have this bit
set.

Wu

---

From: [email-masked] (Hyogon Kim)
Date: Thu, 30 Oct 1997 18:07:23 -0500 (EST)

Wu,

>When the network is uncongested, no packets will have this bit

One concern I have with such an application-level marking scheme is on its 
scalability. Fine when the marker can monitor the throughput of each
flow, but as traffic begins to multiplex, I am not sure if it is feasible
or if anybody would even care about individual throughputs.

One obvious scenario we can imagine would be where a small ISP buys a
profile and resells it to even smaller ISPs or end-users. Such scenario
causes no problem with Clark style profile meters, but the
application-level meter/marker at the ISP just doesn't fit in well there. 
Why would an ISP care about an individual flow's throughput? 

In essence, it seems to me that you are assuming that meters are basically at
the boundary, between end-users and the ingress ISP, and that I think
is a limitation.

-- 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
------------------------------------------------------------------------------

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 31 Oct 1997 09:04:52 +0200

1. It appears that most on the list are looking at a single DP bit as
   opposed to several.

in my i-d i had three dp bits in order to allow implementation of the
sima scheme.  if consensus now is (which i doubt) that we don't want to
support sime, then one bit is fine with me.

   2. It also appears that there is list support to use the precedence
   bits for traffic prioritization.

well, i would rather say that there is support on the list for
indicating the delay/jitter requirements of the packet. if that means
strict priority or something else, i would leave to the
implementations.

   3. As DP bits are being looked at, it implies that profiles are also
   "in" right now.

   I understand the arguments. I'm looking to get some consensus. Is
   anyone working on a draft that incorporates these features yet?  Ken

it is easy to update my i-d, if we can agree, which bit is the dp bit
and which bit is the delay/jitter bit.  since there already is the d bit
in the tos octet and i proposed to use that for delay/jitter rather than
inventing a new bit for the same purpose.  which of the three precedence
bits is used as the dp bit, i don't personally care.

-- juha

---

From: Wu-chang Feng <[email-masked]>
Date: Fri, 31 Oct 1997 09:00:11 -0500

> if it is feasible or if anybody would even care about individual throughputs.

Adaptive marking (or remarking) through a packet marking gateway can be done within the network on a per network/per
subnetwork/per application/etc. basis in order to support the service level agreement scenario that you mention.  We have some
experiments which show how marking can be done on an aggregate to maintain minimum bandwidths.

The end-host should really be responsible for some adaptation, however.  It makes no sense to mark a packet if it goes across a
bottleneck link which doesn't support service differentiation or if the network is uncongested.  With end-host adaptation, the
marking can be turned off upon detecting this.  (i.e. the network shouldn't mark a packet that the application doesn't want/need
marked).

Wu

---

From: Roch Guerin <[email-masked]>
Date: Fri, 31 Oct 97 09:59:56 -0500

>1. It appears that most on the list are looking at a single DP bit as opposed to

That would indeed be my inclination. I have nothing against trying to use
multiple bits, but it's just that I'm not really convinced how useful
it would be.  Given that free bits are likely to be scarce, I'd rather
use them for other purposes, i.e., delay precedence.

>2. It also appears that there is list support to use the precedence bits for 

I definitely would, although as Juha mentioned in his last note, this
should not be meant to imply a particular approach, i.e., priority queues.

>3. As DP bits are being looked at, it implies that profiles are also "in" right

I do think that profiles are a good idea, although again this should
not preclude application based marking.

>on a draft that incorporates these features yet?

Don't know but seem to recall seeing a note from Steven Blake saying
he was working on possibly such a draft.

Roch

---

From: Steven L Blake <[email-masked]>
Date: Fri, 31 Oct 1997 10:08:29 EST

> he was working on possibly such a draft.

Yes.  All I need is one more rainy weekend and I'll be finished.  :)

/*=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
| Steven L. Blake                 [email-masked] |
| Internetworking Technology         (919)254-2030 (work) |
| IBM Networking Hardware Division   (919)254-5483 (fax)  |
| "You like the 'Net?  You ain't seen nothin' yet!"       |
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=*/

---

From: "Alessio Casati" <[email-masked]>
Date: Fri, 31 Oct 1997 17:05:07 +0100

> on a draft that incorporates these features yet?

Ken,

I have been writing some notes collecting some of the issues being raised in the discussion 
on this list as I perceived them and adding something reflecting only my personal opinions.
Hereafter I submit these notes. Maybe it can turn out to be useful to the WG for taking some
steps further in the consensus making process.

Bye

Alessio

*************************************************************

Assumptions:
 
 IPv4 is used.

 Services provided to users:
 ---------------------------

 - Best Effort (BE) (bit 3 in TOS field = 0)
 - First Class (FCS): packets served with delay priority. (bit 3 in TOS field = 1)

 First Class is based on network provisioning and implies
 some negotiation of a service profile (either static, at subscription time,
 or dynamic, in the form of admission based on local estimate of 
 available resources).

 In profile packets are marked (IPI bit, as from Clark/Wroclawski)
 Out packets have IPI unmarked. IPI bit may be bit 0 in the precedence subfield 
 of the TOS field.

 Applications may send unmarked packets and those are not considered
 by the profile meter in their metering activity. Network side Profile meter
 unmark out profile packets sent as IN by the source.

 Basic Router semantic:
 ----------------------

 Two FIFO queues, with First Class packets served first up to a share
 of  bandwidth based on provisioning decision. BE packets can be transmitted
 by exploiting unused FCS bandwidth.
 Within the First Class queue unmarked packets get discarded first.
 Users showing a persistent out of profile behaviour (with high level of
 hits in out packets drop actions) incur in penalty (some filtering action
 in a proper dedicated section)

NOTE: Wherever you find FRED or RED, a buffer management process based on stateless per flow
      buffer allocation and a non per flow  "a la RED" buffer management mechanisms are 
      respectively intended. 

First Class Service 
-------------------

Since IN and OUT packets are queued in the same FIFO queue, buffer management
is critical in order to achieve correct service delivery.
Within the FCS queue, discard policies shouldn't modify the share of bandwidth 
the network commits to deliver. Proper provisioning should make congestion 
occurrence for in profile packets very unlikely. But, in case it occurs, each
IN flow should receive drop actions proportional to the load it offers, that is 
packets must be dropped with a common drop probability. Selective drop actions
might modify the relative bandwidth distribution. That would be unfair since
the traffic mix exactly represents the distribution which stems from accepted
profiles.
A congestion unresponsive  IN flow should not be penalized.
Therefore FRED isn't advisable for IN packets. RED is fair. The short run 
fairness assured by FRED to symmetric TCP connections and the improvement in fair
bandwidth sharing between Fragile and Robust (wrt congestion) TCP connections may not be 
considered as a sufficiently appealing feature in providing service to IN 
packets.
Actually FRED would need some estimate of a flow weight in allowed buffer resources usage
if it has to provide proper service. This is a very though job to do and implies keeping
state also for flows without packets inside the box (ultimately it leads to the need of 
reservations and to inscalability).
FRED is advantageous if  semantic related to FCS TCP profile is allowing getting a
fair share of the leftover bandwidth in the bottleneck of the engineered 
capacity for FCS. Therefore FRED might be used in a separate (virtual) queue reserved to
IN TCP connections. 

Assuring fairness between Fragile and Robust connections for out profile FCS packets is an
option for an ISP, since users are aware their OUT packets will be treated without any
commitment by the network. Therefore RED is needed, FRED is an option for OUT packets. 
Furthermore malicious users might make workarounds cheating FRED 's buffer allocation strategy.

Misbehaving flows identification is a MUST and can be performed by OUT packets RED
drop statistics.

In addition to RED thresholds for OUT profile packets, a drop tail threshold for OUT packets
may be defined in order to set an upper bounded number of OUT packets in queue.
The support for the droptail threshold is to be considered an option and some investigation
has yet to be performed on whether its pros outweigh cons.
It may serve as a Greatest Lower Bound on transient delay effects introduced by OUT packets.
Its also a cap on tolerated misbehaviour (although a not fair one).
An OUT max_threshold should bound the steady state effect of OUT packets on queuing 
delay (Steady State Greatest Lower Bound).

The IN and OUT packets thresholds might look like this (with the OUT droptail as an option)

        IN Maxthr   IN minthr  OUT droptail  OUT Maxthr   OUT minthr
        _____|__________|___________|_____________|______________|______
             |          |           |             |              |      |
 ======>     |          |           |             |              |      |======>
        _____|__________|___________|_____________|______________|______|

In summary, this is a RIO  augmented with an (optional) threshold on OUT packets admission.
How to set the thresholds depends on network tuning and service commitments.

It's not advisable to let First Class use a portion of unused BE bandwidth share,
since downstream routers may have no resources to accommodate it. Some dynamic 
provisioning can be performed in response either to significant IN packet dropping 
or to additional committed resources.
Routing should be made aware of available provisioned resources.

A more complex model may provide more First Class services differentiated by delay 
bounds.
The WG may allocate a set of 2 or 3 bits for this purpose and allow ISPs and router 
vendors to implement as many service classes as they wish, provided that mapping 
and accommodation functionality is provided at the boundaries and service commitments
are satisfied. The only bound on the choice is interoperability.

As from draft-heinanen-diff-tos-octet-00.txt, the 0-3 bits of the TOS field of IPv4 
header may be used for a two  service classes model, encompassing 1 bit delay priority
(bit 3 of the TOS field) and 3 bits for DP (user or network side marking) from the Precedence 
subfield.
A bit from the Precedence subfield might be used to deploy more delay classes, but this
is still something to be checked and agreed. This would not allow SIMA (or at least would limit 
the number of classes it can implement).
Other bits from the TOS field can come available as the WG checks no hindrance 
of existing protocols and functionality stems from their use.

Partition of First Class traffic in TCP (or congestion responsive) and UDP (or 
congestion unresponsive) traffic inside the routers may be an option.
This would let routers to treat congestion responsive and congestion unresponsive
flows in the most appropriate manner. How to distinguish between them is hard,
unless additional subscribtion based network side marking is in place, when 
encription is used.

Marking inside the routers.
---------------------------

RED may mark packets instead of dropping them up to a certain threshold on 
the average queue length (max_thresh, for instance) in order to allow 
adaptive users to lower their sending rate (and choose a less demanding profile,
thus saving money) in times of incipient congestion, before substantial packet
discard occurs. That would be nice for users. And would enable a form of Explicit
Congestion Notification for TCP (look at Sally Floyd paper for details on the issue) 
A TCP receiver receiving marked packets should signal its correspondent of that 
in ACK packets.
The main advantages are in avoiding unnecessary retransmissions (a great plus for
short conversations), in avoiding timeouts and  in avoiding the intrinsic disadvantage for tiny 
windows connections (which have less chance of performing fast retransmission).

This kind of marking could be performed on an ad hoc bit, thus the set of necessary bits is

1 IPI (DP) bit
1 RED marking bit
1 Delay Priority

Best Effort
-----------

No preferred behaviour. Penalty should be a MUST for misbehaving and congestion
unresponsive flows.

Open issues 
-----------

Profiles
Profiles Negotiation Protocol
Dynamic Network Provisioning Functionality
Interaction with routing
   ...
   ...

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 31 Oct 1997 20:16:09 +0200

while the discussion about the different buffer management/scheduling
schemes has been enlightening, i don't think that an rfc that describes
the semantics and syntax of delay/dp bits should say anything about how
things should or even could be implemented inside a box.  implementation
issues should be left solely for vendor differentiation.

-- juha

---

From: [email-masked] (Hyogon Kim)
Date: Fri, 31 Oct 1997 14:03:09 -0500 (EST)

Wu,

>experiments which show how marking can be done on an aggregate to maintain minimum bandwidths.

I am a bit confused. What you say above conflicts with what you say
below between parentheses....

In any case, how can your marker know what happened to its 10,000 flows coming
in from a customer network (e.g. per-network basis adaptive marking
among your examples) 30 hops down their 5,000 different paths in terms of 
their achieved bandwidths and decide whether or not to mark/unmark which?

>marking can be turned off upon detecting this.  (i.e. the network shouldn't mark a packet that the application doesn't want/need

Under usage-based pricing turning off the marking under 
non-congestion or under non-diff-capable bottleneck makes economical sense 
and _individually_ you may be able to do it (hence I guess
"end-host adaptation" above - but even in that case I don't know how you do it
without the meter seriously meddling with at least transport layer  
and up - so my concern "what if inside network?" above naturally arises). 
But my question all along has been: is it scalable? Can it be done in 
aggregate inside the network where flows are highly multiplexed? Namely, how 
would your network midpoint (un)marker learn the absence of congestion or the 
existence of non-diff-capable blttleneck for its 10,000 flows far 
down their different paths, in order to turn off the marks and save
money, but without looking at each flow individually?

-- Hyogon

---

From: Wu-chang Feng <[email-masked]>
Date: Fri, 31 Oct 1997 15:16:15 -0500 (EST)

Sorry about the lack of clarity in the previous message.  This may or
may not help.  We've examined marking schemes both in the network and
at the end-host.  The approaches do conflict somewhat with each other.  
Each has compelling advantages.

  Marking/unmarking in the network:
     Supports SLAs
     Marking on aggregates
     No changes needed at end-host

  Marking at the end-host:
     Allows an optimal (minimal) amount of marking
     Detection and backoff when no service differentiation
     Ability to turn off marking when application has no need for it

One architecture we've considered is to have the end-host mark its
packets depending on what it wants and then have the network unmark 
packets from different flows/aggregates/etc. as needed, depending on 
the SLAs it must support.  If the network continually unmarks a
connection's packets or if no service differentiation is being done,
the connection backs off its marking (temporarily).  Note that
for marking which is done in the network, our experiments count a 
packet arrival against a flow regardless of whether or not it is received 
in the end.  This gives some incentive for the end-host to make sure 
that its packets (both marked and unmarked) have a good chance of making 
it to the other side.  This motivates why we treat marked packets in 
the same way unmarked packets are treated (i.e. with TCP congestion 
control).  

  >> without the meter seriously meddling with at least transport 

The meter in this case does seriously meddle with the transport layer.
(i.e. TCP)  The meddling isn't something that adds a significant
amount of complexity to the transport layer, but it's a big disadvantage.

  >> would your network midpoint (un)marker learn the absence of 
  >> congestion or the existence of non-diff-capable blttleneck 

The network marker/unmarker can detect an absence of congestion 
since it always attempts to achieve its target rate(s) with a 
minimal amount of marking.  It cannot detect a non-diff-capable 
bottleneck which is why we focus on the end-host as well.  

Wu

---

From: Juha Heinanen <[email-masked]>
Date: Sat, 1 Nov 1997 09:57:51 +0200

again i don't think that we need to define where marking is done (in the
application, os, premises routers).  the only thing that matters from
the standardization point of view is the syntax and semantics of the
bits at the INTERFACE where the profiles are subscribed to.

-- juha

---

From: Dimitrios Stiliadis <[email-masked]>
Date: Sun, 2 Nov 1997 13:07:31 -0500 (EST)

> issues should be left solely for vendor differentiation.

I couldn't agree more. Any RFC can not force vendors to use the
same queue management techniqueus. It should simply state the
semantics and syntax of delay/dp bits. Vendors can take 
advantage of their expertise to provide different levels 
of performance.

Dimitri

---

From: "Alessio Casati" <[email-masked]>
Date: Mon, 3 Nov 1997 11:07:53 +0100

> advantage of their expertise to provide different levels 

I completely agree with you both, implementation related matters should not
be part of an RFC (though I can recall some RFC with some "Guidelines
for implementors" and "Examples of Implementation" inside, rfc2212, to name one).
But I think since we are at a very early stage of the work to be done 
(some preceding message confirm this standpoint), and since simulations and
prototyping are in order now ("running code"), I don't think anybody has to quit
proposing some implementation related issue. 
Furthermore IMO I don't think that if people  recognize the value of a
way of getting things done, an RFC shouldn't recall it at all or hide its existence.
The RFC should not tell vendors "you must do that this way" but may tell
"consider this solution, it looks good" if the WG issuing the RFC recognizes
some value in it.

Bye

Alessio

---

From: Roch Guerin <[email-masked]>
Date: Mon, 03 Nov 97 09:35:04 -0500

>bits is used as the dp bit, i don't personally care.

I'd personally would want to see at least two delay/jitter bits.
As I mentioned before, I'm fine with a single DP bit.

Roch

---

From: Juha Heinanen <[email-masked]>
Date: Tue, 4 Nov 1997 20:33:57 +0200

roch,

is it enough for you to have one bit that tells if the packet requests
normal or low delay/jitter and then another bit that tells how low.
that would give you two normal (= delay insensitive class) plus two delay
sensitive classes. or do you really need two bits, that is normal delay
plus three levels of delay sensitiveness?

-- juha

---

From: Roch Guerin <[email-masked]>
Date: Tue, 04 Nov 97 14:04:11 -0500

Juha,

>plus three levels of delay sensitiveness?

Not exactly sure I got your model exactly.  It seems that you still
need two bits, except that one of the combination is not used.  That
can be useful if there is something we can use it for, but I'm not
clear what that would be.

On a different level, i.e., the kind of delay differentiation we need,
I'm ok with one class that says "don't care too much about delay", and
then provide the granularity only within the set of classes that say
"I do care about delay".  

Roch

---

From: Paul Ferguson <[email-masked]>
Date: Tue, 04 Nov 1997 17:56:24 -0500

>then provide the granularity only within the set of classes that say

I can live with that, given the fact that delay may not be an
issue in the implementation.

I would still suggest that one bit is insufficient for either
consideration.

- paul

---

From: Dimitrios Stiliadis <[email-masked]>
Date: Tue, 4 Nov 1997 20:03:24 -0500 (EST)

Juha, Roch,

> plus three levels of delay sensitiveness?

I think there must be a quantitative component in these delay
classes. Given the fact that traffic distributions can not
allow us to even estimate the delays I would propose the following:

Class 1: I need a reasonable delay
Class 2: My delay must be 0.x2 of delay of class 1
Class 3: My delay must be 0.x3 of delay of class 2
Class 4: My delay must be 0.x4 of delay of class 3

Delay can be translated to bandwidth as far as I am
concerned, and I suspect that in a  lot of cases it is 
bandwidth  that people are interested in.

In this way a customer will "adapt" to the congestion
of the network. If she/he uses class x, and is not satisfied
by the current performance he can jump on another class.
I beleive we can allow some kind of adapting to be made
both by customers and the network. And at the same time,
the users must be able to predict the gain they will
see in their performance by changing their class
(i.e. paying more ... )

The tagging bit can be used for each customer to 
determine whether packets are in or out in the border.
ISPs can engineer different classes at different levels
of utilization, thus allowing larger confidence that the
model will be met. Users can get very good service, even
within the low classes, if the network is empty.

Note also, that resource distribution among classes is
not priority based, but rather bandwidth distribution
based.

In addition, if ISP A provides better service for Class x
than ISP B, the customer can move to another ISP and 
save money.

In the end of the day, the people who pay are the customers
and we have to protect them .... :)

Comments ?

Dimitri

---

From: "Alessio Casati" <[email-masked]>
Date: Wed, 5 Nov 1997 10:52:37 +0100

> Class 4: My delay must be 0.x4 of delay of class 3

[..]

> Dimitri

I fell OK with everything you wrote, I'd only make your class 1 the BE class (if by the 
definition you give it's already like that, drop this comment) and shift everything as a 
consequence of that. 

alessio

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 05 Nov 1997 19:47:35 +0200

> I would still suggest that one bit is insufficient for either

i suggested in my i-d a mapping scheme that allows each isp to support as
many bits it likes up to the maximum number allowed by the tos octet.  i
still think that is it a good approach, since it is unlikely that one size
would fit for all.  the only question is where do we take the extra bits
for the delay, since the current tos octet  has only one.

-- juha

---

From: Paul Ferguson <[email-masked]>
Date: Wed, 05 Nov 1997 13:36:10 -0500

Juha,

I'm still very uncomfortable with trying to factor in delay
variables/indicators into a scheme to provide simple traffic
differentiation -- I was under the impression that this was
the gist of the diff-serv effort (avoiding complexities to
determine delay bounds).

Personally, I'm in favor of a simple drop preference indicator
implementation, one that can be used by a preferential drop
mechanism (a la WRED) to drop lower precedence packets in the
face of congestion.

- paul

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 5 Nov 1997 21:04:51 +0200

yes, and you can do it even if we have three bits.  you use the mapping
and map three to one.

i'm in favour of that too, but there is no need to close the door from
having more variation in the future or for some special applications.
especially, when there is 8 bits to play with.

as an isp i would like to start experimenting with only one delay bit
and one dp bit.  it may well turn out that that is all i ever need, but
as i said, some other folk (e.g those experimenting with sima) may want
to have more.

-- juha

---

From: Roch Guerin <[email-masked]>
Date: Wed, 05 Nov 1997 18:29:48 -0500

Paul,

>I would still suggest that one bit is insufficient for either

You'll need more than one bit if you want to have some granularity
within the category that says "I care about delay".  I personally think,
this is useful above and beyond drop precedence, but I'll grant you that
more work is needed to sort out what's important, what works, what will
be used, etc.
But that means that I don't think anyone can claim that either a delay
precedence or a drop precedence only solution is the right one.  Also,
as John Wroclawski mentioned in a recent note, we probably want to have
a scheme that can coexist with existing reservation based approaches,
and that may not be something easily mapped onto just multiple drop
priorities.

Roch

---

From: Paul Ferguson <[email-masked]>
Date: Wed, 05 Nov 1997 18:55:24 -0500

>more work is needed to sort out what's important, what works, what will

I'd still like to hear a practial proposal which uses a 'I care about
delay' bit for something useful. Not that I'm particularly opposed to
the use of one (or several, for that matter), but I'm hesitant to
encourage it for fear that this will lead us down the path of looking
for a magic solution that requires state maintenance to determine
a priori knowledge of path delay.

However, now that I think about this further, a 'delay sensitivity bit'
could indicate to a traffic classifier that the packet simply needs
to be mapped to a special transmission queue. I certainly have no
hesitation about supporting this. A particular implementation could
use this indication in conjunction with special CBQ servicing.

This is straightforward enough.

>and that may not be something easily mapped onto just multiple drop

Agreed, and cannot see any immediate reason why either would not
coexist with RSVP in the same network.

- paul

---

From: Roch Guerin <[email-masked]>
Date: Wed, 05 Nov 1997 21:10:36 -0500

>use this indication in conjunction with special CBQ servicing.

Exactly. I want bits that let me easly direct packets to possibly
(that's only one implementation) different queues that would then be
serviced according to some kind of priority (in a generic sense).

Roch

---

From: "Alessio Casati" <[email-masked]>
Date: Thu, 6 Nov 1997 12:02:34 +0100

> mechanism (a la WRED) to drop lower precedence packets in the

I'm sorry if I'm too basic here, but if you don't have more queues
you'll have either head of line blocking or low utilisation.

alessio

---

From: Dimitrios Stiliadis <[email-masked]>
Date: Thu, 6 Nov 1997 08:01:01 -0500 (EST)

> a priori knowledge of path delay.

First of all, using only Drop bits means that all applications 
in the network are and should be "Politicaly Correct" i.e. 
translate drops as congestion. But, I don't think this is 
the case. 

> use this indication in conjunction with special CBQ servicing.

This is exactly one of the reasons that delay bits is a very
nice feature. Instead of relying on complicated classifiers
whithin the core to differentiate bandwidth, you give this
information on the delay bits and packets are directly 
mapped into different queues. Not only that : But mainly 
you give the ability to the application to change delay
priority if it sees that at the current time/path the
delays in a given class are not enough. 

Dimitri

---

From: Paul Ferguson <[email-masked]>
Date: Thu, 06 Nov 1997 08:53:44 -0500

>you'll have either head of line blocking or low utilisation.

Not at all. RED is a queue *management* tool, not a queue
manipulation tool. When there is no congestion, and there is
no concern about delay indication, a single queue can be
used -- everything can be transmitted FIFO, and everyone
is happy. When there is congestion, WRED just determines
which traffic gets into the FIFO queue in the first place,
instead of trying to reorder packets in a non-FIFO fashion.

Now, if you want to factor in delay, say for instance, by
mapping a specific TOS value into a specific CBQ queue,
then it would stand to reason that WRED could run on each
queue independently. You could frob the CBQ queue servicing
criteria separately -- each independent CBQ queue is still
FIFO unto itself. In the face of congestion, WRED simply
makes a decision, based on the IP precedence value,
on who gets into each specific queue. Those that don't
qualify, get dropped, and never even make it into the
appropriate queue.

- paul

---

From: Paul Ferguson <[email-masked]>
Date: Thu, 06 Nov 1997 09:43:04 -0500

>translate drops as congestion. But, I don't think this is 

TCP does the right thing.

Where the brain damage comes into this equation is that
applications which use UDP *should* be intelligent
enough to recognize situations where loss occurs and
throttle accordingly, since UDP provides no mechanism
to do this. The problem is that this is unfortunately
no the case.

This is also the reason why I made mention earlier of a
differentail/preferential drop mechanism, similar to
FRED, which provides some mechanism to handle no-adaptive
flows.

>delays in a given class are not enough. 

I have no problem with this, as I mentioned earlier. However,
it is my opinion you still need both delay indication bits
*and* drop preference bits to make it work more intelligently,
that is if you care about delay.

- paul

---

From: "Alessio Casati" <[email-masked]>
Date: Thu, 6 Nov 1997 15:53:12 +0100

On  6 Nov 97 at 8:53, Paul Ferguson wrote:

> is happy. 

Yes, In my message I supposed differential services would be 
also differentiating on delay. So you make a difference only
in times of congestion, that is no delay differentiation in
normal times. It's another position we have to consider.
I only ask for a customer out there to write to this list
wheter He/She would be happy to have the same performance
as everybody else except in times of congestion.

The reply would be YES, I WOULD if only you guarantee your network
is x% of the time congested (with x rather high).

So now CISCO (Paul to be fair) is going to offer to providers 
congestion based differentiated services. The worse your network provisioning
and network design, the more your customer will appreciate this kind of
service.

Thanks for your point Paul.

Alessio

Alessio

---

From: Paul Ferguson <[email-masked]>
Date: Thu, 06 Nov 1997 09:54:11 -0500

>and network design, the more your customer will appreciate this kind of

This credo holds true irrepective of the technology implemented.
If a network is sloppily designed, no magic know is going to
save you (of course, the depth of sloppiness is directly
related to how much a certain knob can help). If people are
looking for QoS solutions to correct sloppy network designs,
then I'm afraid they're deluding themselves.

But I digress. Let's focus on non-philosophical issues, shall
we?

Thanks,

- paul

---

From: [email-masked] (Hyogon Kim)
Date: Thu, 6 Nov 1997 13:04:08 -0500 (EST)

>delays in a given class are not enough. 

Certainly. Internet Telephony packets will be more than happy to 
see the low-delay queue. Delay and drop are generally orthogonal.

My concern about the delay field is about its size (I have similar
concern about the drop preference field size but in case of delay
it's more serious). I don't understand why people suggest as
many as 3 bits for the delay field. At the beginning of this thread, 
Dave Clark talked about this working group's similar experience with Int-Serv, 

>Initially, we proposed to have three levels of real time service, 
>that would be distinguished by the "feel" of the delay. The delays had 
>to be substantially different, to make the distinction worth having, 
>and after we screwed around with a range of offered loads and queue 
>service disciplines, we finally realized that if we forced the three 
>levels of delay far enough apart so that they really seemed different, 
>the bottom two were worse than best effort. So we bagged the whole idea, 
>and just went for the very simple, single level "controlled load".

Note that this was about _harder_ guarantees - now we are talking
about _soft_ guarantees, and suddenly it becomes more feasible to provide
finer granularity???

Why are we in such a hurry to use up the bits? 

-- Hyogon