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

From: "Roy, Radhika R." <[email-masked]>
Date: Tue, 25 Jul 2006 11:18:47 -0400

Hi, Roland and all:

You have raised a valid technical question. So, QSPEC also need to be
independent of any QoS model. 

Again the question is this: Why does this QSPEC spec still deal with
some "incomplete" extensions of Y.xxx and DSTE qos-specific models?

BR/Radhika

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Roland Bless
Sent: Tuesday, July 25, 2006 11:09 AM
To: Kappler, Cornelia
Cc: Georgios Karagiannis; Jukka MJ Manner; [email-masked]; Ash, Gerald R
ALABS
Subject: Re: AW: [NSIS] Any resolution to the QSPEC mandatory parameter
list?

Hi all,

> I've been off-list for the last 10 days and may have difficulties
> grasping the real point of the debate.

Sorry, I missed the discussion, though we had some
informal discussion in Dallas one morning at a
roundtable :-)

> I'd prefer some concrete suggestions to which parameters should not
> be mandatory. Rather than blanket statements "List is too long" or
> "List is too short" or "we should have N parameters".
> 
> The question is not really whether it should be 2 or 8 or 20
> mandatory parameters. It is _which_ parameters are necessary to
> _just_ accomodate the key ideas of typical QOSMs.

Now I'll repeat what I already said in Dallas:
I'd prefer to not prescribe any mandatory parameters for all
QoS models. Thus I don't actually like the approach:
"Mandatory parameters in the QSPEC must be
meaningfully interpreted by all QNEs in the path, independent of
which QOSM they support." I disagree,
because we may have different QoS models that not even
require these parameters or future QoS models that require
even more mandatory parameters which are not covered by
the QSPEC template anyway. But trying to be constructive:
I would rather prefer to leave it up to each QoS model
which parameters are mandatory and which are not, like
defining a profile (e.g. similar to MPEG profiles).
Furthermore, interworking between different QoS models
can be defined that describes which parameters can
mapped onto which in the other QoSM.
I agree on this statement in the introduction:
"  A particular QOSM
   specifies a) a set of mandatory and optional QSPEC parameters, and
   b) how the QSPEC information is interpreted by the RMF with respect
   to the QoS description, resources desired, resources available, and
   control information."
The value of the QSPEC is still retained, because a QoSM only
needs to pick certain parameters of the QSPEC which are already
defined therein.

Just my two cents,
 Roland

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

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

---

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 31 Jul 2006 10:00:03 +0100

roy,

my views:

> From: [email-masked] [mailto:[email-masked]] 
> Sent: 31 July 2006 00:17
> To: Hannes Tschofenig
> Cc: [email-masked]; Hancock, Robert
> Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory 
> parameter li st?
> 
> 
> 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.

i would say 'parameters that need to be implemented in the
network infrastructure' rather than 'network centric' but
this is probably just a terminology issue.

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

i can't fully comment on this, not being sufficiently familiar 
with all the other ietf WGs. but do you say this is outside (for
example) mmusic?

>  
> NSIS QOS signaling standards are proceeding OK.

i am glad we all agree on this :-D

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

only in so far as they need to be understood and implemented in
the network infrastructure. so, for example, codec issues would
IMHO be entirely out of scope.

>  
> 2. If so, how do we do this? If not, why not?

we don't because it is not our job to do so? at least, that is
my interpretation. but that is more a question for John and 
the IESG, I think.

robert h.

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

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Mon, 31 Jul 2006 17:32:58 +0200

Hi Roy, 

from the discussion so far it seems that you have looked at the
application layer to NSIS QoS mapping in more detail. 
What was the conclusion?
Are the work-in-progress QoS models support what you want? 

Ciao
Hannes

---

From: <[email-masked]>
Date: Mon, 31 Jul 2006 17:34:28 -0400

I don't usually post here, but I want to chime in, having been active in
QoS and QoE (experience) in other arenas over the years (ITU, ATIS,
IEEE,...).

