Subject: Re: [NSIS] RE: Comments on draft-ietf-nsis-qspec-13.txt

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 04 Jan 2007 13:15:17 +0100

Hi Georgios,

Georgios Karagiannis wrote:
> Hi John
>
> I mainly disagree with the following three points that were never
> discussed before:
>
> Point_1):Removed the QSPEC control information
> ---------------------------------------------------------------
> Jerry mentioned in a previous e-mail that this QSPEC control information
> concept is not removed but it is renamed to Traffic Handling Directives.
>
> If that is the case then Jerry will have to use the same definitions for
> the
> QSEPC control information as used in Section 5.3.1 of:
> http://www.watersprings.org/pub/id/draft-ietf-nsis-qspec-12.txt
>
> Thus my proposal is to change section 4.3.3 as given in v.13 of the QSEPC
> template draft and include the general concept of the QSPEC control
> information that was given in Section 5.3.1 of version 12 of the QSEPC
> template draft. Note that the name can be changed but the semantics
> should remain the same. Thus please chnage Section 4.3.3 as follows:
>
> FROM:
>
> 4.3.3 Traffic Handling Directives
>
>    The <Excess Treatment> parameter describes how the QNE will process
>    excess traffic, that is, out-of-profile traffic.  Excess traffic MAY
>    be dropped, shaped and/or remarked. The excess treatment parameter is
>    initially set by the QNI and cannot be overwritten.
>
>
> INTO:
>
> 4.3.3  Traffic Handling Directives
>
>    Traffic Handling Directives are used for signaling QOSM RMF functions
>    not defined in QoS NSLP.  It enables building new RMF functions
>    required by a QOSM within a QoS NSLP signaling framework, such as
>    specified, for example, in [RMD-QOSM] and [Y.1541-QOSM].
>
>    <QSPEC Control Information> = <Excess Treatment>
>
>    The <Excess Treatment> parameter describes how the QNE will process
>    excess traffic, that is, out-of-profile traffic.  Excess traffic MAY
>    be dropped, shaped and/or remarked. The excess treatment parameter is
>    initially set by the QNI and is read-only.
>
>   

Do you worry about a potential loss of extensibility here?

> -------------------------------
>
> Point_2: dictates that encpasulation of the original initiator QSEPC
> feature cannot be used in combination with the tunneling (parallel
> session) feature.
>
> In the discussion that we have had in the nsis mailing list and during
> the IETF meeting it was stated that both these features should be
> possible, while now version 13 of the QSPEC template draft dicates that
> these two feratures cannot be used togetherand at the same time by the
> same QoS model.
> As I mentioned in all the discussions the encapsulation of the original
> QSPEC feature is needed to satisfy Requirement:
> "5.4.2.  It SHOULD be Possible to Add and Remove Local Domain
> Information" given in: http://www.ietf.org/rfc/rfc3726.txt
> Therefore the encapsulation (of the original initiator QSEPC into a local
> QSPEC) feature should be seen as an independent feature and it should be
> able to be used in combination with the tunneling (parallel session)
> feature that is used for another goal.
>
> Thius my proposal is that it should be mentioned that even when the
> tunneling (parallel session) feature is used, it is also allowed to use,
> at the same time, the encapsulation (of the original initiator QSEPC
> into a local QSPEC) feature in order to satisfy Requirement 5.4.2 of RFC
> 3726.
>   

How would this, for example, impact RMD?

> ---------------------------
>
> Point_3: QSEPC template draft dictates which QOS-NSLP signaling features
> should be used by QOS models.
>
> We have never discussed an agreed that the QSPEC template draft defines
> how the QOS-NSLP functionality should be used by QoS models. This should
> be defined by the QOS-NSLP draft.
> Therefore, regarding this issue  the QSPEC template draft should refer to
> Section "3.1.2.  QoS Models and QoS Specifications"" of:
> http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-12.txt
>
> Therefore the QSPEC tempate draft should adpat the definitiojn of the QoS
> models according to what Section 3.1.2 of the QOS-NSLP draft is saying
> and refer to Section 3.1.2 of the QOS-NSLP draft.
>
>   

I guess this aspect refers to the previous discussion I had with Dave 
and with you subsequently.

When reading through Section 3.1.2 of 
http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-12.txt I am 
sure that the QoS NSLP authors are going to re-write the section.

