Subject: RE: [NSIS] Two kinds of requirements (unsupported domains + chick en and eggs)

From: [email-masked]
Date: Fri, 18 Jan 2002 12:07:39 -0000

I agree with Yaron's comments. USe QoS classes to keep it simple (the KISS
approach is rather well known to me). On the face of it QoS calsses look as
though they lose flexibility - but I don't think it is true.
 
Middleboxes support - needs thinking about. 
For example: if we carry addresses of requested connections, then NATS need
to understand the protocol, but if we don't carry the addresses, then the
NATS don't have to understand it.

Concerning the Chicken and Eggs: Yes I thought about a domain (or chunk of
network) that doesn't support the protocol: there are two cases:
The protocol reaches a node at the edge of a domain/network (an everyedge
node) and knows that the best routing from here is through a chunk of
besteffort (the routing tables tell it so). The node needs to decide whether
or not to progress or to refuse. This gives us a requirement on the
protocol: we need to include a class that says "I'd rather get my comms link
up with a reduced QoS than get a refusal". We also need a class that says
"don't down downgrade me" or "don't down downgrade me below [classX]". If it
does progress across this network domain, we can still signal into the next
NSIS-aware domain (as I am hoping the domain without support can still route
packets).
Note: Best effort means that there are no guarantees because NSIS is not
supported. It might be overprovisioned and providing a superior service, but
it doesn't have a CAC.

Second case: The protocol reaches a node at the edge of a domain/network (an
everyedge node) and knows that the best routing from here is through a chunk
of QoS enabled network that doesn't support the NSIS protocol. It knows it
is QoS enabled because it is aware of (for example) an MPLS route through
the network/domain. So this node might be able to perform a kind of proxying
job on behalf of the other network.

Dick

-----Original Message-----
From: Yaron Kahana [mailto:[email-masked]]
Sent: 16 January 2002 21: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 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 

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

---

From: Giuseppe Bianchi <[email-masked]>
Date: Fri, 18 Jan 2002 14:36:28 +0100 (MET)

Extending Dick's comment:

On Fri, 18 Jan 2002 [email-masked] wrote:
> [...]
> The protocol reaches a node at the edge of a domain/network (aneveryedge

Why leaving this decision up to the node? An alternative (which may
actually coexist with Dick's idea) is to use a form of marking, and take
back to the user the information that one domain along the path is Best
Effort... Depending on its requirements, the user will know whether to
progress or to refuse.

On a more general point of view, and in the spirit of the Internet, I'd
recommend to keep as much as possible the intelligence at the edge of the
network. In this sense, NSIS should be designed as a protocol that allows
end nodes to discover the state of the nodes/domains along the path and to
react accordingly.

To make a simple example: I need to set up a call with some requirements.
I (or my access router) send an NSIS signalling packet including some form
of specifications & requirements. This packet is locally handled by each
network node (domain) as follow: if the node (domain) can guarantee the
reqs, it just forwards the NSIS packet along; If it cannot guarantee the
reqs, but it can accept the request with some downgraded form of of
support, it marks the packet; if, finally, it cannot accept the request,
it just says no (by, e.g. suitably marking the NSIS packet, or, as we
suggested in an earlier internet draft to make this idea compatible with
DiffServ domains, blocking it - timeouts at the end points will do the
rest). When the NSIS signalling packet gets back to the sender, it
contains all the relevant information to proceed.

Giuseppe Bianchi
[email-masked]
http://cerbero.elet.polimi.it/people/bianchi