Subject: Re: [NSIS] Re: Modularity and grouping QoS requirements

From: "Lars.Westberg" <[email-masked]>
Date: Fri, 01 Mar 2002 09:41:55 +0100

Comments

Cedric Westphal wrote:

> Vlora and all,
>
> one reason for using the model in draft-nsis rather than the one in
> draft-partain is that it allows to define mobility requirements.
> For instance, think of a handoff, where the previous access router (PAR)
> transfers QoS context to the new access router (NAR).
> There is no NAR-PAR interface in draft-partain; however, it is easy
> to see that the NAR is a QC (making the CAC decision at least) for
> the new path, and PAR a QI.
>

What are you refrering to ? Do you want that NSIS should specify how mobility
should be solved  or ...?
We have a scenarion chapter incorporating scenarios for different apects. I
sounds for that this is what you are refering to but you are very wellcome to
define a new interface if that is needed from requirements perspective.  What
is the new requirements at the new interface that we have not included ?

>
> Another drawback of the 'interface' framework is that QoS signaling is
> not necessary limited to interfaces. For instance, to update some
> reservation
> after a handoff, you'd need to signal to the crossover router(s),
> wherever it
> is. Most likely this crossover router does not correspond to any interface.
> Note that draft-nsis either does not provide such framework, but it could
> easily (should) be added with a QoS Termination point abstraction. I think
> it is a dead end to assume the starting point and the end point of the
> QoS signaling to
> be some pre-defined interface. Draft-nsis goes a half step in the right
> direction by allowing the starting point to be anywhere and abstracting
> it into
> the QI, which is a better starting point.

 RSVP assumes that all router are processing the same functionality model. We
trying to differentiate the functionality on different type routers to get
better processing performance. To have a model which assumes that all routers
should process everything will probably get difficulties with scaling.

I think that the two approaches are complementing each other and I would
appreciate the discussion how we could combine the benefits of the two models.

Our main target is improved processing in routers by structuring the
requirements on different interfaces. The purpose is to get a modular solution
with improved scaling propery in a new version of RSVP.

>
>
> Cheers,
>
> Cedric.
>
> Vlora Rexhepi (ELN) wrote:
>
> >Hi Marcus,
> >
> >|I am open to the consensus of the WG. Just some remarks inline.
> >Great.
> >
> >|> One of the outcomes of the NSIS meeting in Salt Lake City was
> >|> to start working on defining QoS requirements based on
> >|scenario cases.
> >|>
> >|> Furthermore, we all agreed that modularity is very important;
> >|> During that meeting many people agreed that after the QoS
> >|requirements
> >|> are defined, then they will be grouped according to network
> >|> interfaces (e.g., UNI (access), NNI (backbone));
> >|
> >|Here you have at least 4 types (UNI with home network, UNI
> >|with foreign
> >|network, NNI within same administrative domain, NNI across
> >|admin domains.
> >
> >In draft-partain-nsis-requirements-00.txt there are three types
> >of interfaces identified:
> >- interior <-> interior interface
> >- border node <-> border node interface
> >- host <-> border node interface
> >Please see the draft for detailed info.
> >
> >
> >|> A reasonable way of doing the above, is in my opinion the following:
> >|> * First define the scenario cases;
> >|Agreed
> >Great.
> >
> >
> >|> * Second using these scenario cases, define which QoS
> >|requirements will
> >|> have     to be satisfied on each network interface, and on
> >|each network
> >|> node type, e.g.,    host, access router, interior router,
> >|border router,
> >|> edge router, proxy, bandwidth broker, ...
> >|
> >|We can still do it my concern is that we have then with N scenarios (N
> >|currently 5 to be more) and M interfaces (M as mentioned above
> >|=4) and L
> >|node types (L=7 in your proposal)
> >|
> >|This implies NxMxL entities we have to define requirements
> >|for. And this I
> >|am definitly not willing to do.
> >Understandable. No one is suggesting to have more entities than
> >the number of typical network nodes known in the Internet
> >community.
> >What, Georgios is suggesting is that the [NSIS] WG derives requirements
> >from the scenarios and group them into particular interfaces between
> >different nodes they apply to.  This is already done in
> >draft-partain-nsis-requirements-00.txt.
> >Based on this, the QoS model entities would be defined later.
> >
> >
> >|> Third the outcome of this
> >|> separation of QoS requirements it will result in    an
> >|efficient grouping
> >|> of the QoS requirements.
> >|
> >|We can discuss the grouping (I was just to lazy to change it so far)
> >I already mentioned above one possible way to do it :-).
> >
> >
> >|> After the QOS requirements grouping is done, then we could
> >|define a QoS
> >|> model. This QoS model could have entities such as a QoS
> >|initiator and a
> >|> QoS controller.
> >|
> >|Yes, that is what the framework document does.
> >Exactly. The framework should be a result of scenarios and the
> >requirements derived from them. As it is now in the [NSIS] WG
> >draft the things are done in a different order. And as we could
> >see it the "problem discussion model" has a problem when one wants
> >to apply it in other scenarios rather than the ones described in
> >the [NSIS] WG draft.
> >
> >
> >|> The problem I have with the NSIS WG requirements draft is that these
> >|> sequence of doing things is very much opposite to the
> >|sequence mentioned
> >|> above. In the NSIS WG requirements draft the following sequence of
> >|> actions is followed:
> >|
> >|> First a QoS model and its QoS model entities are
> >|> defined. At this stage, these    QoS model entities, e.g.,
> >|QoS initiator
> >|> and QoS controller, are not representing network entities.
> >|
> >|This is the second step in the draft and it is ment to reduce the node
> >|types.
> >Yes, but it does also impact the QoS requirements.
> >
> >
> >|I understand that some people have problems to see the value
> >|of it, others
> >|very much appreciated the more abstract way of thinking. I
> >|would say it is
> >|50:50 so far.
> >|
> >|And some even think we should get more abstract
> >|
> >|>  * Second, the QoS requirements are grouped according to
> >|these QoS  model
> >|> entities     and not grouped according to any network
> >|interface or any
> >|> network node type!
> >|
> >|No they are grouped into topics like security, flow definition,
> >|architectural, etc. The grouping actually as nothing to do
> >|with the model
> >Right. But, I think the grouping should be done based on the
> >agreement in the meeting at Salt Lake City.
> >
> >|>*Third, the QoS model entites are assigned to
> >|> specific network node types. In my opinion    this  step is
> >|difficult to
> >|> be accomplished and for some scenarios is impossible to be done.
> >|
> >|You might be right, but we have done it so far. Currently I do
> >|not see it
> >|as too difficult, but I might be wrong.
> >We already heard from Danny that in their scenarios it was not
> >an "easy exercise"...
> >So, could someone (other than the authors) please try to relate
> >one of the Scenarios from draft-partain-nsis-requirements-00.txt
> >with "Problem Discussion Model" from the [NSIS] WG draft such that
> >we can close the discussion on the generality of the model? That
> >would be appreciated very much.
> >
> >Regards,
> >Vlora
> >
> >
> >
> >
> >_______________________________________________
> >nsis mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/nsis
> >
>
> _______________________________________________
> 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: "Vlora Rexhepi (ELN)" <[email-masked]>
Date: Fri, 1 Mar 2002 11:53:43 +0100

