Subject: [NSIS] Proposal to move the QSPEC work forward

From: Jukka MJ Manner <[email-masked]>
Date: Tue, 17 Oct 2006 17:49:03 +0300 (EEST)

Hi all,

If this QSPEC debate will not end soon with some kind of solution, in 
order to get at least some of the QSPEC work forward, I propose to

1. Make the QSPEC Template just define parameters and their encoding for 
   QoS Model designers to be used. Loose the QSPEC-1 vs. QSPEC-2 concept.

2. Move _all_ this interworking debate to another draft, which describes 
   how to achieve interworking between domains implementing different QoS 
   Models.

We need the QSPEC Template and the object encoding rules in order to get 
people design new QoS Models. This latter draft will probably be difficult 
to achieve, but at least we would get the spec out for people who are 
interested to design their own QoS Models.

Before the latter draft is done, all QoS Model documents would be 
Informational. Once the latter draft is done, QoS Model authors may update 
their spec based on the interworking rules, and seek to move their QoS 
Models to Standards Track.

Jukka

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

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 17 Oct 2006 17:02:17 +0200

Hi Jukka

This is a very good proposal!
I agree with it!

Best regards,
Georgios

> -----Original Message-----
> From: Jukka MJ Manner [mailto:[email-masked]] 
> Sent: dinsdag 17 oktober 2006 16:49
> To: [email-masked]
> Subject: [NSIS] Proposal to move the QSPEC work forward
> 
> 
> Hi all,
> 
> If this QSPEC debate will not end soon with some kind of 
> solution, in order to get at least some of the QSPEC work 
> forward, I propose to
> 
> We need the QSPEC Template and the object encoding rules in 
> order to get people design new QoS Models. This latter draft 
> will probably be difficult to achieve, but at least we would 
> get the spec out for people who are interested to design 
> their own QoS Models.
> 
> Before the latter draft is done, all QoS Model documents 
> would be Informational. Once the latter draft is done, QoS 
> Model authors may update their spec based on the interworking 
> rules, and seek to move their QoS Models to Standards Track.
> 
> Jukka
>

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 18 Oct 2006 07:34:05 +0200 (MEST)

Hi John

Do you agree with the proposal of Jukka?

Please see below!

Best Regards,
Georgios

---

From: "Robert Hancock" <[email-masked]>
Date: Wed, 18 Oct 2006 09:49:12 +0200

hi,

personally, i don't think this would be a good idea. without
a decision on the type-1/type-2 question, the qspec is a bag
of packet formats, and not much use in creating usable qos
models since it just sidesteps the interoperability questions.

(if the interoperability questions were easy and the packet
formats were hard, then the situation might be different. but
i don't see that deferring the interoperability discussion is
going to make that discussion any easier - it will just present
the illusion of progress.)

i still have yet to see anyone in this debate give any 
counter-argument to my assertion that the type-1/type-2
distinction is both useful and achievable for at least one
parameter(*), which makes me think that the problem is actually
not so hard as some people want to make it seem.

robert h.

(*) see http://www1.ietf.org/mail-archive/web/nsis/current/msg06908.html

> From: Georgios Karagiannis [mailto:[email-masked]] 
> Sent: 18 October 2006 07:34
> To: [email-masked]
> Cc: Jukka MJ Manner; [email-masked]
> Subject: Re: [NSIS] Proposal to move the QSPEC work forward
> 
> 
> 
> Hi John
> 
> solution, in 
> >We need the QSPEC Template and the object encoding rules in order to 
> >get people design new QoS Models. This latter draft will probably be 
> >difficult to achieve, but at least we would get the spec out 
> for people 
> >who are interested to design their own QoS Models.
> >
> >Informational. Once the latter draft is done, QoS Model authors may 
> >update their spec based on the interworking rules, and seek to move 
> >their QoS Models to Standards Track.
> >
> >Jukka
> >

---

From: Attila Báder (IJ/ETH) <[email-masked]>
Date: Wed, 18 Oct 2006 10:08:04 +0200

Hi All, 

