Subject: RE: [NSIS] Tentative Interim Meeting schedule

From: [email-masked]
Date: Mon, 26 Apr 2004 13:25:31 +0300

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 this falls into the general 'intserv/diffserv' discussions
wrt what the QoS application supports. 

My feeling is that NSIS needs to be able to signaling existing
IETF QoS models (intserv/diffserv).  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.

thanks,
John

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

---

From: "David R. Oran" <[email-masked]>
Date: Mon, 26 Apr 2004 12:33:58 -0400

>> qos-models which do this? or should there be an even more
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)

> 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.

> 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
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.