Subject: RE: [NSIS] Tentative Interim Meeting schedule

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

Hi Dave, 

In our concept edge nodes administrate per flow states, interior nodes only per DSCP states. There are two type of messages: per domain and intradomain messages. For per domain meassages the next hop is the next edge router and intention is to use reliable transport for these. Intradomain messages are transported in datagram mode following the data path within the domain. They simply add, remove, refresh resource units for each DSCP in interior nodes, not knowing which flow it belongs to. In case of e.g. unsuccessful reservation int. node marks the corresponding field of the reservation message notyfying egress edge node which have per-flow info and handles the problem. 

You are right, I understand under simple signaling interior node functionality, admission control and datagram transport in the domain.

Best regards, Attila

> -----Original Message-----
> From: David R. Oran [mailto:[email-masked]]
> Sent: Wednesday, April 28, 2004 5:47 PM
> To: Attila Báder (IJ/ETH); [email-masked];
> [email-masked]; [email-masked]
> Subject: RE: [NSIS] Tentative Interim Meeting schedule
> 
> 
> --On Wednesday, April 28, 2004 4:19 PM +0200 "Attila Báder (IJ/ETH)" 
> <[email-masked]> wrote:
> 
> > 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.
> >
> 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.
> 
> > 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 Oran <[email-masked]>
Date: Wed, 28 Apr 2004 12:57:18 -0400

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

> Hi Dave,
>
> In our concept edge nodes administrate per flow states, interior nodes
> only per DSCP states. There are two type of messages: per domain and
> intradomain messages. For per domain meassages the next hop is the next
> edge router and intention is to use reliable transport for these.
> Intradomain messages are transported in datagram mode following the data
> path within the domain. They simply add, remove, refresh resource units
> for each DSCP in interior nodes, not knowing which flow it belongs to. In
> case of e.g. unsuccessful reservation int. node marks the corresponding
> field of the reservation message notyfying egress edge node which have
> per-flow info and handles the problem.
>
I'd have to ponder this pretty hard to figure out how it's supposed to 
work. I'll read you spec. One quick question though - how are the domain 
boundaries determined? This was the hardest part of doing the RSVP 
aggregation work.

> You are right, I understand under simple signaling interior node
> functionality, admission control and datagram transport in the domain.
>
> Best regards, Attila
>

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 29 Apr 2004 09:58:43 +0200

Hi Dave

Thank you for showing interest on the concept of using NSIS
for signaling Diffserv routers. Regarding the issue on how the domain
boundaries are
determined we are using the following.

The boundaries of a Diffserv domain are known by configuration. Furthermore,
there might be different ways of
selecting, for each flow,  the  Diffserv ingress and Diffserv egress nodes.
One of them is to select, for each flow,  the ingress and egress nodes that
are located in the data path
used by the flow.

Best regards,
Georgios

----- Original Message ----- 
From: "David Oran" <[email-masked]>
To: "Attila Báder (IJ/ETH)" <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Wednesday, April 28, 2004 6:57 PM
Subject: RE: [NSIS] Tentative Interim Meeting schedule