Subject: [NSIS] Tentative Interim Meeting schedule

From: [email-masked]
Date: Fri, 23 Apr 2004 13:31:57 +0300

Hi all,

Here is the tentative schedule. Please comment, as I will be looking to
officially announce it early next week.

John

NSIS Interim Meeting
June 1st - 3rd, 2004
Location: Roke Manor Research, Romsey UK

More information at:
http://nsis.srmr.co.uk/interim.html

Tentative schedule

Tueday June 1st
 - QoS NSLP 
 - Support for intserv / diffserv models

Wednesday June 2rd

 - NTLP/GIMPS 
 - NAT / FW NSLP

Thursday June 3rd (half-day)

 - Security / AAA
 - Mobility

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

---

From: Kappler Cornelia <[email-masked]>
Date: Mon, 26 Apr 2004 08:36:57 +0200

Hi John, 

would it be possible to exchange NAT FW and Mobility so I can attend Mobility on Wednesday (I have to leave Wed late afternoon).

Best regards, Cornelia

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] Im 
> Auftrag von [email-masked]
> Gesendet: Freitag, 23. April 2004 12:32
> An: [email-masked]
> Betreff: [NSIS] Tentative Interim Meeting schedule
> 
> 
> Hi all,
>

---

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 26 Apr 2004 10:57:19 +0100

john,

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?

r.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, April 23, 2004 11:32
> To: [email-masked]
> Subject: [NSIS] Tentative Interim Meeting schedule
> 
> 
> Hi all,
>

---

From: [email-masked]
Date: Tue, 27 Apr 2004 14:14:14 +0300

Hi Cornelia,

> would it be possible to exchange NAT FW and Mobility so I can 
> attend Mobility on Wednesday (I have to leave Wed late afternoon).

Well, right now the NAT & FW work has higher priority, that is why
it is scheduled before the mobility, just in case we run short of time.

John

---

From: Kappler Cornelia <[email-masked]>
Date: Tue, 27 Apr 2004 15:33:29 +0200

Hi Dave, 

in this reply I summarize the current state of discussion in the group of people trying to write an ID on QSpec template (mostly Jerry Ash, Attila Bader and myself). So this is QSpec and not actual QoS Model work. I also have inline comments.

By nature of the work we are currently doing we cannot say whether other NSLPs besides QoS NSLP are in need of reserve/commit, priority etc. I would assume so, it would be very interesting to hear comments from the NAT people. 

The goal of the QSpec is defining a _generic set of parameters_ for use for authors of QSpecs. The QSpec contains both QoS Description and Control Information. The token bucket is one example of such a generic parameter. Another examples are priority of a flow or reserve/commit functionality. 

Now there is the interesting issue whether all QNEs MUST (or SHOULD) be able to understand these generic parameters. We came to the conclusion this is going to far. It is, for starters, sufficient to give QSpec developers a common language so they can at least understand each other and possibly translate QSpecs, e.g. at domain borders. So generic parameters SHOULD be used if applicable. QSpec authors are however free to define their own additional parameters if need be.

The other interesting issue is where functionality such as priority and reserve/commit is located. There are two somewhat contradictory guidelines: 

(i) locate it as far down the NSIS "layer model" (NTLP - NSLP - (QoS) Models) as necessary to make it accessible to all functionality who may have need to use it. This also _may_ easy coordination among NSLPs (Although I am not sure whether e.g. locating reserve/commit in e.g. a "common NSLP layer" (which we dont have yet and presumably never will have) would help coordinating reserve/commit for resource reservation and pinhole-opening for the same flow. Prerequisite is some way of coordinating session identifiers, or at least associating different NSLP sessions with each other, which we do not have yet either). 

(ii) locating it where it makes sense regarding the processing. E.g. for the priority information we figure it needs to be processed in the Resource Mangement Function (RMF) (see Fig 1 of QoS NSLP), because it is the RMF that knows resources are scarce, and who needs to consult priority information and find out what to do. So prio information is best stored in the RMF and therefore best located in the QSpec.

The solution we propose (at least for QoS NSLP it is a solution. It does not help with NAT) that we make our generic "Priority" parameter a "SHOULD use" - and one may even think making it a "SHOULD implement in QNEs". So even if some QoS Models dont need it, its implementation and processing would be uniform across QoS Models.

More inline.

> Auftrag von David R. Oran
> Gesendet: Montag, 26. April 2004 18:34
> An: [email-masked]; [email-masked]; [email-masked]
> Betreff: RE: [NSIS] Tentative Interim Meeting schedule
> 
> 
> 
> 
> --On Monday, April 26, 2004 1:25 PM +0300 
> [email-masked] wrote:
> 
> > Hi Robert,
> >
> 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.

Cornelia: 
One could think of using NSIS to signal to edge nodes of DiffServ domains that they should reserve that many resources for a specific PHB.

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

Cornelia:
Actually we are addressing these different dimensions in the QSpec ID (Except (b) which is part of the NSIS flow ID)

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

Cornelia:
We QSpec people think that if the token bucket and whatever other generic parameters we offer are not sufficient for what you want to signal you can define your own parameters (for the domain you are responsible for). We are careful to define too many parameters. Details need to be discussed.

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

Cornelia: 
I think a QoS Model (or: QoS Signaling Model) should describe how the QSpec parameters relate to the underlying QoS Architecture or provisioning model. This is why we need guidelines for QoS Models (to make clear how to do this), and possibly some QoS Model examples. However I think work on concrete mapping of traffic description to network element handling quickly gets beyond the nsis charter.

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

Cornelia: 
Even if this needs to be done, in my view it is (beyond may be examples, see above) not nsis business.

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

---

From: Attila Báder (IJ/ETH)<[email-masked]>
Date: Thu, 29 Apr 2004 10:46:37 +0200

Hi Dave,

Thank you we would be happy to receive comments about RMD. 
http://www.ietf.org/internet-drafts/draft-bader-rmd-qos-model-00.txt

As Georgios said the basic solution for determination of edge nodes is manual configuration. If GIMPS offered a mechanism for determintion of aggregaration boundaries I think we could use it also for RMD.

Best regards, Attila

> From: Georgios Karagiannis [mailto:[email-masked]]
> Sent: Thursday, April 29, 2004 9:59 AM
> To: David Oran; Attila Báder (IJ/ETH); [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [NSIS] Tentative Interim Meeting schedule
> 
> 
> 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
> 
> 
> > --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.
> 
> 
>