Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory parameter li st?

From: "Roy, Radhika R." <[email-masked]>
Date: Tue, 1 Aug 2006 10:23:13 -0400

Hannes:
 
You might be right to some extent as there are so many documents and each
has many things inside it.
 
Yes, the works are contribution driven based on its charter.
 
The basic point, if I understand you correctly, QOS model in NSIS is under
development for QOS signaling as we have been seeing some discussions are
going on.
 
What we are seeing here is this: There is a "gap" how to use the NSIS QOS
model by the application like SIP. As you have said that the application
will request QOS using NSIS QOS model. The application like SIP has to
convert the e2e QOS needs per non-e2e NSIS QOS model. 
 
How the application like SIP will do it is not known - it is a
"non-standard" scheme, and NSIS also does not want to address this as no one
has brought contributions along this line.
 
If it is true, let us make it is clear as objectives because no documents
address this keeping this in disguise as if some miracle happens.
 
That is point that I have been driving at for "complexity" of QOS parameter
discussions that you have trying hard for mapping between NSIS QOS
parameters to WiFi, WiMAX, cellular, IP, etc.
 
Once we know this, we can easily fall back to the same schemes what other
like DIAMETER are doing.
 
Did I summarize correctly? I appreciate your patience.
 
BR/Radhika

  _____  

From: [email-masked] on behalf of Hannes Tschofenig
Sent: Tue 8/1/2006 6:07 AM
To: Roy, Radhika R.
Cc: [email-masked]; Hancock, Robert
Subject: Re: AW: [NSIS] Any resolution to the QSPEC mandatory parameter li
st?

Roy,

to me it seems that you haven't read the existing NSIS documents.
I strongly suggest that you should do that. You cannot put the workload
on me to summarize the documents for you. Since the IETF is contribution
driven I think you should also work on a draft that describes what you
want. You might, for example, develop the QoS model. It is easy to
criticize the work of others if you haven't written your own proposal.

Ciao
Hannes

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

---

From: <[email-masked]>
Date: Wed, 2 Aug 2006 08:37:04 +0300

Hi all,

I think this thread has out-lived its usefulness. Let me summarize.
NSIS has developed a layered signaling model (outlined in the
NSIS Framework RFC).  NSIS is chartered not to develop new QoS
solutions, but to reuse and support other QoS solutions.  The IESG
wanted us to consider how to support other SDO QoS solutions
as well as IETF QoS Solutions (intserv/diffserv).  Solutions
developed outside of the IETF are clearly of Information status.

Radhika would like NSIS QoS signaling to be able to support
signaling different QoS parameters directly - bandwidth,
Delay, Delay Jitter, Packet Loss, etc.  These can be signaling
directly with the Qspec template - I think we might want to
think about creating a generic QoS model that allows endpoints to
signal only what parameters are needed.  This way, if there are
QoS deployments that want to signal their QoS Models, than that
is possible - if there is need to signal just simple parameters
on an end-to-end basis, than that would be possible.

In summary, NSIS is required to be able to signal other SDO's 
QoS Models.  By being able to signal these models, the IETF
is not implying the relative fitness of the specifications
developed elsewhere, but ensuring that NSIS's work supports deployments.

If there is need / interest in signaling very simple or basic
parameters,
I suggest we consider how to generate a generic QoS model that allows
us to signal just the basic parameters on an as-needed basis.

John

>-----Original Message-----
>From: ext Roy, Radhika R. [mailto:[email-masked]] 
>Sent: 01 August, 2006 17:23
>To: Hannes Tschofenig
>Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory 
>parameter li st?
>
>Hannes:
> 
>You might be right to some extent as there are so many 
>documents and each has many things inside it.
> 
>The basic point, if I understand you correctly, QOS model in 
>NSIS is under development for QOS signaling as we have been 
>seeing some discussions are going on.
> 
>What we are seeing here is this: There is a "gap" how to use 
>the NSIS QOS model by the application like SIP. As you have 
>said that the application will request QOS using NSIS QOS 
>model. The application like SIP has to convert the e2e QOS 
>needs per non-e2e NSIS QOS model. 
> 
>"non-standard" scheme, and NSIS also does not want to address 
>this as no one has brought contributions along this line.
> 
>If it is true, let us make it is clear as objectives because 
>no documents address this keeping this in disguise as if some 
>miracle happens.
> 
>That is point that I have been driving at for "complexity" of 
>QOS parameter discussions that you have trying hard for 
>mapping between NSIS QOS parameters to WiFi, WiMAX, cellular, IP, etc.
> 
>Once we know this, we can easily fall back to the same schemes 
>what other like DIAMETER are doing.
> 
>Subject: Re: AW: [NSIS] Any resolution to the QSPEC mandatory 
>parameter li st?
>
>
>
>Roy,
>
>I strongly suggest that you should do that. You cannot put the 
>workload on me to summarize the documents for you. Since the 
>IETF is contribution driven I think you should also work on a 
>draft that describes what you want. You might, for example, 
>develop the QoS model. It is easy to criticize the work of 
>others if you haven't written your own proposal.
>
>Ciao
>Hannes
>
>
>
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 02 Aug 2006 10:47:15 +0200

Thanks for the nice summary, John.

It is a good hint stop at this point.

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Wed, 2 Aug 2006 06:17:40 -0500

John,

> I think we might want to think about creating a generic QoS
> model that allows endpoints to signal only what parameters
> are needed. 

Not sure I get what you mean.  A QNI can already signal 'only what
parameters are needed'.  E.g., there is no need to signal all mandatory
parameters, some or none can be signaled, for example (that's been a
point of confusion).

Jerry