Hi John,

|> |1. that we should annotate requirements according to which 
|> |network environments they are particularly applicable to or 
|> |crucial for (e.g. 'scalability is important in the core' and so on)
|> 
|> I would rather say that the QoS requirements would be derived 
|> from different scenarios/use cases and than grouped according to
|> the interfaces they apply to.
|
|I agree.  For example, on a small lightweight device, scalability
|is very important as well.
True.  

|> |I'm entirely in sympathy with (1) - indeed, that's what I 
|> |thought section 6 of the WG draft was trying to do. (More 
|> |scenarios and the format might start to be tricky, but that's 
|> |another question...)
|> 
|> Section 6 of the WG draft gives a good overview on the importance 
|> of the requirements to the Scenarios 1 - 5, but I would prefer 
|> to see which requirements apply to particular interfaces 
|> in the Scenarios 1-5.
|
|My feeling is that requirements should be left as requirements,
|and we will specify the interfaces in the framework document.
|If we need to provide some textual wrapping to help frame the 
|requirement, then we should.
|
Are you suggesting to keep the definition of QI/QC in the requirements
as well?
If so, than the requirements should be defined such that the
modularity concept is introduced in the definition of QI and QC. 
For example if the QI is in the host different requirements apply from
the case when QI is elsewhere. The same would be in case when QC is a 
centralized point or resides in border or interior node. In all these 
cases there will be specific requirements that would apply. 

|For example, what does scalablity mean?  It could mean several
|things:
|
|	1) Create minimal state in nodes.
|	2) Ability to aggrate traffic.
|	3) ... others ...
|
|If we define all of the requirements in terms of existing solutions or
|scenarios, I think we will have done the wrong job.

Agree. The requirements should be derived from the scenarios, but not 
defined specifically for them.

Regards,
Vlora

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Fri, 1 Mar 2002 13:59:20 +0100

Dear all 

I think there is a disagreement on how the requirements 
are separated/grouped.

I will try to propose another solution.
Maybe we can separate the QoS requirements 
in QoS complexity levels:

For example:
* QoS complexity level (1): minimum QoS  functionality, that is the simplest 
                    QoS functionality  possible, e.g., requirements for 
                    scalability, simplicity, speed;

