Subject: RE: [NSIS] Two kinds of requirements

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 16 Jan 2002 15:45:58 +0100

Hello Dick,

your suggestion is quite reasonable. I also favour an architecture where a QoS request by and large is predefined in terms of the resources required from the available transport mechanism. Service specific parameters to be signaled during reservation should be strictly limited. The more mapping and evaluation of QoS parameters is required during reservation, the more complex the service gets. Complex services are hard to sell and hard to provide.

Regards,

Rüdiger 

Rüdiger Geib
Senior Project Manager
T-Systems Nova GmbH

> I think that what is needed is a new protocol that can signal the
> requirements of any session and can be satisfied by any QoS
> mechanism, existing or new.
> To be more precise, I am suggesting a new protocol that is 
> independent of the underlying transport technology and the QoS
> implemented and is also independent of the session control
> protocol. Such a new protocol would be generic, optionally
> implemented by applications that would benefit from
> end-to-end QoS, and would be complimentary to the QoS 
> mechanisms deployed (and of course other mechanisms,
> such as the routing).
> 
> I think that this implies a more abstract definition of the 
> QoS mechanism and may lend itself to the signalling of
> pre-defined QoS classes rather than parameters.
> 
> Dick Knight

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

---

From: Marcus Brunner <[email-masked]>
Date: Wed, 16 Jan 2002 16:34:37 +0100

Ruediger,

The service needs to be defined anyway. Then there are IMO two 
possibilities
- the provider defines the services and offers them. In this case the 
provider needs to describe the offers in a machine readable form (most 
likely with parameter names and values)
- the consumer requests a particular service (this means the consumer has 
to describe the service he wants in a machine readable form)

So it seams one has to move around service specifications which are 
understandable by the other party anyway, what is now your point? Is it 
that you want to limit/fix as many parameters as possible? Or are you more 
think about standardized services everybody understands?

Marcus

--On Wednesday, January 16, 2002 3:45 PM +0100 "Geib, Ruediger" 
<[email-masked]> wrote:

> Hello Dick,
>
> your suggestion is quite reasonable. I also favour an architecture where
> a QoS request by and large is predefined in terms of the resources
> required from the available transport mechanism. Service specific
> parameters to be signaled during reservation should be strictly limited.
> The more mapping and evaluation of QoS parameters is required during
> reservation, the more complex the service gets. Complex services are hard
> to sell and hard to provide.
>
> Regards,
>
> Rüdiger
>
> Rüdiger Geib
> Senior Project Manager
> T-Systems Nova GmbH
>

--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: [email-masked]
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.brubers.org/marcus