I think when we prescribed the requirements for NSIS and for Qspec template to provide interoperabilty between QoS models and flexibility we made a mistake. They are somewhat contradictory. I tend to be convinced that , interoperabilty of QoS models is less important than flexibilty, especially from the point of view of deployment. So I also agree with Jukka's proposal.

Bets regards, Attila

>From: Robert Hancock [mailto:[email-masked]] 
>Sent: Wednesday, October 18, 2006 9:49 AM
>To: 'Georgios Karagiannis'; [email-masked]
>Cc: 'Jukka MJ Manner'; [email-masked]
>Subject: RE: [NSIS] Proposal to move the QSPEC work forward
>
>hi,
>
>personally, i don't think this would be a good idea. without a 
>decision on the type-1/type-2 question, the qspec is a bag of 
>packet formats, and not much use in creating usable qos models 
>since it just sidesteps the interoperability questions.
>
>going to make that discussion any easier - it will just 
>present the illusion of progress.)
>
>parameter(*), which makes me think that the problem is 
>actually not so hard as some people want to make it seem.
>
>robert h.
>
>(*) see 
>http://www1.ietf.org/mail-archive/web/nsis/current/msg06908.html
>
>order to

---

From: Jukka MJ Manner <[email-masked]>
Date: Wed, 18 Oct 2006 11:19:51 +0300 (EEST)

Hi Rob,

Having partipated and lately just reviewed the arguments for and against, 
I have not seen good examples and solutions that truly and clearly support 
the goal of interworking (except Georgios' comment about having only 
<bandwidth> as QSPES-1). We have seen many emails that point out that 
interworking through the QSPEC-1 concept is _not_achievable, at least not 
currently - the Internet is just too broad in how ISPs and countries 
allow IP packets to be handled.

Thus, my proposal was to make all QOSMs at this stage (just) 
Informational. And once we have some common understanding of how different 
technologies can interwork, we can write a document about it, bringing 
back the concept of QSPEC-1 vs. -2, and QOSM authors, if they want to have 
their solution on the standards track, will need to revise their QOSMs.

IMO, this interworking debate should go to the IAB. This is a larger 
question that a WG can handle. The result affects the fundamentals of the 
Internet.

Jukka

---

From: "Kappler, Cornelia" <[email-masked]>
Date: Wed, 18 Oct 2006 14:41:37 +0200

Hi Jukka, 

we've seen many emails _claiming_ that interworking through the qspec-1 concept is not achievable. I have not seen a solid argument. 

Cornelia 

> -----Ursprüngliche Nachricht-----
> Von: Jukka MJ Manner [mailto:[email-masked]] 
> Gesendet: Mittwoch, 18. Oktober 2006 10:20
> An: Robert Hancock
> Cc: [email-masked]
> Betreff: RE: [NSIS] Proposal to move the QSPEC work forward
> 
> 
> Hi Rob,
> 
> would be

---

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 18 Oct 2006 15:30:34 +0200

Cornelia,

if I get the QOSPEC draft right, then the QOSM IDs must define 
the "not strictly interpret" part of remapped QSPEC-1 
parameters. In the case of eg. priority one domain may support 
complete priority for a QOSM ID, while others don't at all 
and a third may support preemption partially. 
The QOSM ID would have to cover all possible cases of 
QSPEC-1 parameter ID mappings. That sound like a lot of time 
to be pushed into "what if" scenarios.

What I feel to be worrying is that a box is expected to 
touch parameters it doesn't care about. I know this behaviour
as a backward compatibility support mechanism (an there it 
is only used to indicate "don't understand"). Couldn't the 
box just indicate what it does support/understand?

I didn't read the draft completely, but if users with two 
different QOSM's, none of which supports preemption, try 
to set up a call between each other it will require 
QSPEC-1 interpretation.  Could you describe how they 
indicate "no preemption" and successfully set up the call?

Regards,

Rüdiger

