Subject: Flow spec conformance

From: braden (Bob Braden)
Date: Fri, 20 May 1994 12:32:05 -0700

(originally sent to wrong list.  Bob Braden)

----- Begin Included Message -----

>From [email-masked] Wed May 18 14:52:21 1994
Date: Tue, 17 May 1994 12:27:39 +0800
From: [email-masked] (Don Hoffman)
To: [email-masked], [email-masked]
Subject: Re: Comments on RSVP, etc. (flow spec conformacne)
Cc: [email-masked]
X-Sun-Charset: US-ASCII
Content-Length: 3472
X-Lines: 73

>From [email-masked] Tue May 17 00:28 PDT 1994
> ... text deleted ...
>actually, i'm interested in what
>the int-serv & rsvp architecture says happens if you make an RSVP
>across multiple hops that implement multiple scheduling algorithms
>
>(for instance, JW's CSZ code and Van & our CBQ code)
>
>what precisely is the notion of conformance to a flow spec?
>

>From [email-masked] Tue May 17 09:54 PDT 1994
> ... text deleted ...
> It should work without any problems; the information exchange (between
>different nodes) should be independent of the scheduling discipline; for
>example (considering only deterministic and statistically guaranteed
>services), the "downstream" information is the traffic spec, and the
>"remaining" performance spec i.e. delay & jitter bounds, along with the
>probability that each bound would be met, etc etc. 
>
> This is how things work in the new Tenet scheme; they should be the same
>with RSVP and "int-serv" (as per my admittedly limited understanding of 
>the ideas and the design philosophy).
>
> -amit
>
> ps: In principle, we can have multiple scheduling disciplines at a 
>single node!!
>

The flow spec gives you a common language with which to talk to the
admission control and scheduling code. Conformance to a flow spec implies
the ability to map from the common language to the model offered by the local
scheduling discipline.

We are currently trying to understand how we might map the flow spec in the
RSVP spec to the CBQ model (Using some of the really excellent and high
quality code provided to us by the CBQ folks:-)).  Its not been completely
obvious to me (mostly due to my current poor understanding of CBQ).   What
happens if we cannot come up with a perfect mapping.  Does this mean that the
flow spec is not general enough and needs to be improved, or that our
scheduling discipline is not sufficiently conformant (BTW, I am not yet
claiming either is the case).  Basically, one of the measures of conformance
is a claim that we are "close" within some bounds.

How close is close enough?  How do we measure "close".  

For "guaranteed" or statistical types of reservation (I think the types Amit
speaks of), this may be conceptually straightforward (although in practice
difficult -- e.g., have you ever tried to write a performance spec that has
legal standing).

But what about predictive reservations (ala CSZ'92 etc.)?  The whole idea is
that we do not make firm a priori commitments.  Do we refund the cost of the
router for the periods where we are outside the tolerance of the conformance
specification?  On the face this might sound a bit silly, but many think some
sort of economic model is needed to keep the service provider (and service
implementor) honest.  The models could be either explicit, in that I only pay
for the times when I get conformant service, or implicit, where I pay less up
front but agree to live with out-of-conformance service.    We then don't
need to decide a priori if my service or implementation of the flow spec is
conformant or not.  I (as an implementor) am motivated to get close so I can
charge more money (or not if I want to sell at K-Mart prices).  The downside
is that we don't get to write some unambiguous statement in an RFC or
Internet Standard somewhere.  (BTW, I was a bit sloppy above in that
predicive delivery of QoS is different from "predictive" conformance to a
specification, but the parallels should be obvious).

Don

----- End Included Message -----

----- End Included Message -----

---

From: Craig Partridge <[email-masked]>
Date: Fri, 20 May 94 14:55:29 -0700

Don:

I may be misreading your note but I think it raises (at least) two separate
questions:

1. What defines a close enough match of service delivered to what the flow spec
requests?

    My simple minded answer is that I would hope the quality of service
    delivered is at least as good as that requested, and the measure of
    a good service is that it has sufficient flexibility in service offerings
    that the wastage of having to exceed a flow's requirements is not great.
    Similarly, for a flow spec, I'd say it should be able to encompass
    the range of services offered, while staying simple enough that it
    is easy to define the flow spec for a new service.

2. If one is doing predictive service, and falls outside the predicted range,
what do we do (regarding billing)?

    My reaction is that for predictive service, falling outside the range
    was part of the penalty one accepts for a less than perfect service
    guarantee.

    For a perfect service guarantee (in which the system somehow fails to
    deliver) my reaction would be that the network should charge the minimum
    packet rate for packets outside the service guarantee (or perhaps, nothing).

Craig

PS: I don't generally believe in per-packet billing, where the idea is one
keeps careful track of each packet going by and bills to its flow.  Unless
you're prepared to fill a CD ROM with data every 5 minutes for each link
in the network, this doesn't work.  (Where did 5 minutes come from --
assume we find a way to compress the per packet info to 1 byte [implausibly
small], and the average packet size is 1000 bits [the current average],
and you're on a gigabit link [they're coming soon] -- you're generating
about a megabyte per *second* of accounting data, and last I heard [which
was some time ago] CD ROMs stored about 300 MB).

What may work is a meter -- in which one counts packets in a few different
bins (e.g., long distance guaranteed flow, local guaranteed flow, long
distance predictive flow, local predictive flow, long distance datagram,
local datagram).