Ciao
Hannes
> Best Regards,
> Georgios
>
>
>
>
>
>
>
> On 12/23/2006, "[email-masked]" <[email-masked]>
> wrote:
>
>   
>> Hi all,
>>
>> When Jerry posted the draft with the change log, I basically noted
>> that the changes were based upon previous discussions, on the
>> mailing list and the meeting.
>>
>> I am unsure of the techincal issues that are being raised.  Rather
>> than get into a discussion of what was discussed or not, what I
>> would like to understand better is more understanding what are
>> the technical issues behind Georgios' issues.
>>
>> Additionally, I would like to hear from others about their opinions
>> on this issue.
>>
>> thanks,
>> John
>>
>>     
>>> -----Original Message-----
>>> From: ext Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]]
>>> Sent: 22 December, 2006 20:12
>>> To: Georgios Karagiannis; [email-masked]
>>> Cc: Ash, Gerald R (Jerry), ALABS
>>> Subject: RE: [NSIS] RE: Comments on draft-ietf-nsis-qspec-13.txt
>>>
>>> Georgios,
>>>
>>> It's not true as you and 2 others have stated that the changes
>>> were not discussed.  They were discussed, at length.  For
>>> example, the revised definition of QOSM was clearly stated and
>>> discussed on the list, see
>>> http://www1.ietf.org/mail-archive/web/nsis/current/msg07084.htm
>>> l and also see all the list discussion following that post.
>>> The revised definition and all the other changes were clearly
>>> presented in the slides at IETF-67, see minutes and slides at
>>> http://www3.ietf.org/proceedings/06nov/index.html.  You can
>>> listen to the complete IETF-67 presentation/discussion again
>>> at
>>> http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf67/ietf
>>> 67ch4-thu
>>> -am.mp3.
>>>
>>> You can review the slides, meeting discussion, list
>>> discussion, meeting minutes, and verify that for yourself.
>>>
>>> So the editors did not 'make up the changes without
>>> discussion' as you and 2 others have suggested.  That is
>>> certainly wrong and I think you should acknowledge that.
>>>
>>> It is not useful going forward to debate the past, but
>>> incendiary wrong statements should not go unanswered.
>>>
>>> Once again, I've responded to your technical comments, you can
>>> comment further if you wish.
>>>
>>> It would be good for others to comment on the technical points.
>>>
>>> Jerry
>>>
>>> -----Original Message-----
>>> From: Georgios Karagiannis [mailto:[email-masked]]
>>> Sent: Friday, December 22, 2006 11:36 AM
>>> To: Ash, Gerald R (Jerry), ALABS; [email-masked]
>>> Subject: RE: [NSIS] RE: Comments on draft-ietf-nsis-qspec-13.txt
>>>
>>> Hi Jerry
>>>
>>> The changes that are included in version 13 of the QSEPC
>>> template draft regarding the QSPEC control information and the
>>> limitations of the QoS models have never been discussed
>>> because they were never stated clearly.
>>>
>>> If they would have been stated clearly then I would have sent
>>> my comments at that time instead of sending them now!
>>>
>>> Furthermore, from what I have seen in v. 13 of the draft you
>>> also have not solved the stacking issue, because you are
>>> actually dictating that encapsulation cannot be combined and
>>> used together with the tunneling (parallel sessions) method.
>>>
>>>
>>> Best Regards,
>>> Georgios
>>>
>>>       
>>>>
>>>>         
>>>>> -----Original Message-----
>>>>> From: Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]]
>>>>> Sent: vrijdag 22 december 2006 16:37
>>>>> To: Georgios Karagiannis; [email-masked]
>>>>> Cc: Ash, Gerald R (Jerry), ALABS
>>>>> Subject: RE: Comments on draft-ietf-nsis-qspec-13.txt
>>>>>
>>>>> Georgios,
>>>>>
>>>>>           
>>>>>> -----Original Message-----
>>>>>> From: Georgios Karagiannis [mailto:[email-masked]]
>>>>>> Sent: Friday, December 22, 2006 9:13 AM
>>>>>> To: Ash, Gerald R (Jerry), ALABS; [email-masked]
>>>>>> Subject: RE: Comments on draft-ietf-nsis-qspec-13.txt
>>>>>>
>>>>>> Hi Jerry
>>>>>>
>>>>>> By just saying that "these changes are suggested by Dave in the
>>>>>> e-mail" does not work.
>>>>>>
>>>>>> The proposal of Dave was not clear on the QoS model changes
>>>>>>             
>>>>> that you
>>>>>           
>>>>>> wanted to do.
>>>>>>             
>>>>> All changes to the draft have been extensively discussed on
>>>>>           
>>>> the list
>>>>         
>>>>> and are all contained in the slides presented at IETF-67.
>>>>>           
>>> You were
>>>       
>>>>> there at
>>>>> IETF-67 and participated in all the list discussion.  The
>>>>>           
>>>> summary of
>>>>         
>>>>> changes in the slides is quite specific and clear, take
>>>>>           
>>>> another look.
>>>>         
>>>>> Have a look at the minutes as well
>>>>> http://www3.ietf.org/proceedings/06nov/minutes/nsis.txt.  The only
>>>>> disagreements noted are with regard to stacking, which is an issue
>>>>> that we later resolved on the list.  Go back and check it out.
>>>>>
>>>>>           
>>>>>> Now I understand which changes you want to include in the QSPEC
>>>>>> template draft.
>>>>>> This is also the reason of disagreeing with you now and sending
>>>>>> comments to the nsis list.
>>>>>>             
>>>>> I responded to your further comments, see below.  Others are
>>>>> encouraged to comment as well.
>>>>>
>>>>> Jerry
>>>>>
>>>>>           
>>>>>> Furthermore, note that the QOS-NSLP draft defines which
>>>>>>             
>>>>> capabilities
>>>>>           
>>>>>> should be supported by the QoS models and not the QSPEC template
>>>>>> draft.
>>>>>>
>>>>>> Best Regards,
>>>>>> Georgios
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> -----Original Message-----
>>>>>>> From: Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]]
>>>>>>> Sent: vrijdag 22 december 2006 15:01
>>>>>>> To: Georgios Karagiannis; [email-masked]
>>>>>>> Cc: Ash, Gerald R (Jerry), ALABS
>>>>>>> Subject: RE: Comments on draft-ietf-nsis-qspec-13.txt
>>>>>>>
>>>>>>> Georgios,
>>>>>>>
>>>>>>> See below.
>>>>>>>
>>>>>>>               
>>>>>>>> -----Original Message-----
>>>>>>>> From: Georgios Karagiannis [mailto:[email-masked]]
>>>>>>>> Sent: Thursday, December 21, 2006 9:22 AM
>>>>>>>> To: Ash, Gerald R (Jerry), ALABS; [email-masked]
>>>>>>>> Cc: 'Attila Bader (IJ/ETH)'; 'Lars Westberg'
>>>>>>>> Subject: RE: Comments on draft-ietf-nsis-qspec-13.txt
>>>>>>>>
>>>>>>>> Hi Jerry
>>>>>>>>
>>>>>>>> Please see below! I have severe concerns about some changes
>>>>>>>>                 
>>>>>>> that have
>>>>>>>               
>>>>>>>> been done in the QSPEC template draft.
>>>>>>>>
>>>>>>>>                 
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]]
>>>>>>>>> Sent: woensdag 20 december 2006 14:20
>>>>>>>>> To: Georgios Karagiannis; [email-masked]
>>>>>>>>> Cc: Ash, Gerald R (Jerry), ALABS
>>>>>>>>> Subject: RE: Comments on draft-ietf-nsis-qspec-13.txt
>>>>>>>>>
>>>>>>>>> Hi Georgios,
>>>>>>>>>
>>>>>>>>> See below.
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Georgios Karagiannis
>>>>>>>>>>                     
>>> [mailto:[email-masked]]
>>>       
>>>>>>>>>> Sent: Wednesday, December 20, 2006 5:26 AM
>>>>>>>>>> To: Ash, Gerald R (Jerry), ALABS; [email-masked]
>>>>>>>>>> Subject: Comments on draft-ietf-nsis-qspec-13.txt
>>>>>>>>>>
>>>>>>>>>> Hi Jerry
>>>>>>>>>>
>>>>>>>>>> Here are my comments on draft-ietf-nsis-qspec-13.txt:
>>>>>>>>>>
>>>>>>>>>> Comment_1:
>>>>>>>>>> --------------
>>>>>>>>>> Please reinclude the concept of QSPEC control
>>>>>>>>>>                     
>>>>>>> information that was
>>>>>>>               
>>>>>>>>>> included in all previous versions of the QSPEC
>>>>>>>>>>                     
>>>>> template draft.
>>>>>           
>>>>>>>>>> In
>>>>>>>>>>
>>>>>>>>>>                     
>>>> http://www.watersprings.org/pub/id/draft-ietf-nsis-qspec-12.txt: this
>>>>         
>>>>>>>>>> concept was described in Section 5.1.
>>>>>>>>>>                     
>>>>>>>>> Please see previous email comment on QSPEC control
>>>>>>>>>                   
>>>>> information.
>>>>>           
>>>>>>>> Georgios:
>>>>>>>> In order to emphasize the need of having QSPEC control
>>>>>>>>                 
>>>>>> information
>>>>>>             
>>>>>>>> parameters  I  would however appreciate if the name of
>>>>>>>>                 
>>>>>>> Section 4.3.3
>>>>>>>               
>>>>>>>> is changed
>>>>>>>> From:
>>>>>>>> 4.3.3 Traffic Handling Directives
>>>>>>>> INTO:
>>>>>>>> 4.3.3 QSPEC control information
>>>>>>>>                 
>>>>>>> The updated QSPEC parameter terminology/semantics are as
>>>>>>>               
>>>>> suggested
>>>>>           
>>>>>>> by Dave Oran (see slides presented at IETF-67
>>>>>>> http://www3.ietf.org/proceedings/06nov/index.html).  I
>>>>>>>               
>>>> think the
>>>>         
>>>>>>> current terminology is more clear/descriptive of the QSPEC
>>>>>>> parameters so I don't favor going backwards to less clear
>>>>>>> terminology.  I was never clear on why we used the 'control
>>>>>>> information' terminology in the first place, e.g., I
>>>>>>>               
>>>> don't think
>>>>         
>>>>>>> it's a very good descriptor of the 'excess treatment'
>>>>>>>               
>>> parameter.
>>>       
>>>>>>> Perhaps Dave can comment on this point also when he
>>>>>>>               
>>>> gets a chance.
>>>>         
>>>>>>>>>> Comment_2:
>>>>>>>>>> -----------
>>>>>>>>>>
>>>>>>>>>> Section 6.1:
>>>>>>>>>> Please reintroduce the format that is required
>>>>>>>>>>                     
>>> in order to
>>>       
>>>>>>>>> specify the
>>>>>>>>>                   
>>>>>>>>>> QSPEC control information, see:
>>>>>>>>>> Section 7.1 of:
>>>>>>>>>>
>>>>>>>>>>                     
>>>>>> http://www.watersprings.org/pub/id/draft-ietf-nsis-qspec-12.txt
>>>>>>             
>>>>>>>>> Please see previous email comment on QSPEC control
>>>>>>>>>                   
>>>>> information.
>>>>>           
>>>>>>>> Georgios: If you rename section 4.3.3 to QSPEC control
>>>>>>>>                 
>>>>>> information
>>>>>>             
>>>>>>>> then I think that reformatting of section 6.1 is not needed.
>>>>>>>> Please add the proposed sentence by Dave (but change
>>>>>>>>                 
>>> the term
>>>       
>>>>>>>> "handling directives" to "QSPEC control Information"). I am
>>>>>>>>                 
>>>>>>> not sure
>>>>>>>               
>>>>>>>> where it is better to add this sentence, maybe in
>>>>>>>>                 
>>> Section 5.4.
>>>       
>>>>>>>> "QoSMs are free, subject to IANA registration and review
>>>>>>>>                 
>>>>>> rules, to
>>>>>>             
>>>>>>>> extend QSPECs by adding parameters of any of the kinds
>>>>>>>>                 
>>>>>> supported by
>>>>>>             
>>>>>>>> the standard QSPEC. This includes traffic description
>>>>>>>>                 
>>>>> parameters,
>>>>>           
>>>>>>>> constraint parameters and QSPEC control information.
>>>>>>>>                 
>>>>>> QoSMs are not
>>>>>>             
>>>>>>>> permitted, however, to reinterpret or redefine the
>>>>>>>>                 
>>>>> standard QSPEC
>>>>>           
>>>>>>>> parameters specified in this document"
>>>>>>>>                 
>>>>>>> Yes, the text suggested by Dave will be added.
>>>>>>>
>>>>>>>               
>>>>>>>>>> Comment_3:
>>>>>>>>>> ----------
>>>>>>>>>> Section 4.1 :QoS Models
>>>>>>>>>> The definition of the QoS model is not complete. An
>>>>>>>>>>                     
>>>>> important
>>>>>           
>>>>>>>>>> sentence that was used in the previous version of the
>>>>>>>>>>                     
>>>>>> draft is
>>>>>>             
>>>>>>>>>> removed.
>>>>>>>>>> Please add the following sentence to the definition
>>>>>>>>>>                     
>>>>>> of the QoS
>>>>>>             
>>>>>>>>>> Model
>>>>>>>>>> (QOSM):
>>>>>>>>>>
>>>>>>>>>> The same as described above have to be applied in
>>>>>>>>>>                     
>>>>>> this section.
>>>>>>             
>>>>>>>>>> After the following sentence:
>>>>>>>>>>
>>>>>>>>>> "A QOSM specification MAY include the following:"
>>>>>>>>>>
>>>>>>>>>> include the following bullet:
>>>>>>>>>> "- it specifies how to use QOS NSLP to signal for
>>>>>>>>>>                     
>>>> this QOSM"
>>>>         
>>>>>>>>> That sentence was removed in Dave's proposed QOSM
>>>>>>>>>                   
>>>>>>> re-definition, see
>>>>>>>               
>>>> http://www1.ietf.org/mail-archive/web/nsis/current/msg07084.ht
>>>>         
>>>>>>>>> ml.  It was unclear what that sentence meant, QoS-NSLP
>>>>>>>>>                   
>>>>>>> specifies how
>>>>>>>               
>>>>>>>>> to signal, not QOSM specifications, so the sentence
>>>>>>>>>                   
>>>>> was removed.
>>>>>           
>>>>>>>>> I believe the sentence was intended to mean that when
>>>>>>>>>                   
>>>>> QoS NSLP
>>>>>           
>>>>>>>>> allows various options to be selected, a QOSM should
>>>>>>>>>                   
>>>>> be able to
>>>>>           
>>>>>>>>> determine which option is used.  For that purpose the
>>>>>>>>>                   
>>>>> following
>>>>>           
>>>>>>>>> sentence was added in Section 4.1:
>>>>>>>>>
>>>>>>>>> "     A QOSM specification MAY include the following:
>>>>>>>>>      ...
>>>>>>>>>      - can state which QoS-NSLP options a QOSM wants to
>>>>>>>>>                   
>>>>>> use, when
>>>>>>             
>>>>>>>>>      several options are available for a QOSM (e.g.,
>>>>>>>>>                   
>>>>>>> local QSPEC to
>>>>>>>               
>>>>>>>>>      either be a) tunneled or b) encapsulate
>>>>>>>>>                   
>>>>> initiator QSPEC)."
>>>>>           
>>>>>>>>> Also, to avoid any misinterpretation that QOSMs are free
>>>>>>>>>                   
>>>>>>> to specify
>>>>>>>               
>>>>>>>>> additional constraints, state machines, protocol data,
>>>>>>>>>                   
>>>>>>> etc. for NSLP
>>>>>>>               
>>>>>>>>> beyond that which is specific in the QoS NSLP
>>>>>>>>>                   
>>>>>> specification, the
>>>>>>             
>>>>>>>>> following was added to Section 4.1:
>>>>>>>>>
>>>>>>>>> "  QOSMs affect the operation of the RMF in NSIS-capable
>>>>>>>>>                   
>>>>>>> nodes, the
>>>>>>>               
>>>>>>>>>    information carried in QSPEC objects, and may under some
>>>>>>>>>    circumstances (e.g. aggregation) cause a separate NSLP
>>>>>>>>>    session to be
>>>>>>>>>    instantiated by having the RMF as a QNI. QOSMs
>>>>>>>>>                   
>>>> all utilize
>>>>         
>>>>>>>>>    the common
>>>>>>>>>    data, state machines, and APIs of the underlying NSIS
>>>>>>>>>    protocols and
>>>>>>>>>    are not expected to re-define or extend these in
>>>>>>>>>                   
>>>> any way."
>>>>         
>>>>>>>> Georgios:
>>>>>>>> Regarding the sentence in Section 4.1:
>>>>>>>> "QOSMs all utilize
>>>>>>>> the common data, state machines, and APIs of the
>>>>>>>>                 
>>>>> underlying NSIS
>>>>>           
>>>>>>>> protocols and are not expected to re-define or extend
>>>>>>>>                 
>>>>>> these in any
>>>>>>             
>>>>>>>> way."
>>>>>>>>
>>>>>>>> This sentence restricts the possibility of QoS model to use
>>>>>>>>                 
>>>>>>> RMF states
>>>>>>>               
>>>>>>>> and data that are not been defined in neither
>>>>>>>>                 
>>>> QoS-NSLP or QSPEC.
>>>>         
>>>>>>>> This sentence should be removed.
>>>>>>>>                 
>>>>>>> I disagree.  The quoted text was introduced by Dave Oran
>>>>>>>               
>>>>> in addition
>>>>>           
>>>>>>> to removing the phrase implying that a QOSM could specify
>>>>>>>               
>>>>> signaling
>>>>>           
>>>>>>> protocol changes, and I agree with this.
>>>>>>> Any changes/extensions to the signaling protocol or state
>>>>>>>               
>>>>> machines
>>>>>           
>>>>>>> are within the scope of QoS-NSLP draft and not the QSPEC
>>>>>>>               
>>>>> draft or a
>>>>>           
>>>>>>> QOSM specification draft.  I think you have noted that
>>>>>>>               
>>>>> also in your
>>>>>           
>>>>>>> subsequent posting at
>>>>>>>
>>>>>>>               
>>>> http://www1.ietf.org/mail-archive/web/nsis/current/msg07352.html.
>>>>         
>>>>>>> If any extensions are required to the NSIS signaling
>>>>>>>               
>>>>> protocol as a
>>>>>           
>>>>>>> result of the 'severe change on QoS Model definition and
>>>>>>> capabilities'
>>>>>>> you have noted, those proposed changes/extensions should be
>>>>>>> addressed to the QoS NSLP draft IMO.
>>>>>>>
>>>>>>> Perhaps Dave can comment here also when he gets a chance.
>>>>>>>
>>>>>>>               
>>>>>>>>>> Comment_4:
>>>>>>>>>> -------------
>>>>>>>>>> Section 5.1 Local QSPEC definition and processing
>>>>>>>>>>
>>>>>>>>>> By reading this section it gives the impression
>>>>>>>>>>                     
>>>>> that the two
>>>>>           
>>>>>>>>>> methods
>>>>>>>>>> a) and b) cannot be used by the same QoS model.
>>>>>>>>>> Method a): translate the
>>>>>>>>>> initiator QSPEC into a local QSPEC and encapsulate the
>>>>>>>>>>                     
>>>>>>> initiator
>>>>>>>               
>>>>>>>>>> QSPEC in the RESERVE message Method b): b) tunnel the
>>>>>>>>>>                     
>>>>>> initiator
>>>>>>             
>>>>>>>>>> QSPEC through the local domain and reserve resources by
>>>>>>>>>>                     
>>>>>>> generating
>>>>>>>               
>>>>>>>>>> a new RESERVE message through the local domain
>>>>>>>>>>                     
>>>>> containing the
>>>>>           
>>>>>>>>>> local QSPEC.
>>>>>>>>>>
>>>>>>>>>> Note that according to the discussions that we have had
>>>>>>>>>>                     
>>>>>>> until now
>>>>>>>               
>>>>>>>>>> method a) should be able to be used in combination with
>>>>>>>>>>                     
>>>>>>> method b)
>>>>>>>               
>>>>>>>>>> by the same QoS model for the situation that the
>>>>>>>>>>                     
>>>>> local QSPEC
>>>>>           
>>>>>>>>>> encapsulates the initiator QSPEC in order to satisfy
>>>>>>>>>>                     
>>>>>>> requirement
>>>>>>>               
>>>>>>>>>> 5.4.2 that is specified in RFC 3726, see:
>>>>>>>>>> http://www.ietf.org/rfc/rfc3726.txt
>>>>>>>>>>
>>>>>>>>>> Please add the following sentence at the end of
>>>>>>>>>>                     
>>> the first
>>>       
>>>>>>>>>> paragraph of Section 5.1.
>>>>>>>>>> "Note that when method b) is used, the
>>>>>>>>>>                     
>>>> encapsulation of the
>>>>         
>>>>>>>>>> initiator QSPEC into a local QSPEC should also be
>>>>>>>>>>                     
>>>>>> possible when
>>>>>>             
>>>>>>>>>> the local QoS model needs to satisfy Requirement
>>>>>>>>>> 5.4.2 specified in RFC 3726, by adding and
>>>>>>>>>>                     
>>> removing local
>>>       
>>>>>>>>>> QOSM-specific Control Information parameters on
>>>>>>>>>>                     
>>>> top of the
>>>>         
>>>>>>>>>> initiator QSPEC."
>>>>>>>>>>                     
>>>>>>>>> Your comment here is not clear to me.  It would help to
>>>>>>>>>                   
>>>>>>> provide an
>>>>>>>               
>>>>>>>>> example to illustrate what you are trying to accomplish.
>>>>>>>>>                   
>>>>>>> It seems
>>>>>>>               
>>>>>>>>> that you are trying to specify QoS-NSLP functionality,
>>>>>>>>>                   
>>>>>>> rather than
>>>>>>>               
>>>>>>>>> QSPEC functionality.  If so, that functionality should be
>>>>>>>>>                   
>>>>>>> specified
>>>>>>>               
>>>>>>>>> in the QoS-NSLP draft rather than the QSPEC draft,
>>>>>>>>>                   
>>>>> perhaps the
>>>>>           
>>>>>>>>> QoS-NSLP authors can comment.
>>>>>>>>>                   
>>>>>>>> Georgios:
>>>>>>>> No I am not trying to define QOS-NSLP functionality.
>>>>>>>> This is related to QSPEC control information that has to be
>>>>>>>>                 
>>>>>>> carried by
>>>>>>>               
>>>>>>>> end-to-end messages.
>>>>>>>> What I am trying to say is that all the discussion that
>>>>>>>>                 
>>>>>> we have had
>>>>>>             
>>>>>>>> regarding the encapsulation of the QSPEC object were
>>>>>>>>                 
>>>>>>> associated with
>>>>>>>               
>>>>>>>> requirement 5.4.2 of RFC 3726, see below:
>>>>>>>>
>>>>>>>> -----------------
>>>>>>>> "5.4.2.  It SHOULD be Possible to Add and Remove
>>>>>>>>                 
>>> Local Domain
>>>       
>>>>>>>> Information
>>>>>>>>
>>>>>>>>    It SHOULD be possible to add and remove local
>>>>>>>>                 
>>>> scope elements.
>>>>         
>>>>>>>>    Compared to Requirement 5.3.5 this requirement does use
>>>>>>>>                 
>>>>>>> the normal
>>>>>>>               
>>>>>>>>    signaling process and message exchange for
>>>>>>>>                 
>>>> transporting local
>>>>         
>>>>>>>>    information.  For example, at the entrance to a
>>>>>>>>                 
>>>>> domain, domain-
>>>>>           
>>>>>>>>    specific information is added information is added, which
>>>>>>>>    is used in
>>>>>>>>    this domain only, and the information is removed
>>>>>>>>                 
>>>> again when a
>>>>         
>>>>>>>>    signaling message leaves the domain.  The motivation
>>>>>>>>                 
>>>>> is in the
>>>>>           
>>>>>>>>    economy of re-using the protocol for domain internal
>>>>>>>>                 
>>>>>> signaling of
>>>>>>             
>>>>>>>>    various information pieces.  Where additional
>>>>>>>>                 
>>>>>>> information is needed
>>>>>>>               
>>>>>>>>    within a particular domain, it should be possible to
>>>>>>>>                 
>>>>>>> carry this at
>>>>>>>               
>>>>>>>>    the same time as the end-to-end information.",
>>>>>>>>                 
>>>> from RFC 3726
>>>>         
>>>>>>>> ------------------
>>>>>>>> Thus what I am saying is:
>>>>>>>> Please add the following sentence at the end of the first
>>>>>>>>                 
>>>>>>> paragraph of
>>>>>>>               
>>>>>>>> Section 5.1.
>>>>>>>>
>>>>>>>> "Note that when method b) is used, the encapsulation of the
>>>>>>>>                 
>>>>>>> initiator
>>>>>>>               
>>>>>>>> QSPEC into a local QSPEC should also be possible when the
>>>>>>>>                 
>>>>>> local QoS
>>>>>>             
>>>>>>>> model needs to satisfy Requirement
>>>>>>>> 5.4.2 specified in RFC 3726, by adding and removing local
>>>>>>>> QOSM-specific Control Information parameters on top of the
>>>>>>>>                 
>>>>>>> initiator
>>>>>>>               
>>>>>>>> QSPEC."
>>>>>>>>                 
>>>>>>> First, the suggested text isn't clear.  If method b) is used
>>>>>>> (tunneling) then presumably method a) is not also used at
>>>>>>>               
>>>>> the same
>>>>>           
>>>>>>> time.  However, the phrasing of the above makes it
>>>>>>>               
>>>> sound that way.
>>>>         
>>>>>>> Second, an example would help here.  I presume you are
>>>>>>>               
>>>> referring
>>>>         
>>>>>>> e.g., to RMD adding 'control information' (i.e., 'handling
>>>>>>> directive') parameters to the local QSPEC that are not
>>>>>>>               
>>>>> included in
>>>>>           
>>>>>>> the initiator QSPEC.  I think the requirement would be
>>>>>>>               
>>>>> that the RMD
>>>>>           
>>>>>>> QOSM provides a local QSPEC that is consistent with the
>>>>>>>               
>>>> initiator
>>>>         
>>>>>>> QSPEC, as we agreed on the list (see also slide 8 of
>>>>>>>               
>>>> the IETF-67
>>>>         
>>>>>>> presentation).
>>>>>>>
>>>>>>> If the local QSPEC introduces functionality
>>>>>>>               
>>>> inconsistent with the
>>>>         
>>>>>>> initiator QSPEC by appending the handling directive
>>>>>>>               
>>>>> parameters, then
>>>>>           
>>>>>>> it is not allowed.
>>>>>>>
>>>>>>>               
>>>>>>>>>> Comment_5:
>>>>>>>>>> -----------
>>>>>>>>>> Section 5.1, last paragraph:
>>>>>>>>>>
>>>>>>>>>> Please change the following:
>>>>>>>>>> "For example, RMD can define a local QSPEC that
>>>>>>>>>>                     
>>>>>> contains TMOD =
>>>>>>             
>>>>>>>>>> bandwidth (sets r=p, b/m to large)."
>>>>>>>>>>
>>>>>>>>>> Into:
>>>>>>>>>> "For example, in RMD the TMOD parameters contained in
>>>>>>>>>>                     
>>>>>>> the original
>>>>>>>               
>>>>>>>>>> initiator QSPEC are mapped into the equivalent TMOD
>>>>>>>>>>                     
>>>>> parameter
>>>>>           
>>>>>>>>>> representing only the peak bandwidth in the local QSPEC."
>>>>>>>>>>                     
>>>>>>>>> OK with me.
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>>> Comment_6:
>>>>>>>>>> -------------
>>>>>>>>>> In Section 5.3.1, 5.3.2, 5.3.3 the rules that have to
>>>>>>>>>>                     
>>>>>>> be followed
>>>>>>>               
>>>>>>>>>> regarding the QSPEC control information are not given:
>>>>>>>>>>
>>>>>>>>>> Please include the following paragraph at the end of
>>>>>>>>>>                     
>>>>>>> this section:
>>>>>>>               
>>>>>>>>>> "Regarding QSPEC Control Information, the default rule
>>>>>>>>>>                     
>>>>>>> is that all
>>>>>>>               
>>>>>>>>>>    QSPEC parameters that have been included in
>>>>>>>>>>                     
>>>> the RESERVE
>>>>         
>>>>>>>>>>    message by
>>>>>>>>>>    the QNI are also included in the RESPONSE
>>>>>>>>>>                     
>>>> message by the
>>>>         
>>>>>>>>>>    QNR with the
>>>>>>>>>>    value they had when arriving at the QNR.  When
>>>>>>>>>>                     
>>>>>>> traveling in the
>>>>>>>               
>>>>>>>>>>    RESPONSE message, all QSPEC Control Information
>>>>>>>>>>                     
>>>>>>> parameters are
>>>>>>>               
>>>>>>>>>>    read-only.  Note that a QOSM specification may
>>>>>>>>>>                     
>>>>>> define its own
>>>>>>             
>>>>>>>>>>    QOSM-specific Control Information parameters and
>>>>>>>>>>    processing rules."
>>>>>>>>>>                     
>>>>>>>>> Please see previous email comment on QSPEC control
>>>>>>>>>                   
>>>>> information.
>>>>>           
>>>>>>>> Georgios: I think that a description of how the
>>>>>>>>                 
>>> QSPEC control
>>>       
>>>>>>>> information is handled is needed.
>>>>>>>>                 
>>>>>>> Please see above comments on 'control information' terminology.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Jerry
>>>>>>>
>>>>>>>               
>>>>>>>>>> Comment_7:
>>>>>>>>>> ------------
>>>>>>>>>> Section 6.1:
>>>>>>>>>> I do not understand the second sentence from the
>>>>>>>>>>                     
>>> below two
>>>       
>>>>>>>>>> sentences:
>>>>>>>>>> "N Flag: Not-supported QSPEC parameter flag (see
>>>>>>>>>>                     
>>>>>> Section 5.2.2).
>>>>>>             
>>>>>>>>>>            For QSPEC parameters the value of this flag
>>>>>>>>>>                     
>>>>>>> is always
>>>>>>>               
>>>>>>>>>> zero."
>>>>>>>>>>                     
>>>>>>>>> Good catch, this is a typo, the sentence should be removed.
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>> Best Regards,
>>>>>>>> Georgios
>>>>>>>>
>>>>>>>>                 
>>>>>>
>>>>>>             
>>>>
>>>> _______________________________________________
>>>> 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: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 4 Jan 2007 14:13:40 +0100