|-----Original Message-----
|From: Kappler, Cornelia [mailto:[email-masked]]
|Sent: Wednesday, October 18, 2006 2:42 PM
|To: Jukka MJ Manner; Robert Hancock
|Cc: [email-masked]
|Subject: AW: [NSIS] Proposal to move the QSPEC work forward
|
|
|Hi Jukka, 
|
|we've seen many emails _claiming_ that interworking through 
|the qspec-1 concept is not achievable. I have not seen a solid 
|argument. 
|
|Cornelia 
|
|> -----Ursprüngliche Nachricht-----
|> Von: Jukka MJ Manner [mailto:[email-masked]] 
|> Gesendet: Mittwoch, 18. Oktober 2006 10:20
|> An: Robert Hancock
|> Cc: [email-masked]
|> Betreff: RE: [NSIS] Proposal to move the QSPEC work forward
|> 
|> 
|> Hi Rob,
|> 
|> Having partipated and lately just reviewed the arguments for 
|> and against, 
|> I have not seen good examples and solutions that truly and 
|> clearly support 
|> the goal of interworking (except Georgios' comment about having only 
|> <bandwidth> as QSPES-1). We have seen many emails that point 
|out that 
|> interworking through the QSPEC-1 concept is _not_achievable, 
|> at least not 
|> currently - the Internet is just too broad in how ISPs and countries 
|> allow IP packets to be handled.
|> 
|> Thus, my proposal was to make all QOSMs at this stage (just) 
|> Informational. And once we have some common understanding of 
|> how different 
|> technologies can interwork, we can write a document about it, 
|> bringing 
|> back the concept of QSPEC-1 vs. -2, and QOSM authors, if they 
|> want to have 
|> their solution on the standards track, will need to revise 
|> their QOSMs.
|> 
|> IMO, this interworking debate should go to the IAB. This is a larger 
|> question that a WG can handle. The result affects the 
|> fundamentals of the 
|> Internet.
|> 
|> Jukka
|> 
|> On Wed, 18 Oct 2006, Robert Hancock wrote:
|> 
|> > hi,
|> > 
|> > personally, i don't think this would be a good idea. without
|> > a decision on the type-1/type-2 question, the qspec is a bag
|> > of packet formats, and not much use in creating usable qos
|> > models since it just sidesteps the interoperability questions.
|> > 
|> > (if the interoperability questions were easy and the packet
|> > formats were hard, then the situation might be different. but
|> > i don't see that deferring the interoperability discussion is
|> > going to make that discussion any easier - it will just present
|> > the illusion of progress.)
|> > 
|> > i still have yet to see anyone in this debate give any 
|> > counter-argument to my assertion that the type-1/type-2
|> > distinction is both useful and achievable for at least one
|> > parameter(*), which makes me think that the problem is actually
|> > not so hard as some people want to make it seem.
|> > 
|> > robert h.
|> > 
|> > (*) see 
|> http://www1.ietf.org/mail-archive/web/nsis/current/msg06908.html
|> > 
|> > > -----Original Message-----
|> > > From: Georgios Karagiannis [mailto:[email-masked]] 
|> > > Sent: 18 October 2006 07:34
|> > > To: [email-masked]
|> > > Cc: Jukka MJ Manner; [email-masked]
|> > > Subject: Re: [NSIS] Proposal to move the QSPEC work forward
|> > > 
|> > > 
|> > > 
|> > > Hi John
|> > > 
|> > > Do you agree with the proposal of Jukka?
|> > > 
|> > > Please see below!
|> > > 
|> > > Best Regards,
|> > > Georgios
|> > > 
|> > > 
|> > > On 10/17/2006, "Jukka MJ Manner" <[email-masked]> wrote:
|> > > 
|> > > >
|> > > >Hi all,
|> > > >
|> > > >If this QSPEC debate will not end soon with some kind of 
|> > > solution, in 
|> > > >order to get at least some of the QSPEC work forward, I 
|> propose to
|> > > >
|> > > >1. Make the QSPEC Template just define parameters and their 
|> > > encoding for
|> > > >   QoS Model designers to be used. Loose the QSPEC-1 
|vs. QSPEC-2 
|> > > >concept.
|> > > >
|> > > >2. Move _all_ this interworking debate to another draft, 
|> > > which describes
|> > > >   how to achieve interworking between domains implementing 
|> > > different QoS
|> > > >   Models.
|> > > >
|> > > >
|> > > >We need the QSPEC Template and the object encoding rules 
|> in order to 
|> > > >get people design new QoS Models. This latter draft will 
|> probably be 
|> > > >difficult to achieve, but at least we would get the spec out 
|> > > for people 
|> > > >who are interested to design their own QoS Models.
|> > > >
|> > > >Before the latter draft is done, all QoS Model documents 
|> would be 
|> > > >Informational. Once the latter draft is done, QoS Model 
|> authors may 
|> > > >update their spec based on the interworking rules, and 
|> seek to move 
|> > > >their QoS Models to Standards Track.
|> > > >
|> > > >Jukka
|> > > >
|> > > >_______________________________________________
|> > > >nsis mailing list
|> > > >[email-masked]
|> > > >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
|> 
|
|_______________________________________________
|nsis mailing list
[email-masked]
|https://www1.ietf.org/mailman/listinfo/nsis
|

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Wed, 18 Oct 2006 09:11:29 -0500

