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

From: "Roy, Radhika R." <[email-masked]>
Date: Sun, 30 Jul 2006 19:16:49 -0400

Hi, Hannes:
 
Let me summarize again the basic technical "fine" points.
 
It is precisely: a. application layer QOS parameters vs. b. network centric
QOS parameters.
 
No IETF RFCs that are related to QOS had the charter to define QOS signaling
and hence QOS parameters for application layer QOS other than NSIS.
 
NSIS QOS signaling standards are proceeding OK.
 
However, the key technical points that have been missed are this:
 
1. Do the NSIS QOS parameters defined so far represent end-to-end
application QOS parameters (e.g., audio/video codec-to-codec
bandwidth/delay/jitter/packet loss)?
 
2. If so, how do we do this? If not, why not?
 
Best regards,
Radhika
 
PS: 
 
i. I understand the value of so-called QOS models developed by many folks in
many standard organizations and people are implementing a lot of other
things. But none of them doing is doing above based on standards.
 
ii. The whole debates in NSIS QOS parameters have turned into how to carry
the QOS parameters that have been defined in so-called QOS models that are
also network-centric as I explained earlier.
 
iii. Above item ii has obscured the basic fact that NSIS has been chartered
that it will deal with application layer QOS. The question is this: Who will
deal with the application aspect of QOS parameter that are so simple?
 
iv. If 3GPP and other organization could solve the application layer QOS as
described using standards, please let us know.
 
v. If NSIS wants to deviate from its charter that it will NOT define
application layer QOS, let us make the NSIS charter clear. If you think that
the mapping between the network centric QOS and application QOS is a matter
of implementation, I would then suggest, let NSIS charter should be revised
by saying that the network-centric QOS parameters will be defined in along
the spirit of all available so-called QOS models and/or IP
network/MAC/physical layer QOS specific QOS parameters. In this case, we all
know what to focus on without being oscillated between the two extreme ends:
Application QOS vs. Network QOS.

  _____  

From: Hannes Tschofenig [mailto:[email-masked]]
Sent: Sun 7/30/2006 1:44 PM
To: Roy, Radhika R.
Cc: [email-masked]; Hancock, Robert
Subject: Re: AW: [NSIS] Any resolution to the QSPEC mandatory parameter li
st?

Hi Roy,

Roy, Radhika R. wrote:
> Then, we have fundamental problems to fulfill the objectives of NSIS QOS
> standards.

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.

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

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.

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

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

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

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.

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

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.

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

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
> the NSIS WG working so hard to push for all those "technically confusing
and
> 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.

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

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.

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

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

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

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 31 Jul 2006 22:12:44 +0200

Hi Roy,

> It is precisely: a. application layer QOS parameters vs. b. network centric

I don't see them as two distinct parameter sets.

> and hence QOS parameters for application layer QOS other than NSIS.

I am not sure what you mean.
What about the work done in the SIP environment? What about the work in 
the transport working group?

> Application QOS vs. Network QOS.

I am not sure why you stick so much to the parameter discussion.
What parameters would you like to see being used?
What QoS model do you think is the one that would satisfy your needs?

Why don't you write a QoS model draft that contains the parameters that 
you would like to see. The work is contribution driven and there are 
already a number of QOSMs out there that fulfill the needs in certain 
deployment environments. There is nothing to stop us from working on new 
  documents.

Ciao
Hannes