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

From: Roland Bless <[email-masked]>
Date: Tue, 01 Aug 2006 14:24:39 +0200

Hi Hannes,

Hannes Tschofenig schrieb:
> 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.

Yep, but the usefulness of QoS depends IMHO on having
an inter-domain agreement on a common "service" so that one can request
at least for example a reservation of bandwidth from one end of the
Internet to the other. On the one hand I agree that we probably have
different QOSMs and so on (side note: the DiffServ WG did not specify
services, only building blocks in order to let ISPs define their own
services), but on the other hand if QoS is not deployed widely, its use
is very limited (it is similar with IPv6, ECN or multicast). Ok, we must
get started somewhere and it's even progress if you can request QoS at
least in one domain, but as I understood early charters of this WG, it
was also a goal to work towards an Internet-wide (inter-domain)
solution. So the QSPEC template is one contribution to achieve this.

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

Unfortunately, transitions that require infrastructural support and
changes tend to last much longer than one guesses...(cf. examples above)
:-(

Regards,
 Roland

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

-- 
Dr. Roland Bless -- WWW: http://www.tm.uka.de/~bless
Institut für Telematik, Universität Karlsruhe (TH), Germany
Zirkel 2, D-76128 Karlsruhe -- Geb. 20.20, 3.OG, Raum 358
Tel.: +49 721 608-6413 Fax: +49 721 608-6789

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 01 Aug 2006 14:45:54 +0200

Hi Roland,

I guess we agree about the current status of our work and the fact that 
the QSPEC template is very useful. No doubt that there is further work 
ahead of us as well.

I think as a short term goal we need to conclude the discussions 
regarding the set of mandatory parameters for the QSPEC template draft.
The QSPEC draft has already improved a lot with the last few versions 
and this issue seems to be the remaining one.

Ciao
Hannes