> indicate "no preemption" and successfully set up the call?

I think you should read the draft and the email threads before coming
across again with the same questions, which will just generate the same
answers.  See for example the exchange with Janet Gunn yesterday, she
raised more or less the same questions:
http://www1.ietf.org/mail-archive/web/nsis/current/msg06933.html
and generated this answer:
http://www1.ietf.org/mail-archive/web/nsis/current/msg06935.html

There have also been numerous exchanges RE a QNE needing to interpret
parameters it 'doesn't care about'.  That point is also discussed
(again) in the above exchange.

The issue of querying QNE QOSM and capabilities was discussed, at
length, long ago and resolved with use of Q-flag, R-flag, etc.  Please
read the example in Appendix A, which illustrates these capabilities.

There has been a tremendous amount of repetition on this long discussion
and it would help if people confined themselves to shedding new light
(if any).

Hopefully the co-chairs will help us conclude this discussion sometime
soon.

Thanks,
Jerry

---

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 18 Oct 2006 17:08:59 +0200

Jerry,

thanks for the response,

after reading chapter 4 of the draft again I'd like 
to ask others whether they have trouble in understanding 
the following:

"A QOSM specification MUST include the following:

...

- QSPEC parameter behavior for remapping of existing QSPEC
  parameters, as described in Section 6.3.2.  Remapping may result
  in slight modification to the intended specification when strict
  interpretation is not possible." 

I now understand the above. Maybe "populated" or "present" or 
"applied" may be better than "existing". The sentence continues: 

                                "Unless otherwise specified in the
  QOSM specification document, the default QOSM behaviors for all
  QSPEC-1 parameters is to strictly interpret the QSPEC-1 parameters
  as defined in this document through the references that precisely
  define the QSPEC parameter behaviors."

May it be caused by my limited language or mental capabilities, but 
I don't get it by just reading. As I understood after our dialogue, 
the above says that those QSPEC-1 parameters which are populated due to 
a particular QOSM specification (and that may only be a subset of all 
QSPEC-1 parameters defined by your draft) must be remapped following 
the rules determined by your draft. The particular remapping behaviour
is determined by the specifcication of the QOSM executing the 
remapping. Is that right?

I don't ask for changes if I'm the only one who stumbled here.

That means that any QOSMa just signaling bandwidth is conformant 
to your draft. If this QOSMa interprets more complex QOSMb, it 
should tell QOSMb what it doesn't support, if the authors of 
QOSMa have specified that. The latter still worries 
me. But you too don't seem to assume that anybody will try to 
specify all possible interworkings when drafting a QOSM. The 
default behaviour without specified interworking may also
be "release" then (or a less stringent interpretation as 
demanded by your draft). Is that correct too?

Regards, 

Rudiger

