Subject: RE: [NSIS] Two kinds of requirements

From: Yaron Kahana <[email-masked]>
Date: Thu, 17 Jan 2002 13:09:11 +0200

Hi,

I still don't see how such a toolkit can be useful if a certain domain in
the middle did not deployed a support in it and the Chicken and Egg
syndrome.

Yaron

-----Original Message-----
From: Georgios Karagiannis (ELN)
[mailto:[email-masked]]
Sent: Thursday, January 17, 2002 12:04 PM
To: 'Yaron Kahana'; Geib, Ruediger; 'Freytsis, Ilya'
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

Hi Yaron, Ilya, Ruediger

Almost all issues that you addressed in your e-mails can be solved (see also
my previous e-mail
addressed to Dick) by first creating a modular QoS signaling toolkit that
will contain mandatory and
optional QoS requirements.
Second, specifying how the protocol functionality should be separated in
building blocks
(NSIS protocol components) and define a minimum set of mandatory reservation
options/features
that should be processed by any network nodes, e.g., end-hosts, proxies,
edges and interior nodes.

Best Regards,
Georgios

-----Original Message-----
From: Yaron Kahana [mailto:[email-masked]]
Sent: woensdag 16 januari 2002 22:16
To: [email-masked]; Geib, Ruediger; [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] Two kinds of requirements

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 chicke

Yaron Kahana
COGITO Project Manager,
COMGATES

 -----Original Message-----
From:   Marcus Brunner [ mailto:[email-masked]
<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
<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/ <http://www.ccrle.nec.de/> 
personal home page: http://www.brubers.org/marcus
<http://www.brubers.org/marcus> 

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

---

From: Marcus Brunner <[email-masked]>
Date: Thu, 17 Jan 2002 12:28:10 +0100

IMO, there is no solution to a chicken and egg problem in the introduction 
of new Technologies. The deployment is pretty market driven.

Marcus

--On Thursday, January 17, 2002 1:09 PM +0200 Yaron Kahana 
<[email-masked]> wrote:

> [mailto:[email-masked]]  Sent: Thursday, January
> 17, 2002 12:04 PM
> Almost all issues that you addressed in your e-mails can be solved (see
> also my previous e-mail  addressed to Dick) by first creating a modular
> QoS signaling toolkit that will contain mandatory and  optional QoS
> requirements.
> building blocks  (NSIS protocol components) and define a minimum set of
> mandatory reservation options/features  that should be processed by any
> network nodes, e.g., end-hosts, proxies, edges and interior nodes.
>
> Best Regards,
> Georgios
>
> 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.
>
> 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 chicke
>
> Yaron Kahana
> COGITO Project Manager,
> COMGATES
>
> <mailto:[email-masked]> ]  Sent:   Wednesday, January 16, 2002 5:35
> PM
> that you want to limit/fix as many parameters as possible? Or are you
> more  think about standardized services everybody understands?
>
> Marcus
>
>> 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
>>

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