Subject: RE: [NSIS] Two kinds of requirements

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 17 Jan 2002 11:32:49 +0100

Hello Marcus,

if the QoS signalling supports a service description as follows:

- Service ID (say 32 bits)
- Service descriptor (0 to whatever length)

you could operate globally defined services as well as private services. The globally defined ones should be pre-determined in terms of performance parameters to the largest possible extent. This would allow providers/suppliers to map the global service to a network/system and to develop some admission control prior to operation/sale.

The service descriptor and its length are not mandatory per se. Both are service specific parameters (i.e. to a specifc service belongs a specific service descriptor). Obviously, a globally defined service requires both, ID and descriptor, to be formally standardized. Private services don't and may be "flexible" (which, to my experience, means complex if referring to QoS).

I didn't check exactly whether and how RSVP supports this mechanism.

Regards, Rüdiger

> -----Original Message-----
> From: Marcus Brunner [mailto:[email-masked]]
> Sent: Thursday, January 17, 2002 11:17 AM
> To: Yaron Kahana; Geib, Ruediger; [email-masked]
> Cc: [email-masked]
> Subject: RE: [NSIS] Two kinds of requirements
> 
> 
> Yaron,
> 
> Good point, my question is whether the operator more likely opt for a 
> simple solution, with little flexibility, which implies no 
> competition in the type of services offered, since these are
> standardized (I assume there is still a lot of differentiation
> possible with weaker service parameters)
> 
> Marcus
> 
> --On Wednesday, January 16, 2002 11:16 PM +0200 Yaron Kahana 
> <[email-masked]> wrote:
> 
> >
> > Hello Ruediger, Marcus,
> >
> > I agree with your comments. One of the crucial elements is the
> > pre-definition of the provider's policy - admission control decision
> > tree, QoS budgeting guides, CDR generation and considerations. Those
> > could be done in a practical manner only if there will be a 
> rather small
> > number of Service classes (standardized services). I 
> believe that this is
> > by far the most practical approach in a multi-providers 
> environment. This
> > QoS protocol should be supported not only by the 
> applications, the call
> > control elements, and transport routers but by the 
> middleboxes, as well
> > as the SLA/QoS verification entities along the way and the billing
> > elements.
> >
> > We should try to keep it simple, even on the expense of 
> full flexibility.
> >
> > By the way - did anyone considered the problem of a 
> non-cooperative IP
> > domain "in the middle" ? for example, Suppose I'm making a 
> call from Los
> > Angeles to Munich through 3 domains - LA-NY, NY-London, 
> London-Munich.
> > What will happen if the best/cheapest carrier along the 
> NY-London domain
> > won't support this new protocol? Will he be 
> condemned/ignored? When will
> > he upgrade his infrastructure, before the chicken or after the egg?
> >
> > Yaron Kahana
> > COGITO Project Manager,
> > COMGATES
> >
> >  -----Original Message-----
> > From:   Marcus Brunner [mailto:[email-masked]]
> > Sent:   Wednesday, January 16, 2002 5:35 PM
> > To:     Geib, Ruediger; [email-masked]
> > Cc:     [email-masked]
> > Subject:        RE: [NSIS] Two kinds of requirements
> >
> > 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
> >>
> >>> 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
> >>
> >
> >
> > --------------------------------------
> > 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
> >
> >
> > _______________________________________________
> > nsis mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/nsis
> 
> 
> 
> --------------------------------------
> 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
> 
> 
> 
> _______________________________________________
> 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: Marcus Brunner <[email-masked]>
Date: Thu, 17 Jan 2002 12:24:44 +0100

Ruediger, Yaron,

So you say from the service providers point of view a set of pre-defined 
services with a known performance is what is your choice?

Marcus

--On Thursday, January 17, 2002 11:32 AM +0100 "Geib, Ruediger" 
<[email-masked]> wrote:

> you could operate globally defined services as well as private services.
> The globally defined ones should be pre-determined in terms of
> performance parameters to the largest possible extent. This would allow
> providers/suppliers to map the global service to a network/system and to
> develop some admission control prior to operation/sale.
>
> The service descriptor and its length are not mandatory per se. Both are
> service specific parameters (i.e. to a specifc service belongs a specific
> service descriptor). Obviously, a globally defined service requires both,
> ID and descriptor, to be formally standardized. Private services don't
> and may be "flexible" (which, to my experience, means complex if
> referring to QoS).
>