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

From: [email-masked]
Date: Thu, 28 Feb 2002 15:36:52 +0100

Hi Geib,

Good point to bring in  also the concerns related to core networks. The
QoS problem space is quite different than in access (e.g. scalability is
a headache, while mobility is non-issue (just to put a trivial thing :-) 

see further in-line...

"Geib, Ruediger" wrote:
> 
> Muhammed,
> 
> I'm a core network engineer and I prefer fat pipes instead of per flow reservations. 

[DG] OK, we don't want to make the mistake of per-microflow processing
in core routers again, I think nobody objects to that.

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:

[DG] However, I think we should make distinction between provisioning
(making the resources available, e.g. fat-pipe set-up) and signaling
(consuming the resources, e.g. multiplexing microflows in the pipes at
the edges). Clearly resource provisioning may depend on the actual
technology of the concrete network (and is an operator's policy). I
should like to call this "local provisioning means" and the end-to-end
NSIS signaling should, in my opinion, be independent of this local
mechanisms. 

> 
> 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". 

[DG] I have some questions here. There might be some confusion
concerning "THE NSIS protocol". As I see it now, there could be a
"local" signaling and an "end-to-end" signaling. The local signaling is
reserving resources locally, e.g. in the core it could be RSVP-TE (or
just by management, in which case this "local signaling" might be
trivial) for setting up the fat pipes. Another example is maybe
signaling in UMTS from MT to (access) network edge, for reserving
resources in the access network. A lot of things exist already today,
which could be studied for improvement by NSIS. However, the missing
thing is the end-to-end stuff yielding really QoS end-to-end. 

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".

[DG] I have similar ideas regarding this "two-step" approach (at least
for core networks): pre-provision "fat pipes" by any means (RSVP-TE,
Network management or whatever) and then signal for per-flow resources
(AC is barely filling up the pipe until it's full).

> 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.

[DG$ Here I am not sure it should be the first focus of NSIS, imho, NSIS
should have as first target the per-flow signaling and make the "local
provisioning means" transparant for the QoS signaling.

> 
> 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
> 

Regards,
Danny

> 
> > -----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

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

---

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

Hi Danny

> (AC is barely filling up the pipe until it's full).

That's not quite what I'm thinking of. If the mechanism I suggested should support E2E services, RSVP-TE and network management aren't the vehicles to set up reservation aggregates accross arbitrary domains (especially concatenations of domains). RSVP-TE is a layer 2 specific protocol (currently supporting only routing area related TE) and network management is domain specific. What I am looking for is a mechanism to carry the reservation aggregate related signaling also through a full domain (and not only a single routing area) and between domains. How a network provider modifies resources within his domain and at which layer doesn't matter to NSIS and therefore isn't relevant for my proposal. 

Regards, Rüdiger

---

From: [email-masked]
Date: Thu, 28 Feb 2002 16:08:34 +0100

Hi Geib,

see in-line...

"Geib, Ruediger" wrote:
> That's not quite what I'm thinking of. If the mechanism I suggested should support E2E services, RSVP-TE and network management aren't the vehicles to set up reservation aggregates accross arbitrary domains (especially concatenations of domains). RSVP-TE is a layer 2 specific protocol (currently supporting only routing area related TE) and network management is domain specific. 

[DG] Indeed, that's why I didn't understand it should be part of NSIS
scope (clarified now: it is not!)

What I am looking for is a mechanism to carry the reservation aggregate
related signaling also through a full domain (and not only a single
routing area) and between domains. 

So, this is another problem statement than the one I had actually in
mind (enabling e.g. real-time multimedia over the Internet). The problem
if "inter-domain" fat pipes seems different and (as you suggested in
previous mail) is indeed related with some traffic engineering aspects.
Is this in the NSIS scope ?

Regards,
Danny

How a network provider modifies resources within his domain and at which
layer doesn't matter to NSIS and therefore isn't relevant for my
proposal.