Subject: RE: [NSIS] Framework & requirements part of the "Two kinds of requirements" thread

From: [email-masked]
Date: Thu, 24 Jan 2002 18:47:45 +0200

Hi Ping,

> Before we define end-to-end, edge-to-edge and 
> domain-to-domain, ask the 
> following:
> 
> - why do we signal in the first place?
> - where do we need to signal?
> - will signaling work in provider's networks?
> 
> We signal because there is no QoS when we are using some inter-active 
> real-time applications. Since most of the Internet traffic is 
> not within the scope of this "inter-active" and "real-time", let's not 
> consider a kitchen-sink signaling protocol.

I agree.  You are asking very good questions and these are
the items we should focus on.

John

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

---

From: Giuseppe Bianchi <[email-masked]>
Date: Fri, 25 Jan 2002 13:35:14 +0100 (MET)

> > consider a kitchen-sink signaling protocol.

I'd not focus JUST on the user view, i.e. an admission control function is
not just a way for the user to throw in the network a set of requirements
that need to be satisfied. From the provider's perspective, it is a
fundamental way to control that its planned QoS (or utilization) target is
persistently met. And, most important, regardless of what this specific
target is.

In this (perhaps extreme, for someone) view, signalling does not even need
to carry user requirements, but is a tool in the hands of the provider to
allow it to maintain its level of QoS provisioned (decided by the
provider, but not imposed by a standard). Requirements come back into play
when the provider is able to support different levels. Isn't this scenario
very appealing for providers, and a strong motivation for supporting
signalling?

Indeed, as sugested by Dick, the user can have an active role if he is
made able to specify, during call setup, how much its QoS requirements can
be downgraded.

Just my 1 c.

Giuseppe