|-----Original Message-----
|From: Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]]
|Sent: Wednesday, October 18, 2006 4:11 PM
|To: Geib, Rudiger
|Cc: Ash, Gerald R (Jerry), ALABS; [email-masked]
|Subject: RE: [NSIS] Proposal to move the QSPEC work forward
|
|
|> What I feel to be worrying is that a box is expected to 
|> touch parameters it doesn't care about. I know this behaviour
|> as a backward compatibility support mechanism (an there it 
|> is only used to indicate "don't understand"). Couldn't the 
|> box just indicate what it does support/understand?
|> 
|> I didn't read the draft completely, but if users with two 
|> different QOSM's, none of which supports preemption, try 
|> to set up a call between each other it will require 
|> QSPEC-1 interpretation.  Could you describe how they 
|> indicate "no preemption" and successfully set up the call?
|
|I think you should read the draft and the email threads before coming
|across again with the same questions, which will just generate the same
|answers.  See for example the exchange with Janet Gunn yesterday, she
|raised more or less the same questions:
|http://www1.ietf.org/mail-archive/web/nsis/current/msg06933.html
|and generated this answer:
|http://www1.ietf.org/mail-archive/web/nsis/current/msg06935.html
|
|There have also been numerous exchanges RE a QNE needing to interpret
|parameters it 'doesn't care about'.  That point is also discussed
|(again) in the above exchange.
|
|The issue of querying QNE QOSM and capabilities was discussed, at
|length, long ago and resolved with use of Q-flag, R-flag, etc.  Please
|read the example in Appendix A, which illustrates these capabilities.
|
|There has been a tremendous amount of repetition on this long 
|discussion
|and it would help if people confined themselves to shedding new light
|(if any).
|
|Hopefully the co-chairs will help us conclude this discussion sometime
|soon.
|
|Thanks,
|Jerry
|
|_______________________________________________
|nsis mailing list
[email-masked]
|https://www1.ietf.org/mailman/listinfo/nsis
|

---

From: Roland Bless <[email-masked]>
Date: Thu, 19 Oct 2006 11:03:06 +0200

Hi,

> models since it just sidesteps the interoperability questions.

What I understood from the beginning of the QSPEC _TEMPLATE_
draft was that it's just a template or as you say "a bag of
packet formats". Right in the beginning
of the WG we discussed that the WG will not standardize any
services or service models. Right now, I got the impression
that the template effort turned into an interworking effort
directly dealing with service models. I guess that's too much
for this WG and it would probably be the task of a separate
WG to figure all these interworking aspects out.

I'm not saying that we don't need such a thing at the end
of the day, because usually we need a common understanding
and support of a common service to allow for deployment of
end-to-end QoS solutions. But I guess that our task is currently
only to standardize a template. What parameter set should/must
be filled in order to get an end-to-end QoS support could be
figured out separately.

> the illusion of progress.)

You're right that deferring the interoperability discussion is
not going to make that discussion any easier, but it doesn't
mean that this WG is the right place to discuss it now.

> not so hard as some people want to make it seem.

Regards,
 Roland

---

From: David R Oran <[email-masked]>
Date: Thu, 19 Oct 2006 05:05:28 -0400

>> models since it just sidesteps the interoperability questions.
Templates are a way of institutionalizing non-interoperability. I  
agree with Robert that this is an admission of a major defeat.

Dave Oran.

---

From: Roland Bless <[email-masked]>
Date: Thu, 19 Oct 2006 11:32:06 +0200

Hi Dave,

David R Oran wrote:
> Templates are a way of institutionalizing non-interoperability. I agree
> with Robert that this is an admission of a major defeat.

A template without semantics is not very useful indeed,
but it would be a starting point to convey parameters
at all. However, I guess it would be probably easier
to rethink the QSPEC effort along your proposal which
would eliminate a lot of misunderstandings due to mapping
between different QoS models etc.

Especially what I strongly agree with is:
> The key is that they are *traffic source descriptions* and not related
> to any given "QoS model". I keep hammering on this
> systematics/taxonomy issue because I think have the taxonomy along the
> mandatory/optional axis is misleading and in many ways fundamentally
> un-useful, except to save transmitting stuff in messages.

Regards,
 Roland

---

From: <[email-masked]>
Date: Thu, 19 Oct 2006 14:29:31 +0300

Dave,

>>> decision on the type-1/type-2 question, the qspec is a bag of packet

>>> formats, and not much use in creating usable qos models since it
just 
>>> sidesteps the interoperability questions.
>>
>Templates are a way of institutionalizing 
>non-interoperability. I agree with Robert that this is an 
>admission of a major defeat.

I agree with you on this.  I am not sure that the IESG/IAB would
be very happy with us - what is the sense of doing this work if
we cannot hope for some level of interoperability.