Hi Hannes

Please see in line!

> From: Hannes Tschofenig [mailto:[email-masked]] 
> Sent: donderdag 4 januari 2007 13:15
> To: Georgios Karagiannis
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [NSIS] RE: Comments on draft-ietf-nsis-qspec-13.txt
> 
> Hi Georgios,
> 
> > Jerry mentioned in a previous e-mail that this QSPEC control 
> > information concept is not removed but it is renamed to 
> Traffic Handling Directives.
> >
> > If that is the case then Jerry will have to use the same 
> definitions 
> > for the QSEPC control information as used in Section 5.3.1 of:
> > Thus my proposal is to change section 4.3.3 as given in v.13 of the 
> > QSEPC template draft and include the general concept of the QSPEC 
> > control information that was given in Section 5.3.1 of 
> version 12 of 
> > the QSEPC template draft. Note that the name can be changed but the 
> > semantics should remain the same. Thus please chnage 
> Section 4.3.3 as follows:
> >
> > FROM:
> >

Georgios: yes I am very much worried about extensibility and flexibility.

> > possible, while now version 13 of the QSPEC template draft dicates 
> > that these two feratures cannot be used togetherand at the 
> same time 
> > by the same QoS model.
> > As I mentioned in all the discussions the encapsulation of the 
> > original QSPEC feature is needed to satisfy Requirement:
> > QSPEC) feature should be seen as an independent feature and 
> it should 
> > be able to be used in combination with the tunneling (parallel 
> > session) feature that is used for another goal.
> >
> > tunneling (parallel session) feature is used, it is also allowed to 
> > use, at the same time, the encapsulation (of the original initiator 
> > QSEPC into a local QSPEC) feature in order to satisfy Requirement 
> > 5.4.2 of RFC 3726.
> >   
> 

