Subject: [NSIS] QoS NSLP expectations

From: "Geib, Ruediger" <[email-masked]>
Date: Tue, 18 Nov 2003 16:33:02 +0100

Dear all,

the actual state of NTLP, mobility and firewall 
signaling seems to be relatively promising.
The QoS NSLP work may benefit from a more focused
scope. The draft-01 QoS NSLP is flexible 
enough to support almost any application (message 
set, signaling relations, scoping, stacking, 
state models and in a future version aggregation). 
It is more than QoS specific.

The authors circumvent the sensitive issue of 
determining or selecting particular QoS models. 
I agree that NSIS shouldn't define QoS models. 
I also agree that the QoS NSLP should be suitable 
for all possible QoS models. 

I'd favour an attempt like the one used for RTP: 
NSIS defines the basic QoS NSLP and leaves it to 
interested parties to standardise QoS model 
specific behaviour. NSIS should clearly state, 
where this should be done (NSIS, I'd suggest).

The QoS NSLP should be provide a minimum set of 
functionality and allow for QoS NSLP specific 
extensions. If as many options are kept as offered
by the current QoS NSLP draft, at least a basic 
default behaviour should be defined. Otherwise 
interoperability is at risk.

The draft may further benefit if NSIS tried to develop 
a detailed specification supporting deployed QoS 
models. This should be an academic excercise - at 
best informational or a non binding annex. Examples 
of operational QoS models:
- GEANT Premium service
- hose model based QoS services (offered as part of 
  IP VPN services)
- Internet2's LBE
- ??
The QoS NSLP shouldn't be optimised for these services. 
It should however easily be customisable to support 
them in a deployable way.

Regards, Rüdiger

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

---

From: [email-masked]
Date: Wed, 19 Nov 2003 10:03:15 +0200

Hi Rudiger,

> interoperability is at risk.

I basically agree with your points above.

> them in a deployable way.

One suggest would be to take 1 or 2 existing QoS models
and detail them in a seperate draft, as as a sort of 
proof-of-concept for the QoS NSLP.  These documents could
exist as individual submissions, but could be considered
by the WG.  

John

---

From: [email-masked]
Date: Wed, 19 Nov 2003 10:46:13 +0100

Hi Ruediger,

Thanks for your comments on the draft. I think our view on the QoS model is
actually in line with what you propose. What we currently propose in the
draft is to have a template for the QSpec and the consensus during the
meeting was that we should define which parts of this template should be
specified in the QoS NSLP draft. Also, we explicitly support what we call
local QoS models which can be regarded as the QoS model specific extensions
you refer to.

I agree with you that the scope of the work is fairly broad, but I believe
it is not broader then the suite of RSVP-related RFCs that touch on the QoS
signalling issue. Are there any of the topics that we currently have in the
draft that you feel we should not be addressing?

Best regards,
Sven

"Geib, Ruediger" <[email-masked]>@ietf.org on 18/11/2003
16:33:02

Sent by:    [email-masked]

To:    [email-masked]
cc:
Subject:    [NSIS] QoS NSLP expectations

Dear all,

Regards, Rüdiger

---

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 20 Nov 2003 03:42:28 -0000

hi all,

a tiny comment on qnslp vs. rsvp functionality:

> scoping - completely new
> stacking - completely new
> state models - reduced state and stateless added

i see these currently as consequences of the decision
not to have a single QoS model. at the moment, we
don't really have a clue how things should be done
where several different QoS models are supported along
the path - there was some alarming design-on-the-hoof
activity going on during the WG session, but this is
something that really needs to be thought out. 

the scoping and stacking in particular are possible 
mechanisms to make interworking/negotiation *less*
complex to implement and administer; maybe we will 
find better ways to do this as time goes by, but for
now I would be unhappy about saying (effectively)
"let's make things simpler by deferring the hard
problems until later".

cheers,

robert h.