John

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 19 Oct 2006 13:47:44 +0200

Hi John

What about starting with one mandatory parameter, i.e., Bandwidth!
Based on the discussions that we have had until now in the nsis mailing
list,
I think that we could have a consensus on having Bandwidth 
as the mandatory parameter that could be included in the 
QSPEC template draft.

If during the deployment phase we will need more 
parameters we could then start the interworking activity.

Best regards,
Georgios

> From: [email-masked] [mailto:[email-masked]] 
> Sent: donderdag 19 oktober 2006 13:30
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> non-interoperability. I agree 
> I agree with you on this.  I am not sure that the IESG/IAB 
> would be very happy with us - what is the sense of doing this 
> work if we cannot hope for some level of interoperability.
> 
> John
>

---

From: David R Oran <[email-masked]>
Date: Thu, 19 Oct 2006 08:02:06 -0400

> as the mandatory parameter that could be included in the
Here's my problem. Bandwidth is not a mathematically complete  
description of a traffic source. For example, It doesn't tell me over  
what time period this rate applies. It doesn't tell me how big the  
bursts are. Is it ok if I ask for 1mbps but generate 1Gigbit/second  
for 1 second and then shut up for 999 seconds? How can I do admission  
control without knowing the source process that generates the  
traffic, how elastic it is, etc. etc.

Here's a thought experiment. My source asks for 17*10**9 bits/second  
for New York to Shanghai. Now, what I have to do to provide this  
differs quite a bit depending on whether I have to carry the bits  
over a synchronous TDM (or slotted packet scheduled) infrastructure,  
or whether it is acceptable for me to gather these bits, write them  
to DVDROMs, load them into containers, stick them on a container  
ship, sail to Sahnghai, put the DVDROMs in to a player, and fire out  
the 17*10**9 bps to the destination? This is a fundamental constraint  
expression problem and has nothing to do with QoS models.

> parameters we could then start the interworking activity.
this is a nonstarter because I don't even know what it means to  
interwork on the basis of a traffic specification that only specifies  
bandwidth.

You need:
- average rate
- burst size
- peak rate
- minimum quantum (what RSVP TSPEC calls minimum policed unit)

for a complete description of a traffic source.

---

From: Roland Bless <[email-masked]>
Date: Thu, 19 Oct 2006 14:24:04 +0200

Hi Dave,

comments inline.

David R Oran wrote:
> bursts are. Is it ok if I ask for 1mbps but generate 1Gigbit/second for
> 1 second and then shut up for 999 seconds? How can I do admission
> control without knowing the source process that generates the traffic,
> how elastic it is, etc. etc.

I fully agree here, without a defined time period, it's pretty useless.

> for a complete description of a traffic source.

Yes. My guess is that this would be fine to perform
a simple form of admission control, so basically one
is able to control the load for *any* service
class. However, the complexity presumably lies in the contraints
parameter set c). For example whether you can meet the given
constraints or not depends in which PDB (cf. RFC3086)
you put this traffic. I could imagine to have a set of
profiles that each define a certain constraint parameter
set. QoS models then would need to define a mapping to their
own service/traffic classes in order to meet a certain
contraint profile (i.e. common service). To me it makes much
more sense to provide that basic set than having to support
any parameter set of several specific QoS models and having
to define a mapping from each QoS model to my own...

Regards,
 Roland

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 19 Oct 2006 15:01:00 +0200

Hi Dave

Okay but do you agree that we just need to have just one 
mandatory parameter that specifies the traffic description 
instead of having 13 mandatory parameters?

Best Regards,
Georgios

