Subject: [NSIS] QSPEC example 1

From: Xiaoming Fu <[email-masked]>
Date: Wed, 11 Oct 2006 20:51:54 +0200

Hi all,

Let's try to consider what about a virtual network scenario that 
consists of the following nodes:

QNI-a: supports QoSM-a, which uses QSPEC-a (composed of QSPEC-1 
parameters P11 and P12, and QSPEC-2 parameter P21 and P22).
QNE-b: supports QoSM-b, which uses QSPEC-b (composed of QSPEC-1 
parameters P12 and P13, and QSPEC-2 parameters P21 and P23).
QNE-c: supports QoSM-c, which uses QSPEC-c (composed of QSPEC-1 
parameter P14 and QSPEC-2 parameter P24).
QNR-d: supports QoSM-b.

First, for simplicity, let's assume the reservation is made via a 
sender-initiated way; no QSPEC remapping/tunneling/stacking is used in 
all nodes; QSPEC-2 parameters will be ignored in a non-aware node; and 
the e2e resource is enough for this reservation (i.e., admission control 
succeeds). Note interpreting a QSPEC parameter does not imply the 
parameter will be forwarded onto a next node. What will happen?

1) Certainly QNI-a will initialize with a Resv message carrying all its 
support QSPEC parameters (P11, P12; P21, P22).
2) Upon receipt of this message, QNE-b will interpret P11 (likely 
approximate), P12, and P21, and ignore P22. Then it will forward the 
Resv containing  QSPEC (P11, P12, P21).
3) Upon receipt of this message, QNE-c will interpret P11 and P12 (both 
likely approximate) and ignore P21. Then it will forward the Resv 
containing QSPEC (P11, P12)
4) Upon receipt of this message, QNR-c will interpret P11 and P12 
(likely approximate). Then it will issue a Response towards the QNI, 
containing QSPEC (P11, P12, or???!).

This implies to me that either a tunneling/stacking should be used, or a 
remapping of all possible QSPEC-1s to a more generic, small set of 
QSPEC-1 parameters for all QOSMs may be provided. However, reading 
through currently documented QoSMs, only Token Bucket 
(CL/Y1541/draft-jeong-nsis-3gpp-qosm) or bandwidth (RMD) is common for 
all. As tunneling/stacking may be too strong for many QoSMs for 
deployment issues, one more general approach maybe to let QSPEC-1 only 
limit to bandwidth/token bucket....
Is this a too stupid/radical/simple conclusion?
Xiaoming

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

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 12 Oct 2006 18:15:01 +0200

Hi Xiaoming

I support your following conclusion/proposal!

> one more general approach 
> maybe to let QSPEC-1 only limit to bandwidth/token bucket....

Best Regards,
Georgios

> 
> -----Original Message-----
> From: Xiaoming Fu [mailto:[email-masked]] 
> Sent: woensdag 11 oktober 2006 20:52
> To: [email-masked]
> Subject: [NSIS] QSPEC example 1
> 
> Hi all,
> 
> Let's try to consider what about a virtual network scenario 
> that consists of the following nodes:
> 
> QNI-a: supports QoSM-a, which uses QSPEC-a (composed of 
> QSPEC-1 parameters P11 and P12, and QSPEC-2 parameter P21 and P22).
> QNE-b: supports QoSM-b, which uses QSPEC-b (composed of 
> QSPEC-1 parameters P12 and P13, and QSPEC-2 parameters P21 and P23).
> QNE-c: supports QoSM-c, which uses QSPEC-c (composed of 
> QSPEC-1 parameter P14 and QSPEC-2 parameter P24).
> QNR-d: supports QoSM-b.
> 
> First, for simplicity, let's assume the reservation is made 
> via a sender-initiated way; no QSPEC 
> remapping/tunneling/stacking is used in all nodes; QSPEC-2 
> parameters will be ignored in a non-aware node; and the e2e 
> resource is enough for this reservation (i.e., admission 
> control succeeds). Note interpreting a QSPEC parameter does 
> not imply the parameter will be forwarded onto a next node. 
> What will happen?
> 
> 1) Certainly QNI-a will initialize with a Resv message 
> carrying all its support QSPEC parameters (P11, P12; P21, P22).
> 2) Upon receipt of this message, QNE-b will interpret P11 
> (likely approximate), P12, and P21, and ignore P22. Then it 
> will forward the Resv containing  QSPEC (P11, P12, P21).
> 3) Upon receipt of this message, QNE-c will interpret P11 and 
> P12 (both likely approximate) and ignore P21. Then it will 
> forward the Resv containing QSPEC (P11, P12)
> 4) Upon receipt of this message, QNR-c will interpret P11 and 
> P12 (likely approximate). Then it will issue a Response 
> towards the QNI, containing QSPEC (P11, P12, or???!).
> 
> This implies to me that either a tunneling/stacking should be 
> used, or a remapping of all possible QSPEC-1s to a more 
> generic, small set of
> QSPEC-1 parameters for all QOSMs may be provided. However, 
> reading through currently documented QoSMs, only Token Bucket
> (CL/Y1541/draft-jeong-nsis-3gpp-qosm) or bandwidth (RMD) is 
> common for all. As tunneling/stacking may be too strong for 
> many QoSMs for deployment issues, one more general approach 
> maybe to let QSPEC-1 only limit to bandwidth/token bucket....