Subject: Re: Concerns about exported numbers

From: [email-masked] (Mark W Garrett)
Date: Mon, 15 Jan 1996 09:50:58 -0500

> From: Mark Handley:
 > As controlled load is written at the moment, if an application so much
 > as noses above its specified flow, it can suddenly get greatly
 > increased delay...

Is a reasonable solution to say that a flow which exceeds its traffic
description will get the proper QoS applied to a subset of packets
which would be conforming to the traffic description.  The choice of
*which* packets exactly is left up to the network elements.  So the
damage to QoS is in some way proportional to the violation of the traffic
contract.

-Mark

-------------------------------------------------------------------------------
			Bellcore   Rm. 1A-220B			+1 201 829-4439
Mark W. Garrett		445 South St.			[email-masked]
			Morristown NJ 07960-6438  USA	     (FAX 201 829-2504)
                        WWW: ftp://thumper.bellcore.com/pub/mwg/homepage.html
-------------------------------------------------------------------------------

---

From: Jon Crowcroft <[email-masked]>
Date: Tue, 16 Jan 1996 09:10:45 +0000

>damage to QoS is in some way proportional to the violation of the traffic

Mark

we were looking for a more explicit statement of the behaviour of
network elements towards packets that exveed the QoS contract in the
presence of congestion

explicitly, for controlled load, we would like _all packets dropped_
to be part of the specification.....or at least some fixed
behaviour...

the idea is that this particular service class is aimed (we believe)
at rate adaptive senders, but expierenice shows that a human _can_
choose a minimum rate (whether based on cost or quality required) and
that a _known specified_ behaviour for the traffic above that spec is
needed to avoid unfair games being played by smart adaptors (basically
same as games that people can beat fair playing TCPs into submissio
nwith when there are FIFO routers....)

an alternative spec might be 

for packets overlimit, in the presenec of congestion (for this class),
apply RED....

but it isn't so important which is the fall back, but more that there
is only one

generally, we want to disambiguate something (an idea which is obvious
in CBQ, but less so in other approaches....)

when a service class is exceeded, packets can be put into another
service class, however, that does not mean that they penalize the
packets in the queues associated with that other service class who are
obeying their contract....rather, that there is an ordering on the
definitions of classes, and there is a policy which is implemented in
a given network element which may mean that there are allocations of
capicity to flows obeying different service classes,  and there is
what is left over in the absence of congestion within each, and within
all classes seperately - you need to define a notion of borrowing (see
van & sally's excellent link share paper.....or the CBQ code...)

 jon