Georgios: For RMD-QOSM this will mean that for each local refresh RESERVE 
message an additional RESPONSE message will have to be generated.

> > Point_3: QSEPC template draft dictates which QOS-NSLP signaling 
> > features should be used by QOS models.
> >
> > We have never discussed an agreed that the QSPEC template draft 
> > defines how the QOS-NSLP functionality should be used by 
> QoS models. 
> > This should be defined by the QOS-NSLP draft.
> > Therefore, regarding this issue  the QSPEC template draft 
> should refer 
> > to Section "3.1.2.  QoS Models and QoS Specifications"" of:
> > Therefore the QSPEC tempate draft should adpat the 
> definitiojn of the 
> > QoS models according to what Section 3.1.2 of the QOS-NSLP draft is 
> > saying and refer to Section 3.1.2 of the QOS-NSLP draft.
> >
> >   
> 
> I guess this aspect refers to the previous discussion I had 
> with Dave and with you subsequently.

Georgios:
If the the folowing paragraph 
is added to the proposed QoS model capability list 
it will satisfy my concerns:
"The definition of a QoS model may also have implications on how local
   behavior should be implemented in the areas where the QoS NSLP gives
   freedom to implementers. For example, it may be useful to identify
   recommended behavior for how a RESERVE message that is forwarded
   relates to that received, or when additional signaling sessions
   should be started based on existing sessions, such as required for
   aggregate reservations. In some cases, suggestions may be made on
   whether state that may optionally be retained should be held in
   particular scenarios.  A QoS model may specify reservation
   preemption, e.g., an incoming resource request may cause removal of
   an earlier reservation."

