Subject: RE: [NSIS] Georgios' framework decomposition (was Two kinds of re quirements)

From: "Schneider, Marco" <[email-masked]>
Date: Wed, 23 Jan 2002 14:53:25 -0600

Hi Georgios, David

First of all, I support the goal of modular extensible protocol.

The framework appears to make a some presuppositions about the solution that
impose unnecessary and undesireable constraints on the solution. Perhaps it
is simply a matter of clarifying the framework.

We need to develop requirements for an NSIS UNI that allows a host to
request a QOS connection across the network to another host. This protocol
will run across a host to network interface. Presumably this is between host
and edge in the framework diagram provided.

1) The framework refers to an "every hop" protocol component which is shown
in the interior of the network. This presupposes a hop by hop signaling
protocol within the interior of the network. There are a wide variety of
approaches to achieving the QOS connection. 

2) The framework imposes this assumption (of hop by hop signaling) on the
functionality for the NSIS UNI since "everyhop" is shown as part of the host
functionality. 

3) Whereas hop by hop signaling within the interior of a network may require
information on the topology of the network, our requirement is that the host
should not be able to access any topology information. 
 
Marco

-----Original Message-----
From: Georgios Karagiannis (ELN)
[mailto:[email-masked]]
Sent: Wednesday, January 23, 2002 4:55 AM
To: Schneider, Marco
Cc: [email-masked]'
Subject: RE: [NSIS] Georgios' framework decomposition (was Two kinds of
re quirements)

Hi Marco

I agree with David's explanation (see below)!

Best Regards,
georgios

-----Original Message-----
From: David Partain [mailto:[email-masked]]
Sent: woensdag 23 januari 2002 11:30
To: NSIS Mailing List
Subject: [NSIS] Georgios' framework decomposition (was Two kinds of
requirements)

Hi,

Georgios Karagiannis wrote:

> The possible NSIS protocol components that can be
> used on the different NSIS protocol types are the following:
>
>  * used components in "end host to end host" NSIS scenario:
>       [everyhost], [everyedge], [everyhop]
>
>  * used components in "end host to proxy" NSIS scenario:
>       [everyhost], [everyedge], [everyhop]
>
>  * used components in "end host to edge" NSIS scenario:
>       [everyedge], [everyhop]
>
>  * used components in "edge to edge" NSIS scenario:
>       [everyedge], [everyhop]
>
> Regarding the priority, we should decide it after the requirements,
> architecture and framework drafts are done!

Marco Schneider responded:

> Are you suggesting that we organize our requirements according to the
> implementation solution you have proposed below? If that is the case then
I
> strongly disagree.

I don't see Georgios' framework figure or the text above as an
"implementation solution".  It's simply a way of taking a _big_
problem and breaking it down into smaller problem areas that
need attention.

The requirements, in my view, must be based upon the
applications that will use the network ("use case based
requirements").  There seem to be several voices pushing
for this.

If you could, please help me understand exactly what you
disagree with.

Cheers,

dlp

_______________________________________________
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 Partain <[email-masked]>
Date: Fri, 25 Jan 2002 12:45:42 +0100

Greetings Marco,

I've put things in chronological order since I'm a serial kind o'
guy.

Regarding the discussion of the "framework" figure, Marco

> First of all, I support the goal of modular extensible protocol.

Excellent!

> The framework appears to make a some presuppositions about the
> solution that impose unnecessary and undesireable constraints
> on the solution.  Perhaps it is simply a matter of clarifying
> the framework.

First of all, I think it's obvious - but I'll say it anyway -
that this "framework" needs a great deal more discussion.
My question in the long mail yesterday was if we can use this
as a starting point.

> We need to develop requirements for an NSIS UNI that allows
> a host to request a QOS connection across the network to
> another host.

In the end, this is of course what everyone wants.

> This protocol will run across a host to network
> interface. Presumably this is between host and edge in the
> framework diagram provided.

Yes, that's what I would say.

> 1) The framework refers to an "every hop" protocol component
> which is shown in the interior of the network. This presupposes
> a hop by hop signaling protocol within the interior of the
> network. There are a wide variety of approaches to achieving
> the QOS connection.

Yes, I completely agree.  In some networks, there will be no
"everyhop" component included since that network will be
overprovisioned (or whatever the reason may be).  In some
networks, though, each hop will need to look at something
in the signalling message as it flies by and do something
based upon what it sees.  That's needed in some environments.
We just have to make sure that both things are possible.

> 2) The framework imposes this assumption (of hop by hop
> signaling) on the functionality for the NSIS UNI since
> "everyhop" is shown as part of the host functionality.

I certainly don't mean to imply hop-by-hop signalling must take
place everywhere.  As I say above, there will be domains where
this isn't done.  The key point is that a "domain-specific"
answer - however it is determined - is needed in order to build
an end-to-end answer.

> 3) Whereas hop by hop signaling within the interior of a network
> may require information on the topology of the network, our
> requirement is that the host should not be able to access any
> topology information.

A protocol that requires that end hosts/applications know
something about topology is certainly not what I have in mind.

Cheers,

dlp