Subject: RE: Definition of QI was: Re: [NSIS] WG requirements draft

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 28 Feb 2002 09:29:31 +0100

Muhammed,

I'm a core network engineer and I prefer fat pipes instead of per flow reservations. I also prefer "provisioning" to "on the fly" aggregation as the mode of "fat pipe" set up. That's the background. What I'd like to get may look like that:

a) Initial situation:

      Edge QC--QC--QC--QC--QC--Edge QC

Note that also the "internal" QC's could be edge QC's. It's not relevant.

b) QoS Tunnel set up (being triggered by management, not by terminal per flow signalling)

      Edge QC==="Fat Pipe"===Edge QC

All the involved QC's should use standard NSIS signaling to set up the "fat pipe". During the fat pipe set up, the systems marked as "edge QCs" act as QI. Note that than one requirement for NSIS would be to support reservations to IP address + prefix range instead of IP address only. (Maybe even several IP adress + prefix ranges!)

c) Now per flow reservations may turn up, being handled by direct QC edge to edge signaling:

Host QI--Edge QC==signals directly to==Edge QC--Host QI

This saves per flow signalling and state from all the intermediate QCs (and hence improves scaleability). Admission Control decisions are speeded up too. It's of course not a general solution, and some "per flow" signaling will have to be done by the intermediate QCs for destinations without pre-installed "fat pipes".
If you'd like to look at it that way, it's a requirement for NSIS signalling to support some kind of traffic engineering. Support here is limited to control "fat pipe" set up, maintenance and release.

Another requirement in the above case is that the tunnel entry point must recognize a per flow reservation fitting to a specific tunnel.

Regards, Rüdiger

> -----Original Message-----
> From: Muhammad Jaseemuddin [mailto:[email-masked]]
> Sent: Wednesday, February 27, 2002 7:58 PM
> To: Geib, Ruediger
> Cc: [email-masked]; [email-masked]
> Subject: Re: Definition of QI was: Re: [NSIS] WG requirements draft
> 
> 
> Ruediger:
> 
>  I agree that the requirement should also consider the case 
> where QC may 
> act as QI. I am not sure if I understood the example you gave. But, I 
> know for example in GPRS there is a network initiated PDP context 
> activation procedure, where the GGSN (QC) requests MS (QI) to 
> initiate 
> the PDP context activation procedure. This is a genuine case 
> because a 
> QC (e.g. GGSN or a an edge router) may receive packets for 
> delivery to 
> the hosts (normally a QI) for which QoS needs to be setup along the 
> path. In this case essentially QI remains the actual initiaor, but it 
> initiates at the request of QC.
> 
> Cheers,
> - Muhammad Jaseemuddin
> 
> Geib, Ruediger wrote:
> 
> >Roland,
> >
> >I agree with your view completely. Let's go on with the 
> requirements and stop a discussion of architectures. That's 
> part of the solutions.
> >
> >A requirement may be that in some cases a "QC" may act as 
> "QI": An edge to edge QoS tunnel set up (maybe even spanning 
> several domains). This would allow the tunnel entry point QC 
> to do per flow edge to edge admission control once the QI 
> requests service for the tunnel destination domain. To me 
> this is the simplest and therefore most desireable way of per 
> service reservation aggregation.
> >
> >Regards, Rüdiger 
> >
> >>Hi all,
> >>
> >>I think we can solve this issue by not complicating the role model. 
> >>It is also mentioned in section 4.1 of the nsis-req draft that QoS
> >>Controllers interact with other QoS Controllers (as I understood). 
> >>Therefore, there is signaling between different QCs. I don't think 
> >>that we should complicate the model by explicitly defining every QC 
> >>also as QI, although the QC initiates a further signaling 
> transaction 
> >>with another QC. I also don't think that the terms QC and 
> QI are not 
> >>generic enough to also cover a distributed approach. For a more 
> >>complete model my suggestion (we add also a QoS Responder):
> >>
> >>          Domain A             Domain B
> >>        .......................      .......................
> >>        .                     .      .                     .
> >>QI <--> . QC <==> ... <==> QC . <==> . QC <==> ... <==> QC . <--> QR
> >>        .......................      .......................
> >>     a)       b)                  c)                           a)
> >>
> >>1.) The QI can be an end system or signaling proxy acting on
> >>    behalf of an end system. 
> >>2.) There can be several QoS Controllers involved in signaling. 
> >>    Some of the QCs may be located within one administrative
> >>    domain (allowing the distributed case where each router 
> >>    or each edge router or several BBs are involved within
> >>    such a domain) whereas others are located within different
> >>    domains. 
> >>3.) Finally, we should add the QoS Responder (QR) in order to have 
> >>    a "symmetric" model where the corresponding end system
> >>    can be also involved in signaling (e.g., to let a 
> mobile terminal 
> >>    decide about the priority of requests due to scarce bandwidth).
> >>    As with the QI the QR could be also a signaling proxy. 
> >>    Alternatively, the QC can act as proxy.
> >>
> >>I think that this model covers all the different signaling cases:
> >>a) end <-> edge/network
> >>b) network internal, also covering edge to edge (intra-domain)
> >>c) network <-> network (inter-domain)
> >>and considering the whole signaling scenario by combining
> >>the parts
> >>d) end to end (QI <--> QR indirectly via a)b)c), not at 
> >>application level)
> >>
> >>Won't this fit most use cases?
> >>
> >
> >_______________________________________________
> >nsis mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/nsis
> >
> 
> -- 
> ==================================================
> Muhammad Jaseemuddin
> Associate Professor
> Departement of Electrical and Computer Engineering
> Ryerson University
> 350 Victoria Street
> Toronto, ON M5B 2K3
> Tel: +1 416 979-5000x6073
> Fax: +1 416 979-5280
> Email: [email-masked]
> Web: http://www.ee.ryerson.ca/~jaseem
> ==================================================
> 
> 
> 

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

