Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt

From: [email-masked]
Date: Fri, 8 Mar 2002 08:55:34 +0100

Roland and Maring, 

I sympathize with your wish to define inter-domain QoS. However, I do not fully understand what you are referring to. 

If service description is out of scope. The 'adverticement' of SDs may be in scope. The SLS negotiation is out of scope (which Ruediger and I discussed before). What do you mean by inter-domain QoS? And, what do you mean is the requirements regarding inter-domain QoS? 

As a second point, how much of the Inter-domain issues that need to be solved is a technical issue and how much is better left for the carriers to figure out themselves? 

I would agree that working out an architecture that gives the incentives for the carriers to optimise the Internet on delay would be a truly valuable task. The question for me is what is the minimal thing needed to give the carriers this incentive, without forcing them (us) into a solution that constrains the business models? 

From my part, I believe that the minimal architectural component that is needed is the 'adverticement' of SDs. That's where I have landed after thinking about this for a long time. This adverticement have the exact same function as BGP adverticement and can be implemented in BGP (see for example draft-jacquenet-qos-nlri-04.txt for one solution).

This functionality (assuming some quality parameters and pricing information is included) would give the carrier a tool and some incentive to optimise the network. Observe, I still believe the service description is way out of scope (this is a business issue for me). 

I can agree to this being important (after all I am working for a carrier...). 

What I am suggestion - also in my previoius email - is that this part and the requirements for this is clearly separated in the requirement document from the 'call'-signaling that I mentioned in a previous email. This two may lead to two different solutions.

Anders

> > I strongly suggest that nsis should work now on interdomain 
> > QoS signaling.
> > This is a major piece missing in global QoS support. A main 
> feature of
> > the Internet is its global connectivity (availability of the 
> > "same" basic
> > service), so it would be nice to have at least a few globally 
> > available
> > public/standardized services (aggreement on them is a 
> > business issue, so
> > out of scope). But nsis signaling would allow to request 
> resources of
> > such services on demand between arbitrary sources and destinations.
> 
> Exactly! If you want to deliver a "useful" inter-domain 
> service to the end customer, then there must be some common 
> sense between all involved domains about that service. So I 
> think, that a globally well known service will be necessary 
> to achieve that. It is not achievable to negotiate service 
> details between domains for each call. Also aggregation might 
> not be possible without globally well known services.
> 
> I do not want to define these globally well known services 
> within NSIS. But I think the NSIS signalling should be aware, 
> that such services will exist, and should allow calls based 
> on such services.
> 
> > 
> > Regards,
> >  Roland
> 

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

---

From: Roland Bless <[email-masked]>
Date: Fri, 08 Mar 2002 15:58:23 +0100

Hi,

> If service description is out of scope. The 'adverticement' of SDs may
> be in scope. The SLS negotiation is out of scope (which Ruediger and I
> discussed before). What do you mean by inter-domain QoS? And, what do
> you mean is the requirements regarding inter-domain QoS? 

I mean that one can request some service X for a flow with certain 
parameter values (e.g. bandwidth=100kbit/s). Service X is defined 
outside of nsis. Now, if the flow traverses several domains or ASs
every provider should be able to request the same service from its
adjacent provider. 
The most important requirement is IMO scalability, so -- as already
many others stated -- essentially support of eastablishing and managing
reservation aggregates (aka pipes,tunnels,...) for services.

> As a second point, how much of the Inter-domain issues that need to be
> solved is a technical issue and how much is better left for the carriers
> to figure out themselves? 

I think there is a lot for providers to figure out:
- local QoS provisioning architecture
- admission and resource reservation policies

> I would agree that working out an architecture that gives the incentives
> for the carriers to optimise the Internet on delay would be a truly
> valuable task. The question for me is what is the minimal thing needed
> to give the carriers this incentive, without forcing them (us) into a
> solution that constrains the business models? 

I think there is a solution, that doesn't constrain the business models
of providers so much. Surely, reservation aggregates will require some
pricing model that gives incentives to initiate creation of aggregates,
but that's it.

> From my part, I believe that the minimal architectural component that
> is needed is the 'adverticement' of SDs. That's where I have landed
> after thinking about this for a long time. This adverticement have the
> exact same function as BGP adverticement and can be implemented in BGP
> (see for example draft-jacquenet-qos-nlri-04.txt for one solution).

I even don't think that one needs to advertise service descriptions,
because they have to be interpreted, understood and implemented somehow.

> This functionality (assuming some quality parameters and pricing
> information is included) would give the carrier a tool and some
> incentive to optimise the network. Observe, I still believe the service
> description is way out of scope (this is a business issue for me). 

Yes, I agree fully with that.

> What I am suggestion - also in my previoius email - is that this part
> and the requirements for this is clearly separated in the requirement
> document from the 'call'-signaling that I mentioned in a previous email.
> This two may lead to two different solutions.

I don't think that they lead to two different solutions. One can cover
them together easily, and, they will fit perfectly together. 
On-demand aggregate signaling is not that different from flow signaling.

Regards,
 Roland

-- 
Roland Bless -- e-Mail: [email-masked]
Institute of Telematics, University of Karlsruhe, Germany  
Zirkel 2, D-76128 Karlsruhe -- Office: Bld. 20.20, 3rd floor, R 358
Phone: +49 721 608-6413 Fax: +49 721 388097