> From: David R Oran [mailto:[email-masked]] 
> Sent: donderdag 19 oktober 2006 14:02
> To: Georgios Karagiannis
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> > Based on the discussions that we have had until now in the nsis 
> > mailing list, I think that we could have a consensus on having 
> > Bandwidth as the mandatory parameter that could be included in the 
> > QSPEC template draft.
> >
> description of a traffic source. For example, It doesn't tell 
> me over what time period this rate applies. It doesn't tell 
> me how big the bursts are. Is it ok if I ask for 1mbps but 
> generate 1Gigbit/second for 1 second and then shut up for 999 
> seconds? How can I do admission control without knowing the 
> source process that generates the traffic, how elastic it is, 
> etc. etc.
> 
> Here's a thought experiment. My source asks for 17*10**9 
> bits/second for New York to Shanghai. Now, what I have to do 
> to provide this differs quite a bit depending on whether I 
> have to carry the bits over a synchronous TDM (or slotted 
> packet scheduled) infrastructure, or whether it is acceptable 
> for me to gather these bits, write them to DVDROMs, load them 
> into containers, stick them on a container ship, sail to 
> Sahnghai, put the DVDROMs in to a player, and fire out the 
> 17*10**9 bps to the destination? This is a fundamental 
> constraint expression problem and has nothing to do with QoS models.
> 
> > If during the deployment phase we will need more parameters 
> we could 
> > then start the interworking activity.
> >
> this is a nonstarter because I don't even know what it means 
> to interwork on the basis of a traffic specification that 
> only specifies bandwidth.
> 
> You need:
> - average rate
> - burst size
> - peak rate
> >> very happy with us - what is the sense of doing this work if we 
> >> cannot hope for some level of interoperability.
> >>
> >> John
> >>
>

---

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 19 Oct 2006 16:21:35 +0200

Dave,

in an environment where statistical multiplexing doesn't work, 
peak bandwidth and quantum would do, wouldn't it?

Regards,

Rudiger

|You need:
|- average rate
|- burst size
|- peak rate
|- minimum quantum (what RSVP TSPEC calls minimum policed unit)
|
|for a complete description of a traffic source.

---

From: David R Oran <[email-masked]>
Date: Thu, 19 Oct 2006 10:29:07 -0400

> peak bandwidth and quantum would do, wouldn't it?
In a packet based system you also need the minimum quantum since the  
scheduling isn't accurate to the bit level.
For CBR flows peak=average and burst=quantum. It is actually a  
feature that you can detect a CBR flow by the equality of these pairs  
of parameters in the traffic description. so it's in some sense there  
are some benefits to always including them.

If you have a VBR flow with short term bursts (which can exceed peak  
over small time scales) the burst size in the traffic description  
tells you how much burst buffering you have to set aside to avoid drops.

If you have enough statistical multiplexing gain and lightly loaded  
links, you can admit at the average bandwidth as long as the peak  
rate does not exceed the link capacity.

All this is basic QoS-101.

Dave Oran.

---

From: David R Oran <[email-masked]>
Date: Thu, 19 Oct 2006 11:15:29 -0400

On Oct 19, 2006, at 8:24 AM, Roland Bless wrote:

>>> mailing
> class.
Well if there are no constraints the problem is degenerate and you  
can admit anything :-)
That's why the traffic description is something fundamentally  
different from a QoS model or a service class.

> However, the complexity presumably lies in the contraints
> parameter set c).
Absolutely. This is the hard part. It's easy to define all kinds of  
constraint statements. What's hard is to design something which meets  
them. This is why it's in the user's interest to specify the minimum  
constraints that result in adequate goodput for his traffic, and if  
the traffic is elastic those constraints could in fact be quite  
loose. For inelastic plesio-isochronous traffic with non-trivial  
delay bounds, only deterministic TDM schedulers are likely to be able  
to meet the constraints. You get what you pay for. This notion of  
mapping among QoS models is frankly in my opinion an attempt to paper  
over hard problems, or cast them as interworking problems, or beat  
the devil, or look for a free lunch, depending on your metaphorical  
predilections.

> For example whether you can meet the given
> you put this traffic.
Yup. So something that NSIS has to carry is a directive for how to  
mark your traffic when admitted. It isn't clear if this is part of  
the QSPEC, any more than the flow classifiers are part of the QSPEC.

> I could imagine to have a set of
> set.
This is fine with me and if you want to call each set a "QoS Model" I  
won't object.

> QoS models then would need to define a mapping to their
> contraint profile (i.e. common service).
I'm not sure this constitutes a mapping so much as a closed state  
space over the parameter-value axes of the contsraints. But, this may  
be getting too mathematical than we need to be to convey the intent.

