Subject: [NSIS] Where we stand with the draft-ietf-nsis-qspec draft

From: <[email-masked]>
Date: Mon, 23 Oct 2006 09:59:26 +0300

Hi all,

We have had a very large thread on the current
draft-ietf-nsis-qspec-12.txt draft.
We don't have a clear consensus, so I'd like to try to summarize the
discussions.

Several people feel that the current draft contains too many mandatory
parameters
and mapping some QoS Models to others is mixing apples-to-oranges.  The
feeling
is that interoperability is hard to achieve and therefore we should not
try to 
gain interoperability.  Jukka Manner's message on 17th of October
proposed a way forward.
http://www1.ietf.org/mail-archive/web/nsis/current/msg06919.html

However, several (other) people feel that interoperability is imporant
and is
needed. Giving up on interoperability would not be a good thing, and
that we
are very close to a solution.  Dave Oran proposed a mechanism to reach a
solution
on the 19th October:
http://www1.ietf.org/mail-archive/web/nsis/current/msg06962.html

I have asked Jerry and Dave to make a proposal along the lines of Dave's
message
above, and the working group can review this, to see if we can gain
consensus on this.
I think it would be sufficient to send some rough text to the mailing
list, and if
this is OK, then we can revise the draft.

One open question to Dave/Jerry about the proposal is, in the event that
the
source cannot be described a mathematically complete way, is there any
value
(or does it make any sense at all) in sending an incomplete qspec, or
potentially 
"wildcarding" sending some of the manditory parameters.  I'm wondering
if some
sources / deployments may have certain parameters that are relatively
well defined,
but not all are so well defined.

thanks,
John

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

---

From: Jukka MJ Manner <[email-masked]>
Date: Mon, 23 Oct 2006 10:30:12 +0300 (EEST)

Hi John,

My proposal _did not_ seek to give up interoperability. Instead it 
proposed a way forward, where we separate the object encoding from 
interoperability rules. This would allow making more focused specs, i.e., 
we have one spec for only encoding rules, and one that defines 
how/when/where/why interoperability can be achieved.

If one wants to design his own private/internal QOSM, he can follow the 
former spec. Only, when a QOSM is meant for a wide range of use cases, the 
QOSM spec must also follow the latter spec.

Jukka

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 23 Oct 2006 09:44:29 +0200 (MEST)

Hi John

Another proposal for solving the inetroperability issue and the issue of
having too many parameters was to:
* use only one mandatory parameter, i.e., Token Bucket that could  be
remapped into the peak Bandwidth parameter.
Thus except the Token Bucket parameter,
* change the QSPEC-1 parameters into QSPEC-2 parameters
* describe the remapping procedure of the Token Bucket into the peak
Bandwidth parameter in the QSPEC template draft.

After that we can submit the QSPEC template draft for last WG call. If
after the deployment phase we conclude that more mandatory parameters
are needed for interoperability then we could work on an interworking
draft.

I think that there are many of us that would agree with such a proposal.

Best Regards,
Georgios

---

From: <[email-masked]>
Date: Mon, 23 Oct 2006 13:01:06 +0300

Hi Georgios,

>Another proposal for solving the inetroperability issue and 
>the issue of having too many parameters was to:
>* use only one mandatory parameter, i.e., Token Bucket that 
>could  be remapped into the peak Bandwidth parameter.
>* describe the remapping procedure of the Token Bucket into 
>the peak Bandwidth parameter in the QSPEC template draft.

This could be one, I think we could see what Jerry / Dave
propose and compare it with this proposal.

>After that we can submit the QSPEC template draft for last WG 
>call. If after the deployment phase we conclude that more 
>mandatory parameters are needed for interoperability then we 
>could work on an interworking draft.
>

Do others find this to be a potential solution?

John

---

From: <[email-masked]>
Date: Mon, 23 Oct 2006 13:03:31 +0300

Hi Jukka,

>My proposal _did not_ seek to give up interoperability. 
>Instead it proposed a way forward, where we separate the 
>object encoding from interoperability rules. This would allow 
>making more focused specs, i.e., we have one spec for only 
>encoding rules, and one that defines how/when/where/why 
>interoperability can be achieved.
>
>If one wants to design his own private/internal QOSM, he can 
>follow the former spec. Only, when a QOSM is meant for a wide 
>range of use cases, the QOSM spec must also follow the latter spec.

In theory, you could be correct - but I think the current set of
QoSMs are fairly "standard" so we would need to have the
interoperability
requirement for them met immediately.

John

---

From: Xiaoming Fu <[email-masked]>
Date: Mon, 23 Oct 2006 12:05:37 +0200

> Do others find this to be a potential solution?
Count me in.
Xiaoming

---

From: David R Oran <[email-masked]>
Date: Mon, 23 Oct 2006 08:25:14 -0400

> this is OK, then we can revise the draft.
I just got home Friday night from an around-the-world trip, and am  
unburiying. I'll try to sync up with Jerry by mid-week and see what  
we can jointly come up with. Since the I-D wondow is closed, we can  
just come up with a prposal that can be discussed at the WG meeting  
in SD, if that's ok.

> "wildcarding" sending some of the manditory parameters.
If the source can't be described, how can you provide QoS for it?

>   I'm wondering
Maybe something which generated quantum packets...

Seriously, just like on can always over-provision resources in order  
to be able to make QoS "guarantees", one can always either over- 
estimate or underestimate one's traffic source depending on whether  
you want the system to be optimistic or pessimistic when making its  
admission control decision and resource allocations.

