Subject: Re: differential services tos octet

From: Francois Toutain <[email-masked]>
Date: Thu, 16 Oct 1997 14:14:04 +0200

> Support for drop preference creates an undesirable incentive for
> applications to send packets that will not reach their destinations
> (knowing that the routers will discard the "less important" or "out-
> of-profile" packets at a point of congestion).  Packets that fail to
> reach their destinations consume bandwidth on all the links up to
> the drop point, bandwidth that might otherwise have been productively
> used by other traffic flows destined to different places.  It is much
> better, from the point of view of efficient use of the Net, to design
> the applications to desist from sending undeliverable traffic along
> congested paths, but the application designers won't go to the effort
> of designing effective congestion-backoff mechanisms if they can rely
> on drop preference instead.

Well some diffserv schemes may well provide such an incentive in a different
way. For instance the SIMA proposal computes the priority as a function of
the actual bit rate sent and the nominal bit rate that was requested (NBR
being linked to charging). So under this scheme there is no real conformance
to a given profile, as all packets (of a CBR traffic) get the same priority.
Now assume you send an actual rate higher than the nominal
one (and thus get a low priority). If you get packet losses, then you have
an incentive to reduce the actual rate, in order to get a higher priority
and thus avoid losses. Alternately you can choose to raise the nominal bit
rate (<=> pay more) so as to send the same trafic with a higher priority.
IMHO this is the essence of *differential* service : you can get a service
different from someone else, provided you pay for it ; this doesn't prevent
to adopt a "good-citizen" behaviour w.r.t. congestion control.

-ft.

---

From: Steve Deering <[email-masked]>
Date: Thu, 16 Oct 1997 14:21:54 -0700

> rate (<=> pay more) so as to send the same trafic with a higher priority.

Interesting.  I am unclear about whether you are talking about priority or
drop preference.  Some differences between those two mechanisms are:

	- A drop-preference mechanism does not effect packet ordering
	  whereas a priority mechanism (whether implemented as multiple
	  queues or by moving higher-priority packets to the front of
	  a single, shared queue) creates a reordering hazard.  One
	  practical effect of that difference is that applications are
	  unlikely to include packets of different priorities in a single
	  transport flow, whereas they might well mix packets of
	  different drop preference within a single transport flow
	  (or a traffic policer might well turn on DP bits in packets
	  without regard to which transport flows those packets belong to.)

	- In a priority scheme, one is often (though not always) concerned
	  about either bounding the bandwidth of the higher priorities
	  or guaranteeing some minimum amount of bandwidth for the lower
	  priorities, so that lower-priority traffic cannot be completely
	  starved out by higher-priority traffic.  Certainly an ISP selling
	  multiple priorities of service for differing prices would be
	  expected to do that.  In a drop preference scheme, on the other
	  hand, one never worries about starvation of DP-marked traffic.

Not having read the SIMA description yet, but reading into your above
comments, I suspect that SIMA is based on a priority mechanism, rather
than a drop preference mechanism.  It was drop preference that I was
arguing against.

I'm also unclear, from what you said above, about the granularity at which
NBR might be renegotiated.  Monthly?  Per "call"?  Within a call?  To all
possible destinations?  Separately to each currently-targetted destination?
It seems that you are thinking about renegotiating within a call, but that
sounds like potentially a lot of signalling back-and-forth as congestion
arises and subsides as a result of changing competing traffic loads and
changing routes.  Also, presumably, the costs of a particular priority
level would depend on the specific destination you were talking to (high
priority from California to Outer Mongolia via a dozen ISPs would likely
cost more than high priority from California to California across a
single ISP), so the signalling traffic would likely need to include
(instantaneous?) pricing information, and the applications are likely to
need pretty sophisticated algorithms (or a high-bandwith UI to a human)
to make the right economic trade-offs.  Hmm, I guess I ought to go and
read the SIMA proposal before indulging in any more wild speculation based
on trying to read between the lines of your brief message.  :-)

> different from someone else, provided you pay for it ;

Sure, I'm all in favor of ISPs providing some number of levels of priority,
and charging more money for subscriptions to higher priority service.  But
within each priority level, I think it would be a mistake to support drop
preference, because it would lead to poor use of the available resources
(by letting non-deliverable DP traffic consume bandwidth that could be more
productively used either by deliverable DP traffic at the same priority level
or by DP or non-DP traffic at lower priority levels).

> this doesn't prevent to adopt a "good-citizen" behaviour w.r.t. congestion
> control.

I never said that priority schemes prevent good behavior; I said that
drop-preference schemes encourage bad bahavior.

Steve