* QoS complexity level (2): a higher level of QoS functionality complexity 
                    than complexity level (1), e.g., requirements for QoS 
                    domain admission control;
* QoS complexity level (3): a higher level of QoS functionality complexity 
                    than complexity level (2), e.g., requirements for security and 
                    accounting (related to QoS);
 .
.
* QoS complexity level (N): a higher level of QoS functionality complexity 
                    than complexity 
                    level (N-1) (e.g., centralised QoS functionality);

In this way we define some kind of QoS toolbox, that can be used in a flexible
way by e.g., a network provider.
For example a network provider could choose to implement 
the QoS complexity level (2) in a border router. Some other 
network provider may  choose to implement the  QoS complexity
level (3) into a border router;
The same holds for other network entities;

Can we reach a consensus on this?

Best regards,
Georgios

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: donderdag 28 februari 2002 22:31
To: [email-masked]; [email-masked];
[email-masked]
Subject: RE: [NSIS] RE: Modularity and grouping QoS requirements

Hi All,

> |1. that we should annotate requirements according to which 
> |network environments they are particularly applicable to or 
> |crucial for (e.g. 'scalability is important in the core' and so on)
> 
> I would rather say that the QoS requirements would be derived 
> from different scenarios/use cases and than grouped according to
> the interfaces they apply to.

I agree.  For example, on a small lightweight device, scalability
is very important as well.
  
> |I'm entirely in sympathy with (1) - indeed, that's what I 
> |thought section 6 of the WG draft was trying to do. (More 
> |scenarios and the format might start to be tricky, but that's 
> |another question...)
> 
> Section 6 of the WG draft gives a good overview on the importance 
> of the requirements to the Scenarios 1 - 5, but I would prefer 
> to see which requirements apply to particular interfaces 
> in the Scenarios 1-5.

My feeling is that requirements should be left as requirements,
and we will specify the interfaces in the framework document.
If we need to provide some textual wrapping to help frame the 
requirement, then we should.

For example, what does scalablity mean?  It could mean several
things:

	1) Create minimal state in nodes.
	2) Ability to aggrate traffic.
	3) ... others ...

If we define all of the requirements in terms of existing solutions or
scenarios, I think we will have done the wrong job.

John

---

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 1 Mar 2002 15:31:54 -0000

Georgios,

I think this could be a useful 'explanatory' grouping method which complements the scenario allocation stuff in the current section 6. I think we're all clear that we will need to be able to tune 'the' NSIS protocol to the point in the network where it is used, and this grouping should give us an idea of what typical option groups might be (e.g. what is the simplest possible protocol we can think of).

I wouldn't expect the 'capability sets' to be strictly ordered in complexity, but let's see what happens. I would also see these things applying to protocols rather than nodes (so, in your example, a border router might use one protocol for external communication and another one with different scaling and security properties for internal signalling); we need an NSIS framework to enable us to ensure that these individual protocols do actually fit together.

Yours,

Robert H.

> From: Georgios Karagiannis (ELN)
> [mailto:[email-masked]]
> Sent: 01 March 2002 12:59
> To: [email-masked]

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Fri, 1 Mar 2002 17:12:36 +0100

Hi Robert

Thank you for your reply!
Should I and the authors of  the "draft-nsis-partain.."  think about 
some text for Section 6?
In the mean while we will also
list the requirements that are given in the "draft-nsis-partain" and 
are not listed in the NSIS WG draft.

Regarding the NSIS framework we will be happy to co-operate!

Best regards,
Georgios

-----Original Message-----
From: Hancock, Robert [mailto:[email-masked]]
Sent: vrijdag 1 maart 2002 16:32
To: 'Georgios Karagiannis (ELN)'; [email-masked]
Subject: RE: [NSIS] RE: Modularity and grouping QoS requirements

Georgios,

Yours,

Robert H.

---

From: [email-masked]
Date: Fri, 1 Mar 2002 22:56:08 +0200

Hi Vlora,

> the interfaces they apply to.

Can I ask what will this bring us?  Remember, the WG has a framework
document on its list of things to do.  Frameworks usually suggest
creating architectures & giving scenarios.  Isn't your suggest
a bit like putting the cart before the horse?

> to see which requirements apply to particular interfaces 

I truly believe it would be much more useful for us to spend
time on specifying the requirements correctly than saying
'if you are trying to do this, do this.'

We are trying to build some basic building blocks here, so
that vendors, service providers, etc. can put them together
to do some interesting things.  If John Postel had specified 
UDP so that it could carry VoIP traffic, I think UDP would
have suffered from much bloat and be much less useful ... 
just as an example.

John

---

From: [email-masked]
Date: Fri, 1 Mar 2002 22:56:03 +0200

Hi Robert,

Putting my chair hat on:

> A question on what is really being proposed here (about 
> modularity/grouping):
> 
> When people say that we should group the requirements 
> according to things like UNI(access) or NNI(backbone), do they mean
> 
> 1. that we should annotate requirements according to which 
> network environments they are particularly applicable to or 
> crucial for (e.g. 'scalability is important in the core' and so on)

I think that the above is dangerous because it is limiting.
Usage scenarious are useful when they help us understand
why a certain requirement is needed.  However, if the usage
scenario is more important than the requirement, then we are 
in trouble.

> 2. that we already know there will be a UNI NSIS protocol and 
> an NNI NSIS protocol and we are actually trying to write 
> requirements specifications for these particular protocols

This, imo, is a bad thing.  Requirements SHOULD NOT presuppose
a network architecure.   

> Or is there already a consensus on the 'two protocols is the 
> solution' view within the WG?

This is something that the WG cannot decide on yet.  We are 
working on requirements, not solutions yet.  To be very
specific, I see the current work to be this: create
requirements, and use some scenarios to illustrate
the requirements (i.e. - try to ground them in some
reality).  Develop a framework which will support
these requirements.  Create a solution which fits into
the framework & fufills the requirements.

Many protocols were less than successful because they
attempted to solve a problem which ended-up not being
the problem that needed to be solved.  If we color
the requirements by focusing on specific scenarios,
we run the same risk.

John

---

From: [email-masked]
Date: Mon, 4 Mar 2002 09:25:10 +0200

Hi Georios,

> In this way we define some kind of QoS toolbox, that can be 
> used in a flexible way by e.g., a network provider.

My opinion would be that the framework document can do this.
The framework doc will discuss the NSIS architecture &
could apply the requirements to the architecture.  I think
the disagreement on the grouping / seperation of requirements
are a bit pointless - we should be focusing on the requirements.

John

---

From: [email-masked]
Date: Mon, 4 Mar 2002 12:32:24 +0200

Hi Vlora,

> Are you suggesting to keep the definition of QI/QC in the requirements

Well, some sort of definition will be needed.  I think the WG should
try to come up with a definition.  If the above terms are not
acceptable for everyone, let's try to find ones that are.

> cases there will be specific requirements that would apply. 

I agree that the requirements should support modularity.  

John

---

From: "Vlora Rexhepi (ELN)" <[email-masked]>
Date: Mon, 4 Mar 2002 11:52:42 +0100

Hi John,

|> I would rather say that the QoS requirements would be derived 
|> from different scenarios/use cases and than grouped according to
|> the interfaces they apply to.
|
|Can I ask what will this bring us?  Remember, the WG has a framework
|document on its list of things to do.  Frameworks usually suggest
|creating architectures & giving scenarios.  Isn't your suggest
|a bit like putting the cart before the horse?

As I see it is that we are having certain scenarios in mind where an
NSIS protocol is needed and these scenarios would help us to be more 
focussed when defining requirements and grouping them into interfaces
would help further into the focussing process.

|> Section 6 of the WG draft gives a good overview on the importance 
|> of the requirements to the Scenarios 1 - 5, but I would prefer 
|> to see which requirements apply to particular interfaces 
|> in the Scenarios 1-5.
|
|I truly believe it would be much more useful for us to spend
|time on specifying the requirements correctly than saying
|'if you are trying to do this, do this.'
True. Definitely agree. 
But before doing this we need to have a well defined terminology 
on the entities used when defining requirements.

|We are trying to build some basic building blocks here, so
|that vendors, service providers, etc. can put them together
|to do some interesting things.  If John Postel had specified 
|UDP so that it could carry VoIP traffic, I think UDP would
|have suffered from much bloat and be much less useful ... 
|just as an example.
Good point :-).
  
Regards,
Vlora

---

From: [email-masked]
Date: Mon, 4 Mar 2002 13:04:53 +0200

Hi Vlora,

> would help further into the focussing process.

This isn't a bad thing, if we don't get carried away.  IntServ was
based on usage for sets of scenarios, which led into some well
known results.  IntServ, for what it tried to do, is actually
quite good - however, in my (personal) opinion, IntServ might
have been more successful if it were not bounded by some initial
considerations.  I want to make sure we don't fall into the same trap.

> on the entities used when defining requirements.

Definately, that is why terminology should be a key subject for 
discussion.

John

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Mon, 4 Mar 2002 14:20:44 +0100

Hi John

I agree with your proposal. However, 
I think that it will be difficult to
specify if a requirement is a MUST, SHOULD or MAY
if we don't group the requirements (according to the 
modularity requirement).

Regarding terminology:
Do you also mean that the definition of the 
QoS initiator and QoS Controller will also be moved 
to the "framework" draft.

Best regards,
Georgios

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: maandag 4 maart 2002 8:25
To: [email-masked]; [email-masked]
Subject: RE: [NSIS] RE: Modularity and grouping QoS requirements

Hi Georios,

John