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

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Wed, 27 Feb 2002 14:09:32 +0100

Hi John

Thank you for your reply!

[JL] >> Finally, I would suggest that everyone try to 
[JL] >>  comment directly on the draft - add text, delete 
[JL] >> text, etc. rather then having 
[JL]>> gerneralized concerns.

I think that we first have to find out if a consensus
within the NSIS working group can be found on the method
of creating and separating (grouping) the QoS requirements.
The draft "draft-partain-nsis-requirements-00.txt" is 
using a method to create, separate/group the QoS requirements 
that is in line with what has been agreed during the 
NSIS WG meeting in Salt Lake City.
The NSIS WG draft apparently does not.

Best regards,
Georgios

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: woensdag 27 februari 2002 13:48
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: Modularity and grouping QoS requirements

Hi Georgios,

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

Unfortunately, I am under server deadline pressures this week,
so I have not given the requirements document an indepth reading
which it deserves.

My high level comment should be that any model in the requirements
should be for illustrative purposes, not to imply any requirements.
Additionallly, the model should should functional blocks, not
how these functions are actually implemented.

Finally, I would suggest that everyone try to comment directly on 
the draft - add text, delete text, etc. rather then having 
gerneralized concerns.

John

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

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Wed, 27 Feb 2002 14:54:50 +0100

Sorry if you have received this e-mail twice!

-----Original Message-----
From: Georgios Karagiannis (ELN) 
Sent: woensdag 27 februari 2002 14:10
To: [email-masked]'; [email-masked]
Cc: [email-masked]
Subject: RE: Modularity and grouping QoS requirements

Hi John

Best regards,
Georgios

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: woensdag 27 februari 2002 13:48
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: Modularity and grouping QoS requirements

Hi Georgios,

John

---

From: [email-masked]
Date: Wed, 27 Feb 2002 18:03:22 +0100

Hi Vlora, Marcus,

I support the approach as seems to be agreed in the mail discussions:
- define and study scenario cases 
- identify the particular QoS interfaces
- group requirements according to the identified interfaces
- define functional entities (like QI, QC, etc) and elaborate the QoS
model. 

I am also in favour the idea of identifying interfaces and grouping
requirements because it seems to me that important requirements, such as
e.g. mobility, only apply to UNI and not to NNI. I also think that there
are not infinite number of (particular) interfaces and that, basically
one has:
- UNI: host-network edge (border)
- NNI: which may have particular requirments and features whether it
concerns access-core | core-core
- interior 

Regarding the 3-interface proposal of Vlora: although i perfectly
understand the meaning, i rather prefer the taxonomy of Marcus because
this leaves open whether the interface is on the data-path (in-band &
out-of-band mechanisms are in scope I guess)

BTW, If we follow this approach, it seems to me that a kind of "QoS
mapping" (QM) functional entity seems also necessary for enbabling
end-to-end QoS. The QM entity could e.g. have some
aggregating/de-aggregating functionality (at e.g. network edge), resolve
the mapping of QoS parameters from UNI to NNI, etc. 

In the scenario cases of draft-buchli-nsis-req-00.txt (PSTN trunking and
UMTS access over a single IP core), we needed such a kind of QM
function. We put this QM function as a part of the QI (to line up with
draft-brunner-...), but I now think it is a dedicated function. Anyhow,
that's why i said previously that "it was not so simple" and that the
definition of functional entities is to be elaborated further.

Regards,
Danny

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

---

From: [email-masked]
Date: Wed, 27 Feb 2002 21:45:02 +0200

Hi Georgios,

A point of procedure:

[clip]
> NSIS WG meeting in Salt Lake City.

Agreements cannot be made during the meetings, but only
on the mailing list.  However, we need to get consensus
on this issue.

John

---

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 28 Feb 2002 14:44:42 -0000

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)

OR do they mean

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

?

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

I'm less in sympathy with (2), certainly at this stage - we need have the requirements and an overall framework first before making such a concrete decision. (And even then, I'm not sure that such clear network hierarchy boundaries are always so easy to draw in the Internet-in-the-wild. I would expect that allowing multiple protocols is needed, but it doesn't seem that we can yet constrain the solution by knowing exactly how many and where they are to be used.)

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

Yours,

Robert H.

> Sent: 27 February 2002 19:45
> Subject: [NSIS] RE: Modularity and grouping QoS requirements
> 
> 
> Hi Georgios,
> 
> A point of procedure:
> 
> [clip]

---

From: "Vlora Rexhepi (ELN)" <[email-masked]>
Date: Thu, 28 Feb 2002 17:38:54 +0100

Hi Robert,

|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.
 
|OR do they mean
|
|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

I don't think this is a discussion issue at this point.

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

Regards,
Vlora

---

From: [email-masked]
Date: Thu, 28 Feb 2002 23:30:54 +0200

Hi All,

> the interfaces they apply to.

I agree.  For example, on a small lightweight device, scalability
is very important as well.
  
> to see which requirements apply to particular interfaces 

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