Subject: Re: [NSIS] WG requirements draft

From: [email-masked]
Date: Tue, 26 Feb 2002 11:56:08 +0100

Hi Vlora,

As I wrote a minute ago, I agree that NSIS should not restrict itself to
one basic model for deriving requirements. I also agree that the use
case of a central entity ("bandwidth broker" or whatever you call it)
does not cover a number of important cases: e.g. PacketCable (RSVP++
signaling) and UMTS (PDP-signaling). 

However, the distributed approach does not cover other use cases
neither. For example, in xDSL broadband access, the "L2 QoS signaling"
protocol, setting up ATM Switched Virtual Connections is, not deployed
in today networks. Another example is a DiffServ IP network provider,
which would also like to offer QoS to "user applications" (i.e. at the
microflow level and not just on an DiffServ aggrege DSCP- basis). But
the edge routers do not implement RSVP and therefore InServ over
DiffServ is not an option... 

As we all know, there has been quite some effort to solve this "pure
DiffServ case", and much of these approaches have been categorised as
"Bandwidth broker solutions", initially proposed by Van Jacobson,
researched by Internet2, etc. 
I agree with you that much of these approaches do not scale in DiffServ
networks: especially you can not "trigger"/configure (by e.g. the COPS
protocol) the routers on a micro-flow bases from a central entity "BB".
This approach even scales worse than IntServ all the way. In my view,
the DiffServ routers should not **at all** be triggered by a
per-micro-flow signaling/reservation protocol (not in band alike RSVP
and not out-of-band from a BB-alike entity). 

In a simple use case of our draft, we present a possible alternative
approach for pure DiffServ networks, not requiring any per-flow
interaction with the routers, but nevertheless being capable of offering
"per-micro flow" QoS. 

Just want to say that at this stage we should not excluse neither
distributed nor centralised approaches. In particular, I guess both will
co-exist in the future and NSIS should try to give a solution for their
interworking, yielding end-to-end QoS.

Best regards
Danny

"Vlora Rexhepi (ELN)" wrote:
> 
> Hi,
> 
> I think that the NSIS WG should certainly not use this model
> as the basis for the requirements. I believe that initially
> the NSIS WG should derive the requirements from typical scenarios/use
> cases as it also stated in the [NSIS] WG requirements draft without
> any assumptions/relations to any kind of a model. In fact a
> model/framework should be developed based on the derived
> requirements.
> I think, the problem with the "discussion model" described in
> Section 4.1, is that it does not seem to be generic enough to
> derive requirements for all the use cases, even though
> introduced for this purpose.
> What I mean is that it can not be straightforwardly seen
> how this model would apply to typical scenarios/use cases. This
> is due to the fact that the scenarios/use cases described in the
> draft are not common as it is considered that there is an
> centralized entity for the resource management, i.e. "access
> network manager" ("Scenario 1: Terminal Mobility"), bandwidth
> broker ("Scenario 2: Cellular networks"). Typically this is not the
> case since many existing scenarios are using distributed resource
> management concepts, e.g. RSVPv1, RSVP Aggregation, etc. where the
> resource management is provided on a distributed manner by
> many nodes (e.g. RSVP-aware nodes) along the communication path.
> Without the assumption of having this centralized resource
> management entity it is very difficult to see how this model
> is applied efficiently. For example if there is no such centralized
> entity in the access network such as "access network manager" how
> would this model be applied?
> In my understanding  of the model you would need to have on
> each node on the communication path a "QoS Initiator" and a
> "QoS controller". This I believe will be a very complex system
> which would deteriorate severely the scalability and performance
> of the protocol. This kind of scenario/use case on Terminal
> Mobility, which in my opinion is typical use case, is missing from
> the draft.
> As far as I know, centralized resource management is not a goal
> of NSIS and it has not been discussed in other individual drafts
> submitted to NSIS WG.
> So, firstly it looks kind of strange to derive the requirements
> based on a model and also unusual to base them on this specific
> model?!
> Furthermore, there are several requirements which are specifically
> related to the entities of this model, i.e. QoS
> Initiator and QoS controller, such as e.g. requirement on
> "Automatic notification on available resources not been granted
> before" (section 5.3.7) where the QoS Initiator would like to
> have notification of resources he requested in the past time...
> To conclude regarding this issue I would appreciate that:
> - the NSIS WG derives first the requirements from the scenarios/use
>   cases without any assumptions/relations to any kind of a model.
> - the requirements should be based on typical scenarios/use cases
> - the requirements should not be dependent on the model entities such
>   as "QoS initiator" and the "QoS controller", but should be related to
>   typical scenarios/use cases network entities/nodes, e.g. host, border
>   nodes, interior nodes, etc.
> - the requirements should not be constrained to specific resource
>   management schemes, i.e. NSIS protocol  should fulfil the QoS
>   requirements independently of the resource management scheme
>   used (centralized or distributed)
> 
> Regards,
> Vlora
> 
> _______________________________________________
> 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: Roland Bless <[email-masked]>
Date: Wed, 27 Feb 2002 00:08:32 +0100

Hi Danny,

> and not out-of-band from a BB-alike entity). 

I disagree here, but I don't think we should discuss different 
architectural approaches now, or even exclude some approaches.
All have their pros and cons. In my view, it should be possible
to define nsis protocols that allow different QoS architectures
within domains. Thus, neither for the requirements nor for the
signaling protocol(s) it should matter whether QCs are routers
or BBs.

I'd like to bring up two issues here:
- One should really carefully think about the processing burden
  for routers (even edge routers) caused by letting them act as 
  QoS controllers rather than one or more dedicated QC systems.
- Most architectures only consider scalability/performance within
  a single domain. We should also work on global scalability, i.e.
  considering the multi-domain/multi-AS case.

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