Many years ago, e2e QoS experts around the globe agreed that it was NOT
a good idea to leave the assignment and allocation of individual
performance parameters up to the user/application. Having even an
educated user try to negotiate an infinite combination of levels of
loss, delay, jitter, etc., was not seen as feasible. Moreover it was
seen as unnecessary because most all applications fall into one of a
finite set ( < 10) classes.

That is why we came up with the QoS classes in Y.1541, which takes the
full range of common applications into account--voice, data, IPTV, large
frame TCP, best effort, whatever. Regarding QoS, all the application
need signal is which of the eight classes is needed. The network can
indicate whether the objectives of that class can be met, or possibly
offer another class. 

We appreciate that not everyone may buy in to this approach, and we are
not forcing this approach on everyone. However, there is sufficient
critical mass for this "QoS model" to justify it; indeed Y.1541 is *the*
basis for "network QoS" in other forums, and we see NSIS as also
usefully supporting it. So in like kind, we ask that no one force their
solution on us!

Respectfully

Chuck Dvorak
AT&T Labs

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Monday, July 31, 2006 3:34 PM
To: Roy, Radhika R.
Cc: Hancock, Robert; [email-masked]; Tschofenig, Hannes
Subject: Re: AW: [NSIS] Any resolution to the QSPEC mandatory parameter
li st?

Hi Roy,

I strongly believe that we need the QoS model concept. I also think that

there will never be a single QoS model that everyone can agree with. You

will always find deployment environments that are a bit different that 
others. We already see this happening today.

NSIS is about signaling QoS information obtained from the application to

the network, in one of the envisioned usage scenarios. But there are 
others as well that are important. You just need to think about the 
transition time where an E2E solution cannot be deployed.

Ciao
Hannes

Roy, Radhika R. wrote:
> Hi, Hannes:
>  
> The most important conclusion is this: We do not need any QOS model.
Period.
>  
> All we want in NSIS is this: Like NSIS QOS signaling messages, we just
need
> to express the end-to-end QOS parameters of the applications as
follows:
> Bandwidth, Delay, Jitter, and Packet Loss.
>  
> For non-real-time data application, "jitter" may or may not be
required, but
> for real-time/near-real-time audio/video application, the above 4
parameters
> are needed.
>  
> The application will express those values on end-to-end basis,
"independent"
> of any transport networking that may consist of one or many networks
while
> transporting the application messages/payload on end-to-end basis.
>  
> By the way, NSIS's charter is not to standardize or specify any
"value" for
> those performance parameters.
>  
> It is so simple.
>  
> How to deal with the network QOS, it is not NSIS's problems. NSIS's
charter
> is to "signal" the QOS parameters on end-to-end basis between the
> applications. By the way, the end-to-end QOS requirements for
applications
> will remain the "same" because it is based on the "inherent"
characteristics
> of the system (e.g., MOS of audio/video application, response time
> requirements for data application depending on human or automa). 
>  
> Best regards,
> Radhika
>  
> PS:
>  
> 1. Now, 3G may solve their part of the network QOS. For example, they
> provide the access wireless network.
>  
> 2. IEEE may solve the access LAN QOS problems.
>  
> 3. IETF may solve the problems of public Internet backbone network QOS
> (e.g., DiffServ, DSTE), access IP network QOS (e.g., IntServ) or
end-to-end
> IP (access + backbone).
>  
> 4. An implementer (say, service provider) that wants to provide
end-to-end
> VoIP/SIP service will take NSIS QOS as the fundamental reference for
> addressing the end-to-end QOS for the application. They now need to
choose
> what type of networks they will use on the end-to-end path.
Accordingly,
> they will divide the NSIS's end-to-end QOS that has been signaled by
the
> application into individual networks. The beauty of this is this: NSIS
QOS
> signaling protocol still be used on end-to-end basis between the
> applications.
>  
> 5. If NSIS needs to address item 4, it needs to change its charter. It
is a
> huge problem to solve. I am extremely worried that NSIS focus might
have
> distorted due to unnecessarily mixing of items 1, 2, 3, and 4 while
they
> started discussing the QOS parameters.
> 
>   _____  
> 
> From: [email-masked] on behalf of Tschofenig, Hannes
> Sent: Mon 7/31/2006 11:32 AM
> To: Roy, Radhika R.; Hannes Tschofenig; Hancock, Robert
> Cc: [email-masked]
> Subject: AW: AW: [NSIS] Any resolution to the QSPEC mandatory
parameter li
> <https://www1.ietf.org/mailman/listinfo/nsis> 
> 
> 
>