> To me it makes much
I agree 100% with this. If you as a user want interoperability AND  
high probability of admission control success, you should be very  
careful to not over-constrain your QoS request. If you as a network  
element implementer what to have a cost effective queueing/policing/ 
shaping network element, you had better choose a constraint set and  
value range that your silicon and software can do. If you are a  
network operator, you had better choose to deploy this stuff in a way  
that your resources are used cost effectively.

---

From: "Roy, Radhika R." <[email-masked]>
Date: Thu, 19 Oct 2006 12:51:03 -0400

Right!
 
RSVP spec is clear about these things.
 
BR/Radhika

________________________________

From: [email-masked] on behalf of David R Oran
Sent: Thu 10/19/2006 10:29 AM
To: Geib, Ruediger
Cc: [email-masked]
Subject: Re: [NSIS] Proposal to move the QSPEC work forward

Dave Oran.

---

From: "Geib, Ruediger" <[email-masked]>
Date: Mon, 30 Oct 2006 10:52:37 +0100

Dave,

My question was about admission control in environments 
where statistical multiplexing is not possible. 

|If you have a VBR flow with short term bursts (which can exceed peak  
|over small time scales) the burst size in the traffic description  
|tells you how much burst buffering you have to set aside to 
|avoid drops.

That means you must set aside a buffer space of number of 
VBR sources * burst size to avoid losses (assume purely VBR sources). 
Additionally you'd control the sum of the peak rates.

I so far expected the burst size to define the maximimum burst 
at a defined rate, not at an undefined one - so thanks for 
your explanation.

The 4 parameters proposed by you make sense then (assuming that most 
reservations pass also a network sections where multiplexing is 
applied).

Regards,

Rudiger

---

From: David R Oran <[email-masked]>
Date: Mon, 30 Oct 2006 07:12:05 -0500

> where statistical multiplexing is not possible.
OK.

> |over small time scales)
By definition, a "peak" rate is a rate you never exceed...did you  
mean "which can exceed average rate...over small time scales"

> the burst size in the traffic description
correct, but this is not directly related to the peak rate, it's  
related to the short-term packet generation process.

> VBR sources * burst size to avoid losses (assume purely VBR sources).
That is correct, and why most VBR sources I know about (like MPEG  
video) actually do "capped VBR" and don't burst - they still shape  
their output do a rate below the cap.

> Additionally you'd control the sum of the peak rates.
Right.

> at a defined rate, not at an undefined one - so thanks for
Correct.

> reservations pass also a network sections where multiplexing is
Glad we're converging here. My group actually has an implementation  
in the RSVP world that does more or less what you mention (for DOCSIS  
with UGS - unsolicited grant service - which is essentially TDM).

The difficult flows for an application to describe are highly elastic  
flows, and on-off flows, but that difficulty arises from the  
fundamentals of dealing with such kinds of traffic optimally.

Dave.

---

From: "Geib, Ruediger" <[email-masked]>
Date: Mon, 30 Oct 2006 13:47:42 +0100

Hi Dave,

ummm, I've quoted your first response to my mail below. When you 
are asking "did you mean", the addressed "you" is Dave Oran. 

D> |If you have a VBR flow with short term bursts (which can 
|> |exceed peak over small time scales)

D|By definition, a "peak" rate is a rate you never exceed...did you  
 |mean "which can exceed average rate...over small time scales"

So far I also thought that the peak rate is never exceeded. You 
puzzeled me with your first response. Thanks for clarification.

I then think that in an environment without multiplexing gains
admission control puerely based on peak rates is sufficient. 
The buffer should be dimensioned to avoid losses by random 
packet collisions.

[snip]

D|The difficult flows for an application to describe are highly elastic

 |flows, and on-off flows, but that difficulty arises from the  
 |fundamentals of dealing with such kinds of traffic optimally.

Admission Control for On-Off sources with a session context (RSVP, 
NSIS or any other) may be performed by peak rate reservation if 
multiplexing is impossible.
 
If difficult here means, that the "average rate" of a flow can't
be calculated for admission control in environments allowing 
multiplexing gains, because the average rate is unknown prior 
to the call, then measurement based admission control may 
offer a solution. An example may be a phone conversation with 
silence suppression. 

Regards,

Rudiger