Subject: RE: [NSIS] Tentative Interim Meeting schedule

From: Attila Báder (IJ/ETH)<[email-masked]>
Date: Wed, 28 Apr 2004 16:19:29 +0200

Hi Dave, 

Thank you for your comments, they are very useful, we will use them for the QoS model template draft.

One comment regarding "diffserv is usually *not* doing QoS signaling":

Our QoS model proposal, RMD, uses a lightweight QoS signaling within Diffserv domain for making per-DSCP aggregated reservations within DiffServ routers. So this is something new that we want to do with NSIS.

Best regards, Attila

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On 
> Behalf Of David
> R. Oran
> Sent: Monday, April 26, 2004 6:34 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [NSIS] Tentative Interim Meeting schedule
> 
> 
> 
> 
> --On Monday, April 26, 2004 1:25 PM +0300 
> [email-masked] wrote:
> 
> > Hi Robert,
> >
> >> minor comment: there is some discussion on whether there are
> >> application-generic functionalities outside the transport.
> >>
> >> the specific item that made me think about this is the
> >> 'intserv/diffserv' agenda point: does this include handling
> >> mlpp and 2-phase operation? or should it be generalised to
> >> qos-models which do this? or should there be an even more
> >> wide-ranging discussion?
> >
> I think these things are in fact *orthogonal* to the QoS 
> model and in fact 
> have broader semantics than QoS. My partial list includes:
> - precedence and preemption
> - separation of reserve and commit phases
> - fate sharing
> - policy control for AAA and envelope resource utilization
> 
> These all strike me as things which are not really part of 
> the transport, 
> but which are identical or nearly so across NLSPs, and may in 
> fact need 
> explicit coordination across NLSPs.
> 
> There are also some gray areas:
> - route recording and explicit routing (this might belong 
> directly in the 
> transport, or between the transport and the NLSPs)
> - resource sharing (this might not gain much abstracted from the NLSP)
> 
> > I think this falls into the general 'intserv/diffserv' discussions
> > wrt what the QoS application supports.
> >
> I'm not sure if we're talking about the same thing here. In 
> fact, diffserv 
> is mostly about *not* doing QoS signaling, so I'm already 
> lost when you 
> talk about this being related to NLSP-dependent versus independent 
> functions.
> 
> > My feeling is that NSIS needs to be able to signaling existing
> > IETF QoS models (intserv/diffserv).
> Do we have a rigorous definition of what constitutes a "QoS 
> model"? I think 
> not...ergo, I have some ramblings below which if nothing else 
> might shed 
> light on how *I* think about this stuff.
> 
> 
> > Dave Oran also made the point
> > in Seoul about RSVP's TSPEC being a 'complete' representation of a
> > QoS model.  What I'd like to discuss at the interim meeting with
> > regards to the QoS application is what is needed to support
> > in the Qspec.
> >
> I think there are multiple dimensions to this:
> a) how you as a host describe your traffic via the control 
> plane signaling
> b) how you describe the binding between the described traffic and the 
> packets it applies to, so the data plane can do the right 
> classification
> c) how a NE describes what it is capable to doing with 
> traffic that arrives
> d) how a concatenation of NEs describe to a host how they 
> collectively will 
> treat the traffic when offered.
> 
> My comment about a TSPEC being a "complete traffic 
> description" applies 
> only to (a). In addition, a TSPEC may be an *overdescription* of the 
> traffic in the sense that if certain properties of the 
> description are not 
> honored, I'm still happy to have the traffic admitted. Things 
> that may 
> violate the stated properties include:
> - a drop rate > zero
> - a delay bound higher than some constant K for at least one packet
> - a delay bound higher than k for some fraction of packets 
> statistically 
> lower than  x percent
> 
> I recall Henning saying in Seoul that what we may really be 
> talking about 
> with QoS models is how to relate the various parameters of a traffic 
> description to the service properties of the various network 
> elements. I 
> agree with this view.
> 
> Another dimension of the mapping of the traffic description 
> to the service 
> is when you need to map down to classification and scheduling 
> limitations 
> of actual implementations and of various layer 2 QoS mechanics.
> 
> Just to give one example, assume you have an L2 which has a slotted 
> scheduler (e.g 802.11, DOCSIS). If you can't describe the 
> traffic properly, 
> you have to do slot size and slot rate allocation which is highly 
> pessimistic. It is really advantageous to be able to tell if 
> the traffic 
> source is CBR with a fixed packetization, because this 
> (common) subcase can 
> in fact result in optimal resource usage in a slotted L2. So, 
> continuing 
> this example using a TSPEC as the traffic description, you 
> can detect CBR 
> by a TSPEC where (peak rate = token bucket rate) and (minimum 
> policed size 
> = burst size). With this you can safely set the slot rate to 
> the token 
> bucket rate and slot size = burst size and never miss a 
> scheduled slot 
> (once you achieve initial phase lock on packet arrivals).
> 
> I think there's a lot of work yet to do on this, and what 
> I've seen so far 
> in the QoS model work doesn't seem to map terribly well onto my 
> understanding of what needs to be done.
> 
> Continuing on this general theme, what is done today with 
> intserv is that 
> there are only two "QoS models", the controlled load and guaranteed 
> service. The controlled load service is parameter-less; the 
> guaranteed 
> service has a single parameter - the deterministic upper 
> delay bound. If 
> people are saying we need more flexibility than that I won't 
> necessarily 
> disagree, but the work has to have a degree of rigor and not 
> fall into the 
> trap of micro-optimization, where the ATM traffic models have 
> sometimes 
> wound up.
> 
> Lastly, I do think that the RSVP machinery where all a NE can 
> do to report 
> what it will do with traffic is to reduce the TSPEC envelope 
> it is willing 
> to honor via an ADSPEC is likely inadequate. It does not capture the 
> ability to report service properties as I noted above. It 
> would be nice to 
> have something which could report the actual service 
> properties that a 
> given flow will get if admitted.
> 
> (Sorry for all the rambling above - if it isn't helpful then 
> just ignore 
> it).
> 
> Dave.
> > thanks,
> > John
> >
> > _______________________________________________
> > nsis mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/nsis
> 
> 
> 
> 

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: "David R. Oran" <[email-masked]>
Date: Wed, 28 Apr 2004 11:46:42 -0400

--On Wednesday, April 28, 2004 4:19 PM +0200 "Attila Báder (IJ/ETH)" 
<[email-masked]> wrote:

> Our QoS model proposal, RMD, uses a lightweight QoS signaling within
> Diffserv domain for making per-DSCP aggregated reservations within
> DiffServ routers. So this is something new that we want to do with NSIS.
>
I don't understand how you do this with a path-coupled signaling protocol. 
You'd need something which runs over a spanning tree of the entire domain 
to do this. Ditto for something somebody mentioned earlier in the thread 
about distributing diffserv class allocations and classification state to 
all the edge devices of a diffserv domain.

I do understand how you can use path-coupled signaling to indicate a given 
flow is to simply be bound into a particular Diffserv aggregate and to keep 
track of committed bandwidth in that aggregate on a particular path. There 
are some pretty tricky data plane things you need to make this work (e.g. 
hierarchical policer/shapers), but it can be done. Is this actually what 
you intend?

I also don't quite know what you mean by "lightweight QoS signaling". 
There's nothing lightweight about NSIS! Are you referring to the admission 
control decision and the amount of state installed being lightweight? 
There's a subtle difference between the signaling being lightweight and the 
computation and state installed being lightweight.

Sorry if I'm confused. I don't want to inject useless noise here.

Dave.