---

From: Roland Bless <[email-masked]>
Date: Thu, 28 Feb 2002 13:06:54 +0100

Hi Ruediger,

> All the involved QC's should use standard NSIS signaling to set up the
> "fat pipe". During the fat pipe set up, the systems marked as "edge QCs"
> act as QI. Note that than one requirement for NSIS would be to support
> reservations to IP address + prefix range instead of IP address only.
> (Maybe even several IP adress + prefix ranges!)

I prefer the term reservation aggregate, because "tunnel" is often associated with 
encapsulation of packets in packets. I know that the Q-Bone approach used this term.

> This saves per flow signalling and state from all the intermediate QCs
> (and hence improves scaleability). Admission Control decisions are
> speeded up too. It's of course not a general solution, and some "per
> flow" signaling will have to be done by the intermediate QCs for
> destinations without pre-installed "fat pipes".

I think this is a very good point according to scalability. Hence, in my
view the nsis protocol should allow to set up and manage reservation
aggregates. The DARIS approach is a bit more general, because it also
supports full hierachical aggregation of reservations between arbitrary
domains. Therefore, the "fat pipes" are not restricted to reach from
Edge network to Edge network: every domain can decide by itself to set
up an aggregate to any other domain, and, aggregates can be nested.

Moreover, I designed a signaling protocol that allows more efficient
aggregation management (saving more than one RTT in delay, for instance
in case the aggregate capacity has to be changed).

> If you'd like to look at it that way, it's a requirement for NSIS
> signalling to support some kind of traffic engineering. Support here is
> limited to control "fat pipe" set up, maintenance and release.

Yes, but not limited to pipes reaching from edge to edge network.

> Another requirement in the above case is that the tunnel entry point
> must recognize a per flow reservation fitting to a specific tunnel.

Right. Additionally, it can also decide when to set up a new aggregate.

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