Subject: Re: On services, mechanisms, and naughty bits

From: [email-masked]
Date: Mon, 5 Jan 1998 19:48:33 +0100

Scott

> As a provider, I want the ability to invoke an arbitrary mechanism
> to an arbitrary bit pattern, and to remap those bit patterns on
> entry (and perhaps on exit).  This provides at least one minimal
> set of flexibility required to build a service.  

Does the above mean, that you would like to see an Internet standard
regarding the TOS bits saying something like "Bits X, Y and Z can be
used to indicate the service. The meaning of these bits is local within
an administrative domain." ?

Then why do we need to specify mechanisms at all? I guess the mechanisms
used are much more internal to the provider than the header semantics.
So why stick to some standardized mechanisms?
Why not just leave everything to the service providers to define?
Interoperability issues can then be solved via configuration of 
very flexibile boxes and bi-lateral agreements?

Zoltan Richard Turanyi
Ericsson TrafficLab, Hungary

---

From: Jon Crowcroft <[email-masked]>
Date: Mon, 19 Jan 1998 10:20:36 +0000

some random scribblings... why we might need several delay preference bits....

imagine we have an mbone conference as right now
and we run wb/vat/vic and maybe a web browser

at a diff-serv policer, you need to distinguish at least 2 delays and
2 precedence (at least that was what was argued for when CBQ was
talked about in various papers on it....)

so there's 2 things

you need  more than 1 level of priority
you need more than 1 dimension on which to differentiate what is
wanted in the way of service....(at least in the API)

we could look at the QoS tradeoffs that can be made in the various
end system tools - 

resolution
^
| \
|  \
|   \
|\   \      video
| \   \
|  \   \
|   \   \
| \  \   \
- ------------framerate

fidelity
^
| \
|  \
|   \
|\   \ 		audio
| \   \
|  \   \ 
|   \   \
| \  \   \
- ------------interactivity

[on the graphs above the sloping lines which are not necesarily straight, 
are iso-qos-surfaces.....i.e. same answer, but up to the application
to choose - but in and end system, this needs at least a bit extra
between the scheduler and the app, to allow dynamic selection of which
lone to choose...)

and in the network, the different queues are selected given a delay
and thruput preference
assuming admission for profile was using the parekh eqn, 
[worst-case-delay (d) = token-bucket-size (b)/allocated rate (g) +
                        (# hops (N) -1) * my max. pkt size (P1max)/g +
                       N * network's max pkt size (P2max) / link speed (r)]
[thanks to keshav for summarising eqn]
but queued according to a simple priority scheme.....so we need to
police accoridng to one thing, and forward according to another...

we might have alternate routes....so we have to differentiate
quite a few different things here....in any realistic scenaro

 cheers

   jon