---

From: "Roy, Radhika R." <[email-masked]>
Date: Mon, 31 Jul 2006 22:49:11 -0400

Hi, Hannes:
 
It is very interesting that NSIS wants QOS model concept for signaling. The
question is this: Which QOS model?
 
More inline [RRR].
 
BR/Radhika

  _____  

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

Hi Roy,

I strongly believe that we need the QoS model concept. 

[RRR] Which QOS model?

I also think that
there will never be a single QoS model that everyone can agree with. 

[RRR] Again, which QOS model that NSIS needs to agree with?

You

[RRR] Agreed. NSIS is not standardizing any specific implemention or
deployment.

NSIS is about signaling QoS information obtained from the application to
the network, in one of the envisioned usage scenarios. 

[RRR] Agreed. One of the important real-time multimedia applications is SIP.
If its needs are not met, which applications that NSIS is shooting for?
Could you please provide a scenario how the SIP application will use NSIS
QOS parameters that will have no knowledge of any underlying transport
networks or network-specific QOS models other than its own codecs per se? I
would appreciate your help.

But there are
others as well that are important. 

[RRR] I would think so. Could you please be more specifc with a given
example instead of being abstract?

You just need to think about the
transition time where an E2E solution cannot be deployed.

[RRR] Good. Let us understand what is the transitional QOS model where e2e
QOS solution cannot be deployed. No one in NSIS has yet written a
requirement that NSIS will develop a QOS signaling standard that will deal
with a transitional case before the e2e QOS solution is deployed. If so, let
us make it very specific what is the scope of this transitional QOS
solution. If we know this, definitely we all will work to this end. Let us
write a requirement document on this instead of being abstract.

[RRR] We thought that NSIS will do in two steps: a. Simple one with e2e
application QOS and b. Network-specific e2e QOS while complementing the e2e
application QOS as the fundamental reference. Case a will always remain the
same as SIP will always use its QOS reference to its codecs while case b
will have numerous soultions/implementations, and NSIS may work for a long
time on item b.

Ciao
Hannes

Period.
need
> to express the end-to-end QOS parameters of the applications as follows:
> For non-real-time data application, "jitter" may or may not be required,
but
parameters
"independent"
> of any transport networking that may consist of one or many networks while
> By the way, NSIS's charter is not to standardize or specify any "value"
for
charter
> applications. By the way, the end-to-end QOS requirements for applications
characteristics
end-to-end
> IP (access + backbone).
> 
> 4. An implementer (say, service provider) that wants to provide end-to-end
> addressing the end-to-end QOS for the application. They now need to choose
> what type of networks they will use on the end-to-end path. Accordingly,
> they will divide the NSIS's end-to-end QOS that has been signaled by the
> application into individual networks. The beauty of this is this: NSIS QOS
> 5. If NSIS needs to address item 4, it needs to change its charter. It is
a
> huge problem to solve. I am extremely worried that NSIS focus might have
> distorted due to unnecessarily mixing of items 1, 2, 3, and 4 while they
> Subject: AW: AW: [NSIS] Any resolution to the QSPEC mandatory parameter li
> st?
>
>
>
> Hi Roy,
>