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

From: "Roy, Radhika R." <[email-masked]>
Date: Sat, 29 Jul 2006 23:26:11 -0400

Then, we have fundamental problems to fulfill the objectives of NSIS QOS
standards.
 
If you look very carefully, NSIS QOS is tied to the applications in the
first place for which it is being designed to meet the very needs of QOS. If
NSIS QOS is de-coupled from the applications to meet the needs of QOS, why
are we developing so many fancy performance parameters? In the end of the
day what purpose will NSIS QOS serve to meet the QOS needs of the
applications?
 
Let me summarize the problems that NSIS QOS standards will create if it is
decoupled from the application QOS:
 
1. If a call from the application (e.g., SIP INVITE with G.711 codec) is
made, the application will not be able to map it QOS needs (e.g., Bandwidth,
Delay, Delay Jitter, Packet Loss) to the NSIS QOS signaling protocol
messages.
 
2. If any arbitrary QOS needs are signaled to the NSIS QOS parameters
decoupling from the application QOS needs, these QOS needs will be just some
kinds of arbitrary IP network/MAC layer/Physical layer-centric QOS
parameters that are only understood by the network entities like IP routers,
LANs, base stations, etc., not by applications.
 
3. At the end of all those, when NSIS QOS parameters are sent to the
application (e.g., G.711), what will the G.711 codec do?
 
4. If one thinks that some kinds of mapping between so-called NSIS IP
network/MAC layer/Physical layer-centric QOS parameters will be magically be
transformed into QOS parameters that the application (e.g., G.711), what is
that standard? Is that so-called Y.xxxx or DSTE QOS model? If not, why are
the NSIS WG working so hard to push for all those "technically confusing and
contradicting" things that no direct relevance to NSIS QOS?
 
5. If you thinks that SDP needs to indicate bandwidth, delay, jitter, and
packet loss for G.711, it can be done very easily and, like bandwidth, it
will be end-to-end codec-to-codec delay/jitter/packet loss. Again, it will
constitute the needs from the application point of view, and the SIP call is
between the end-users - more appropriately between the codes.
 
6. If you think that NSIS will focus only on end-to-end application QOS
parameters, can we not simplify using only few specific performance
parameters for NSIS and let the network centric QOS folks develop all those
billions of "segmented" performance parameters and so-called QOS models
specific to all networks decoupling from the applications?
 
Would you please take a little pain to clarify the above to the WG members
as you are doing great jobs for so many things in many WGs including NSIS?
 
Best regards,
Radhika

  _____  

From: [email-masked] on behalf of Hannes Tschofenig
Sent: Sat 7/29/2006 5:26 PM
To: Roy, Radhika R.
Cc: [email-masked]; Hancock, Robert
Subject: Re: AW: [NSIS] Any resolution to the QSPEC mandatory parameter li
st?

No, I did not try to map the SIP/SDP parameters to the QSPEC.
If we ignore the codecs then the only relevant parameter carried in SDP
is a bandwidth parameter.

Ciao
Hannes

Roy, Radhika R. wrote:
> Hi, Hannes and Robert:
> 
> Inline [RRR].
> 
> BR/Radhika
>
>   _____ 
>
> From: [email-masked] on behalf of Hannes Tschofenig
> Sent: Sat 7/29/2006 5:38 AM
> To: Hancock, Robert
> Cc: Ash, Gerald R (Jerry), ALABS; [email-masked]
> Subject: Re: AW: [NSIS] Any resolution to the QSPEC mandatory parameter
> list?
>
>
>
> When I tried to map the IEEE 802.16e QoS parameters to the parameters in
> the QSPEC template I had a really hard time because they did not match
> 100%. Sure, you can attempt to use the QSPEC parmeters with some
> additional wording but try to convince folks in Wimax that this is a
> good approach.
>
> [RRR] Did you also try to map from the application (e.g., SIP/SDP) to
QSPEC
> parameters as NSIS is trying to do so? For example, there is a SIP INVITE
> and SDP expresses G.711 audio?
>
> Ciao
> Hannes
>

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 30 Jul 2006 19:44:29 +0200

Hi Roy,

> Then, we have fundamental problems to fulfill the objectives of NSIS QOS

There is no reason to be concerned. Just because I haven't done anything 
  by my own isn't alarming. I bet a number of folks have done the 
analysis   in a great level of detail.

> day what purpose will NSIS QOS serve to meet the QOS needs of the

It is true that the parameters at all layers need to fit together if the 
  goal is to signal for per-flow application layer traffic. Note, that 
there are some other scenarios where this is not necessarily true.

> Delay, Delay Jitter, Packet Loss) to the NSIS QOS signaling protocol

Do you currently have the impression that this is not possible?

> LANs, base stations, etc., not by applications.

If the goal is to signal for end-to-end application layer traffic and 
the parameters at the link, network and the application layers do not 
fit together then there is a problem.

> application (e.g., G.711), what will the G.711 codec do?

It should be the other way around. The application knows what it wants 
todo and then it initiates QoS signaling with parameters it feels 
comfortable with.

> that standard?

There shouldn't be magic, obviously. However, you will not find IETF 
documents that describe these types of things since they are mostly 
implementation specific.

  Is that so-called Y.xxxx or DSTE QOS model? If not, why are
> contradicting" things that no direct relevance to NSIS QOS?

I know that you are not particularly excited about the Y.1541 work.

Some environments will use the QoS model they like. The IETF (and the 
NSIS working group) is not the QoS deployment police.

Let folks write the QoS model they like. No big problem if the document 
is properly written.

With respect to the 'mandatory' QoS parameters we obviously need to make 
sure that we get them right. That was the reason we had some many 
discussions over the past few months.

> between the end-users - more appropriately between the codes.

I looked at the 3GPP specs what they do with regard to the Diameter QoS 
work. They use information from SDP (bandwidth) and then use information 
about the environment (i.e., 3G access network) and then they generate 
the parameters.

> specific to all networks decoupling from the applications?

Why don't you like the concept of QoS models? It is a useful concept and 
does not cause harm. You might not agree with all QoS models, for sure, 
but nobody will ever do so.

RFC 3726 states that we focus on various deployment models; not only on 
E2E QoS.

Ciao
Hannes