Best regards,
Georgios
> http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-1
2.txt I am sure that the QoS NSLP authors are going to re-write > the
section.
> >> that the changes were based upon previous discussions, on 
> the mailing 
> >> list and the meeting.
> >>
> >> than get into a discussion of what was discussed or not, 
> what I would 
> >> like to understand better is more understanding what are the 
> >> technical issues behind Georgios' issues.
> >>
> >>> It's not true as you and 2 others have stated that the 
> changes were 
> >>> not discussed.  They were discussed, at length.  For example, the 
> >>> revised definition of QOSM was clearly stated and 
> discussed on the 
> >>> list, see 
> >>> http://www3.ietf.org/proceedings/06nov/index.html.  You 
> can listen 
> >>> to the complete IETF-67 presentation/discussion again at 
> >>> You can review the slides, meeting discussion, list discussion, 
> >>> meeting minutes, and verify that for yourself.
> >>>
> discussion' as 
> >>> you and 2 others have suggested.  That is certainly wrong and I 
> >>> think you should acknowledge that.
> >>>
> >>> It is not useful going forward to debate the past, but incendiary 
> >>> wrong statements should not go unanswered.
> >>>
> >>> The changes that are included in version 13 of the QSEPC template 
> >>> draft regarding the QSPEC control information and the 
> limitations of 
> >>> the QoS models have never been discussed because they were never 
> >>> stated clearly.
> >>>
> >>> If they would have been stated clearly then I would have sent my 
> >>> comments at that time instead of sending them now!
> >>>
> >>> Furthermore, from what I have seen in v. 13 of the draft you also 
> >>> have not solved the stacking issue, because you are actually 
> >>> dictating that encapsulation cannot be combined and used together 
> >>> with the tunneling (parallel sessions) method.
> >>>
> >>>
> >>> Best Regards,
> >>> Georgios
> >>>
> >>>       
> >>>>
> >>>>

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Thu, 4 Jan 2007 14:48:53 +0100