---

From: <[email-masked]>
Date: Mon, 23 Oct 2006 16:50:24 +0300

Hi Roland,

Thanks for your reply, your comments seem sensible to me.

John 

>-----Original Message-----
>From: ext Roland Bless [mailto:[email-masked]] 
>Sent: 23 October, 2006 16:40
>To: Loughney John (Nokia-NRC/Helsinki)
>Cc: [email-masked]
>Subject: Re: [NSIS] Where we stand with the draft-ietf-nsis-qspec draft
>
>Hi John,
>
>> parameters and mapping some QoS Models to others is mixing 
>> apples-to-oranges.  The
>
>Yes. I agree with this.
>
>> feeling
>> is that interoperability is hard to achieve and therefore we should 
>> not try to gain interoperability.  Jukka Manner's message on 17th of 
>> October proposed a way forward.
>No, because there is a better alternative now...
>
>> and is needed. Giving up on interoperability would not be a good 
>> thing, and that we are very close to a solution.  Dave Oran 
>proposed a 
>> mechanism to reach a solution on the 19th October:
>Yep. I'd prefer too see a new proposal along this lines...
>
>> I have asked Jerry and Dave to make a proposal along the lines of 
>> Dave's message above, and the working group can review this, 
>to see if 
>> we can gain consensus on this.
>> list, and if this is OK, then we can revise the draft.
>
>Yep.
>
>> One open question to Dave/Jerry about the proposal is, in the event 
>> that the source cannot be described a mathematically 
>complete way, is 
>> there any value (or does it make any sense at all) in sending an 
>> incomplete qspec, or potentially "wildcarding" sending some of the 
>> manditory parameters.  I'm wondering if some sources / 
>deployments may 
>> have certain parameters that are relatively well defined, 
>but not all 
>> are so well defined.
>
>I find it confusing to have mandatory parameters that are 
>somehow optional to provide (omitting or wildcarding values...).
>IMHO, each QoS model could determine on its own which 
>(constraint) parameters are relevant to consider during 
>admission control.
>
>Regards,
> Roland
>
>

---

From: Roland Bless <[email-masked]>
Date: Mon, 23 Oct 2006 15:40:10 +0200

Hi John,

Yes. I agree with this.

Yep.

> but not all are so well defined.

I find it confusing to have mandatory parameters that
are somehow optional to provide (omitting or wildcarding values...).
IMHO, each QoS model could determine on its own
which (constraint) parameters are relevant to consider during
admission control.

Regards,
 Roland

---

From: Janet P Gunn <[email-masked]>
Date: Mon, 23 Oct 2006 10:44:33 -0400

I think Interoperability is important.

But I don't think that a longish list of "mandatory parameters" is the way
to get interoperability.

Janet

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit written
agreement or government initiative expressly permitting the use of e-mail
for such purpose.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

             <john.loughney@no                                             
             kia.com>                                                      
                                                                        To 
             10/23/2006 02:59          <[email-masked]>                     
             AM                                                         cc 
                                                                           
                                                                   Subject 
                                       [NSIS] Where we stand with the      
                                       draft-ietf-nsis-qspec draft         

                                                                           

Hi all,

thanks,
John

---

From: <[email-masked]>
Date: Thu, 26 Oct 2006 12:37:34 +0300

Hi Dave,

>> Dave's message above, and the working group can review this, to see
if 

>I just got home Friday night from an around-the-world trip, 
>and am unburiying. I'll try to sync up with Jerry by mid-week 
>and see what we can jointly come up with. Since the I-D wondow 
>is closed, we can just come up with a prposal that can be 
>discussed at the WG meeting in SD, if that's ok.

That is fine, but please send the proposal to the list before the
meeting.

>> that the source cannot be described a mathematically complete way, is

>> manditory parameters.
>>   I'm wondering if some

>> well defined, but not all are so well defined.
>>
>Seriously, just like on can always over-provision resources in 
>order to be able to make QoS "guarantees", one can always 
>either over- estimate or underestimate one's traffic source 
>depending on whether you want the system to be optimistic or 
>pessimistic when making its admission control decision and 
>resource allocations.

I think that could be a solution, how does the wg feel about this?From [email-masked] Thu Oct 26 05:38:24 2006
Content-class: urn:content-classes:message
Subject: RE: [NSIS] Where we stand with the draft-ietf-nsis-qspec draft
Date: Thu, 26 Oct 2006 12:37:34 +0300
From: <[email-masked]>
To: <[email-masked]>
Cc: [email-masked]

Hi Dave,

>> Dave's message above, and the working group can review this, to see
if 

>I just got home Friday night from an around-the-world trip, 
>and am unburiying. I'll try to sync up with Jerry by mid-week 
>and see what we can jointly come up with. Since the I-D wondow 
>is closed, we can just come up with a prposal that can be 
>discussed at the WG meeting in SD, if that's ok.

That is fine, but please send the proposal to the list before the
meeting.

>> that the source cannot be described a mathematically complete way, is

>> manditory parameters.
>>   I'm wondering if some

>> well defined, but not all are so well defined.
>>
>Seriously, just like on can always over-provision resources in 
>order to be able to make QoS "guarantees", one can always 
>either over- estimate or underestimate one's traffic source 
>depending on whether you want the system to be optimistic or 
>pessimistic when making its admission control decision and 
>resource allocations.

I think that could be a solution, how does the wg feel about this?

thanks,
John