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

From: "Roy, Radhika R." <[email-masked]>
Date: Mon, 31 Jul 2006 12:35:24 -0400

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

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

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

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 31 Jul 2006 21:34:03 +0200

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