Hi Georgios, 

> -----Ursprüngliche Nachricht-----
> Von: Georgios Karagiannis [mailto:[email-masked]] 
> Gesendet: Donnerstag, 4. Januar 2007 14:14
> An: 'Hannes Tschofenig'
> Betreff: RE: [NSIS] RE: Comments on draft-ietf-nsis-qspec-13.txt
> 
> Hi Hannes
> 
> Please see in line!
>  
> 

Would you like the QSPEC draft to indicate how to extend the Traffic Handling Directives? 

Would there be an implication based on the current QSPEC draft for the RMD document (as an example)?

> > > Therefore the encapsulation (of the original initiator 
> QSEPC into a 
> > > local

As an example, the exchange in Figure 3 of http://www.ietf.org/internet-drafts/draft-ietf-nsis-rmd-08.txt would change from:

              QNE             QNE             QNE            QNE
            Ingress         Interior        Interior        Egress
        NTLP stateful  NTLP stateless  NTLP stateless  NTLP stateful
               |               |               |              |
       RESERVE |               |               |              |
      -------->| RESERVE       |               |              |
               +--------------------------------------------->|
               | RESERVE'      |               |              |
               +-------------->|               |              |
               |               | RESERVE'      |              |
               |               +-------------->|              |
               |               |               | RESERVE'     |
               |               |               +------------->|
               |               |               |              | RESERVE
               |               |               |              +------->
               |               |               |              |RESPONSE
               |               |               |              |<-------
               |               |               |     RESPONSE |
               |<---------------------------------------------+
       RESPONSE|               |               |              |
      <--------|               |               |              |
   
   Figure 3: Sender-initiated reservation with Reduced State Interior
             Nodes

To 

              QNE             QNE             QNE            QNE
            Ingress         Interior        Interior        Egress
        NTLP stateful  NTLP stateless  NTLP stateless  NTLP stateful
               |               |               |              |
       RESERVE |               |               |              |
      -------->| RESERVE       |               |              |
               +--------------------------------------------->|
               | RESERVE'      |               |              |
               +-------------->|               |              |
               |               | RESERVE'      |              |
               |               +-------------->|              |
               |               |               | RESERVE'     |
               |               |               +------------->|
               |               |               |              | RESERVE
               |               |               |              +------->
               |               |               |              |RESPONSE
               |               |               |              |<-------
               |               |               |     RESPONSE'|
               |<---------------------------------------------+
               |               |               |     RESPONSE |
               |<---------------------------------------------+
       RESPONSE|               |               |              |
      <--------|               |               |              |
   
   Figure 3: Sender-initiated reservation with Reduced State Interior
             Nodes

Correct?

>    preemption, e.g., an incoming resource request may cause removal of

I wonder what the impact for the RMD draft are based on the fact that it supports all signaling modes already. When I read it last time I thought it described how RMD works in case of e2e sender-initiated and e2e receiver-initiated reservation.

Ciao
Hannes

> incendiary

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 4 Jan 2007 15:04:41 +0100

Hi Hannes

Please see in line! 

> From: Tschofenig, Hannes [mailto:[email-masked]] 
> Sent: donderdag 4 januari 2007 14:49
> To: Georgios Karagiannis; Hannes Tschofenig
> Subject: AW: [NSIS] RE: Comments on draft-ietf-nsis-qspec-13.txt
> 
> Hi Georgios, 
>  
> 
> Would there be an implication based on the current QSPEC 
> draft for the RMD document (as an example)?

Georgios: The RMD-QOSM uses many QSPEC spcific control information
parameters 
that are different and have to be processed differently 
than the <Excess treatment> parameter. It should be possible to define and
use 
such parameters.

> > Georgios: For RMD-QOSM this will mean that for each local refresh 
> > RESERVE message an additional RESPONSE message will have to be 
> > generated.
> 
> 
> 
> As an example, the exchange in Figure 3 of 
> http://www.ietf.org/internet-drafts/draft-ietf-nsis-rmd-08.txt
>  would change from:
> 
> 
>               QNE             QNE             QNE            QNE
>                |               |               |              
> | RESERVE
>                |               |               |              
> +------->
>                |               |               |              
> |RESPONSE
>                |               |               |              
> |<-------
>                |               |               |              
> | RESERVE
>                |               |               |              
> +------->
>                |               |               |              
> |RESPONSE
>                |               |               |              
> |<-------
Georgios: Yes it is correct, but I have to mention that I have made a
mistake 
in the argumentation given above. (Note that this function 
is related to 
the initiation message and not the refresh message:
Georgios: For RMD-QOSM this will mean that for each local initiator 
RESERVE message an additional RESPONSE message will have to be generated.

> > > I guess this aspect refers to the previous discussion I had with 
> > > Dave and with you subsequently.
> > 
> > Georgios:
> > is added to the proposed QoS model capability list it will 
> satisfy my 
> > concerns:
> I wonder what the impact for the RMD draft are based on the 
> fact that it supports all signaling modes already. When I 
> read it last time I thought it described how RMD works in 
> case of e2e sender-initiated and e2e receiver-initiated reservation.

Georgios: RMD-QOSM uses signaling modes, such as 
severe congestion handling and others.

Best regards,
Georgios

> discussion,

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Thu, 4 Jan 2007 15:25:36 +0100

Hi Georgios, 
Hi QSPEC authors, 

I guess we are getting closer to the core issues and we need input from
the QSPEC authors. 

~snip~
> than the <Excess treatment> parameter. It should be possible 

Question to the QSPEC authors: What should happen with these control
parameters in a QoSM like RMD? 

[[Minor question: Wouldn't the NSIS PCN QoSM also require additional
signaling exchanges? ]]

~snip~

> RESERVE message an additional RESPONSE message will have to 

If this additional message is only relevant for the initial setup then
the impact shouldn't be large? Right? 

~snip~

> severe congestion handling and others.

Question to the QSPEC authors: What would happen to these types of
signaling exchanges? 

Ciao
Hannes

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 4 Jan 2007 15:33:19 +0100

Hi Hannes
 
Please see in line!

> Sent: donderdag 4 januari 2007 15:26
> I guess we are getting closer to the core issues and we need 
> input from the QSPEC authors. 
> 
> ~snip~
> > parameters that are different and have to be processed differently 
> > than the <Excess treatment> parameter. It should be 
> possible to define 
> > and use such parameters.
> 
> 
> Question to the QSPEC authors: What should happen with these 
> control parameters in a QoSM like RMD? 
> 
> [[Minor question: Wouldn't the NSIS PCN QoSM also require 
> additional signaling exchanges? ]]
Georgios: Yes I think so!
> > mistake in the argumentation given above. (Note that this 
> function is 
> > related to the initiation message and not the refresh message:
> If this additional message is only relevant for the initial 
> setup then the impact shouldn't be large? Right? 

Georgios: Yes you are right, but when this feature is used 
it will severely increase the performance of NSIS when such solutions are
applied 
in very highly utilised networks!
 
> ~snip~
> 
> > Georgios: RMD-QOSM uses signaling modes, such as severe congestion 
> > handling and others.
> 
> 
> Question to the QSPEC authors: What would happen to these 
> types of signaling exchanges? 
Georgios: Note that such signaling modes will also be required by the NSIS
PCN QoSM!

Best Regards,
Georgios

---

From: Attila Báder (IJ/ETH) <[email-masked]>
Date: Thu, 4 Jan 2007 15:43:30 +0100

Hi All, 

I do not think that the three points Georgios has raised would be unresolvable issues. See below, 

Best regards, Attila

>Sent: Thursday, January 04, 2007 3:26 PM
>> than the <Excess treatment> parameter. It should be possible 
>to define 
>> and use such parameters.
>
>

I assume that such control information is still possible to define and use. Control information was not removed, it was renamed and definition has changed. Traffic handling directives may not the best name. QoS NSLP allows different signaling options, that is another reason for control information, so there should be "signaling handling directives" as well. I do not see problems adding the text proposed by Georgios. 

>additional signaling exchanges? ]]

I assume, yes.

>types of signaling exchanges? 

I do not think QSpec template doc. should contain signaling definitions or restictions like which signaling options should be used. It should be defined by QoS model. Can we aggree with it? I think, to update the template doc. according to it does not require much change.

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Thu, 4 Jan 2007 15:52:33 +0100

Hi Georgios,

> in very highly utilised networks!

You mean 'severely impact the performance'. 

Every end-to-end reservation setup request would add a single message
within the RMD domain. 

Ciao
Hannes

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 4 Jan 2007 16:06:49 +0100

Hi Hannes

Please see in line!

> Sent: donderdag 4 januari 2007 15:53
> > Georgios: Yes you are right, but when this feature is used it will 
> > severely increase the performance of NSIS when such solutions are 
> > applied in very highly utilised networks!
> 
> Every end-to-end reservation setup request would add a single 
> message within the RMD domain. 

Georgios: yes, but in a highly utilsed domain that uses call holding time 
applications this number can be very large!

Best regards,
Georgios

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 4 Jan 2007 16:13:09 +0100

Hi hannes

I meant:
Georgios: yes, but in a highly utilsed domain that uses short call 
holding time applications this number can be very large!

Best regards,
Georgios
> Sent: donderdag 4 januari 2007 16:07
> To: 'Tschofenig, Hannes'; 'Hannes Tschofenig'
> Georgios: yes, but in a highly utilsed domain that uses call 
> holding time applications this number can be very large!
> 
> Best regards,
> Georgios
> 
> > 
> > Ciao
> > Hannes
> >

---

From: <[email-masked]>
Date: Thu, 4 Jan 2007 17:38:55 +0200

Hi Georgios,

>I meant:
>Georgios: yes, but in a highly utilsed domain that uses short 
>call holding time applications this number can be very large!

Do you have any simulation results or estimates? I'd like to understand
a little bit
about making a special purpose solution when we are trying to define a
general
protocol.

thanks,
John

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 4 Jan 2007 16:52:52 +0100

Hi John

Just an example:
Suppose that 100000 calls/second have to be supported 
by a RMD-QOSM aware domain.
This will mean that in a worst case situation
100000 additional messages/sec will have to be processed 
by an interior node.

Best regards,
Georgios

> From: [email-masked] [mailto:[email-masked]] 
> Sent: donderdag 4 januari 2007 16:39
> To: [email-masked]; [email-masked]; 
> [email-masked]
> Cc: [email-masked]; [email-masked]
> Do you have any simulation results or estimates? I'd like to 
> understand a little bit about making a special purpose 
> solution when we are trying to define a general protocol.
> 
> thanks,
> John
>