Subject: [NSIS] questions on partain draft-partain-...

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

Hi David, Vlora and co-authors,

I have been reading with interest the draft you submitted recently and,
of course, i have quite some questions. 

First, let me start with the figures.
Figure 1: the Joint Point of Reservation (JPR). I find it an interesting
idea and want to have a better understanding. In an UMTS access network,
is this JPR meant to be the SGSN or the GGSN, or could it be both? 

MH --- (UMTS access) --- SGSN ---(UMTS backbone)--- GGSN -- BR (e.g. A
DiffServ edge router). 

If I want to map this figure 2 on figure 3: 
--- is the JPR (fig 2) = BGW (fig 3) (which could be a GGSN) or 
----is the JPR = ER before the backbone (... SGSN).

Returning now to figure 1. I like the figure, but I have two remarks.
First, I think it should better elaborate the access - edge- core
interworking. For example

host ----(access network)---- EN - BN----(interios core)----BN-BN---

EN is edge node, which, in the UMTS case, is the GGSN. In our draft we
gave this box the generic term "access gate" (AG), which can thus be a
GGSN (UMTS), a BAS (xDSL), CMTS (PacketCable) or even a trunking GW in
case of connection with the PSTN.

For me figure 1 (enlarged with the above suggstion) gives a high-level
(but clear) view on the QoS segments in the end-to-end path. However, I
have one important question concerning the applicability of the figure:
a BN is this restricted to a border Router or can it be any box at the
network edge/border. In other words, i should like that out-of-band
mechanisms are not a-priori excluded and i think it should try to aline
with the suggestions for out-of-band approaches in draft-brunner...

So, if i quote the draft, i share your viewpoint on the following:

"  End-to-end QoS management does not necessarily mean that a single
   one-size-fits-all QoS signalling protocol must be applied end-to-end.
   In fact, it is most likely that the end-to-end QoS management
   architecture will consist of many interoperable and concatenated QoS
   management architectures rather than one global end-to-end QoS
   infrastructure."

This is also the viewpoint we expressed in our draft. I also support the
following:

"  Each QoS domain is responsible for taking its own decisions in its
own domain-
   specific ways."

For me this is an important requirement. It means to a certain extend
that QoS provisioning (at the end of the day this is about bandwidth and
buffer resources in the routers) and QoS signaling  (request for
consuming the resources) should be kept separated to the extend
possible. In the extreme case of "over-provisioning" (whatever this
might be), resources are pre-provisioned and signaling is (almost ?)
trivial.

However, If I follow the above arguments, then I must admit I can not
support the following restriction of the QoS signaling/framework

" In all the scenarios ... the data MUST follow the same path as the
signalling messages."

Don't agree with this restriction. 

It should e.g. be possible for a DiffServ network operator to
pre-provision his network for EF traffic and nevertheless participate in
NSIS signaling without the need to upgrade all his routers. So, he may
opt to install (an almost trivial ?) QoS policy server with an NSIS
agent to put himself into the NSIS QoS inter-network. It least, this may
not be excluded at this moment.

One way to make it concrete is e.g. to try to "inter-connect your use
case 3.1/3.2 with our use case UMTS (figure 2, figure 3)

I have also a question on the use case 3.3 PSTN gateways ans IP
backbone. We have the same use case, and so it could be interesting to
compare both and lign-up. I appreciate the analysis (page 8) made on how
the backbone may provision resources (4 possibilities). In our use we
outline (what i think) is a combination of your points 2 and 4 (2= AC
per policy server) 4 (par call AC based on 5-tuple). 

Anyhow, we need some more discussion here, and i also am interested to
see your comments, in particular about the use cases.

Still a lot of questions, but let it keep it here for the moment...

Regards,
Danny

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