From nsis-bounces@ietf.org Mon Oct 02 04:36:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUJGe-00031y-Un; Mon, 02 Oct 2006 04:35:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUJGd-0002wQ-Hu for nsis@ietf.org; Mon, 02 Oct 2006 04:35:15 -0400 Received: from smtp.mei.co.jp ([133.183.129.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUJGc-0002si-NS for nsis@ietf.org; Mon, 02 Oct 2006 04:35:15 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kings) with ESMTP id k928Yvr3027549; Mon, 2 Oct 2006 17:34:57 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id k928Yw314365; Mon, 2 Oct 2006 17:34:58 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/mariners) with SMTP id k928Yx108761; Mon, 2 Oct 2006 17:34:59 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] A question to people about QoS NSLP Tear operation Date: Mon, 2 Oct 2006 16:33:37 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD012F2302@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] A question to people about QoS NSLP Tear operation Thread-Index: AcbkrfZd6oorKppjQcSCkXcZwrdLQQBTa0Fw From: "Cheng Hong" To: "Bernd Schloer" X-Spam-Score: 0.1 (/) X-Scan-Signature: 7e267523e0685e5aa2dbbdde4b659686 Cc: Jukka MJ Manner , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Bernd, Please see some comments below: > the Mobility Applicability draft mentions that after=20 > reestablishing NSIS state along a new path the reservation on=20 > the old path needs to be quickly removed to avoid double=20 > reservations and waste of resources. It is recommended to use=20 > teardown messages rather than soft state removal. I believe=20 > that explicit confirmations of state removals and=20 > notifications in error cases support to quickly delete the old state. Yes. That is also a reason for me to agree that the notification in error cases for tearing is desired. > Is this a possible approach for NSIS mobility or is the MIPv6=20 > Fast Handover (RFC 4068) more preferred? The disadvantage of=20 > the two radio model is the higher power consumption for=20 > mobile devices. But as long as there are not continous=20 > Ping-Pong handoffs the second device could be used only for=20 > periodic scannings. Regarding this, I think it is not up to the NSIS WG to decide which approach is better. Different cases have their own virtues. It probably depends on the deployment environments, e.g. in 3G system or in general Internet. For NSIS, the protocol should be designed to support both cases (unless they conflict with each other).=20 As for the FMIP case, I believe the second radio should also be switched on before the actual path switch? There are quite a few more interesting issues for using the NSIS with FMIP, but it might not be an appropriate topic for this thread :) cheers Cheng Hong > -----Original Message----- > From: Bernd Schloer [mailto:bschloer@cs.uni-goettingen.de]=20 > Sent: Sunday, October 01, 2006 12:33 AM > To: Cheng Hong > Cc: Jukka MJ Manner; nsis@ietf.org > Subject: Re: [NSIS] A question to people about QoS NSLP Tear operation >=20 > Hi, >=20 > the Mobility Applicability draft mentions that after=20 > reestablishing NSIS state along a new path the reservation on=20 > the old path needs to be quickly removed to avoid double=20 > reservations and waste of resources. It is recommended to use=20 > teardown messages rather than soft state removal. I believe=20 > that explicit confirmations of state removals and=20 > notifications in error cases support to quickly delete the old state. >=20 > The draft also talks about Multihomed mobile environments and=20 > about MNs with multiple interfaces. Multiple interfaces could=20 > be used simultaneously when a handoff occurs to reduce the=20 > latency. When using two interfaces, the second could perform=20 > the scanning for new channels in the background while the=20 > first operates normally. The scanning for new channels is=20 > quite time consuming. When scanning, authentication and=20 > reassociation is done, one can switch to the second device. >=20 > Is this a possible approach for NSIS mobility or is the MIPv6=20 > Fast Handover (RFC 4068) more preferred? The disadvantage of=20 > the two radio model is the higher power consumption for=20 > mobile devices. But as long as there are not continous=20 > Ping-Pong handoffs the second device could be used only for=20 > periodic scannings. >=20 > Bernd >=20 >=20 >=20 > Cheng Hong wrote: > > Hi Jukka and Bernd, and all, > >=20 > > I would agree with Bernd that the explicit signaling is better than=20 > > soft state removal. Relying on the soft state removal means the=20 > > relevant resources would be kept for the timeout period.=20 > This is not=20 > > desired in scenarios where mobility and aggregations are involved. > >=20 > > As already discussed in the Mobility Applicability draft, in the=20 > > mobile environment, it is preferred to have explicit tearing of the=20 > > old states to avoid double reservations. In certain case,=20 > it is even=20 > > desired to allow intermediary nodes, e.g. CRN, to trigger=20 > the tearing=20 > > for network optimization. > >=20 > > Aggregation is another case that prompt removal is important.=20 > > Aggregated reservation usually holds much more resources than=20 > > individual reservation. Allowing such state to relinquish for the=20 > > timeout period would put delay on new reservations'=20 > acceptances. And=20 > > this could again cause interruptions to seamless transitions. > >=20 > > Although the soft state guarantees the ultimate removal of=20 > the state,=20 > > the network will scale much better with the explicit signaling=20 > > supported. (Considering there could be thousands of states=20 > involved.)=20 > > Therefore, signaling of the errors should be supported even for the=20 > > teardown case. > >=20 > >=20 > > cheers > >=20 > > Cheng Hong > >=20 > >=20 > >>-----Original Message----- > >>From: Bernd Schloer [mailto:bschloer@cs.uni-goettingen.de] > >>Sent: Friday, September 29, 2006 3:08 AM > >>To: Jukka MJ Manner > >>Cc: nsis@ietf.org > >>Subject: Re: [NSIS] A question to people about QoS NSLP=20 > Tear operation > >> > >>Hi, > >> > >>if a teardown is not possible due to some errors and the QNI gets=20 > >>informed about them, then the errors might be fixed and a clean=20 > >>teardown gets possible. > >> > >>I prefer the signaling of errors rather than soft state removal. > >> > >>Bernd > >> > >> > >>Jukka MJ Manner wrote: > >> > >>>Hi, > >>> > >>>If you look at the QoS NSLP error situations (codes), all sorts of=20 > >>>things could go wrong, e.g.: > >>> > >>>- Informational: unknown bound session ID > >>>- Protocol error: all errors are valid > >>>- Transient: possibly "RII conflict", "Mismatch synchronization" > >>>- Permanent failure: both (some system error, or authorization > >>>failure) > >>> > >>>Thus, would it be important to signal those errors to the > >> > >>QNI when a > >> > >>>resource removal failed? > >>> > >>>Jukka > >>> > >>>On Wed, 27 Sep 2006, Bernd Schloer wrote: > >>> > >>> > >>> > >>>>Hi Jukka and all, > >>>> > >>>>I agree with David that the soft state removes a session if > >> > >>it isn't > >> > >>>>refreshed any more. On the other hand it can be of interest > >> > >>for a QNI > >> > >>>>to know immediately about the success of a state removal.=20 > >> > >>It can take > >> > >>>>quite a long time till the soft state expires. This could > >> > >>be a waste > >> > >>>>of resources. > >>>> > >>>>What error conditions do you have in mind? Do you thing the > >> > >>existing > >> > >>>>teardown is not reliable? > >>>> > >>>>Bernd > >>>> > >>>> > >>>> > >>>>David Palma wrote: > >>>> > >>>> > >>>>>Hi Jukka and all, > >>>>> > >>>>>From my point of view even that the draft recommends to send a=20 > >>>>>RESPONSE message to errors that might occur on a RESERVE=20 > with the=20 > >>>>>TEAR flag, like missing QSPEC (if necessary) or if a > >> > >>reservation does > >> > >>>>>not exist (this message might also be silently dropped), > >> > >>this is not necessary. > >> > >>>>>Even if the RESERVE with the TEAR flag is not accepted, > >> > >>after a while > >> > >>>>>the soft-state will take care of the process of removing > >> > >>this session > >> > >>>>>since it isn't refreshed anymore. > >>>>> > >>>>>For the same reason I believe that RII is not necessary > >> > >>since the QNI > >> > >>>>>doesn't need to be concerned with reservations that=20 > might have not=20 > >>>>>been torn down because they will be when the soft state expires. > >>>>> > >>>>>Best regards, > >>>>> > >>>>>David Palma > >>>>> > >>>>>Jukka MJ Manner wrote: > >>>>> > >>>>> > >>>>> > >>>>>>Hi all, > >>>>>> > >>>>>>It seems that our spec is not very clear on how Tear-operations=20 > >>>>>>should be handled, or at least leaves some things a bit=20 > too open. > >>>>>> > >>>>>>1. Can a Tear-operation cause an error situation, and > >> > >>cause an error > >> > >>>>>> message to be sent back towards the QNI? Should some errors be=20 > >>>>>>silently accepted, should the tearing RESERVE still be sent=20 > >>>>>>further? > >>>>>> > >>>>>>2. Can the QNI request a confirmation of state removal,=20 > that the=20 > >>>>>>operation was successful, e.g, by including an RII into > >> > >>the tearing RESERVE? > >> > >>>>>>3. If either, or both, should be made possible by the spec, how=20 > >>>>>>would this affect GIST? A QNE gets a tearing RESERVE, it > >> > >>removes the > >> > >>>>>>state (1), forwards the message towards the next QNE=20 > (2), and may=20 > >>>>>>ask GIST to remove any routing state for this session. > >> > >>Now, if this QNE later gets > >> > >>>>>>back an error message, or a RESPONSE, for a session it no > >> > >>longer knows, > >> > >>>>>>what does the QNE do? Re-set up routing state towards the > >> > >>QNI using > >> > >>>>>>GIST, and send the message forward? > >>>>>> > >>>>>>RSVP RFC2209 says basically that unknown messages are > >> > >>silently dropped. > >> > >>>>>>Still, in this case, an error message, or a RESPONSE, can be=20 > >>>>>>considered to be similar to an RSVP CONFIRM (RACK) > >> > >>message, which is > >> > >>>>>>just forwarded without much processing. > >>>>>> > >>>>>> > >>>>>>Regards, > >>>>>>Jukka > >>>>>> > >>>>>>_______________________________________________ > >>>>>>nsis mailing list > >>>>>>nsis@ietf.org > >>>>>>https://www1.ietf.org/mailman/listinfo/nsis > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>>_______________________________________________ > >>>>>nsis mailing list > >>>>>nsis@ietf.org > >>>>>https://www1.ietf.org/mailman/listinfo/nsis > >>>> > >>_______________________________________________ > >>nsis mailing list > >>nsis@ietf.org > >>https://www1.ietf.org/mailman/listinfo/nsis > >=20 > >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 02 05:03:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUJhh-000620-QW; Mon, 02 Oct 2006 05:03:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUJhf-000614-Lk for nsis@ietf.org; Mon, 02 Oct 2006 05:03:11 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUJeQ-0005yR-Mc for nsis@ietf.org; Mon, 02 Oct 2006 04:59:53 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k928xS7e004238; Mon, 2 Oct 2006 10:59:32 +0200 (MEST) From: "Georgios Karagiannis" To: "'Cheng Hong'" , "'Bernd Schloer'" Subject: RE: [NSIS] A question to people about QoS NSLP Tear operation Date: Mon, 2 Oct 2006 10:59:24 +0200 Message-ID: <001501c6e601$12277790$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcbkrfZd6oorKppjQcSCkXcZwrdLQQBTa0FwAAFLxCA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <5F09D220B62F79418461A978CA0921BD012F2302@pslexc01.psl.local> X-Spam-Score: -5.691 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Mon, 02 Oct 2006 10:59:46 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6437e26f1586b9f35812ea5ebeedf4ad Cc: 'Jukka MJ Manner' , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Cheng, Bernd and Jukka I think Bernd and Cheng are right! The chocice depends on the deployment environments, e.g. in 3G system or in general Internet. For NSIS, the protocol should be designed to support both cases (unless they conflict with each other). Best regards, Georgios -----Original Message----- From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com] Sent: maandag 2 oktober 2006 10:34 To: Bernd Schloer Cc: Jukka MJ Manner; nsis@ietf.org Subject: RE: [NSIS] A question to people about QoS NSLP Tear operation Hi Bernd, Please see some comments below: > the Mobility Applicability draft mentions that after reestablishing > NSIS state along a new path the reservation on the old path needs to > be quickly removed to avoid double reservations and waste of > resources. It is recommended to use teardown messages rather than soft > state removal. I believe that explicit confirmations of state removals > and notifications in error cases support to quickly delete the old > state. Yes. That is also a reason for me to agree that the notification in error cases for tearing is desired. > Is this a possible approach for NSIS mobility or is the MIPv6 Fast > Handover (RFC 4068) more preferred? The disadvantage of the two radio > model is the higher power consumption for mobile devices. But as long > as there are not continous Ping-Pong handoffs the second device could > be used only for periodic scannings. Regarding this, I think it is not up to the NSIS WG to decide which approach is better. Different cases have their own virtues. It probably depends on the deployment environments, e.g. in 3G system or in general Internet. For NSIS, the protocol should be designed to support both cases (unless they conflict with each other). As for the FMIP case, I believe the second radio should also be switched on before the actual path switch? There are quite a few more interesting issues for using the NSIS with FMIP, but it might not be an appropriate topic for this thread :) cheers Cheng Hong > -----Original Message----- > From: Bernd Schloer [mailto:bschloer@cs.uni-goettingen.de] > Sent: Sunday, October 01, 2006 12:33 AM > To: Cheng Hong > Cc: Jukka MJ Manner; nsis@ietf.org > Subject: Re: [NSIS] A question to people about QoS NSLP Tear operation > > Hi, > > the Mobility Applicability draft mentions that after reestablishing > NSIS state along a new path the reservation on the old path needs to > be quickly removed to avoid double reservations and waste of > resources. It is recommended to use teardown messages rather than soft > state removal. I believe that explicit confirmations of state removals > and notifications in error cases support to quickly delete the old > state. > > The draft also talks about Multihomed mobile environments and about > MNs with multiple interfaces. Multiple interfaces could be used > simultaneously when a handoff occurs to reduce the latency. When using > two interfaces, the second could perform the scanning for new channels > in the background while the first operates normally. The scanning for > new channels is quite time consuming. When scanning, authentication > and reassociation is done, one can switch to the second device. > > Is this a possible approach for NSIS mobility or is the MIPv6 Fast > Handover (RFC 4068) more preferred? The disadvantage of the two radio > model is the higher power consumption for mobile devices. But as long > as there are not continous Ping-Pong handoffs the second device could > be used only for periodic scannings. > > Bernd > > > > Cheng Hong wrote: > > Hi Jukka and Bernd, and all, > > > > I would agree with Bernd that the explicit signaling is better than > > soft state removal. Relying on the soft state removal means the > > relevant resources would be kept for the timeout period. > This is not > > desired in scenarios where mobility and aggregations are involved. > > > > As already discussed in the Mobility Applicability draft, in the > > mobile environment, it is preferred to have explicit tearing of the > > old states to avoid double reservations. In certain case, > it is even > > desired to allow intermediary nodes, e.g. CRN, to trigger > the tearing > > for network optimization. > > > > Aggregation is another case that prompt removal is important. > > Aggregated reservation usually holds much more resources than > > individual reservation. Allowing such state to relinquish for the > > timeout period would put delay on new reservations' > acceptances. And > > this could again cause interruptions to seamless transitions. > > > > Although the soft state guarantees the ultimate removal of > the state, > > the network will scale much better with the explicit signaling > > supported. (Considering there could be thousands of states > involved.) > > Therefore, signaling of the errors should be supported even for the > > teardown case. > > > > > > cheers > > > > Cheng Hong > > > > > >>-----Original Message----- > >>From: Bernd Schloer [mailto:bschloer@cs.uni-goettingen.de] > >>Sent: Friday, September 29, 2006 3:08 AM > >>To: Jukka MJ Manner > >>Cc: nsis@ietf.org > >>Subject: Re: [NSIS] A question to people about QoS NSLP > Tear operation > >> > >>Hi, > >> > >>if a teardown is not possible due to some errors and the QNI gets > >>informed about them, then the errors might be fixed and a clean > >>teardown gets possible. > >> > >>I prefer the signaling of errors rather than soft state removal. > >> > >>Bernd > >> > >> > >>Jukka MJ Manner wrote: > >> > >>>Hi, > >>> > >>>If you look at the QoS NSLP error situations (codes), all sorts of > >>>things could go wrong, e.g.: > >>> > >>>- Informational: unknown bound session ID > >>>- Protocol error: all errors are valid > >>>- Transient: possibly "RII conflict", "Mismatch synchronization" > >>>- Permanent failure: both (some system error, or authorization > >>>failure) > >>> > >>>Thus, would it be important to signal those errors to the > >> > >>QNI when a > >> > >>>resource removal failed? > >>> > >>>Jukka > >>> > >>>On Wed, 27 Sep 2006, Bernd Schloer wrote: > >>> > >>> > >>> > >>>>Hi Jukka and all, > >>>> > >>>>I agree with David that the soft state removes a session if > >> > >>it isn't > >> > >>>>refreshed any more. On the other hand it can be of interest > >> > >>for a QNI > >> > >>>>to know immediately about the success of a state removal. > >> > >>It can take > >> > >>>>quite a long time till the soft state expires. This could > >> > >>be a waste > >> > >>>>of resources. > >>>> > >>>>What error conditions do you have in mind? Do you thing the > >> > >>existing > >> > >>>>teardown is not reliable? > >>>> > >>>>Bernd > >>>> > >>>> > >>>> > >>>>David Palma wrote: > >>>> > >>>> > >>>>>Hi Jukka and all, > >>>>> > >>>>>From my point of view even that the draft recommends to send a > >>>>>RESPONSE message to errors that might occur on a RESERVE > with the > >>>>>TEAR flag, like missing QSPEC (if necessary) or if a > >> > >>reservation does > >> > >>>>>not exist (this message might also be silently dropped), > >> > >>this is not necessary. > >> > >>>>>Even if the RESERVE with the TEAR flag is not accepted, > >> > >>after a while > >> > >>>>>the soft-state will take care of the process of removing > >> > >>this session > >> > >>>>>since it isn't refreshed anymore. > >>>>> > >>>>>For the same reason I believe that RII is not necessary > >> > >>since the QNI > >> > >>>>>doesn't need to be concerned with reservations that > might have not > >>>>>been torn down because they will be when the soft state expires. > >>>>> > >>>>>Best regards, > >>>>> > >>>>>David Palma > >>>>> > >>>>>Jukka MJ Manner wrote: > >>>>> > >>>>> > >>>>> > >>>>>>Hi all, > >>>>>> > >>>>>>It seems that our spec is not very clear on how Tear-operations > >>>>>>should be handled, or at least leaves some things a bit > too open. > >>>>>> > >>>>>>1. Can a Tear-operation cause an error situation, and > >> > >>cause an error > >> > >>>>>> message to be sent back towards the QNI? Should some errors be > >>>>>>silently accepted, should the tearing RESERVE still be sent > >>>>>>further? > >>>>>> > >>>>>>2. Can the QNI request a confirmation of state removal, > that the > >>>>>>operation was successful, e.g, by including an RII into > >> > >>the tearing RESERVE? > >> > >>>>>>3. If either, or both, should be made possible by the spec, how > >>>>>>would this affect GIST? A QNE gets a tearing RESERVE, it > >> > >>removes the > >> > >>>>>>state (1), forwards the message towards the next QNE > (2), and may > >>>>>>ask GIST to remove any routing state for this session. > >> > >>Now, if this QNE later gets > >> > >>>>>>back an error message, or a RESPONSE, for a session it no > >> > >>longer knows, > >> > >>>>>>what does the QNE do? Re-set up routing state towards the > >> > >>QNI using > >> > >>>>>>GIST, and send the message forward? > >>>>>> > >>>>>>RSVP RFC2209 says basically that unknown messages are > >> > >>silently dropped. > >> > >>>>>>Still, in this case, an error message, or a RESPONSE, can be > >>>>>>considered to be similar to an RSVP CONFIRM (RACK) > >> > >>message, which is > >> > >>>>>>just forwarded without much processing. > >>>>>> > >>>>>> > >>>>>>Regards, > >>>>>>Jukka > >>>>>> > >>>>>>_______________________________________________ > >>>>>>nsis mailing list > >>>>>>nsis@ietf.org > >>>>>>https://www1.ietf.org/mailman/listinfo/nsis > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>>_______________________________________________ > >>>>>nsis mailing list > >>>>>nsis@ietf.org > >>>>>https://www1.ietf.org/mailman/listinfo/nsis > >>>> > >>_______________________________________________ > >>nsis mailing list > >>nsis@ietf.org > >>https://www1.ietf.org/mailman/listinfo/nsis > > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 02 10:30:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUOni-0007Ue-Ln; Mon, 02 Oct 2006 10:29:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUOnh-0007UT-2m for nsis@ietf.org; Mon, 02 Oct 2006 10:29:45 -0400 Received: from mclmx2.mail.saic.com ([149.8.64.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUOnf-0000z1-S1 for nsis@ietf.org; Mon, 02 Oct 2006 10:29:45 -0400 Received: from 0015-its-ieg01.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com; Mon, 2 Oct 2006 10:29:31 -0400 Received: from 0015-ITS-EXBH01.us.saic.com ([10.43.229.18]) by 0015-its-ieg01.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006100210293111871 ; Mon, 02 Oct 2006 10:29:31 -0400 Received: from 0591-ITS-EXMP02.us.saic.com ([10.42.81.248]) by 0015-ITS-EXBH01.us.saic.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Oct 2006 10:29:31 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] A question to people about QoS NSLP Tear operation Date: Mon, 2 Oct 2006 10:29:30 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426230EB4@0591-ITS-EXMP02.us.saic.com> In-Reply-To: <001501c6e601$12277790$4c0d5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] A question to people about QoS NSLP Tear operation Thread-Index: AcbkrfZd6oorKppjQcSCkXcZwrdLQQBTa0FwAAFLxCAAC0HaAA== From: "Roy, Radhika R." To: "Georgios Karagiannis" , "Cheng Hong" , "Bernd Schloer" X-OriginalArrivalTime: 02 Oct 2006 14:29:31.0597 (UTC) FILETIME=[2CCAAFD0:01C6E62F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Jukka MJ Manner , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Folks: No matter what the implementation modes are there, the Interworking needs to be there. Let me provide some examples as follows: 1. 3GPP Wireless access networks + IP backbone network (DiffServ, MPLS DSTE QOS, Y.xxx QOS, and/or others). 2. IP access networks (RSVP) + IP backbone network (DiffServ, MPLS DSTE QOS, Y.xxx QOS, and/or others). You may end-up, for example, Interworking with DSTE QOS and Y.xxx QOS and other Interworking QOS scenarios. One-way of avoiding this Interworking is to delete those unnecessary things for which Interworking in QOS is not possible, for example, so-called DSTE and Y.xxxx specific QOS classes. Another alternative is to provide clear implementation directions where and how Interworking in QOS problems can be avoided in these messy environments. Best regards, RAdhika -----Original Message----- From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On Behalf Of Georgios Karagiannis Sent: Monday, October 02, 2006 4:59 AM To: 'Cheng Hong'; 'Bernd Schloer' Cc: 'Jukka MJ Manner'; nsis@ietf.org Subject: RE: [NSIS] A question to people about QoS NSLP Tear operation Hi Cheng, Bernd and Jukka I think Bernd and Cheng are right! The chocice depends on the deployment environments, e.g. in 3G=20 system or in general Internet. For NSIS, the protocol should be=20 designed to support both cases (unless they conflict with each other).=20 Best regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 03 02:47:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUe3X-0003E1-Nv; Tue, 03 Oct 2006 02:47:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUe3W-0003Dr-8p for nsis@ietf.org; Tue, 03 Oct 2006 02:47:06 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUe3U-0007CB-Qh for nsis@ietf.org; Tue, 03 Oct 2006 02:47:06 -0400 Received: from sbz-30.cs.helsinki.fi (sbz-30.cs.helsinki.fi [128.214.9.98]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Tue, 03 Oct 2006 09:47:01 +0300 id 000AFD5F.45220765.000035CC Date: Tue, 3 Oct 2006 09:47:01 +0300 (EEST) From: Jukka MJ Manner To: "Roy, Radhika R." Subject: RE: [NSIS] A question to people about QoS NSLP Tear operation In-Reply-To: <62D92A9A02BCC845B202323D49A48426230EB4@0591-ITS-EXMP02.us.saic.com> Message-ID: References: <62D92A9A02BCC845B202323D49A48426230EB4@0591-ITS-EXMP02.us.saic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Roy, I don't really follow what you are saying. Should the QoS NSLP have an explicit tear down confirmation and error signaling, or not? If it should have, how would it work considering that NSLP and GIST states are removed as the tearing RESERVE goes through the network. Furthermore, note that currently we only support a tear-down initiated by the QNI. No other node can tear down a reservation on behalf of the QNI. Regards, Jukka On Mon, 2 Oct 2006, Roy, Radhika R. wrote: > Folks: > > No matter what the implementation modes are there, the Interworking > needs to be there. Let me provide some examples as follows: > > 1. 3GPP Wireless access networks + IP backbone network (DiffServ, MPLS > DSTE QOS, Y.xxx QOS, and/or others). > > 2. IP access networks (RSVP) + IP backbone network (DiffServ, MPLS DSTE > QOS, Y.xxx QOS, and/or others). > > You may end-up, for example, Interworking with DSTE QOS and Y.xxx QOS > and other Interworking QOS scenarios. > > One-way of avoiding this Interworking is to delete those unnecessary > things for which Interworking in QOS is not possible, for example, > so-called DSTE and Y.xxxx specific QOS classes. > > Another alternative is to provide clear implementation directions where > and how Interworking in QOS problems can be avoided in these messy > environments. > > Best regards, > RAdhika > > -----Original Message----- > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On Behalf Of > Georgios Karagiannis > Sent: Monday, October 02, 2006 4:59 AM > To: 'Cheng Hong'; 'Bernd Schloer' > Cc: 'Jukka MJ Manner'; nsis@ietf.org > Subject: RE: [NSIS] A question to people about QoS NSLP Tear operation > > Hi Cheng, Bernd and Jukka > > I think Bernd and Cheng are right! > The chocice depends on the deployment environments, e.g. in 3G > system or in general Internet. For NSIS, the protocol should be > designed to support both cases (unless they conflict with each other). > > Best regards, > Georgios > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 03 03:37:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUeph-0004or-Kc; Tue, 03 Oct 2006 03:36:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUepg-0004jk-LG for nsis@ietf.org; Tue, 03 Oct 2006 03:36:52 -0400 Received: from smtp.mei.co.jp ([133.183.129.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUee0-0001GF-1z for nsis@ietf.org; Tue, 03 Oct 2006 03:24:49 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/bulls) with ESMTP id k937OcNL028179; Tue, 3 Oct 2006 16:24:38 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id k937Ob010406; Tue, 3 Oct 2006 16:24:37 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/bluejays) with ESMTP id k937OW313894; Tue, 3 Oct 2006 16:24:33 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] A question to people about QoS NSLP Tear operation Date: Tue, 3 Oct 2006 15:23:28 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD01365BD9@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] A question to people about QoS NSLP Tear operation Thread-Index: Acbmt/Guir8aSgtORgSNjzXBdd4b+gAA+ciA From: "Cheng Hong" To: "Jukka MJ Manner" , "Roy, Radhika R." X-Spam-Score: 0.1 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jukka, > Should the QoS=20 > NSLP have an explicit tear down confirmation and error=20 > signaling, or not? If it should have, how would it work=20 > considering that NSLP and GIST states are removed as the=20 > tearing RESERVE goes through the network. This is an interesting point. I guess the NSLP state would be removed as a result of the tearing RESERVE, but not necessarily the GIST state.=20 Another thought is that if the confirmation is required, maybe the NSLP state will only be removed after receiving the confirmation (similar to the two stage RESERVE commitment)? cheers Cheng=20 > -----Original Message----- > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI]=20 > Sent: Tuesday, October 03, 2006 2:47 PM > To: Roy, Radhika R. > Cc: nsis@ietf.org > Subject: RE: [NSIS] A question to people about QoS NSLP Tear operation >=20 >=20 > Roy, >=20 > I don't really follow what you are saying. Should the QoS=20 > NSLP have an explicit tear down confirmation and error=20 > signaling, or not? If it should have, how would it work=20 > considering that NSLP and GIST states are removed as the=20 > tearing RESERVE goes through the network. >=20 > Furthermore, note that currently we only support a tear-down=20 > initiated by the QNI. No other node can tear down a=20 > reservation on behalf of the QNI. >=20 > Regards, > Jukka >=20 > On Mon, 2 Oct 2006, Roy, Radhika R. wrote: >=20 > > Folks: > >=20 > > No matter what the implementation modes are there, the Interworking=20 > > needs to be there. Let me provide some examples as follows: > >=20 > > 1. 3GPP Wireless access networks + IP backbone network=20 > (DiffServ, MPLS=20 > > DSTE QOS, Y.xxx QOS, and/or others). > >=20 > > 2. IP access networks (RSVP) + IP backbone network (DiffServ, MPLS=20 > > DSTE QOS, Y.xxx QOS, and/or others). > >=20 > > You may end-up, for example, Interworking with DSTE QOS and=20 > Y.xxx QOS=20 > > and other Interworking QOS scenarios. > >=20 > > One-way of avoiding this Interworking is to delete those=20 > unnecessary=20 > > things for which Interworking in QOS is not possible, for example,=20 > > so-called DSTE and Y.xxxx specific QOS classes. > >=20 > > Another alternative is to provide clear implementation directions=20 > > where and how Interworking in QOS problems can be avoided in these=20 > > messy environments. > >=20 > > Best regards, > > RAdhika > >=20 > > -----Original Message----- > > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org]=20 > On Behalf=20 > > Of Georgios Karagiannis > > Sent: Monday, October 02, 2006 4:59 AM > > To: 'Cheng Hong'; 'Bernd Schloer' > > Cc: 'Jukka MJ Manner'; nsis@ietf.org > > Subject: RE: [NSIS] A question to people about QoS NSLP=20 > Tear operation > >=20 > > Hi Cheng, Bernd and Jukka > >=20 > > I think Bernd and Cheng are right! > > The chocice depends on the deployment environments, e.g. in=20 > 3G system=20 > > or in general Internet. For NSIS, the protocol should be=20 > designed to=20 > > support both cases (unless they conflict with each other). > >=20 > > Best regards, > > Georgios > >=20 > >=20 > >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 03 09:54:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUkiF-0003FS-0u; Tue, 03 Oct 2006 09:53:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUkiD-0003Ds-PG for nsis@ietf.org; Tue, 03 Oct 2006 09:53:33 -0400 Received: from mclmx2.mail.saic.com ([149.8.64.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUkXG-0005q8-4Z for nsis@ietf.org; Tue, 03 Oct 2006 09:42:15 -0400 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com; Tue, 3 Oct 2006 09:42:03 -0400 Received: from 0015-ITS-EXBH01.us.saic.com ([10.43.229.18]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006100309420424034 ; Tue, 03 Oct 2006 09:42:04 -0400 Received: from 0591-ITS-EXMP02.us.saic.com ([10.42.81.248]) by 0015-ITS-EXBH01.us.saic.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Oct 2006 09:42:04 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] A question to people about QoS NSLP Tear operation Date: Tue, 3 Oct 2006 09:42:03 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426230EBB@0591-ITS-EXMP02.us.saic.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] A question to people about QoS NSLP Tear operation Thread-Index: Acbmt8JuWunbVWL/QimgdoUWQuRcAwAOdPgA From: "Roy, Radhika R." To: X-OriginalArrivalTime: 03 Oct 2006 13:42:04.0017 (UTC) FILETIME=[B5EA3610:01C6E6F1] X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Jukka: I am saying with respect QSPEC that will be used. Best regards, Radhika -----Original Message----- From: jmanner@cs.Helsinki.FI [mailto:jmanner@cs.Helsinki.FI]=20 Sent: Tuesday, October 03, 2006 2:47 AM To: Roy, Radhika R. Cc: nsis@ietf.org Subject: RE: [NSIS] A question to people about QoS NSLP Tear operation Roy, I don't really follow what you are saying. Should the QoS NSLP have an explicit tear down confirmation and error signaling, or not? If it should have, how would it work considering that NSLP and GIST states are removed as the tearing RESERVE goes through the network. Furthermore, note that currently we only support a tear-down initiated by=20 the QNI. No other node can tear down a reservation on behalf of the QNI. Regards, Jukka On Mon, 2 Oct 2006, Roy, Radhika R. wrote: > Folks: >=20 > No matter what the implementation modes are there, the Interworking > needs to be there. Let me provide some examples as follows: >=20 > 1. 3GPP Wireless access networks + IP backbone network (DiffServ, MPLS > DSTE QOS, Y.xxx QOS, and/or others). >=20 > 2. IP access networks (RSVP) + IP backbone network (DiffServ, MPLS DSTE > QOS, Y.xxx QOS, and/or others). >=20 > You may end-up, for example, Interworking with DSTE QOS and Y.xxx QOS > and other Interworking QOS scenarios. >=20 > One-way of avoiding this Interworking is to delete those unnecessary > things for which Interworking in QOS is not possible, for example, > so-called DSTE and Y.xxxx specific QOS classes. >=20 > Another alternative is to provide clear implementation directions where > and how Interworking in QOS problems can be avoided in these messy > environments. >=20 > Best regards, > RAdhika >=20 > -----Original Message----- > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On Behalf Of > Georgios Karagiannis > Sent: Monday, October 02, 2006 4:59 AM > To: 'Cheng Hong'; 'Bernd Schloer' > Cc: 'Jukka MJ Manner'; nsis@ietf.org > Subject: RE: [NSIS] A question to people about QoS NSLP Tear operation >=20 > Hi Cheng, Bernd and Jukka >=20 > I think Bernd and Cheng are right! > The chocice depends on the deployment environments, e.g. in 3G=20 > system or in general Internet. For NSIS, the protocol should be=20 > designed to support both cases (unless they conflict with each other). >=20 > Best regards, > Georgios >=20 >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 04 15:01:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVByv-0002zU-4m; Wed, 04 Oct 2006 15:00:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVByt-0002wz-Ci for nsis@ietf.org; Wed, 04 Oct 2006 15:00:35 -0400 Received: from natklopstock.rzone.de ([81.169.145.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVBys-0001Ll-0r for nsis@ietf.org; Wed, 04 Oct 2006 15:00:35 -0400 Received: from [192.168.178.200] (p5484B1D2.dip0.t-ipconnect.de [84.132.177.210]) (authenticated bits=0) by post.webmailer.de (8.13.6/8.13.6) with ESMTP id k94J0V9D014562; Wed, 4 Oct 2006 21:00:31 +0200 (MEST) Message-ID: <452404B9.9040102@cs.uni-goettingen.de> Date: Wed, 04 Oct 2006 21:00:09 +0200 From: Bernd Schloer User-Agent: Opera/8.51 (Windows NT 5.1; U; en) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jukka MJ Manner Subject: Re: [NSIS] A question to people about QoS NSLP Tear operation References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jukka, what if the QNE asks GIST to remove routing state after receiving the RESPONSE to the tearing RESERVE when requested or directly when no response is requested? Bernd > 3. If either, or both, should be made possible by the spec, how would this > affect GIST? A QNE gets a tearing RESERVE, it removes the state (1), > forwards the message towards the next QNE (2), and may ask GIST to > remove any routing state for this session. Now, if this QNE later gets > back an error message, or a RESPONSE, for a session it no longer > knows, what does the QNE do? Re-set up routing state towards the QNI > using GIST, and send the message forward? _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 04 15:14:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVCBj-0008CW-FW; Wed, 04 Oct 2006 15:13:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVCBh-00080y-Jb for nsis@ietf.org; Wed, 04 Oct 2006 15:13:49 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVCBg-0003MJ-9I for nsis@ietf.org; Wed, 04 Oct 2006 15:13:49 -0400 Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Wed, 04 Oct 2006 22:13:45 +0300 id 000AFD30.452407E9.00001015 Date: Wed, 4 Oct 2006 22:13:45 +0300 (EEST) From: Jukka MJ Manner To: Bernd Schloer Subject: Re: [NSIS] A question to people about QoS NSLP Tear operation In-Reply-To: <452404B9.9040102@cs.uni-goettingen.de> Message-ID: References: <452404B9.9040102@cs.uni-goettingen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Yes, that is something I was thinking. Still, we have a small performance problem if no RESPONSE is requested, but there is an error in the processing of a tearing RESERVE. E.g., we have QNI <--> QNE1 <--> QNE2 <--> QNE3 <--> QNR 1. QNI asks to remove a reservation, without confirmation 2. QNE1 does that, asks GIST remove the state, and sends the requests to QNE2 3. QNE does the same and sends the message to QNE3 4. QNE3 noticies some error situation, and sends an error message towards the QNI 5. QNE3 still has a GIST MA with QNE2, and QNE3 can send the error to QNE2 6. QNE2 now does not have anymore a GIST MA towards QN1, thus, it needs to set up one 7. In turn QNE1 gets the same problem to reach the QNI. Thus, phases 6 & 7 get us a performance penalty, but if we consider that a tear in the common case does not fail in the middle of the network, then we could just follow the procedure above. Anyway, if people are fine with the above, I'll introduce this functionality to the spec. Then we are done with it, and ready for either another WGLC, or AD review. Jukka On Wed, 4 Oct 2006, Bernd Schloer wrote: > Hi Jukka, > > what if the QNE asks GIST to remove routing state after receiving the RESPONSE > to the tearing RESERVE when requested or directly when no response is > requested? > > Bernd > > > 3. If either, or both, should be made possible by the spec, how would this > > affect GIST? A QNE gets a tearing RESERVE, it removes the state (1), > > forwards the message towards the next QNE (2), and may ask GIST to remove > > any routing state for this session. Now, if this QNE later gets back an > > error message, or a RESPONSE, for a session it no longer knows, what does > > the QNE do? Re-set up routing state towards the QNI using GIST, and send > > the message forward? > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 04 16:20:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVDDz-0005Ae-GB; Wed, 04 Oct 2006 16:20:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVDDF-0002jV-SE for nsis@ietf.org; Wed, 04 Oct 2006 16:19:29 -0400 Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVD4U-00045n-Iw for nsis@ietf.org; Wed, 04 Oct 2006 16:10:28 -0400 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx.mail.saic.com; Wed, 4 Oct 2006 16:10:18 -0400 Received: from 0015-ITS-EXBH01.us.saic.com ([10.43.229.18]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006100416101505065 ; Wed, 04 Oct 2006 16:10:17 -0400 Received: from 0591-ITS-EXMP02.us.saic.com ([10.42.81.248]) by 0015-ITS-EXBH01.us.saic.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Oct 2006 16:10:14 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 4 Oct 2006 16:08:57 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426E1CE8E@0591-ITS-EXMP02.us.saic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ieprep] proposed charter 5 priority levels Thread-Index: AcbiVI1Z5372pMhfQ7+veJsSynvFnQDJjEW5AC9o1hAALo0ssAA/lYat References: <62D92A9A02BCC845B202323D49A48426230EBC@0591-ITS-EXMP02.us.saic.com> From: "Roy, Radhika R." To: X-OriginalArrivalTime: 04 Oct 2006 20:10:14.0143 (UTC) FILETIME=[1A5328F0:01C6E7F1] X-Spam-Score: 0.1 (/) X-Scan-Signature: 06d29b9b22258f4f07fe89b4d4a05a86 Cc: "King, Kimberly S." , sob@harvard.edu, curtis@occnc.com Subject: [NSIS] RE: [Ieprep] proposed charter 5 priority levels X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0482396748==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0482396748== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6E7F1.196725EC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6E7F1.196725EC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thought that it might be interesting in this WG as well ... ________________________________ From: Roy, Radhika R. Sent: Tue 10/3/2006 9:58 AM To: 'curtis@occnc.com' Cc: 'ieprep@ietf.org'; 'sob@harvard.edu'; King, Kimberly S. Subject: RE: [Ieprep] proposed charter 5 priority levels=20 Posting again as it did no go through ... (Curtis: Kindly reply my mail = even if it does not come out of the IETF reflector.) =20 Curtis: =20 Your explanation are OK. It is what we all like to see happen, but the = standards are yet to be there from SIP point of view. =20 If we take the SIP call as an example, there are couple of steps = involved to come to the point of actions in QOS that you have explained. = The steps are as follows: 1. SIP call has couple of priority levels. It is called call-level = priority. That is, if there are the SIP call and the Web call and if the = SIP call has the higher priority precedence that that of the Web call, = SIP call will be treated with higher priority (even if pre-emption is = allowed, Web call may even be pre-empted if needed). The QOS in dealing = with the SIP will be maintained to transfer its call signaling message = with proper QOS. How about the media payload that is supposed to be = transferred once the call is established? 2. Even if the SIP call is set up with proper maintaining proper = QOS level, the SDP message field may contain one or more media. There is = no standard how to map the SIP call-level priority to the media payload = level priority. For example, there may be audio, video, and data = sharing. Audio may have the highest priority and data sharing may be the = second highest priority while video may have the lowest priority. If = there is scarcity in bandwidth in the middle of the communication after = a while, video or data may even be dropped. In summary, there is no IETF = standard for mapping between the call SIP call-level priority to the SDP = media level priority. 3. With respect to RSVP, there is also not any standard in the IETF = to map the SIP call-level priority to media payload level priority level = attributes to the RSVP-level attributes. If someone can map all those = QOS attributes of media payload to RSVP parameters, the rest is simple = or there is at least some standard procedures for providing = some-sort-of-QOS on end-to-end basis to maintain the application QOS, = for example, as you have provided some pointers. (I am also skeptical = here the way IETF NSIS WG is working for QOS signaling. The present NSIS = QOS signaling in rather network-centric, NOT end-to-end = application-centric. There is also a huge disconnect to satisfy the = end-to-end application QOS.) 4. For mapping the QOS from the VoIP call signaling to media = payload attributes to RSVP QOS parameters, there is a complete standard = available in the ITU-T SG16 for H.323 - done almost 8 years ago. But SIP = is yet to do this standard. I hope that you would now understand my concerns that just by saying = that SIP priority levels are there and there is nothing but is simply = like handwaving as if everything is in place and no work is needed in = QOS to fill those gaps. James P. has done a good amount of works for SIP priority levels. He and = Henning S. may point more on this. Sorry for the delayed response. Best regards, Radhika ________________________________ From: curtis@workhorse.brookfield.occnc.com on behalf of Curtis = Villamizar Sent: Wed 9/27/2006 1:32 PM To: Roy, Radhika R. Cc: Ash, Gerald R (Jerry), ALABS; curtis@occnc.com; ieprep@ietf.org Subject: Re: [Ieprep] proposed charter 5 priority levels=20 =20 In message = <62D92A9A02BCC845B202323D49A48426E1CE7E@0591-ITS-EXMP02.us.saic.com> "Roy, Radhika R." writes: >=20 >=20 > Can SIP priority level be mapped to media which is the main objective = of > QOS? If not, what help does it provide with respect to QOS? >=20 > RRR Both SIP priority and DSCP are carried in the RSVP signaling (or NSIS as Jerry pointed out). This allows queues to be dynamically adjusted if need be. Only one DSCP marking is being proposed on the traffic itself so that the SIP priority in the traffic itself cannot be distinguished. This is not regarded as a problem since the traffic is policed and the reservation for this DSCP marking should assure zero drop as long as the policing is effective. This "one marking for all" scheme does preclude the use of highly efficient multiplexing that might introduce limited loss to the lowest priority traffic or allow all traffic classes to exceed their stated allocation (ie: AF where marking is done at ingress, not policing). This does not preclude multiplexing gains. For example, many audio encodings peak at 5-10 times their average BW. This can be specified in the peak, burst size, and average values in RSVP with the policers and queuing set (dynamically if needed) to allow multiplexing but keep loss at zero. Worst case would still be a spike in delay. For example consider audio near a disaster scene. An explosion could cause a spike in audion on many senders. There would be no loss per se but an increase in delay that would exceed the playback jitter buffering and cause a click and may move the jitter buffer out to a longer playback point. If the playback buffer could not compensate, the audio playback of the explosion would not be accurate, but that is probably the least of anyone's worries in this scenario. After the explosion audio would return to normal. Note that policers and queuing can be set dynamically or staticly. If set staticly then blocking would occur when limits were hit. If the ETS traffic is very small compared to the capacity of the network it is running over then static may make sense, or just static queue allocation in the network core. I hope this thoroughly answered your question (and correctly too, if not experts on this please jump in and correct me). I'm learning too but I think I'm coming up to speed. Curtis ------_=_NextPart_001_01C6E7F1.196725EC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Ieprep] proposed charter 5 priority = levels=0A= =0A= =0A= =0A= =0A= =0A=
=0A=
Thought that = it might be interesting in this WG as well ...
=0A=

=0A=
=0A= From: Roy, Radhika = R.
Sent: Tue 10/3/2006 9:58 AM
To: = 'curtis@occnc.com'
Cc: 'ieprep@ietf.org'; 'sob@harvard.edu'; = King, Kimberly S.
Subject: RE: [Ieprep] proposed charter 5 = priority levels

=0A=
=0A=
=0A=
=0A=

Posting again = as it did no go through … (Curtis: Kindly reply my mail even if it = does not come out of the IETF reflector.)

=0A=

 

=0A=

Curtis:

=0A=
=0A=

 

=0A=
=0A=

Your explanation are OK. = It is what we all like to see happen, but the standards are yet to = be there from SIP point of view.

=0A=
=0A=

 

=0A=
=0A=

If we take the SIP call as = an example, there are couple of steps involved to come to the point of = actions in QOS that you have explained. The steps are as = follows:

=0A=
=0A=
=0A=

1.      = SIP call has couple of = priority levels. It is called call-level priority. That is, if there are = the SIP call and the Web call and if the SIP call has the higher = priority precedence that that of the Web call, SIP call will be treated = with higher priority (even if pre-emption is allowed, Web call may even = be pre-empted if needed). The QOS in dealing with the SIP will be = maintained to transfer its call signaling message with proper QOS. How = about the media payload that is supposed to be transferred once the call = is established?

=0A=
=0A=

2.      = Even if the SIP call is = set up with proper maintaining proper QOS level, the SDP message field = may contain one or more media. There is no standard how to map the SIP = call-level priority to the media payload level priority. For example, = there may be audio, video, and data sharing. Audio may have the highest = priority and data sharing may be the second highest priority while video = may have the lowest priority. If there is scarcity in bandwidth in the = middle of the communication after a while, video or data may even be = dropped. In summary, there is no IETF standard for mapping between the = call SIP call-level priority to the SDP media level = priority.

=0A=
=0A=

3.      = With respect to RSVP, = there is also not any standard in the IETF to map the SIP call-level = priority to media payload level priority level attributes to the = RSVP-level attributes. If someone can map all those QOS attributes = of media payload to RSVP parameters, the rest is simple or there is at = least some standard procedures for providing some-sort-of-QOS on = end-to-end basis to maintain the application QOS, for example, = as you have provided some pointers. (I am also skeptical here the way = IETF NSIS WG is working for QOS signaling. The present NSIS QOS = signaling in rather network-centric, NOT end-to-end = application-centric. There is also a huge disconnect to satisfy the = end-to-end application QOS.)

=0A=
=0A=

4.      = For mapping the QOS from = the VoIP call signaling to media payload attributes to RSVP QOS = parameters, there is a complete standard available in the ITU-T SG16 for = H.323 - done almost 8 years ago. But SIP is yet to do this = standard.

=0A=

I hope that you would now understand my concerns = that just by saying that SIP priority levels are there and there is = nothing but is simply like handwaving as if everything is in place = and no work is needed in QOS to fill those gaps.

=0A=

James P. has done a good amount of works for SIP = priority levels. He and Henning S. may point more on = this.

=0A=

Sorry for the delayed response.

=0A=
=0A=

Best = regards,

=0A=
=0A=

Radhika

=0A=
=0A=
=0A=
=0A=
=0A=
=0A=

From: = curtis@workhorse.brookfield.occnc.com on behalf of Curtis = Villamizar
Sent: Wed = 9/27/2006 1:32 PM
To: = Roy, Radhika R.
Cc: = Ash, Gerald R (Jerry), ALABS; curtis@occnc.com; = ieprep@ietf.org
Subject: Re: [Ieprep] proposed charter 5 priority = levels

=0A=
=0A=

 

=0A=

In message = <62D92A9A02BCC845B202323D49A48426E1CE7E@0591-ITS-EXMP02.us.saic.com>= ;
"Roy, Radhika R." writes:
> 
> 
> Can = SIP priority level be mapped to media which is the main objective = of
> QOS? If not, what help does it provide with respect to = QOS?
> 
> RRR


Both SIP priority and DSCP are = carried in the RSVP signaling (or NSIS
as Jerry pointed out).  = This allows queues to be dynamically adjusted
if need be.

Only = one DSCP marking is being proposed on the traffic itself so that
the = SIP priority in the traffic itself cannot be distinguished.  = This
is not regarded as a problem since the traffic is policed and = the
reservation for this DSCP marking should assure zero drop as long = as
the policing is effective.

This "one marking for all" = scheme does preclude the use of highly
efficient multiplexing that = might introduce limited loss to the lowest
priority traffic or allow = all traffic classes to exceed their stated
allocation (ie: AF where = marking is done at ingress, not policing).
This does not preclude = multiplexing gains.  For example, many audio
encodings peak at = 5-10 times their average BW.  This can be specified
in the peak, = burst size, and average values in RSVP with the policers
and queuing = set (dynamically if needed) to allow multiplexing but keep
loss at = zero.

Worst case would still be a spike in delay.  For = example consider
audio near a disaster scene.  An explosion = could cause a spike in
audion on many senders.  There would be = no loss per se but an increase
in delay that would exceed the = playback jitter buffering and cause a
click and may move the jitter = buffer out to a longer playback point.
If the playback buffer could = not compensate, the audio playback of the
explosion would not be = accurate, but that is probably the least of
anyone's worries in this = scenario.  After the explosion audio would
return to = normal.

Note that policers and queuing can be set dynamically or = staticly.  If
set staticly then blocking would occur when limits = were hit.  If the
ETS traffic is very small compared to the = capacity of the network it
is running over then static may make = sense, or just static queue
allocation in the network core.

I = hope this thoroughly answered your question (and correctly too, = if
not experts on this please jump in and correct me).  I'm = learning too
but I think I'm coming up to = speed.

Curtis

------_=_NextPart_001_01C6E7F1.196725EC-- --===============0482396748== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0482396748==-- From nsis-bounces@ietf.org Wed Oct 04 16:20:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVDE6-0005bM-33; Wed, 04 Oct 2006 16:20:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVDDR-00036j-HD for nsis@ietf.org; Wed, 04 Oct 2006 16:19:41 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVCzB-0003PK-LT for nsis@ietf.org; Wed, 04 Oct 2006 16:05:21 -0400 Received: from [192.168.178.22] (pD9548A1D.dip0.t-ipconnect.de [217.84.138.29]) by kyoto.netlab.nec.de (Postfix) with ESMTP id DE1721BAC4D; Wed, 4 Oct 2006 22:04:56 +0200 (CEST) In-Reply-To: <20060829084511.GA27113@mafr.de> References: <20060829084511.GA27113@mafr.de> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3A8B6BF1-3D31-4DF4-8B64-285D43DB10EF@netlab.nec.de> Content-Transfer-Encoding: 7bit From: Martin Stiemerling Date: Wed, 4 Oct 2006 22:04:53 +0200 To: Matthias Friedrich X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Cc: nsis@ietf.org Subject: [NSIS] Re: NATFW: some minor, non-technical issues X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Matthias, Thanks for the nits. More inline. Martin Am 29.08.2006 um 10:45 schrieb Matthias Friedrich: > Hi, > > I'd like to post my list of collected nitpicks (mostly spelling) > before > I lose the file once again. The section numbers have been updated to > draft version -12. > > * Section 3.2.3., first paragraph > "consists" seems to be superfluous here Fixed. > > * Section 3.7.5., item "NSLP responder" > "The _NF_ should never receive NOTIFY messages ..." -> should > be NR Fixed. > > * Section 3.7.6., second paragraph > "The processing when receiving a TRACE message is _the_ different > for ..." Fixed. > > * Section 3.7.7., last paragraph > "... by setting the P flag in the NSLP header _is set_ to P=1 ..." Fixed. > > * Section 3.7.7.1., first paragraph > "In this case, _a_ NR can signal ..." -> an Fixed. > > * Section 3.7.7.1., second paragraph > "The absence of _an_ NONCE object ..." -> a Fixed. > > * Section 3.7.7.2., last paragraph > "Any device beyond this point will never _received_ ..." -> > receive Fixed. > > * Section 5.1.1., first paragraph > "_An_ addition to authentication the nodes will ..." -> In > addition? The sentence was totally broken. It reads now: The nodes will have to authorize each other, additionally to the authentication. > > * Section 5.1.2., first paragraph > "In such a scenario, _a_ the previously discussed ..." Fixed. > > * Section 5.1.3., first paragraph > "In many cases the signaling message initiator might already aware > of ... " -> already _be_ aware Fixed. > > * Section 5.2.4., first sentence > I don't get it. Also, what does the "(*)" mean? Well, basically a good catch. :-) It now reads: When a data receiver DR behind a NAT sends a RESERVE-EXTERNAL-ADDRESS (REA) message to get a public reachable address, this address can be used as a contact address by an arbitrary data sender, if the DR was unable to restrict the future data sender. The (*) means wildcard or not specified. I have added some description for this. > > * Section 5.2.4., third paragraph > "The data _sender_ might want to update the NAT binding ..." > Shouldn't this be the receiver? Yes, should be receiver. Fixed. > > * Section 5.2.4., last paragraph > "The DR MUST be able to specify which data _sender_ are allowed > to traverse the NAT in order to be forwarded to _DRs_ address." > -> plural, DR's Fixed to: The DR MUST be able to specify which data sender is allowed to traverse the NAT in order to be forwarded to DR's address. > > * Section 5.2.5., third paragraph > "By injecting a bogus _responses_ or NOTIFY message, for instance, > _timeout_, a malicious host could try to teardown NATFW NSLP > session > state as well." > -> "responses"? And what is meant by "timeout" here? Responses refers to responses to CREATE/REA. The timeout is the session timeout. Fixed. > > * Section 5.3.1.3., last paragraph > "A NATFW NSLP node MUST be configurable to block unauthorized > signaling _message_." -> plural Fixed. > > * Section 5.4., last paragraph > There is no "firewall FW" in figure 42. Removed the sentences, i.e., it was a left-over from an old version. > > * Section 5.11.1., first paragraph > I'd remove the "provide" after the colon. Removed and fixed. > > * Section 5.11.1., last paragraph > "Hencem" Fixed. Thanks for all the fixes! Martin _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 05 06:27:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVQRd-00051A-4Q; Thu, 05 Oct 2006 06:27:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVQRc-000515-Os for nsis@ietf.org; Thu, 05 Oct 2006 06:27:12 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVQRb-0001vt-Az for nsis@ietf.org; Thu, 05 Oct 2006 06:27:12 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k95AQb9k009873; Thu, 5 Oct 2006 12:26:50 +0200 (MEST) From: "Georgios Karagiannis" To: "'Jukka MJ Manner'" , "'Bernd Schloer'" Subject: RE: [NSIS] A question to people about QoS NSLP Tear operation Date: Thu, 5 Oct 2006 12:26:34 +0200 Message-ID: <000001c6e868$c19a1020$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: Acbn6VZsb30Y6J2mQImWBvPvXz8qbQAfx4IQ In-Reply-To: X-Spam-Score: -5.899 () ALL_TRUSTED,BAYES_00 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Thu, 05 Oct 2006 12:26:54 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jukka I think it is a good solution, that solves the discussed requirements. Best Regards, Georgios -----Original Message----- From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] Sent: woensdag 4 oktober 2006 21:14 To: Bernd Schloer Cc: nsis@ietf.org Subject: Re: [NSIS] A question to people about QoS NSLP Tear operation Yes, that is something I was thinking. Still, we have a small performance problem if no RESPONSE is requested, but there is an error in the processing of a tearing RESERVE. E.g., we have QNI <--> QNE1 <--> QNE2 <--> QNE3 <--> QNR 1. QNI asks to remove a reservation, without confirmation 2. QNE1 does that, asks GIST remove the state, and sends the requests to QNE2 3. QNE does the same and sends the message to QNE3 4. QNE3 noticies some error situation, and sends an error message towards the QNI 5. QNE3 still has a GIST MA with QNE2, and QNE3 can send the error to QNE2 6. QNE2 now does not have anymore a GIST MA towards QN1, thus, it needs to set up one 7. In turn QNE1 gets the same problem to reach the QNI. Thus, phases 6 & 7 get us a performance penalty, but if we consider that a tear in the common case does not fail in the middle of the network, then we could just follow the procedure above. Anyway, if people are fine with the above, I'll introduce this functionality to the spec. Then we are done with it, and ready for either another WGLC, or AD review. Jukka On Wed, 4 Oct 2006, Bernd Schloer wrote: > Hi Jukka, > > what if the QNE asks GIST to remove routing state after receiving the > RESPONSE to the tearing RESERVE when requested or directly when no > response is requested? > > Bernd > > > 3. If either, or both, should be made possible by the spec, how would this > > affect GIST? A QNE gets a tearing RESERVE, it removes the state (1), > > forwards the message towards the next QNE (2), and may ask GIST to remove > > any routing state for this session. Now, if this QNE later gets back an > > error message, or a RESPONSE, for a session it no longer knows, what does > > the QNE do? Re-set up routing state towards the QNI using GIST, and send > > the message forward? > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 05 10:59:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVUgB-00086t-B0; Thu, 05 Oct 2006 10:58:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVUg9-0007wX-ON for nsis@ietf.org; Thu, 05 Oct 2006 10:58:29 -0400 Received: from natklopstock.rzone.de ([81.169.145.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVUYo-00030R-Q7 for nsis@ietf.org; Thu, 05 Oct 2006 10:50:57 -0400 Received: from [192.168.178.200] (p5484B5B4.dip0.t-ipconnect.de [84.132.181.180]) (authenticated bits=0) by post.webmailer.de (8.13.6/8.13.6) with ESMTP id k95EooY6005689; Thu, 5 Oct 2006 16:50:51 +0200 (MEST) Message-ID: <45251BB7.7030403@cs.uni-goettingen.de> Date: Thu, 05 Oct 2006 16:50:31 +0200 From: Bernd Schloer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jukka MJ Manner Subject: Re: [NSIS] A question to people about QoS NSLP Tear operation References: <452404B9.9040102@cs.uni-goettingen.de> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Is it important to send the error message back to the QNI? What can the QNI do QNE2 can't do? It would be more scalable for the network to send the error message not further than QNE2. The QNI has not requested a confirmation. QNE2 can take over the role of the QNI and take care about removing state. Bernd Jukka MJ Manner wrote: > Yes, that is something I was thinking. Still, we have a small performance > problem if no RESPONSE is requested, but there is an error in the > processing of a tearing RESERVE. > > E.g., we have > > QNI <--> QNE1 <--> QNE2 <--> QNE3 <--> QNR > > 1. QNI asks to remove a reservation, without confirmation > 2. QNE1 does that, asks GIST remove the state, and sends the requests to > QNE2 > 3. QNE does the same and sends the message to QNE3 > 4. QNE3 noticies some error situation, and sends an error message towards > the QNI > 5. QNE3 still has a GIST MA with QNE2, and QNE3 can send the error to QNE2 > 6. QNE2 now does not have anymore a GIST MA towards QN1, thus, it needs to > set up one > 7. In turn QNE1 gets the same problem to reach the QNI. > > Thus, phases 6 & 7 get us a performance penalty, but if we consider that a > tear in the common case does not fail in the middle of the network, then > we could just follow the procedure above. > > Anyway, if people are fine with the above, I'll introduce this > functionality to the spec. Then we are done with it, and ready for either > another WGLC, or AD review. > > Jukka > > On Wed, 4 Oct 2006, Bernd Schloer wrote: > > >>Hi Jukka, >> >>what if the QNE asks GIST to remove routing state after receiving the RESPONSE >>to the tearing RESERVE when requested or directly when no response is >>requested? >> >>Bernd >> >> >>>3. If either, or both, should be made possible by the spec, how would this >>> affect GIST? A QNE gets a tearing RESERVE, it removes the state (1), >>> forwards the message towards the next QNE (2), and may ask GIST to remove >>> any routing state for this session. Now, if this QNE later gets back an >>> error message, or a RESPONSE, for a session it no longer knows, what does >>> the QNE do? Re-set up routing state towards the QNI using GIST, and send >>> the message forward? >> >> _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 05 12:54:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVWUC-0004Op-B6; Thu, 05 Oct 2006 12:54:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVWUB-0004Oj-NJ for nsis@ietf.org; Thu, 05 Oct 2006 12:54:15 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVWU3-0007LI-JD for nsis@ietf.org; Thu, 05 Oct 2006 12:54:15 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D5B0E8E0001 for ; Thu, 5 Oct 2006 18:54:04 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Oct 2006 18:54:04 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Oct 2006 18:54:04 +0200 Message-ID: <452538AC.6030902@ericsson.com> Date: Thu, 05 Oct 2006 18:54:04 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: NSIS Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Oct 2006 16:54:04.0069 (UTC) FILETIME=[DD3A2550:01C6E89E] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [NSIS] Discusses on GIST X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org As you may have seen GIST has received a very long list of DISCUSSES. If you have not seen the list it is available here: https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1546&filename=draft-ietf-nsis-ntlp Robert, Henning and John has already done some discussion with me and the ADs that have made some progress on a lot of the issues. In addition the routing directorate review comments are listed as discusses but are not necessary all as strong as DISCUSSes. I will also work during the coming week to consolidate the list for making it more understandable. There are however so many text changes identified to address the comments that the document will go back to the WG for new WG last calls after it has been updated address these issues. There are also a number issues that will require quite a bit more discussion between the Author, WG and the IESG. We will do our best to split up these major issues into individual email threads. The smaller issues I expect Robert to present a summary of what has been discussed so far and what is proposed to fix it. Regards Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 05 13:07:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVWgq-0007lD-Ns; Thu, 05 Oct 2006 13:07:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVWgp-0007l8-Nu for nsis@ietf.org; Thu, 05 Oct 2006 13:07:19 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVWgo-0002YN-98 for nsis@ietf.org; Thu, 05 Oct 2006 13:07:19 -0400 Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Thu, 05 Oct 2006 20:07:13 +0300 id 000AFD8A.45253BC1.000047D6 Date: Thu, 5 Oct 2006 20:07:13 +0300 (EEST) From: Jukka MJ Manner To: Bernd Schloer Subject: Re: [NSIS] A question to people about QoS NSLP Tear operation In-Reply-To: <45251BB7.7030403@cs.uni-goettingen.de> Message-ID: References: <452404B9.9040102@cs.uni-goettingen.de> <45251BB7.7030403@cs.uni-goettingen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, Good point, in most cases this would work. And if there is an error the previous QNEs did not have, most probably the QNI is not anymore able to help either, since it has removed, and lost, all NSLP states it had. Thus, if there is no RII in the tearing RESERVE, any error in the processing should be propagated to the previous hop, but not further. Jukka On Thu, 5 Oct 2006, Bernd Schloer wrote: > Is it important to send the error message back to the QNI? What can the QNI > do > QNE2 can't do? It would be more scalable for the network to send the error > message > not further than QNE2. The QNI has not requested a confirmation. QNE2 can take > over the role of the QNI and take care about removing state. > > Bernd > > > Jukka MJ Manner wrote: > > Yes, that is something I was thinking. Still, we have a small performance > > problem if no RESPONSE is requested, but there is an error in the processing > > of a tearing RESERVE. > > > > E.g., we have > > > > QNI <--> QNE1 <--> QNE2 <--> QNE3 <--> QNR > > > > 1. QNI asks to remove a reservation, without confirmation > > 2. QNE1 does that, asks GIST remove the state, and sends the requests to > > QNE2 > > 3. QNE does the same and sends the message to QNE3 > > 4. QNE3 noticies some error situation, and sends an error message towards > > the QNI > > 5. QNE3 still has a GIST MA with QNE2, and QNE3 can send the error to QNE2 > > 6. QNE2 now does not have anymore a GIST MA towards QN1, thus, it needs to > > set up one > > 7. In turn QNE1 gets the same problem to reach the QNI. > > > > Thus, phases 6 & 7 get us a performance penalty, but if we consider that a > > tear in the common case does not fail in the middle of the network, then we > > could just follow the procedure above. > > > > Anyway, if people are fine with the above, I'll introduce this functionality > > to the spec. Then we are done with it, and ready for either another WGLC, or > > AD review. > > > > Jukka > > > > On Wed, 4 Oct 2006, Bernd Schloer wrote: > > > > > > >Hi Jukka, > > > > > >what if the QNE asks GIST to remove routing state after receiving the > > >RESPONSE > > >to the tearing RESERVE when requested or directly when no response is > > >requested? > > > > > >Bernd > > > > > > > > > >3. If either, or both, should be made possible by the spec, how would > > > >this > > > > affect GIST? A QNE gets a tearing RESERVE, it removes the state (1), > > > > forwards the message towards the next QNE (2), and may ask GIST to > > > > remove > > > > any routing state for this session. Now, if this QNE later gets back > > > > an > > > > error message, or a RESPONSE, for a session it no longer knows, what > > > > does > > > > the QNE do? Re-set up routing state towards the QNI using GIST, and > > > > send > > > > the message forward? > > > > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 05 13:24:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVWwh-00085e-F5; Thu, 05 Oct 2006 13:23:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVWwg-00085X-Sb for nsis@ietf.org; Thu, 05 Oct 2006 13:23:42 -0400 Received: from natblert.rzone.de ([81.169.145.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVWwe-0006fI-EA for nsis@ietf.org; Thu, 05 Oct 2006 13:23:42 -0400 Received: from [192.168.178.200] (p5484B5B4.dip0.t-ipconnect.de [84.132.181.180]) (authenticated bits=0) by post.webmailer.de (8.13.6/8.13.6) with ESMTP id k95HNbbI024494; Thu, 5 Oct 2006 19:23:38 +0200 (MEST) Message-ID: <45253F86.4020209@cs.uni-goettingen.de> Date: Thu, 05 Oct 2006 19:23:18 +0200 From: Bernd Schloer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jukka MJ Manner Subject: Re: [NSIS] A question to people about QoS NSLP Tear operation References: <452404B9.9040102@cs.uni-goettingen.de> <45251BB7.7030403@cs.uni-goettingen.de> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Sounds good to me. Bernd Jukka MJ Manner wrote: > Hi, > > Good point, in most cases this would work. And if there is an error the > previous QNEs did not have, most probably the QNI is not anymore > able to help either, since it has removed, and lost, all NSLP states it > had. > > Thus, if there is no RII in the tearing RESERVE, any error in the > processing should be propagated to the previous hop, but not further. > > Jukka > > On Thu, 5 Oct 2006, Bernd Schloer wrote: > > >>Is it important to send the error message back to the QNI? What can the QNI >>do >>QNE2 can't do? It would be more scalable for the network to send the error >>message >>not further than QNE2. The QNI has not requested a confirmation. QNE2 can take >>over the role of the QNI and take care about removing state. >> >>Bernd >> >> >>Jukka MJ Manner wrote: >> >>>Yes, that is something I was thinking. Still, we have a small performance >>>problem if no RESPONSE is requested, but there is an error in the processing >>>of a tearing RESERVE. >>> >>>E.g., we have >>> >>>QNI <--> QNE1 <--> QNE2 <--> QNE3 <--> QNR >>> >>>1. QNI asks to remove a reservation, without confirmation >>>2. QNE1 does that, asks GIST remove the state, and sends the requests to >>>QNE2 >>>3. QNE does the same and sends the message to QNE3 >>>4. QNE3 noticies some error situation, and sends an error message towards >>>the QNI >>>5. QNE3 still has a GIST MA with QNE2, and QNE3 can send the error to QNE2 >>>6. QNE2 now does not have anymore a GIST MA towards QN1, thus, it needs to >>>set up one >>>7. In turn QNE1 gets the same problem to reach the QNI. >>> >>>Thus, phases 6 & 7 get us a performance penalty, but if we consider that a >>>tear in the common case does not fail in the middle of the network, then we >>>could just follow the procedure above. >>> >>>Anyway, if people are fine with the above, I'll introduce this functionality >>>to the spec. Then we are done with it, and ready for either another WGLC, or >>>AD review. >>> >>>Jukka >>> >>>On Wed, 4 Oct 2006, Bernd Schloer wrote: >>> >>> >>> >>>>Hi Jukka, >>>> >>>>what if the QNE asks GIST to remove routing state after receiving the >>>>RESPONSE >>>>to the tearing RESERVE when requested or directly when no response is >>>>requested? >>>> >>>>Bernd >>>> >>>> >>>> >>>>>3. If either, or both, should be made possible by the spec, how would >>>>>this >>>>> affect GIST? A QNE gets a tearing RESERVE, it removes the state (1), >>>>> forwards the message towards the next QNE (2), and may ask GIST to >>>>> remove >>>>> any routing state for this session. Now, if this QNE later gets back >>>>> an >>>>> error message, or a RESPONSE, for a session it no longer knows, what >>>>> does >>>>> the QNE do? Re-set up routing state towards the QNI using GIST, and >>>>> send >>>>> the message forward? >>>> >>>> _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Oct 06 10:22:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVqa6-0007qS-IW; Fri, 06 Oct 2006 10:21:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVqa3-0007nS-Qb for nsis@ietf.org; Fri, 06 Oct 2006 10:21:40 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVqa2-0005UW-B1 for nsis@ietf.org; Fri, 06 Oct 2006 10:21:39 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id C2FCC1BAC9E for ; Fri, 6 Oct 2006 16:21:37 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <86A92449-6906-4CA6-80A8-518E1BF9D239@netlab.nec.de> Content-Transfer-Encoding: 7bit From: Martin Stiemerling Date: Fri, 6 Oct 2006 16:21:36 +0200 To: nsis X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Subject: [NSIS] Voting: REA Naming Contest (reanco) - the candidates X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Dear all, Even though the REA naming contest (reanco) got stuck for a while, it's still running. The deadline for submitting proposals was Aug 3rd and the final decision should be made before the next IETF meeting for two reasons: a) getting the name in the draft and b) some beer for the winner at the IETF. The candidates for the name we have (given order is **NO** ranking!): a) Open Internal Path (OIP) message <-- my favourite b) Configure Internal Path (CIP) message c) Prepare For Ucreate (PFU) message (where UCREATE is actually now REA) d) Internal Network Configuration (INC) message e) EXT (for playing with the external address and opening firewall holes for external data senders (incoming streams)) f) Open Path Interactive (OPI) message g) Open Interactive Path (OIP) message h) Path Opening Interactive (POI) message i) Interactive Path Opening (IPO) message j) CREATE -> ICREATE (Initiator CREATE); REA -> RCREATE (Responder CREATE) k) CREATE -> SCREATE (Sender CREATE); REA -> RCREATE (Receiver CREATE) **Please send me directly an email with your vote, stating whether you prefer any out of a) to k)! **All votes MUST be done, i.e., in my inbox, by October 12th, 11pm Pacific Time. **If there is no voting at all, the authors will rule the new name. Happy voting!! Martin Am 13.07.2006 um 15:32 schrieb Martin Stiemerling: > Dear All, > > We have discussed about the naming issues for the NATFW NSLP's > RESERVE-EXTERNAL-ADDRESS (REA) message. > > In the past revisions of the NATFW NSLP REA has been used to obtain an > external IP address/port at the outermost NAT (and at in between NATs > too). > But the semantics of REA changed over time from purely NAT usage to a > combined NAT and firewall usage, i.e., a combination of the old REA > and > the old UCREATE. > > REA is used for: > - Used to get external address/port at NAT > - Used to install firewall rules for inbound traffic > - Used in proxy mode usage > > So the current name is not really describing the semantics/usage > anymore > and we need to something different. Since the authors haven't had any > good idea and some off-line discussions didn't bring a good name, we > are starting the > > REA naming contest (reanco) > > This contest calls the NSIS WG for input on name suggestions for the > message currently called REA. > > The contest starts today (actually already yesterday during the > session) > and will run until August 3rd 8am EST. Suggestion made after > August 3rd EST are not accepted anymore. All suggestions must be sent > to the NSIS working group list (nsis@ietf.org). It is not valid to > use a > naming generator that simply tries combinations of characters. > > The one who has suggested the name that will be finally taken as > the new > name for REA will be awarded with a six-pack of local beer at next > IETF in > San Diego. If there are multiple people suggesting the same name, they > must share the six pack (sorry for that, but not enough money for > it ;-) > > Of course all things apply here: participants must be older than 18 > or 21 years > (depending on location of IETF and the local laws), no guarantees, > not entitled > for anything, must be at the next IETF meeting in San Diego in > November 2006, > no monetary refunding, etc... > > > So, looking forward to many suggestion for a "new REA". > > Martin for the NATFW NSLP authors. > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Oct 06 10:30:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVqi9-0005Ek-21; Fri, 06 Oct 2006 10:30:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVqi7-0005EV-08 for nsis@ietf.org; Fri, 06 Oct 2006 10:29:59 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVqi4-0007bU-G5 for nsis@ietf.org; Fri, 06 Oct 2006 10:29:58 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 111591BAC9E for ; Fri, 6 Oct 2006 16:29:56 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <35F9F869-0972-4393-896D-A72B6E6E1935@netlab.nec.de> References: <35F9F869-0972-4393-896D-A72B6E6E1935@netlab.nec.de> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Martin Stiemerling Date: Fri, 6 Oct 2006 16:29:54 +0200 To: nsis X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Subject: [NSIS] Again: NATFW TRACE semantics X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, The semantics of TRACE in the NATFW NSLP is still unclear, i.e., only partially specified. I have already asked for some input on this on May 11th (see attached email) and highlighted the issue in the issue tracker (no. 77) and during the last NSIS session at the 66th IETF meeting in Montreal. See links below as reference. There has still been no input on this and would follow the suggestion made on slide no. 10 of the IETF-66 presentation: Remove TRACE completely. Please respond by October 11th, 11pm Pacific Time, if have semantics for TRACE. If there is no proposal for TRACE semantics, I will remove TRACE completely. Thanks Martin https://kobe.netlab.nec.de/roundup/nsis-natfw-nslp/issue77 http://www3.ietf.org/proceedings/06jul/slides/nsis-16/sld9.htm http://www3.ietf.org/proceedings/06jul/slides/nsis-16/sld10.htm Am 11.05.2006 um 15:07 schrieb Martin Stiemerling: > Dear all, > > This is a request to read about the TRACE message in > the NATFW NSLP draft > (http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp- > natfw-11.txt) > and to comment on it. The semantics of TRACE is preliminary > and we need to get more input on it what exactly TRACE should > do in the opinion of the working group. > > The important section about TRACE are: > - 3.8.6 > - 4.2.8 > - 4.3.5 > > Currently, TRACE can be only sent by the session owner. TRACE > will collect the identifiers of the NATFW NSLP nodes involved > in a particular session. However, it is not specified which identifier > in a case of a NAT is included or what happens if there is a change > of the address family (e.g. from IPv4 to IPv6) is happening. > > Looking forward to the proposals and discussions > > Martin > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sat Oct 07 04:54:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GW7ts-0006Es-3s; Sat, 07 Oct 2006 04:51:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GW7tq-0006At-Fg for nsis@ietf.org; Sat, 07 Oct 2006 04:51:14 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GW7i1-00051A-NH for nsis@ietf.org; Sat, 07 Oct 2006 04:39:03 -0400 Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Sat, 07 Oct 2006 11:38:56 +0300 id 000AFD1A.452767A0.0000626B Date: Sat, 7 Oct 2006 11:38:56 +0300 (EEST) From: Jukka MJ Manner To: Bernd Schloer Subject: Re: [NSIS] A question to people about QoS NSLP Tear operation In-Reply-To: <45253F86.4020209@cs.uni-goettingen.de> Message-ID: References: <452404B9.9040102@cs.uni-goettingen.de> <45251BB7.7030403@cs.uni-goettingen.de> <45253F86.4020209@cs.uni-goettingen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, Actually the proposed solution will not work. When any QNE gets a tearing RESERVE without RII, the QNE accepts it, removes the reservations, and sends it further to the next hop. Now, if this next hop gets into an error situation, it is basically useless to send an error message even to its previous hop (not to mention the QNI), since it has already removed the reservation, and its associated state - only GIST MA is probably still available, but not QoS NSLP state. Thus, we seem to have two options: a) Just note in the spec, that sending error messages related to the processing of a tearing RESERVE is uselsss, or b) define that a QNE SHOULD keep the reservation state for a period of X before finally removing the state. This would allow processing of a error related to tearing. Still, what could a QNE do different then? Regards, Jukka On Thu, 5 Oct 2006, Bernd Schloer wrote: > Sounds good to me. > > Bernd > > > Jukka MJ Manner wrote: > > Hi, > > > > Good point, in most cases this would work. And if there is an error the > > previous QNEs did not have, most probably the QNI is not anymore able to > > help either, since it has removed, and lost, all NSLP states it had. > > > > Thus, if there is no RII in the tearing RESERVE, any error in the processing > > should be propagated to the previous hop, but not further. > > > > Jukka > > > > On Thu, 5 Oct 2006, Bernd Schloer wrote: > > > > > > >Is it important to send the error message back to the QNI? What can the > > >QNI > > >do > > >QNE2 can't do? It would be more scalable for the network to send the error > > >message > > >not further than QNE2. The QNI has not requested a confirmation. QNE2 can > > >take > > >over the role of the QNI and take care about removing state. > > > > > >Bernd > > > > > > > > >Jukka MJ Manner wrote: > > > > > > >Yes, that is something I was thinking. Still, we have a small performance > > > >problem if no RESPONSE is requested, but there is an error in the > > > >processing > > > >of a tearing RESERVE. > > > > > > > >E.g., we have > > > > > > > >QNI <--> QNE1 <--> QNE2 <--> QNE3 <--> QNR > > > > > > > >1. QNI asks to remove a reservation, without confirmation > > > >2. QNE1 does that, asks GIST remove the state, and sends the requests to > > > >QNE2 > > > >3. QNE does the same and sends the message to QNE3 > > > >4. QNE3 noticies some error situation, and sends an error message towards > > > >the QNI > > > >5. QNE3 still has a GIST MA with QNE2, and QNE3 can send the error to > > > >QNE2 > > > >6. QNE2 now does not have anymore a GIST MA towards QN1, thus, it needs > > > >to > > > >set up one > > > >7. In turn QNE1 gets the same problem to reach the QNI. > > > > > > > >Thus, phases 6 & 7 get us a performance penalty, but if we consider that > > > >a > > > >tear in the common case does not fail in the middle of the network, then > > > >we > > > >could just follow the procedure above. > > > > > > > >Anyway, if people are fine with the above, I'll introduce this > > > >functionality > > > >to the spec. Then we are done with it, and ready for either another WGLC, > > > >or > > > >AD review. > > > > > > > >Jukka > > > > > > > >On Wed, 4 Oct 2006, Bernd Schloer wrote: > > > > > > > > > > > > > > > > >Hi Jukka, > > > > > > > > > >what if the QNE asks GIST to remove routing state after receiving the > > > > >RESPONSE > > > > >to the tearing RESERVE when requested or directly when no response is > > > > >requested? > > > > > > > > > >Bernd > > > > > > > > > > > > > > > > > > > > >3. If either, or both, should be made possible by the spec, how would > > > > > >this > > > > > > affect GIST? A QNE gets a tearing RESERVE, it removes the state > > > > > > (1), > > > > > > forwards the message towards the next QNE (2), and may ask GIST to > > > > > > remove > > > > > > any routing state for this session. Now, if this QNE later gets > > > > > > back > > > > > > an > > > > > > error message, or a RESPONSE, for a session it no longer knows, > > > > > > what > > > > > > does > > > > > > the QNE do? Re-set up routing state towards the QNI using GIST, and > > > > > > send > > > > > > the message forward? > > > > > > > > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sat Oct 07 06:40:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GW9aL-0003BV-HL; Sat, 07 Oct 2006 06:39:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GW9aJ-00034y-Py for nsis@ietf.org; Sat, 07 Oct 2006 06:39:11 -0400 Received: from smtp.dei.uc.pt ([193.137.203.228] helo=smtp2.dei.uc.pt) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GW9aH-0008LJ-3X for nsis@ietf.org; Sat, 07 Oct 2006 06:39:11 -0400 Received: from kanito (bl5-223-205.dsl.telepac.pt [82.154.223.205]) (authenticated bits=0) by smtp2.dei.uc.pt (8.13.6/8.13.6) with ESMTP id k97Acn5T012463; Sat, 7 Oct 2006 11:38:50 +0100 Message-Id: <200610071038.k97Acn5T012463@smtp2.dei.uc.pt> From: "David Palma" To: "'Jukka MJ Manner'" , "'Bernd Schloer'" Subject: RE: [NSIS] A question to people about QoS NSLP Tear operation Date: Sat, 7 Oct 2006 11:38:54 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: Thread-Index: Acbp7j9KOLVIXhQHQx2/zzPhj7USsgACvDbQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-FCTUC-DEI-SIC-MailScanner-Information: Please contact helpdesk@dei.uc.pt for more information X-FCTUC-DEI-SIC-MailScanner: Found to be clean X-FCTUC-DEI-SIC-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-4.399, required 3, autolearn=not spam, ALL_TRUSTED -1.80, BAYES_00 -2.60) X-FCTUC-DEI-SIC-MailScanner-From: palma@student.dei.uc.pt X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jukka and all, I agree with everything said in your previous email but would like to = ask a question and suggest some other option. Regarding the second option, by maintaining the reservation state for a certain period of time (almost like soft stat on the first option), if = there is no error and the QNI has not included the RII object (it is not = mandatory right?). We will have a waste of resources on every peer except on the = QNR for every successful reservation.=20 With the first option we only waste some resources when there is an = error (which is not probable as success) and this waste of resources only = affects the peer that produced the error and forward. Although the first option still seems to me less wasteful, none of the options are perfect. From my point of view a mix of the two options = would be perfect. My proposal is: If a RESERVE with the TEAR flag set is sent every peer should check for = the presence of the RII object. If this one exists, the state should not be removed until it receives a successful REPONSE from the QNR (after the QOSNSLP_RETRY_MAX it stops waiting, and acts accordingly). If it does not exists the state should be immediately removed and if = there is some kind of error the soft state will take care of removing all the remaining resources on the path. I hope that I have understood everything correctly and that my proposal makes sense to you. Best Regards, David Palma -----Mensagem original----- De: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI]=20 Enviada: s=E1bado, 7 de Outubro de 2006 9:39 Para: Bernd Schloer Cc: nsis@ietf.org Assunto: Re: [NSIS] A question to people about QoS NSLP Tear operation Hi all, Actually the proposed solution will not work. When any QNE gets a = tearing=20 RESERVE without RII, the QNE accepts it, removes the reservations, and=20 sends it further to the next hop. Now, if this next hop gets into an = error=20 situation, it is basically useless to send an error message even to its=20 previous hop (not to mention the QNI), since it has already removed the=20 reservation, and its associated state - only GIST MA is probably still=20 available, but not QoS NSLP state. Thus, we seem to have two options: a) Just note in the spec, that sending error messages related to the=20 processing of a tearing RESERVE is uselsss, or b) define that a QNE SHOULD keep the reservation state for a period of X = before finally removing the state. This would allow processing of a = error=20 related to tearing. Still, what could a QNE do different then? Regards, Jukka On Thu, 5 Oct 2006, Bernd Schloer wrote: > Sounds good to me. >=20 > Bernd >=20 >=20 > Jukka MJ Manner wrote: > > Hi, > >=20 > > Good point, in most cases this would work. And if there is an error = the > > previous QNEs did not have, most probably the QNI is not anymore = able to > > help either, since it has removed, and lost, all NSLP states it had. > >=20 > > Thus, if there is no RII in the tearing RESERVE, any error in the processing > > should be propagated to the previous hop, but not further. > >=20 > > Jukka > >=20 > > On Thu, 5 Oct 2006, Bernd Schloer wrote: > >=20 > >=20 > > >Is it important to send the error message back to the QNI? What = can the > > >QNI > > >do > > >QNE2 can't do? It would be more scalable for the network to send = the error > > >message > > >not further than QNE2. The QNI has not requested a confirmation. = QNE2 can > > >take > > >over the role of the QNI and take care about removing state. > > > > > >Bernd > > > > > > > > >Jukka MJ Manner wrote: > > > > > > >Yes, that is something I was thinking. Still, we have a small performance > > > >problem if no RESPONSE is requested, but there is an error in the > > > >processing > > > >of a tearing RESERVE. > > > > > > > >E.g., we have > > > > > > > >QNI <--> QNE1 <--> QNE2 <--> QNE3 <--> QNR > > > > > > > >1. QNI asks to remove a reservation, without confirmation > > > >2. QNE1 does that, asks GIST remove the state, and sends the = requests to > > > >QNE2 > > > >3. QNE does the same and sends the message to QNE3 > > > >4. QNE3 noticies some error situation, and sends an error message towards > > > >the QNI > > > >5. QNE3 still has a GIST MA with QNE2, and QNE3 can send the = error to > > > >QNE2 > > > >6. QNE2 now does not have anymore a GIST MA towards QN1, thus, it needs > > > >to > > > >set up one > > > >7. In turn QNE1 gets the same problem to reach the QNI. > > > > > > > >Thus, phases 6 & 7 get us a performance penalty, but if we = consider that > > > >a > > > >tear in the common case does not fail in the middle of the = network, then > > > >we > > > >could just follow the procedure above. > > > > > > > >Anyway, if people are fine with the above, I'll introduce this > > > >functionality > > > >to the spec. Then we are done with it, and ready for either = another WGLC, > > > >or > > > >AD review. > > > > > > > >Jukka > > > > > > > >On Wed, 4 Oct 2006, Bernd Schloer wrote: > > > > > > > > > > > > > > > > >Hi Jukka, > > > > > > > > > >what if the QNE asks GIST to remove routing state after = receiving the > > > > >RESPONSE > > > > >to the tearing RESERVE when requested or directly when no = response is > > > > >requested? > > > > > > > > > >Bernd > > > > > > > > > > > > > > > > > > > > >3. If either, or both, should be made possible by the spec, = how would > > > > > >this=20 > > > > > > affect GIST? A QNE gets a tearing RESERVE, it removes the = state > > > > > > (1), > > > > > > forwards the message towards the next QNE (2), and may ask = GIST to > > > > > > remove > > > > > > any routing state for this session. Now, if this QNE later = gets > > > > > > back > > > > > > an > > > > > > error message, or a RESPONSE, for a session it no longer = knows, > > > > > > what > > > > > > does > > > > > > the QNE do? Re-set up routing state towards the QNI using = GIST, and > > > > > > send > > > > > > the message forward? > > > > > > > > > > >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --=20 Checked by AVG Free Edition. Version: 7.1.407 / Virus Database: 268.13.0/465 - Release Date: = 06-10-2006 =20 --=20 Checked by AVG Free Edition. Version: 7.1.407 / Virus Database: 268.13.0/465 - Release Date: = 06-10-2006 =20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sat Oct 07 12:37:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWFAH-0002GM-6g; Sat, 07 Oct 2006 12:36:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWFAG-0002GG-3n for nsis@ietf.org; Sat, 07 Oct 2006 12:36:40 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWFAE-0005Vt-Ca for nsis@ietf.org; Sat, 07 Oct 2006 12:36:40 -0400 Received: from sbz-30.cs.helsinki.fi (sbz-30.cs.helsinki.fi [128.214.9.98]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Sat, 07 Oct 2006 19:36:33 +0300 id 000AFCEF.4527D791.000045E7 Date: Sat, 7 Oct 2006 19:36:31 +0300 (EEST) From: Jukka MJ Manner To: David Palma Subject: RE: [NSIS] A question to people about QoS NSLP Tear operation In-Reply-To: <200610071038.k97Acn5T012463@smtp2.dei.uc.pt> Message-ID: References: <200610071038.k97Acn5T012463@smtp2.dei.uc.pt> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_courier-17899-1160238998-0001-2" X-Spam-Score: 0.0 (/) X-Scan-Signature: 249cd1efd3d5e0d09114abe826a41235 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_courier-17899-1160238998-0001-2 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from 8bit to quoted-printable by courier 0.47 Hi, That is exactly what I have written in my editor's copy currently. Furthermore, I had an idea for a small additional functionality. When a QNE sends forward a tear, how long should it wait for the RESPONS= E to come back through towards the QNI? I think we have to have some time limit how long we still keep the resources. I was thinking of "one refre= sh interval". At the expiry of the time interval, the QNE will remove the reservation. A QNE must also stop sending periodic refresh messages, eve= n if one was earlier scheduled to be sent. This should not happen, if we consider that proper timer management makes sure that if a node gets any= RESERVE message, it removes it's pending refresh timer, and possibly restart it. Regards, Jukka On Sat, 7 Oct 2006, David Palma wrote: > Hi Jukka and all, > > I agree with everything said in your previous email but would like to = ask a > question and suggest some other option. > > Regarding the second option, by maintaining the reservation state for = a > certain period of time (almost like soft stat on the first option), if= there > is no error and the QNI has not included the RII object (it is not man= datory > right?). We will have a waste of resources on every peer except on the= QNR > for every successful reservation. > > With the first option we only waste some resources when there is an er= ror > (which is not probable as success) and this waste of resources only af= fects > the peer that produced the error and forward. > > Although the first option still seems to me less wasteful, none of the > options are perfect. From my point of view a mix of the two options wo= uld be > perfect. > > My proposal is: > > If a RESERVE with the TEAR flag set is sent every peer should check fo= r the > presence of the RII object. If this one exists, the state should not b= e > removed until it receives a successful REPONSE from the QNR (after the > QOSNSLP_RETRY_MAX it stops waiting, and acts accordingly). > > If it does not exists the state should be immediately removed and if t= here > is some kind of error the soft state will take care of removing all th= e > remaining resources on the path. > > > I hope that I have understood everything correctly and that my proposa= l > makes sense to you. > > Best Regards, > David Palma > > > -----Mensagem original----- > De: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > Enviada: s=E1bado, 7 de Outubro de 2006 9:39 > Para: Bernd Schloer > Cc: nsis@ietf.org > Assunto: Re: [NSIS] A question to people about QoS NSLP Tear operation > > > Hi all, > > Actually the proposed solution will not work. When any QNE gets a tear= ing > RESERVE without RII, the QNE accepts it, removes the reservations, and= > sends it further to the next hop. Now, if this next hop gets into an e= rror > situation, it is basically useless to send an error message even to it= s > previous hop (not to mention the QNI), since it has already removed th= e > reservation, and its associated state - only GIST MA is probably still= > available, but not QoS NSLP state. > > Thus, we seem to have two options: > > a) Just note in the spec, that sending error messages related to the > processing of a tearing RESERVE is uselsss, or > > b) define that a QNE SHOULD keep the reservation state for a period of= X > before finally removing the state. This would allow processing of a er= ror > related to tearing. Still, what could a QNE do different then? > > > Regards, > Jukka > > On Thu, 5 Oct 2006, Bernd Schloer wrote: > > > Sounds good to me. > > > > Bernd > > > > > > Jukka MJ Manner wrote: > > > Hi, > > > > > > Good point, in most cases this would work. And if there is an erro= r the > > > previous QNEs did not have, most probably the QNI is not anymore a= ble to > > > help either, since it has removed, and lost, all NSLP states it ha= d. > > > > > > Thus, if there is no RII in the tearing RESERVE, any error in the > processing > > > should be propagated to the previous hop, but not further. > > > > > > Jukka > > > > > > On Thu, 5 Oct 2006, Bernd Schloer wrote: > > > > > > > > > >Is it important to send the error message back to the QNI? What = can > the > > > >QNI > > > >do > > > >QNE2 can't do? It would be more scalable for the network to send = the > error > > > >message > > > >not further than QNE2. The QNI has not requested a confirmation. = QNE2 > can > > > >take > > > >over the role of the QNI and take care about removing state. > > > > > > > >Bernd > > > > > > > > > > > >Jukka MJ Manner wrote: > > > > > > > > >Yes, that is something I was thinking. Still, we have a small > performance > > > > >problem if no RESPONSE is requested, but there is an error in t= he > > > > >processing > > > > >of a tearing RESERVE. > > > > > > > > > >E.g., we have > > > > > > > > > >QNI <--> QNE1 <--> QNE2 <--> QNE3 <--> QNR > > > > > > > > > >1. QNI asks to remove a reservation, without confirmation > > > > >2. QNE1 does that, asks GIST remove the state, and sends the re= quests > to > > > > >QNE2 > > > > >3. QNE does the same and sends the message to QNE3 > > > > >4. QNE3 noticies some error situation, and sends an error messa= ge > towards > > > > >the QNI > > > > >5. QNE3 still has a GIST MA with QNE2, and QNE3 can send the er= ror to > > > > >QNE2 > > > > >6. QNE2 now does not have anymore a GIST MA towards QN1, thus, = it > needs > > > > >to > > > > >set up one > > > > >7. In turn QNE1 gets the same problem to reach the QNI. > > > > > > > > > >Thus, phases 6 & 7 get us a performance penalty, but if we cons= ider > that > > > > >a > > > > >tear in the common case does not fail in the middle of the netw= ork, > then > > > > >we > > > > >could just follow the procedure above. > > > > > > > > > >Anyway, if people are fine with the above, I'll introduce this > > > > >functionality > > > > >to the spec. Then we are done with it, and ready for either ano= ther > WGLC, > > > > >or > > > > >AD review. > > > > > > > > > >Jukka > > > > > > > > > >On Wed, 4 Oct 2006, Bernd Schloer wrote: > > > > > > > > > > > > > > > > > > > > >Hi Jukka, > > > > > > > > > > > >what if the QNE asks GIST to remove routing state after recei= ving > the > > > > > >RESPONSE > > > > > >to the tearing RESERVE when requested or directly when no res= ponse > is > > > > > >requested? > > > > > > > > > > > >Bernd > > > > > > > > > > > > > > > > > > > > > > > > >3. If either, or both, should be made possible by the spec,= how > would > > > > > > >this > > > > > > > affect GIST? A QNE gets a tearing RESERVE, it removes the= state > > > > > > > (1), > > > > > > > forwards the message towards the next QNE (2), and may as= k GIST > to > > > > > > > remove > > > > > > > any routing state for this session. Now, if this QNE late= r gets > > > > > > > back > > > > > > > an > > > > > > > error message, or a RESPONSE, for a session it no longer = knows, > > > > > > > what > > > > > > > does > > > > > > > the QNE do? Re-set up routing state towards the QNI using= GIST, > and > > > > > > > send > > > > > > > the message forward? > > > > > > > > > > > > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > --=_courier-17899-1160238998-0001-2 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --=_courier-17899-1160238998-0001-2-- From nsis-bounces@ietf.org Sun Oct 08 02:12:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWRsp-0003Ko-Cv; Sun, 08 Oct 2006 02:11:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWRsn-0003Kj-Vr for nsis@ietf.org; Sun, 08 Oct 2006 02:11:29 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWRsl-0003CC-A9 for nsis@ietf.org; Sun, 08 Oct 2006 02:11:29 -0400 Received: from zeus.cs.utwente.nl (zeus.ewi.utwente.nl [130.89.10.12]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k986BLUj020205; Sun, 8 Oct 2006 08:11:21 +0200 (MEST) Received: from janus.ewi.utwente.nl (janus [130.89.10.26]) by zeus.cs.utwente.nl (8.12.10/8.12.10) with ESMTP id k986BLL0007083; Sun, 8 Oct 2006 08:11:21 +0200 (MEST) Received: (from nobody@localhost) by janus.ewi.utwente.nl (8.11.7p1+Sun/8.10.2) id k986BKi29885; Sun, 8 Oct 2006 08:11:20 +0200 (MEST) Date: Sun, 8 Oct 2006 08:11:20 +0200 (MEST) X-Authentication-Warning: janus.ewi.utwente.nl: nobody set sender to karagian@cs.utwente.nl using -f To: jmanner@cs.Helsinki.FI, palma@student.dei.uc.pt Subject: RE: [NSIS] A question to people about QoS NSLP Tear operation Received: from 84.82.109.231 (auth. user karagian@imap2.cs.utwente.nl) by webmail.cs.utwente.nl with HTTP; Sun, 08 Oct 2006 06:11:20 +0000 X-IlohaMail-Blah: karagian@ewi.utwente.nl X-IlohaMail-Method: mail() [mem] X-IlohaMail-Dummy: moo X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -5.668 () ALL_TRUSTED,AWL,BAYES_00,MIME_QP_LONG_LINE X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Sun, 08 Oct 2006 08:11:24 +0200 (MEST) X-Spam-Score: 0.1 (/) X-Scan-Signature: 850245b51c39701e2700a112f3032caa Cc: "nsis@ietf.org" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jukka Please note that this waiting time will influence the way of how the retransmission procedure decribed in Section 5.2.4 QoS-NSLP. If this waiting time is higher than the variable QOSNSLP_REQUEST_RETRY, then the QNI will start a retransmission. I think, in case of a Tear RESERVE, this should not happen. Best Regards, Georgios > >Hi, > >That is exactly what I have written in my editor's copy currently. >Furthermore, I had an idea for a small additional functionality. > >When a QNE sends forward a tear, how long should it wait for the RESPONSE >to come back through towards the QNI? I think we have to have some time >limit how long we still keep the resources. I was thinking of "one refresh >interval". At the expiry of the time interval, the QNE will remove the >reservation. A QNE must also stop sending periodic refresh messages, even >if one was earlier scheduled to be sent. This should not happen, if we >consider that proper timer management makes sure that if a node gets any >RESERVE message, it removes it's pending refresh timer, and possibly >restart it. > >Regards, >Jukka > >On Sat, 7 Oct 2006, David Palma wrote: > >> Hi Jukka and all, >> >> I agree with everything said in your previous email but would like to ask = a >> question and suggest some other option. >> >> Regarding the second option, by maintaining the reservation state for a >> certain period of time (almost like soft stat on the first option), if the= re >> is no error and the QNI has not included the RII object (it is not mandato= ry >> right?). We will have a waste of resources on every peer except on the QNR >> for every successful reservation. >> >> With the first option we only waste some resources when there is an error >> (which is not probable as success) and this waste of resources only affect= s >> the peer that produced the error and forward. >> >> Although the first option still seems to me less wasteful, none of the >> options are perfect. From my point of view a mix of the two options would = be >> perfect. >> >> My proposal is: >> >> If a RESERVE with the TEAR flag set is sent every peer should check for th= e >> presence of the RII object. If this one exists, the state should not be >> removed until it receives a successful REPONSE from the QNR (after the >> QOSNSLP_RETRY_MAX it stops waiting, and acts accordingly). >> >> If it does not exists the state should be immediately removed and if there >> is some kind of error the soft state will take care of removing all the >> remaining resources on the path. >> >> >> I hope that I have understood everything correctly and that my proposal >> makes sense to you. >> >> Best Regards, >> David Palma >> >> >> -----Mensagem original----- >> De: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] >> Enviada: s=E1bado, 7 de Outubro de 2006 9:39 >> Para: Bernd Schloer >> Cc: nsis@ietf.org >> Assunto: Re: [NSIS] A question to people about QoS NSLP Tear operation >> >> >> Hi all, >> >> Actually the proposed solution will not work. When any QNE gets a tearing >> RESERVE without RII, the QNE accepts it, removes the reservations, and >> sends it further to the next hop. Now, if this next hop gets into an error >> situation, it is basically useless to send an error message even to its >> previous hop (not to mention the QNI), since it has already removed the >> reservation, and its associated state - only GIST MA is probably still >> available, but not QoS NSLP state. >> >> Thus, we seem to have two options: >> >> a) Just note in the spec, that sending error messages related to the >> processing of a tearing RESERVE is uselsss, or >> >> b) define that a QNE SHOULD keep the reservation state for a period of X >> before finally removing the state. This would allow processing of a error >> related to tearing. Still, what could a QNE do different then? >> >> >> Regards, >> Jukka >> >> On Thu, 5 Oct 2006, Bernd Schloer wrote: >> >> > Sounds good to me. >> > >> > Bernd >> > >> > >> > Jukka MJ Manner wrote: >> > > Hi, >> > > >> > > Good point, in most cases this would work. And if there is an error th= e >> > > previous QNEs did not have, most probably the QNI is not anymore able = to >> > > help either, since it has removed, and lost, all NSLP states it had. >> > > >> > > Thus, if there is no RII in the tearing RESERVE, any error in the >> processing >> > > should be propagated to the previous hop, but not further. >> > > >> > > Jukka >> > > >> > > On Thu, 5 Oct 2006, Bernd Schloer wrote: >> > > >> > > >> > > >Is it important to send the error message back to the QNI? What can >> the >> > > >QNI >> > > >do >> > > >QNE2 can't do? It would be more scalable for the network to send the >> error >> > > >message >> > > >not further than QNE2. The QNI has not requested a confirmation. QNE2 >> can >> > > >take >> > > >over the role of the QNI and take care about removing state. >> > > > >> > > >Bernd >> > > > >> > > > >> > > >Jukka MJ Manner wrote: >> > > > >> > > > >Yes, that is something I was thinking. Still, we have a small >> performance >> > > > >problem if no RESPONSE is requested, but there is an error in the >> > > > >processing >> > > > >of a tearing RESERVE. >> > > > > >> > > > >E.g., we have >> > > > > >> > > > >QNI <--> QNE1 <--> QNE2 <--> QNE3 <--> QNR >> > > > > >> > > > >1. QNI asks to remove a reservation, without confirmation >> > > > >2. QNE1 does that, asks GIST remove the state, and sends the reques= ts >> to >> > > > >QNE2 >> > > > >3. QNE does the same and sends the message to QNE3 >> > > > >4. QNE3 noticies some error situation, and sends an error message >> towards >> > > > >the QNI >> > > > >5. QNE3 still has a GIST MA with QNE2, and QNE3 can send the error = to >> > > > >QNE2 >> > > > >6. QNE2 now does not have anymore a GIST MA towards QN1, thus, it >> needs >> > > > >to >> > > > >set up one >> > > > >7. In turn QNE1 gets the same problem to reach the QNI. >> > > > > >> > > > >Thus, phases 6 & 7 get us a performance penalty, but if we consider >> that >> > > > >a >> > > > >tear in the common case does not fail in the middle of the network, >> then >> > > > >we >> > > > >could just follow the procedure above. >> > > > > >> > > > >Anyway, if people are fine with the above, I'll introduce this >> > > > >functionality >> > > > >to the spec. Then we are done with it, and ready for either another >> WGLC, >> > > > >or >> > > > >AD review. >> > > > > >> > > > >Jukka >> > > > > >> > > > >On Wed, 4 Oct 2006, Bernd Schloer wrote: >> > > > > >> > > > > >> > > > > >> > > > > >Hi Jukka, >> > > > > > >> > > > > >what if the QNE asks GIST to remove routing state after receiving >> the >> > > > > >RESPONSE >> > > > > >to the tearing RESERVE when requested or directly when no respons= e >> is >> > > > > >requested? >> > > > > > >> > > > > >Bernd >> > > > > > >> > > > > > >> > > > > > >> > > > > > >3. If either, or both, should be made possible by the spec, how >> would >> > > > > > >this >> > > > > > > affect GIST? A QNE gets a tearing RESERVE, it removes the sta= te >> > > > > > > (1), >> > > > > > > forwards the message towards the next QNE (2), and may ask GI= ST >> to >> > > > > > > remove >> > > > > > > any routing state for this session. Now, if this QNE later ge= ts >> > > > > > > back >> > > > > > > an >> > > > > > > error message, or a RESPONSE, for a session it no longer know= s, >> > > > > > > what >> > > > > > > does >> > > > > > > the QNE do? Re-set up routing state towards the QNI using GIS= T, >> and >> > > > > > > send >> > > > > > > the message forward? >> > > > > > >> > > > > > >> > >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis >> >> ) _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Oct 08 12:08:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWbCF-0006ik-7X; Sun, 08 Oct 2006 12:08:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWbCD-0006fr-UE for nsis@ietf.org; Sun, 08 Oct 2006 12:08:09 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWbCD-0008Br-66 for nsis@ietf.org; Sun, 08 Oct 2006 12:08:09 -0400 Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Sun, 08 Oct 2006 19:08:05 +0300 id 000AFD49.45292265.000067E2 Date: Sun, 8 Oct 2006 19:08:03 +0300 (EEST) From: Jukka MJ Manner To: Georgios Karagiannis Subject: RE: [NSIS] A question to people about QoS NSLP Tear operation In-Reply-To: Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_courier-26632-1160323689-0001-2" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9f79b8e383fd3af2b1b5b1d0910f6094 Cc: "nsis@ietf.org" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_courier-26632-1160323689-0001-2 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from 8bit to quoted-printable by courier 0.47 Right. But still, if the QNI _really_ wants a confirmation, shouldn't it= be allowed to use retransmissions? It should in my opinion. But then we have an issue if the QNI retransmits a tearing RESERVE but some QNEs on the path were too eager to remove the reservation. Thus, the time out for removing a reservation in case an RII was used, SHOULD be at least, e.g., twice the QOSNSLP_REQUEST_RETRY value. Jukka On Sun, 8 Oct 2006, Georgios Karagiannis wrote: > > Hi Jukka > > Please note that this waiting time will influence the way of how the > retransmission procedure decribed in Section 5.2.4 QoS-NSLP. > If this waiting time is higher than the variable QOSNSLP_REQUEST_RETRY= , > then the QNI will start a retransmission. I think, in case of a Tear > RESERVE, this should not happen. > > Best Regards, > Georgios > > > > > > > >Hi, > > > >That is exactly what I have written in my editor's copy currently. > >Furthermore, I had an idea for a small additional functionality. > > > >When a QNE sends forward a tear, how long should it wait for the RESP= ONSE > >to come back through towards the QNI? I think we have to have some ti= me > >limit how long we still keep the resources. I was thinking of "one re= fresh > >interval". At the expiry of the time interval, the QNE will remove th= e > >reservation. A QNE must also stop sending periodic refresh messages, = even > >if one was earlier scheduled to be sent. This should not happen, if w= e > >consider that proper timer management makes sure that if a node gets = any > >RESERVE message, it removes it's pending refresh timer, and possibly > >restart it. > > > >Regards, > >Jukka > > > >On Sat, 7 Oct 2006, David Palma wrote: > > > >> Hi Jukka and all, > >> > >> I agree with everything said in your previous email but would like = to ask a > >> question and suggest some other option. > >> > >> Regarding the second option, by maintaining the reservation state f= or a > >> certain period of time (almost like soft stat on the first option),= if there > >> is no error and the QNI has not included the RII object (it is not = mandatory > >> right?). We will have a waste of resources on every peer except on = the QNR > >> for every successful reservation. > >> > >> With the first option we only waste some resources when there is an= error > >> (which is not probable as success) and this waste of resources only= affects > >> the peer that produced the error and forward. > >> > >> Although the first option still seems to me less wasteful, none of = the > >> options are perfect. From my point of view a mix of the two options= would be > >> perfect. > >> > >> My proposal is: > >> > >> If a RESERVE with the TEAR flag set is sent every peer should check= for the > >> presence of the RII object. If this one exists, the state should no= t be > >> removed until it receives a successful REPONSE from the QNR (after = the > >> QOSNSLP_RETRY_MAX it stops waiting, and acts accordingly). > >> > >> If it does not exists the state should be immediately removed and i= f there > >> is some kind of error the soft state will take care of removing all= the > >> remaining resources on the path. > >> > >> > >> I hope that I have understood everything correctly and that my prop= osal > >> makes sense to you. > >> > >> Best Regards, > >> David Palma > >> > >> > >> -----Mensagem original----- > >> De: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > >> Enviada: s=E1bado, 7 de Outubro de 2006 9:39 > >> Para: Bernd Schloer > >> Cc: nsis@ietf.org > >> Assunto: Re: [NSIS] A question to people about QoS NSLP Tear operat= ion > >> > >> > >> Hi all, > >> > >> Actually the proposed solution will not work. When any QNE gets a t= earing > >> RESERVE without RII, the QNE accepts it, removes the reservations, = and > >> sends it further to the next hop. Now, if this next hop gets into a= n error > >> situation, it is basically useless to send an error message even to= its > >> previous hop (not to mention the QNI), since it has already removed= the > >> reservation, and its associated state - only GIST MA is probably st= ill > >> available, but not QoS NSLP state. > >> > >> Thus, we seem to have two options: > >> > >> a) Just note in the spec, that sending error messages related to th= e > >> processing of a tearing RESERVE is uselsss, or > >> > >> b) define that a QNE SHOULD keep the reservation state for a period= of X > >> before finally removing the state. This would allow processing of a= error > >> related to tearing. Still, what could a QNE do different then? > >> > >> > >> Regards, > >> Jukka > >> > >> On Thu, 5 Oct 2006, Bernd Schloer wrote: > >> > >> > Sounds good to me. > >> > > >> > Bernd > >> > > >> > > >> > Jukka MJ Manner wrote: > >> > > Hi, > >> > > > >> > > Good point, in most cases this would work. And if there is an e= rror the > >> > > previous QNEs did not have, most probably the QNI is not anymor= e able to > >> > > help either, since it has removed, and lost, all NSLP states it= had. > >> > > > >> > > Thus, if there is no RII in the tearing RESERVE, any error in t= he > >> processing > >> > > should be propagated to the previous hop, but not further. > >> > > > >> > > Jukka > >> > > > >> > > On Thu, 5 Oct 2006, Bernd Schloer wrote: > >> > > > >> > > > >> > > >Is it important to send the error message back to the QNI? Wh= at can > >> the > >> > > >QNI > >> > > >do > >> > > >QNE2 can't do? It would be more scalable for the network to se= nd the > >> error > >> > > >message > >> > > >not further than QNE2. The QNI has not requested a confirmatio= n. QNE2 > >> can > >> > > >take > >> > > >over the role of the QNI and take care about removing state. > >> > > > > >> > > >Bernd > >> > > > > >> > > > > >> > > >Jukka MJ Manner wrote: > >> > > > > >> > > > >Yes, that is something I was thinking. Still, we have a smal= l > >> performance > >> > > > >problem if no RESPONSE is requested, but there is an error i= n the > >> > > > >processing > >> > > > >of a tearing RESERVE. > >> > > > > > >> > > > >E.g., we have > >> > > > > > >> > > > >QNI <--> QNE1 <--> QNE2 <--> QNE3 <--> QNR > >> > > > > > >> > > > >1. QNI asks to remove a reservation, without confirmation > >> > > > >2. QNE1 does that, asks GIST remove the state, and sends the= requests > >> to > >> > > > >QNE2 > >> > > > >3. QNE does the same and sends the message to QNE3 > >> > > > >4. QNE3 noticies some error situation, and sends an error me= ssage > >> towards > >> > > > >the QNI > >> > > > >5. QNE3 still has a GIST MA with QNE2, and QNE3 can send the= error to > >> > > > >QNE2 > >> > > > >6. QNE2 now does not have anymore a GIST MA towards QN1, thu= s, it > >> needs > >> > > > >to > >> > > > >set up one > >> > > > >7. In turn QNE1 gets the same problem to reach the QNI. > >> > > > > > >> > > > >Thus, phases 6 & 7 get us a performance penalty, but if we c= onsider > >> that > >> > > > >a > >> > > > >tear in the common case does not fail in the middle of the n= etwork, > >> then > >> > > > >we > >> > > > >could just follow the procedure above. > >> > > > > > >> > > > >Anyway, if people are fine with the above, I'll introduce th= is > >> > > > >functionality > >> > > > >to the spec. Then we are done with it, and ready for either = another > >> WGLC, > >> > > > >or > >> > > > >AD review. > >> > > > > > >> > > > >Jukka > >> > > > > > >> > > > >On Wed, 4 Oct 2006, Bernd Schloer wrote: > >> > > > > > >> > > > > > >> > > > > > >> > > > > >Hi Jukka, > >> > > > > > > >> > > > > >what if the QNE asks GIST to remove routing state after re= ceiving > >> the > >> > > > > >RESPONSE > >> > > > > >to the tearing RESERVE when requested or directly when no = response > >> is > >> > > > > >requested? > >> > > > > > > >> > > > > >Bernd > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > >3. If either, or both, should be made possible by the sp= ec, how > >> would > >> > > > > > >this > >> > > > > > > affect GIST? A QNE gets a tearing RESERVE, it removes = the state > >> > > > > > > (1), > >> > > > > > > forwards the message towards the next QNE (2), and may= ask GIST > >> to > >> > > > > > > remove > >> > > > > > > any routing state for this session. Now, if this QNE l= ater gets > >> > > > > > > back > >> > > > > > > an > >> > > > > > > error message, or a RESPONSE, for a session it no long= er knows, > >> > > > > > > what > >> > > > > > > does > >> > > > > > > the QNE do? Re-set up routing state towards the QNI us= ing GIST, > >> and > >> > > > > > > send > >> > > > > > > the message forward? > >> > > > > > > >> > > > > > > >> > > >> > >> _______________________________________________ > >> nsis mailing list > >> nsis@ietf.org > >> https://www1.ietf.org/mailman/listinfo/nsis > >> > >> ) > --=_courier-26632-1160323689-0001-2 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --=_courier-26632-1160323689-0001-2-- From nsis-bounces@ietf.org Sun Oct 08 15:31:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWeMI-0003Bl-7O; Sun, 08 Oct 2006 15:30:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWeMG-0003Bc-6W for nsis@ietf.org; Sun, 08 Oct 2006 15:30:44 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWeME-0007om-Jn for nsis@ietf.org; Sun, 08 Oct 2006 15:30:44 -0400 Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Sun, 08 Oct 2006 22:30:39 +0300 id 000AFD8A.452951DF.00003CEB Date: Sun, 8 Oct 2006 22:30:39 +0300 (EEST) From: Jukka MJ Manner To: nsis@ietf.org Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [NSIS] About the QSPEC 1 vs. 2 discussion X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, I went through again the long discussion about QSPEC- vs. QSPEC-2. In order to get people's opinions, it might be good for Jerry as the QSPEC editor to summarize what is being discussed. ( I think the discussion ended after Rudi's comment :) ). Still, two thoughts about the discussion (I may not have understood all, though): A) How come a QNI making a resource request can dictate (, QSPEC-1) what the network does if the QNI sends illegal amounts of traffic? How come if I make a reservation for 1 Mbps, and then send more than that, I can still ask the network something? If I was a network operator (luckily for us all I'm not ;), I'd drop all packets from the node that tries to send more than it requested resources for. Thus, I think the should be QSPEC-2, at most. B) For the other QSPEC-1 parameters, how can a QNI figure out, e.g., what QoS class its flow should be, if it is making a Controlled Load reservation? Where do I get this information? I want just bandwidth, I don't know anyting about DiffServ or any other class-based schemes. Thus, I'd rather see as more of an optional hint a node can give. And for the other QSPEC-1 parameters, hopefully I don't need to figure out values for them if I don't (want to) understand them. Regards, Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Oct 08 18:39:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWhIP-0005hv-5T; Sun, 08 Oct 2006 18:38:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWhIN-0005hd-8a for nsis@ietf.org; Sun, 08 Oct 2006 18:38:55 -0400 Received: from mclmx2.mail.saic.com ([149.8.64.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWhIL-0003TB-Qd for nsis@ietf.org; Sun, 08 Oct 2006 18:38:55 -0400 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com; Sun, 8 Oct 2006 18:38:41 -0400 Received: from 0015-ITS-EXBH01.us.saic.com ([10.43.229.18]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006100818383401178 ; Sun, 08 Oct 2006 18:38:37 -0400 Received: from 0591-ITS-EXMP02.us.saic.com ([10.42.81.248]) by 0015-ITS-EXBH01.us.saic.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 8 Oct 2006 18:38:33 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [NSIS] About the QSPEC 1 vs. 2 discussion Date: Sun, 8 Oct 2006 18:38:33 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426E1CEA9@0591-ITS-EXMP02.us.saic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] About the QSPEC 1 vs. 2 discussion Thread-Index: AcbrEJcA7uuffDIsRmeOZPjsydvJ8wAFnws4 References: From: "Roy, Radhika R." To: "Jukka MJ Manner" X-OriginalArrivalTime: 08 Oct 2006 22:38:33.0875 (UTC) FILETIME=[7CA17E30:01C6EB2A] X-Spam-Score: 0.1 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1276485184==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============1276485184== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6EB2A.7C423B86" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6EB2A.7C423B86 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Jukka: =20 I appreciate that you are trying to solve the problems of QSPEC. I am = reacting with reference to QOS Classes of QSPEC as referred in your = email. =20 However, do you ever recognize the two fundamental things that = contradict in mapping/interoperability in NSIS QOS as follows: 1.=09 Parameters that can take any values. 2.=09 Parameters that have been "hard-coded" with "specific" values. The whole NSIS QOS signaling specification is based on item 1. If so, why are we muddling with only two items in QSEPC that deal with = item 2? These items in QSPEC are as follows: * Y.xxxx QOS Classes and DSTE QOS classes.=20 * Unlike DiffSev, RSVP, and other QOS schemes these QOS classes are = based on item 2 as mentioned above. If these two QOS classes, Y.xxxx QOS Classes and DSTE QOS, would have = been based on say "GOLD, SILVER, COPPER, or similar to those of like = item 1, there would have been no so much problems for = interworking/mapping in NSIS signaling schemes. What are those Y.xxxx QOS Classes and DSTE QOS classes are based on some = "hard-coded" specific values line 50-ms, 100-ms, 150-ms, etc and not = like bandwidth, delay, jitter, or packet loss. How can one map/interwork between 50-ms class 1 (say Y.xxxx) and 75-ms = class Y (say DSTE)? Had those QOS classes like RSVP parameters been like "Guaranteed," = "Controlled," or "Best-Effort," could we not solve these problems of = mapping/interworking easily? If so, why are we not dropping those = "peculiar" QOS classes from the QSPEC spec? If needed, separate drafts can be written to deal with these Y.xxxx QOS = Classes and DSTE QOS classes in NSIS QOS protocol. There is no hurry for = the IETF to deal with this now in the NSIS WG. I would appreciate your response to deal with these problems. Best regards, Radhika ________________________________ From: nsis-bounces@ietf.org on behalf of Jukka MJ Manner Sent: Sun 10/8/2006 3:30 PM To: nsis@ietf.org Subject: [NSIS] About the QSPEC 1 vs. 2 discussion Hi all, I went through again the long discussion about QSPEC- vs. QSPEC-2. In order to get people's opinions, it might be good for Jerry as the QSPEC editor to summarize what is being discussed. ( I think the discussion ended after Rudi's comment :) ). Still, two thoughts about the discussion (I may not have understood all, though): A) How come a QNI making a resource request can dictate (, QSPEC-1) what the network does if the QNI sends illegal amounts of traffic? How come if I make a reservation for 1 Mbps, and = then send more than that, I can still ask the network something? If I was a network operator (luckily for us all I'm not ;), I'd drop all packets = from the node that tries to send more than it requested resources for. Thus, = I think the should be QSPEC-2, at most. B) For the other QSPEC-1 parameters, how can a QNI figure out, e.g., = what QoS class its flow should be, if it is making a Controlled Load reservation? Where do I get this information? I want just bandwidth, I don't know anyting about DiffServ or any other class-based schemes. Thus, I'd rather see as more of an optional hint a = node can give. And for the other QSPEC-1 parameters, hopefully I don't need = to figure out values for them if I don't (want to) understand them. Regards, Jukka ------_=_NextPart_001_01C6EB2A.7C423B86 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [NSIS] About the QSPEC 1 vs. 2 = discussion=0A= =0A= =0A= =0A=
Hi, = Jukka:
=0A=
 
=0A=
I appreciate that you are = trying to solve the problems of QSPEC. I am reacting with reference to = QOS Classes of QSPEC as referred in your email.
=0A=
 
=0A=
However, do you ever = recognize the two fundamental things that contradict in = mapping/interoperability in  NSIS QOS as follows:
=0A=
=0A=
    =0A=
  1. =0A=
    Parameters that can take any = values.
    2. =0A=
  2. =0A=
    Parameters that have been "hard-coded" = with "specific" values.
=0A=

The whole NSIS QOS signaling = specification is based on item 1.

=0A=

If so, why are we muddling with only two = items in QSEPC that deal with item 2? These items in QSPEC are as = follows:

=0A=
    =0A=
  • Y.xxxx QOS Classes and DSTE QOS classes. =
    • =0A=
  • Unlike DiffSev, RSVP, and other QOS = schemes these QOS classes are based on item 2 as mentioned = above.
=0A=

If these two QOS classes, Y.xxxx QOS = Classes and DSTE QOS, would have been based on say "GOLD, SILVER, = COPPER, or similar to those of like item 1, there would have been no so = much problems for interworking/mapping in NSIS signaling = schemes.

=0A=

What are those Y.xxxx QOS Classes and = DSTE QOS classes are based on some "hard-coded" specific values line = 50-ms, 100-ms, 150-ms, etc and not like bandwidth, delay, jitter, or = packet loss.

=0A=

How can one map/interwork between 50-ms = class 1 (say Y.xxxx) and 75-ms class Y (say DSTE)?

=0A=

Had those QOS classes like RSVP = parameters been like "Guaranteed," "Controlled," or "Best-Effort," could = we not solve these problems of mapping/interworking easily? If so, why = are we not dropping those "peculiar" QOS classes from the QSPEC = spec?

=0A=

If needed, separate drafts can be written = to deal with these Y.xxxx QOS Classes and DSTE QOS classes in NSIS QOS = protocol. There is no hurry for the IETF to deal with this now in the = NSIS WG.

=0A=

I would appreciate your response to deal = with these problems.

=0A=

Best regards,

=0A=

Radhika

=0A=
=0A=
=0A=
=0A=
From: = nsis-bounces@ietf.org on behalf of Jukka MJ Manner
Sent: Sun = 10/8/2006 3:30 PM
To: nsis@ietf.org
Subject: [NSIS] = About the QSPEC 1 vs. 2 discussion

=0A=

=0A=

Hi all,

I went through again the long = discussion about QSPEC- vs. QSPEC-2. In
order to get people's = opinions, it might be good for Jerry as the QSPEC
editor to summarize = what is being discussed. ( I think the discussion
ended after Rudi's = comment :) ).

Still, two thoughts about the discussion (I may not = have understood all,
though):

A) How come a QNI making a = resource request can dictate (<Excess
Treatment>, QSPEC-1) what = the network does if the QNI sends illegal
amounts of traffic? How = come if I make a reservation for 1 Mbps, and then
send more than = that, I can still ask the network something? If I was a
network = operator (luckily for us all I'm not ;), I'd drop all packets = from
the node that tries to send more than it requested resources = for. Thus, I
think the <Excess Treatment> should be QSPEC-2, at = most.

B) For the other QSPEC-1 parameters, how can a QNI figure = out, e.g., what
QoS class its flow should be, if it is making a = Controlled Load
reservation? Where do I get this information? I want = just bandwidth, I
don't know anyting about DiffServ or any other = class-based schemes.

Thus, I'd rather see <Excess = Treatment> as more of an optional hint a node
can give. And for = the other QSPEC-1 parameters, hopefully I don't need to
figure out = values for them if I don't (want to) understand = them.

Regards,
Jukka

------_=_NextPart_001_01C6EB2A.7C423B86-- --===============1276485184== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============1276485184==-- From nsis-bounces@ietf.org Mon Oct 09 02:04:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWoEr-0000ET-Hh; Mon, 09 Oct 2006 02:03:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWoEq-0000EN-7h for nsis@ietf.org; Mon, 09 Oct 2006 02:03:44 -0400 Received: from smtp.mei.co.jp ([133.183.129.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWoEo-00088O-EI for nsis@ietf.org; Mon, 09 Oct 2006 02:03:44 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/jazz) with ESMTP id k9963Vxm020501; Mon, 9 Oct 2006 15:03:31 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id k9963WS28658; Mon, 9 Oct 2006 15:03:32 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/mariners) with ESMTP id k9963T105574; Mon, 9 Oct 2006 15:03:29 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] A question to people about QoS NSLP Tear operation Date: Mon, 9 Oct 2006 14:02:23 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD013661E4@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] A question to people about QoS NSLP Tear operation Thread-Index: AcbqLykDiFkhmJ7jQ9OQ/HZXSRJQhQBON4Lw From: "Cheng Hong" To: "Jukka MJ Manner" , "David Palma" X-Spam-Score: 0.1 (/) X-Scan-Signature: fe105289edd72640d9f392da880eefa2 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jukka, How about when a QNE receives a TEAR, it free the resources of the = reservation (that is a job of RMF), but keep the NSLP state (marked with = a flag) for the confirmation? In this case, no network resources would = be wasted, and the error message could be still correctly processed by = the previous hop. Then, the solution you mentioned earlier could be = used, e.g. the NSLP state to be removed after a timeout, etc. cheers Cheng Hong > -----Original Message----- > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI]=20 > Sent: Sunday, October 08, 2006 12:37 AM > To: David Palma > Cc: nsis@ietf.org > Subject: RE: [NSIS] A question to people about QoS NSLP Tear operation >=20 >=20 > Hi, >=20 > That is exactly what I have written in my editor's copy currently.=20 > Furthermore, I had an idea for a small additional functionality. >=20 > When a QNE sends forward a tear, how long should it wait for=20 > the RESPONSE to come back through towards the QNI? I think we=20 > have to have some time limit how long we still keep the=20 > resources. I was thinking of "one refresh interval". At the=20 > expiry of the time interval, the QNE will remove the=20 > reservation. A QNE must also stop sending periodic refresh=20 > messages, even if one was earlier scheduled to be sent. This=20 > should not happen, if we consider that proper timer=20 > management makes sure that if a node gets any RESERVE=20 > message, it removes it's pending refresh timer, and possibly=20 > restart it. >=20 > Regards, > Jukka >=20 > On Sat, 7 Oct 2006, David Palma wrote: >=20 > > Hi Jukka and all, > >=20 > > I agree with everything said in your previous email but=20 > would like to=20 > > ask a question and suggest some other option. > >=20 > > Regarding the second option, by maintaining the reservation=20 > state for=20 > > a certain period of time (almost like soft stat on the=20 > first option),=20 > > if there is no error and the QNI has not included the RII=20 > object (it=20 > > is not mandatory right?). We will have a waste of resources=20 > on every=20 > > peer except on the QNR for every successful reservation. > >=20 > > With the first option we only waste some resources when there is an=20 > > error (which is not probable as success) and this waste of=20 > resources=20 > > only affects the peer that produced the error and forward. > >=20 > > Although the first option still seems to me less wasteful,=20 > none of the=20 > > options are perfect. From my point of view a mix of the two options=20 > > would be perfect. > >=20 > > My proposal is: > >=20 > > If a RESERVE with the TEAR flag set is sent every peer should check=20 > > for the presence of the RII object. If this one exists, the state=20 > > should not be removed until it receives a successful=20 > REPONSE from the=20 > > QNR (after the QOSNSLP_RETRY_MAX it stops waiting, and acts=20 > accordingly). > >=20 > > If it does not exists the state should be immediately=20 > removed and if=20 > > there is some kind of error the soft state will take care=20 > of removing=20 > > all the remaining resources on the path. > >=20 > >=20 > > I hope that I have understood everything correctly and that my=20 > > proposal makes sense to you. > >=20 > > Best Regards, > > David Palma > >=20 > >=20 > > -----Mensagem original----- > > De: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > Enviada: s=E1bado, 7 de Outubro de 2006 9:39 > > Para: Bernd Schloer > > Cc: nsis@ietf.org > > Assunto: Re: [NSIS] A question to people about QoS NSLP=20 > Tear operation > >=20 > >=20 > > Hi all, > >=20 > > Actually the proposed solution will not work. When any QNE gets a=20 > > tearing RESERVE without RII, the QNE accepts it, removes the=20 > > reservations, and sends it further to the next hop. Now, if=20 > this next=20 > > hop gets into an error situation, it is basically useless=20 > to send an=20 > > error message even to its previous hop (not to mention the=20 > QNI), since=20 > > it has already removed the reservation, and its associated state -=20 > > only GIST MA is probably still available, but not QoS NSLP state. > >=20 > > Thus, we seem to have two options: > >=20 > > a) Just note in the spec, that sending error messages=20 > related to the=20 > > processing of a tearing RESERVE is uselsss, or > >=20 > > b) define that a QNE SHOULD keep the reservation state for=20 > a period of=20 > > X before finally removing the state. This would allow=20 > processing of a=20 > > error related to tearing. Still, what could a QNE do different then? > >=20 > >=20 > > Regards, > > Jukka > >=20 > > On Thu, 5 Oct 2006, Bernd Schloer wrote: > >=20 > > > Sounds good to me. > > >=20 > > > Bernd > > >=20 > > >=20 > > > Jukka MJ Manner wrote: > > > > Hi, > > > >=20 > > > > Good point, in most cases this would work. And if there is an=20 > > > > error the previous QNEs did not have, most probably the=20 > QNI is not=20 > > > > anymore able to help either, since it has removed, and=20 > lost, all NSLP states it had. > > > >=20 > > > > Thus, if there is no RII in the tearing RESERVE, any=20 > error in the > > processing > > > > should be propagated to the previous hop, but not further. > > > >=20 > > > > Jukka > > > >=20 > > > > On Thu, 5 Oct 2006, Bernd Schloer wrote: > > > >=20 > > > >=20 > > > > >Is it important to send the error message back to the=20 > QNI? What=20 > > > > >can > > the > > > > >QNI > > > > >do > > > > >QNE2 can't do? It would be more scalable for the=20 > network to send=20 > > > > >the > > error > > > > >message > > > > >not further than QNE2. The QNI has not requested a=20 > confirmation.=20 > > > > >QNE2 > > can > > > > >take > > > > >over the role of the QNI and take care about removing state. > > > > > > > > > >Bernd > > > > > > > > > > > > > > >Jukka MJ Manner wrote: > > > > > > > > > > >Yes, that is something I was thinking. Still, we have a small > > performance > > > > > >problem if no RESPONSE is requested, but there is an=20 > error in=20 > > > > > >the processing of a tearing RESERVE. > > > > > > > > > > > >E.g., we have > > > > > > > > > > > >QNI <--> QNE1 <--> QNE2 <--> QNE3 <--> QNR > > > > > > > > > > > >1. QNI asks to remove a reservation, without confirmation 2.=20 > > > > > >QNE1 does that, asks GIST remove the state, and sends the=20 > > > > > >requests > > to > > > > > >QNE2 > > > > > >3. QNE does the same and sends the message to QNE3 4. QNE3=20 > > > > > >noticies some error situation, and sends an error message > > towards > > > > > >the QNI > > > > > >5. QNE3 still has a GIST MA with QNE2, and QNE3 can send the=20 > > > > > >error to > > > > > >QNE2 > > > > > >6. QNE2 now does not have anymore a GIST MA towards=20 > QN1, thus,=20 > > > > > >it > > needs > > > > > >to > > > > > >set up one > > > > > >7. In turn QNE1 gets the same problem to reach the QNI. > > > > > > > > > > > >Thus, phases 6 & 7 get us a performance penalty, but if we=20 > > > > > >consider > > that > > > > > >a > > > > > >tear in the common case does not fail in the middle of the=20 > > > > > >network, > > then > > > > > >we > > > > > >could just follow the procedure above. > > > > > > > > > > > >Anyway, if people are fine with the above, I'll=20 > introduce this=20 > > > > > >functionality to the spec. Then we are done with it,=20 > and ready=20 > > > > > >for either another > > WGLC, > > > > > >or > > > > > >AD review. > > > > > > > > > > > >Jukka > > > > > > > > > > > >On Wed, 4 Oct 2006, Bernd Schloer wrote: > > > > > > > > > > > > > > > > > > > > > > > > >Hi Jukka, > > > > > > > > > > > > > >what if the QNE asks GIST to remove routing state after=20 > > > > > > >receiving > > the > > > > > > >RESPONSE > > > > > > >to the tearing RESERVE when requested or directly when no=20 > > > > > > >response > > is > > > > > > >requested? > > > > > > > > > > > > > >Bernd > > > > > > > > > > > > > > > > > > > > > > > > > > > > >3. If either, or both, should be made possible=20 > by the spec,=20 > > > > > > > >how > > would > > > > > > > >this > > > > > > > > affect GIST? A QNE gets a tearing RESERVE, it=20 > removes the=20 > > > > > > > >state > > > > > > > > (1), > > > > > > > > forwards the message towards the next QNE (2), and may=20 > > > > > > > >ask GIST > > to > > > > > > > > remove > > > > > > > > any routing state for this session. Now, if this QNE=20 > > > > > > > > later gets back an error message, or a=20 > RESPONSE, for a=20 > > > > > > > > session it no longer knows, what does the QNE do?=20 > > > > > > > > Re-set up routing state towards the QNI using GIST, > > and > > > > > > > > send > > > > > > > > the message forward? > > > > > > > > > > > > > > > > >=20 > >=20 > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > >=20 > >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 09 04:29:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWqVD-0002E6-VX; Mon, 09 Oct 2006 04:28:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWqVD-0002Bv-Fs for nsis@ietf.org; Mon, 09 Oct 2006 04:28:47 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWqVC-0008Ij-NG for nsis@ietf.org; Mon, 09 Oct 2006 04:28:47 -0400 Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Mon, 09 Oct 2006 11:28:43 +0300 id 000AFD22.452A083B.00007169 Date: Mon, 9 Oct 2006 11:28:42 +0300 (EEST) From: Jukka MJ Manner To: Cheng Hong Subject: RE: [NSIS] A question to people about QoS NSLP Tear operation In-Reply-To: <5F09D220B62F79418461A978CA0921BD013661E4@pslexc01.psl.local> Message-ID: References: <5F09D220B62F79418461A978CA0921BD013661E4@pslexc01.psl.local> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_courier-29037-1160382526-0001-2" X-Spam-Score: 0.0 (/) X-Scan-Signature: e16ce0269ccb2f59707d16700199d13b Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_courier-29037-1160382526-0001-2 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from 8bit to quoted-printable by courier 0.47 Sounds like a good plan. Jukka On Mon, 9 Oct 2006, Cheng Hong wrote: > Hi Jukka, > > How about when a QNE receives a TEAR, it free the resources of the res= ervation (that is a job of RMF), but keep the NSLP state (marked with a = flag) for the confirmation? In this case, no network resources would be = wasted, and the error message could be still correctly processed by the = previous hop. Then, the solution you mentioned earlier could be used, e.= g. the NSLP state to be removed after a timeout, etc. > > cheers > > Cheng Hong > > > > > > > -----Original Message----- > > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > Sent: Sunday, October 08, 2006 12:37 AM > > To: David Palma > > Cc: nsis@ietf.org > > Subject: RE: [NSIS] A question to people about QoS NSLP Tear operati= on > > > > > > Hi, > > > > That is exactly what I have written in my editor's copy currently. > > Furthermore, I had an idea for a small additional functionality. > > > > When a QNE sends forward a tear, how long should it wait for > > the RESPONSE to come back through towards the QNI? I think we > > have to have some time limit how long we still keep the > > resources. I was thinking of "one refresh interval". At the > > expiry of the time interval, the QNE will remove the > > reservation. A QNE must also stop sending periodic refresh > > messages, even if one was earlier scheduled to be sent. This > > should not happen, if we consider that proper timer > > management makes sure that if a node gets any RESERVE > > message, it removes it's pending refresh timer, and possibly > > restart it. > > > > Regards, > > Jukka > > > > On Sat, 7 Oct 2006, David Palma wrote: > > > > > Hi Jukka and all, > > > > > > I agree with everything said in your previous email but > > would like to > > > ask a question and suggest some other option. > > > > > > Regarding the second option, by maintaining the reservation > > state for > > > a certain period of time (almost like soft stat on the > > first option), > > > if there is no error and the QNI has not included the RII > > object (it > > > is not mandatory right?). We will have a waste of resources > > on every > > > peer except on the QNR for every successful reservation. > > > > > > With the first option we only waste some resources when there is a= n > > > error (which is not probable as success) and this waste of > > resources > > > only affects the peer that produced the error and forward. > > > > > > Although the first option still seems to me less wasteful, > > none of the > > > options are perfect. From my point of view a mix of the two option= s > > > would be perfect. > > > > > > My proposal is: > > > > > > If a RESERVE with the TEAR flag set is sent every peer should chec= k > > > for the presence of the RII object. If this one exists, the state > > > should not be removed until it receives a successful > > REPONSE from the > > > QNR (after the QOSNSLP_RETRY_MAX it stops waiting, and acts > > accordingly). > > > > > > If it does not exists the state should be immediately > > removed and if > > > there is some kind of error the soft state will take care > > of removing > > > all the remaining resources on the path. > > > > > > > > > I hope that I have understood everything correctly and that my > > > proposal makes sense to you. > > > > > > Best Regards, > > > David Palma > > > > > > > > > -----Mensagem original----- > > > De: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > > Enviada: s=E1bado, 7 de Outubro de 2006 9:39 > > > Para: Bernd Schloer > > > Cc: nsis@ietf.org > > > Assunto: Re: [NSIS] A question to people about QoS NSLP > > Tear operation > > > > > > > > > Hi all, > > > > > > Actually the proposed solution will not work. When any QNE gets a > > > tearing RESERVE without RII, the QNE accepts it, removes the > > > reservations, and sends it further to the next hop. Now, if > > this next > > > hop gets into an error situation, it is basically useless > > to send an > > > error message even to its previous hop (not to mention the > > QNI), since > > > it has already removed the reservation, and its associated state -= > > > only GIST MA is probably still available, but not QoS NSLP state. > > > > > > Thus, we seem to have two options: > > > > > > a) Just note in the spec, that sending error messages > > related to the > > > processing of a tearing RESERVE is uselsss, or > > > > > > b) define that a QNE SHOULD keep the reservation state for > > a period of > > > X before finally removing the state. This would allow > > processing of a > > > error related to tearing. Still, what could a QNE do different the= n? > > > > > > > > > Regards, > > > Jukka > > > > > > On Thu, 5 Oct 2006, Bernd Schloer wrote: > > > > > > > Sounds good to me. > > > > > > > > Bernd > > > > > > > > > > > > Jukka MJ Manner wrote: > > > > > Hi, > > > > > > > > > > Good point, in most cases this would work. And if there is an > > > > > error the previous QNEs did not have, most probably the > > QNI is not > > > > > anymore able to help either, since it has removed, and > > lost, all NSLP states it had. > > > > > > > > > > Thus, if there is no RII in the tearing RESERVE, any > > error in the > > > processing > > > > > should be propagated to the previous hop, but not further. > > > > > > > > > > Jukka > > > > > > > > > > On Thu, 5 Oct 2006, Bernd Schloer wrote: > > > > > > > > > > > > > > > >Is it important to send the error message back to the > > QNI? What > > > > > >can > > > the > > > > > >QNI > > > > > >do > > > > > >QNE2 can't do? It would be more scalable for the > > network to send > > > > > >the > > > error > > > > > >message > > > > > >not further than QNE2. The QNI has not requested a > > confirmation. > > > > > >QNE2 > > > can > > > > > >take > > > > > >over the role of the QNI and take care about removing state. > > > > > > > > > > > >Bernd > > > > > > > > > > > > > > > > > >Jukka MJ Manner wrote: > > > > > > > > > > > > >Yes, that is something I was thinking. Still, we have a sma= ll > > > performance > > > > > > >problem if no RESPONSE is requested, but there is an > > error in > > > > > > >the processing of a tearing RESERVE. > > > > > > > > > > > > > >E.g., we have > > > > > > > > > > > > > >QNI <--> QNE1 <--> QNE2 <--> QNE3 <--> QNR > > > > > > > > > > > > > >1. QNI asks to remove a reservation, without confirmation 2= . > > > > > > >QNE1 does that, asks GIST remove the state, and sends the > > > > > > >requests > > > to > > > > > > >QNE2 > > > > > > >3. QNE does the same and sends the message to QNE3 4. QNE3 > > > > > > >noticies some error situation, and sends an error message > > > towards > > > > > > >the QNI > > > > > > >5. QNE3 still has a GIST MA with QNE2, and QNE3 can send th= e > > > > > > >error to > > > > > > >QNE2 > > > > > > >6. QNE2 now does not have anymore a GIST MA towards > > QN1, thus, > > > > > > >it > > > needs > > > > > > >to > > > > > > >set up one > > > > > > >7. In turn QNE1 gets the same problem to reach the QNI. > > > > > > > > > > > > > >Thus, phases 6 & 7 get us a performance penalty, but if we > > > > > > >consider > > > that > > > > > > >a > > > > > > >tear in the common case does not fail in the middle of the > > > > > > >network, > > > then > > > > > > >we > > > > > > >could just follow the procedure above. > > > > > > > > > > > > > >Anyway, if people are fine with the above, I'll > > introduce this > > > > > > >functionality to the spec. Then we are done with it, > > and ready > > > > > > >for either another > > > WGLC, > > > > > > >or > > > > > > >AD review. > > > > > > > > > > > > > >Jukka > > > > > > > > > > > > > >On Wed, 4 Oct 2006, Bernd Schloer wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Hi Jukka, > > > > > > > > > > > > > > > >what if the QNE asks GIST to remove routing state after > > > > > > > >receiving > > > the > > > > > > > >RESPONSE > > > > > > > >to the tearing RESERVE when requested or directly when no= > > > > > > > >response > > > is > > > > > > > >requested? > > > > > > > > > > > > > > > >Bernd > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >3. If either, or both, should be made possible > > by the spec, > > > > > > > > >how > > > would > > > > > > > > >this > > > > > > > > > affect GIST? A QNE gets a tearing RESERVE, it > > removes the > > > > > > > > >state > > > > > > > > > (1), > > > > > > > > > forwards the message towards the next QNE (2), and ma= y > > > > > > > > >ask GIST > > > to > > > > > > > > > remove > > > > > > > > > any routing state for this session. Now, if this QNE > > > > > > > > > later gets back an error message, or a > > RESPONSE, for a > > > > > > > > > session it no longer knows, what does the QNE do? > > > > > > > > > Re-set up routing state towards the QNI using GIST, > > > and > > > > > > > > > send > > > > > > > > > the message forward? > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > --=_courier-29037-1160382526-0001-2 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --=_courier-29037-1160382526-0001-2-- From nsis-bounces@ietf.org Mon Oct 09 04:51:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWqqS-0006TI-4a; Mon, 09 Oct 2006 04:50:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWqqQ-0006TD-S2 for nsis@ietf.org; Mon, 09 Oct 2006 04:50:42 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWqqQ-0003jo-81 for nsis@ietf.org; Mon, 09 Oct 2006 04:50:42 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k998oNjx006859; Mon, 9 Oct 2006 10:50:28 +0200 (MEST) From: "Georgios Karagiannis" To: "'Jukka MJ Manner'" , "'Cheng Hong'" Subject: RE: [NSIS] A question to people about QoS NSLP Tear operation Date: Mon, 9 Oct 2006 10:50:20 +0200 Message-ID: <001001c6eb7f$f662ec90$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcbrfVqYEfX967srTd2bIjB91+4giQAAS0wg X-Spam-Score: -5.691 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Mon, 09 Oct 2006 10:50:31 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d9ae72af46718088458d214998cc683 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jukka The problem that I have with the retransmission of tear RESERVE is the following: Consider the following scenario: QNI <----> Ruoter1 <-----> Router2 <------> QNR =20 RS RS RS ----> ------> -----> RP RP XX <----- <---- Note that RS is assumed to be a tear RESERVE that carries a RII object. RP is assumed to be a RESPONSE. Based on what we have discussed in = previous e-mails, QNR will remove the state and Router2 will remove the state when the RESPONSE arrives at Router2. However, the tear RESPONSE is lost before reaching Router1 (this is = shown by XX in above figure).=20 This means that the QNI will retransmit the tear RESERVE. This retransmitted tear RESERVE=20 will be processed by Router1 since the state is not released, but when = the=20 tear RESERVE is sent to Router2 it will not be able to be processed=20 since the state has been removed earlier. Router2 will generate an error RESPONSE message. This error RESPONSE message will again not remove the state in Router1. I am afraid that this problem cannot be easily solved. A solution could be to disalow retransmissions when the tear RESERVE messages=20 are generated by the QNI. If the QNI does not receive a RESPONSE for the tear RESERVE=20 then it will assume that an error occurred, but it will know that=20 the release of all resources is accomplished by the soft state. Best Regards, Georgios =20 -----Original Message----- From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI]=20 Sent: maandag 9 oktober 2006 10:29 To: Cheng Hong Cc: nsis@ietf.org Subject: RE: [NSIS] A question to people about QoS NSLP Tear operation Sounds like a good plan. Jukka On Mon, 9 Oct 2006, Cheng Hong wrote: > Hi Jukka, >=20 > How about when a QNE receives a TEAR, it free the resources of the reservation (that is a job of RMF), but keep the NSLP state (marked with = a flag) for the confirmation? In this case, no network resources would be wasted, and the error message could be still correctly processed by the previous hop. Then, the solution you mentioned earlier could be used, = e.g. the NSLP state to be removed after a timeout, etc. >=20 > cheers >=20 > Cheng Hong >=20 >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > Sent: Sunday, October 08, 2006 12:37 AM > > To: David Palma > > Cc: nsis@ietf.org > > Subject: RE: [NSIS] A question to people about QoS NSLP Tear=20 > > operation > >=20 > >=20 > > Hi, > >=20 > > That is exactly what I have written in my editor's copy currently.=20 > > Furthermore, I had an idea for a small additional functionality. > >=20 > > When a QNE sends forward a tear, how long should it wait for the=20 > > RESPONSE to come back through towards the QNI? I think we have to=20 > > have some time limit how long we still keep the resources. I was=20 > > thinking of "one refresh interval". At the expiry of the time=20 > > interval, the QNE will remove the reservation. A QNE must also stop=20 > > sending periodic refresh messages, even if one was earlier scheduled = > > to be sent. This should not happen, if we consider that proper timer = > > management makes sure that if a node gets any RESERVE message, it=20 > > removes it's pending refresh timer, and possibly restart it. > >=20 > > Regards, > > Jukka > >=20 > > On Sat, 7 Oct 2006, David Palma wrote: > >=20 > > > Hi Jukka and all, > > >=20 > > > I agree with everything said in your previous email but > > would like to > > > ask a question and suggest some other option. > > >=20 > > > Regarding the second option, by maintaining the reservation > > state for > > > a certain period of time (almost like soft stat on the > > first option), > > > if there is no error and the QNI has not included the RII > > object (it > > > is not mandatory right?). We will have a waste of resources > > on every > > > peer except on the QNR for every successful reservation. > > >=20 > > > With the first option we only waste some resources when there is=20 > > > an error (which is not probable as success) and this waste of > > resources > > > only affects the peer that produced the error and forward. > > >=20 > > > Although the first option still seems to me less wasteful, > > none of the > > > options are perfect. From my point of view a mix of the two=20 > > > options would be perfect. > > >=20 > > > My proposal is: > > >=20 > > > If a RESERVE with the TEAR flag set is sent every peer should=20 > > > check for the presence of the RII object. If this one exists, the=20 > > > state should not be removed until it receives a successful > > REPONSE from the > > > QNR (after the QOSNSLP_RETRY_MAX it stops waiting, and acts > > accordingly). > > >=20 > > > If it does not exists the state should be immediately > > removed and if > > > there is some kind of error the soft state will take care > > of removing > > > all the remaining resources on the path. > > >=20 > > >=20 > > > I hope that I have understood everything correctly and that my=20 > > > proposal makes sense to you. > > >=20 > > > Best Regards, > > > David Palma > > >=20 > > >=20 > > > -----Mensagem original----- > > > De: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > > Enviada: s=E1bado, 7 de Outubro de 2006 9:39 > > > Para: Bernd Schloer > > > Cc: nsis@ietf.org > > > Assunto: Re: [NSIS] A question to people about QoS NSLP > > Tear operation > > >=20 > > >=20 > > > Hi all, > > >=20 > > > Actually the proposed solution will not work. When any QNE gets a=20 > > > tearing RESERVE without RII, the QNE accepts it, removes the=20 > > > reservations, and sends it further to the next hop. Now, if > > this next > > > hop gets into an error situation, it is basically useless > > to send an > > > error message even to its previous hop (not to mention the > > QNI), since > > > it has already removed the reservation, and its associated state - = > > > only GIST MA is probably still available, but not QoS NSLP state. > > >=20 > > > Thus, we seem to have two options: > > >=20 > > > a) Just note in the spec, that sending error messages > > related to the > > > processing of a tearing RESERVE is uselsss, or > > >=20 > > > b) define that a QNE SHOULD keep the reservation state for > > a period of > > > X before finally removing the state. This would allow > > processing of a > > > error related to tearing. Still, what could a QNE do different = then? > > >=20 > > >=20 > > > Regards, > > > Jukka > > >=20 > > > On Thu, 5 Oct 2006, Bernd Schloer wrote: > > >=20 > > > > Sounds good to me. > > > >=20 > > > > Bernd > > > >=20 > > > >=20 > > > > Jukka MJ Manner wrote: > > > > > Hi, > > > > >=20 > > > > > Good point, in most cases this would work. And if there is an=20 > > > > > error the previous QNEs did not have, most probably the > > QNI is not > > > > > anymore able to help either, since it has removed, and > > lost, all NSLP states it had. > > > > >=20 > > > > > Thus, if there is no RII in the tearing RESERVE, any > > error in the > > > processing > > > > > should be propagated to the previous hop, but not further. > > > > >=20 > > > > > Jukka > > > > >=20 > > > > > On Thu, 5 Oct 2006, Bernd Schloer wrote: > > > > >=20 > > > > >=20 > > > > > >Is it important to send the error message back to the > > QNI? What > > > > > >can > > > the > > > > > >QNI > > > > > >do > > > > > >QNE2 can't do? It would be more scalable for the > > network to send > > > > > >the > > > error > > > > > >message > > > > > >not further than QNE2. The QNI has not requested a > > confirmation.=20 > > > > > >QNE2 > > > can > > > > > >take > > > > > >over the role of the QNI and take care about removing state. > > > > > > > > > > > >Bernd > > > > > > > > > > > > > > > > > >Jukka MJ Manner wrote: > > > > > > > > > > > > >Yes, that is something I was thinking. Still, we have a=20 > > > > > > >small > > > performance > > > > > > >problem if no RESPONSE is requested, but there is an > > error in > > > > > > >the processing of a tearing RESERVE. > > > > > > > > > > > > > >E.g., we have > > > > > > > > > > > > > >QNI <--> QNE1 <--> QNE2 <--> QNE3 <--> QNR > > > > > > > > > > > > > >1. QNI asks to remove a reservation, without confirmation = 2.=20 > > > > > > >QNE1 does that, asks GIST remove the state, and sends the=20 > > > > > > >requests > > > to > > > > > > >QNE2 > > > > > > >3. QNE does the same and sends the message to QNE3 4. QNE3=20 > > > > > > >noticies some error situation, and sends an error message > > > towards > > > > > > >the QNI > > > > > > >5. QNE3 still has a GIST MA with QNE2, and QNE3 can send=20 > > > > > > >the error to > > > > > > >QNE2 > > > > > > >6. QNE2 now does not have anymore a GIST MA towards > > QN1, thus, > > > > > > >it > > > needs > > > > > > >to > > > > > > >set up one > > > > > > >7. In turn QNE1 gets the same problem to reach the QNI. > > > > > > > > > > > > > >Thus, phases 6 & 7 get us a performance penalty, but if we=20 > > > > > > >consider > > > that > > > > > > >a > > > > > > >tear in the common case does not fail in the middle of the=20 > > > > > > >network, > > > then > > > > > > >we > > > > > > >could just follow the procedure above. > > > > > > > > > > > > > >Anyway, if people are fine with the above, I'll > > introduce this > > > > > > >functionality to the spec. Then we are done with it, > > and ready > > > > > > >for either another > > > WGLC, > > > > > > >or > > > > > > >AD review. > > > > > > > > > > > > > >Jukka > > > > > > > > > > > > > >On Wed, 4 Oct 2006, Bernd Schloer wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Hi Jukka, > > > > > > > > > > > > > > > >what if the QNE asks GIST to remove routing state after=20 > > > > > > > >receiving > > > the > > > > > > > >RESPONSE > > > > > > > >to the tearing RESERVE when requested or directly when no = > > > > > > > >response > > > is > > > > > > > >requested? > > > > > > > > > > > > > > > >Bernd > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >3. If either, or both, should be made possible > > by the spec, > > > > > > > > >how > > > would > > > > > > > > >this > > > > > > > > > affect GIST? A QNE gets a tearing RESERVE, it > > removes the > > > > > > > > >state > > > > > > > > > (1), > > > > > > > > > forwards the message towards the next QNE (2), and=20 > > > > > > > > >may ask GIST > > > to > > > > > > > > > remove > > > > > > > > > any routing state for this session. Now, if this QNE=20 > > > > > > > > > later gets back an error message, or a > > RESPONSE, for a > > > > > > > > > session it no longer knows, what does the QNE do?=20 > > > > > > > > > Re-set up routing state towards the QNI using GIST, > > > and > > > > > > > > > send > > > > > > > > > the message forward? > > > > > > > > > > > > > > > > > > > >=20 > > >=20 > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > >=20 > > >=20 > >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 09 05:15:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWrE0-0004aJ-55; Mon, 09 Oct 2006 05:15:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWrDy-0004aC-PC for nsis@ietf.org; Mon, 09 Oct 2006 05:15:02 -0400 Received: from smtp.mei.co.jp ([133.183.129.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWrDw-0007NV-TF for nsis@ietf.org; Mon, 09 Oct 2006 05:15:02 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/bulls) with ESMTP id k999EVUg020387; Mon, 9 Oct 2006 18:14:31 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id k999EXa03797; Mon, 9 Oct 2006 18:14:33 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/expos) with ESMTP id k999EUl20488; Mon, 9 Oct 2006 18:14:30 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] A question to people about QoS NSLP Tear operation Date: Mon, 9 Oct 2006 17:13:40 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD01366274@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] A question to people about QoS NSLP Tear operation Thread-Index: AcbrfVqYEfX967srTd2bIjB91+4giQAAS0wgAADymCA= From: "Cheng Hong" To: "Georgios Karagiannis" , "Jukka MJ Manner" X-Spam-Score: 0.1 (/) X-Scan-Signature: e9d8c60d9288f2c774f26bab15869505 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Georgios, Sounds that we need a reliable tranport for the Response. I think the problem you pointed out could be solved by setting the = criteria of removing of the state to when the RP is successfully = forwarded the next hop, i.e. Router1.=20 Of course, if the transport layer does not support Ack, we may need to = resort to the solution you suggested, i.e. disallow restransmission of = RS. What do you think? cheers Cheng Hong=20 > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 > Sent: Monday, October 09, 2006 4:50 PM > To: 'Jukka MJ Manner'; Cheng Hong > Cc: nsis@ietf.org > Subject: RE: [NSIS] A question to people about QoS NSLP Tear operation >=20 > Hi Jukka >=20 > The problem that I have with the retransmission of tear RESERVE is the > following: >=20 > Consider the following scenario: >=20 > QNI <----> Ruoter1 <-----> Router2 <------> QNR > =20 > RS RS RS > ----> ------> -----> > RP RP > XX <----- <---- >=20 >=20 > Note that RS is assumed to be a tear RESERVE that carries a=20 > RII object. > RP is assumed to be a RESPONSE. Based on what we have=20 > discussed in previous e-mails, QNR will remove the state and=20 > Router2 will remove the state when the RESPONSE arrives at Router2. >=20 > However, the tear RESPONSE is lost before reaching Router1=20 > (this is shown by XX in above figure).=20 > This means that the QNI will retransmit the tear RESERVE. =20 > This retransmitted tear RESERVE will be processed by Router1=20 > since the state is not released, but when the tear RESERVE is=20 > sent to Router2 it will not be able to be processed since the=20 > state has been removed earlier. Router2 will generate an=20 > error RESPONSE message. > This error RESPONSE message will again not remove the state=20 > in Router1. > I am afraid that this problem cannot be easily solved. >=20 > A solution could be to disalow retransmissions when the tear=20 > RESERVE messages are generated by the QNI. If the QNI does=20 > not receive a RESPONSE for the tear RESERVE then it will=20 > assume that an error occurred, but it will know that the=20 > release of all resources is accomplished by the soft state. >=20 >=20 > Best Regards, > Georgios > =20 >=20 > -----Original Message----- > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > Sent: maandag 9 oktober 2006 10:29 > To: Cheng Hong > Cc: nsis@ietf.org > Subject: RE: [NSIS] A question to people about QoS NSLP Tear operation >=20 >=20 > Sounds like a good plan. >=20 > Jukka >=20 > On Mon, 9 Oct 2006, Cheng Hong wrote: >=20 > > Hi Jukka, > >=20 > > How about when a QNE receives a TEAR, it free the resources of the > reservation (that is a job of RMF), but keep the NSLP state=20 > (marked with a > flag) for the confirmation? In this case, no network=20 > resources would be > wasted, and the error message could be still correctly=20 > processed by the > previous hop. Then, the solution you mentioned earlier could=20 > be used, e.g. > the NSLP state to be removed after a timeout, etc. > >=20 > > cheers > >=20 > > Cheng Hong > >=20 > >=20 > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > > Sent: Sunday, October 08, 2006 12:37 AM > > > To: David Palma > > > Cc: nsis@ietf.org > > > Subject: RE: [NSIS] A question to people about QoS NSLP Tear=20 > > > operation > > >=20 > > >=20 > > > Hi, > > >=20 > > > That is exactly what I have written in my editor's copy=20 > currently.=20 > > > Furthermore, I had an idea for a small additional functionality. > > >=20 > > > When a QNE sends forward a tear, how long should it wait for the=20 > > > RESPONSE to come back through towards the QNI? I think we have to=20 > > > have some time limit how long we still keep the resources. I was=20 > > > thinking of "one refresh interval". At the expiry of the time=20 > > > interval, the QNE will remove the reservation. A QNE must=20 > also stop=20 > > > sending periodic refresh messages, even if one was=20 > earlier scheduled=20 > > > to be sent. This should not happen, if we consider that=20 > proper timer=20 > > > management makes sure that if a node gets any RESERVE message, it=20 > > > removes it's pending refresh timer, and possibly restart it. > > >=20 > > > Regards, > > > Jukka > > >=20 > > > On Sat, 7 Oct 2006, David Palma wrote: > > >=20 > > > > Hi Jukka and all, > > > >=20 > > > > I agree with everything said in your previous email but > > > would like to > > > > ask a question and suggest some other option. > > > >=20 > > > > Regarding the second option, by maintaining the reservation > > > state for > > > > a certain period of time (almost like soft stat on the > > > first option), > > > > if there is no error and the QNI has not included the RII > > > object (it > > > > is not mandatory right?). We will have a waste of resources > > > on every > > > > peer except on the QNR for every successful reservation. > > > >=20 > > > > With the first option we only waste some resources when=20 > there is=20 > > > > an error (which is not probable as success) and this waste of > > > resources > > > > only affects the peer that produced the error and forward. > > > >=20 > > > > Although the first option still seems to me less wasteful, > > > none of the > > > > options are perfect. From my point of view a mix of the two=20 > > > > options would be perfect. > > > >=20 > > > > My proposal is: > > > >=20 > > > > If a RESERVE with the TEAR flag set is sent every peer should=20 > > > > check for the presence of the RII object. If this one=20 > exists, the=20 > > > > state should not be removed until it receives a successful > > > REPONSE from the > > > > QNR (after the QOSNSLP_RETRY_MAX it stops waiting, and acts > > > accordingly). > > > >=20 > > > > If it does not exists the state should be immediately > > > removed and if > > > > there is some kind of error the soft state will take care > > > of removing > > > > all the remaining resources on the path. > > > >=20 > > > >=20 > > > > I hope that I have understood everything correctly and that my=20 > > > > proposal makes sense to you. > > > >=20 > > > > Best Regards, > > > > David Palma > > > >=20 > > > >=20 > > > > -----Mensagem original----- > > > > De: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > > > Enviada: s=E1bado, 7 de Outubro de 2006 9:39 > > > > Para: Bernd Schloer > > > > Cc: nsis@ietf.org > > > > Assunto: Re: [NSIS] A question to people about QoS NSLP > > > Tear operation > > > >=20 > > > >=20 > > > > Hi all, > > > >=20 > > > > Actually the proposed solution will not work. When any=20 > QNE gets a=20 > > > > tearing RESERVE without RII, the QNE accepts it, removes the=20 > > > > reservations, and sends it further to the next hop. Now, if > > > this next > > > > hop gets into an error situation, it is basically useless > > > to send an > > > > error message even to its previous hop (not to mention the > > > QNI), since > > > > it has already removed the reservation, and its=20 > associated state -=20 > > > > only GIST MA is probably still available, but not QoS=20 > NSLP state. > > > >=20 > > > > Thus, we seem to have two options: > > > >=20 > > > > a) Just note in the spec, that sending error messages > > > related to the > > > > processing of a tearing RESERVE is uselsss, or > > > >=20 > > > > b) define that a QNE SHOULD keep the reservation state for > > > a period of > > > > X before finally removing the state. This would allow > > > processing of a > > > > error related to tearing. Still, what could a QNE do=20 > different then? > > > >=20 > > > >=20 > > > > Regards, > > > > Jukka > > > >=20 > > > > On Thu, 5 Oct 2006, Bernd Schloer wrote: > > > >=20 > > > > > Sounds good to me. > > > > >=20 > > > > > Bernd > > > > >=20 > > > > >=20 > > > > > Jukka MJ Manner wrote: > > > > > > Hi, > > > > > >=20 > > > > > > Good point, in most cases this would work. And if=20 > there is an=20 > > > > > > error the previous QNEs did not have, most probably the > > > QNI is not > > > > > > anymore able to help either, since it has removed, and > > > lost, all NSLP states it had. > > > > > >=20 > > > > > > Thus, if there is no RII in the tearing RESERVE, any > > > error in the > > > > processing > > > > > > should be propagated to the previous hop, but not further. > > > > > >=20 > > > > > > Jukka > > > > > >=20 > > > > > > On Thu, 5 Oct 2006, Bernd Schloer wrote: > > > > > >=20 > > > > > >=20 > > > > > > >Is it important to send the error message back to the > > > QNI? What > > > > > > >can > > > > the > > > > > > >QNI > > > > > > >do > > > > > > >QNE2 can't do? It would be more scalable for the > > > network to send > > > > > > >the > > > > error > > > > > > >message > > > > > > >not further than QNE2. The QNI has not requested a > > > confirmation.=20 > > > > > > >QNE2 > > > > can > > > > > > >take > > > > > > >over the role of the QNI and take care about=20 > removing state. > > > > > > > > > > > > > >Bernd > > > > > > > > > > > > > > > > > > > > >Jukka MJ Manner wrote: > > > > > > > > > > > > > > >Yes, that is something I was thinking. Still, we have a=20 > > > > > > > >small > > > > performance > > > > > > > >problem if no RESPONSE is requested, but there is an > > > error in > > > > > > > >the processing of a tearing RESERVE. > > > > > > > > > > > > > > > >E.g., we have > > > > > > > > > > > > > > > >QNI <--> QNE1 <--> QNE2 <--> QNE3 <--> QNR > > > > > > > > > > > > > > > >1. QNI asks to remove a reservation, without=20 > confirmation 2.=20 > > > > > > > >QNE1 does that, asks GIST remove the state, and=20 > sends the=20 > > > > > > > >requests > > > > to > > > > > > > >QNE2 > > > > > > > >3. QNE does the same and sends the message to=20 > QNE3 4. QNE3=20 > > > > > > > >noticies some error situation, and sends an error message > > > > towards > > > > > > > >the QNI > > > > > > > >5. QNE3 still has a GIST MA with QNE2, and QNE3 can send=20 > > > > > > > >the error to > > > > > > > >QNE2 > > > > > > > >6. QNE2 now does not have anymore a GIST MA towards > > > QN1, thus, > > > > > > > >it > > > > needs > > > > > > > >to > > > > > > > >set up one > > > > > > > >7. In turn QNE1 gets the same problem to reach the QNI. > > > > > > > > > > > > > > > >Thus, phases 6 & 7 get us a performance penalty,=20 > but if we=20 > > > > > > > >consider > > > > that > > > > > > > >a > > > > > > > >tear in the common case does not fail in the=20 > middle of the=20 > > > > > > > >network, > > > > then > > > > > > > >we > > > > > > > >could just follow the procedure above. > > > > > > > > > > > > > > > >Anyway, if people are fine with the above, I'll > > > introduce this > > > > > > > >functionality to the spec. Then we are done with it, > > > and ready > > > > > > > >for either another > > > > WGLC, > > > > > > > >or > > > > > > > >AD review. > > > > > > > > > > > > > > > >Jukka > > > > > > > > > > > > > > > >On Wed, 4 Oct 2006, Bernd Schloer wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Hi Jukka, > > > > > > > > > > > > > > > > > >what if the QNE asks GIST to remove routing=20 > state after=20 > > > > > > > > >receiving > > > > the > > > > > > > > >RESPONSE > > > > > > > > >to the tearing RESERVE when requested or=20 > directly when no=20 > > > > > > > > >response > > > > is > > > > > > > > >requested? > > > > > > > > > > > > > > > > > >Bernd > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >3. If either, or both, should be made possible > > > by the spec, > > > > > > > > > >how > > > > would > > > > > > > > > >this > > > > > > > > > > affect GIST? A QNE gets a tearing RESERVE, it > > > removes the > > > > > > > > > >state > > > > > > > > > > (1), > > > > > > > > > > forwards the message towards the next QNE (2), and=20 > > > > > > > > > >may ask GIST > > > > to > > > > > > > > > > remove > > > > > > > > > > any routing state for this session. Now,=20 > if this QNE=20 > > > > > > > > > > later gets back an error message, or a > > > RESPONSE, for a > > > > > > > > > > session it no longer knows, what does =20 > the QNE do?=20 > > > > > > > > > > Re-set up routing state towards the QNI using GIST, > > > > and > > > > > > > > > > send > > > > > > > > > > the message forward? > > > > > > > > > > > > > > > > > > > > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > nsis mailing list > > > > nsis@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > >=20 > > > >=20 > > >=20 > >=20 >=20 >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 09 05:25:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWrMz-0003H2-Hq; Mon, 09 Oct 2006 05:24:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWrMy-0003Gw-Qs for nsis@ietf.org; Mon, 09 Oct 2006 05:24:20 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWrMy-0000Vl-4d for nsis@ietf.org; Mon, 09 Oct 2006 05:24:20 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k999O5Fr010021; Mon, 9 Oct 2006 11:24:10 +0200 (MEST) From: "Georgios Karagiannis" To: "'Cheng Hong'" , "'Jukka MJ Manner'" Subject: RE: [NSIS] A question to people about QoS NSLP Tear operation Date: Mon, 9 Oct 2006 11:24:02 +0200 Message-ID: <001c01c6eb84$abb3b710$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <5F09D220B62F79418461A978CA0921BD01366274@pslexc01.psl.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcbrfVqYEfX967srTd2bIjB91+4giQAAS0wgAADymCAAAIcDkA== X-Spam-Score: -5.69 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Mon, 09 Oct 2006 11:24:14 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9e1884bf469cda400682762c3e8d96c9 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Cheng Hong But we cannot always assume that these criteria are met. That is why we=20 are using the retransmission procedure! Best Regards, Georgios -----Original Message----- From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com]=20 Sent: maandag 9 oktober 2006 11:14 To: Georgios Karagiannis; Jukka MJ Manner Cc: nsis@ietf.org Subject: RE: [NSIS] A question to people about QoS NSLP Tear operation Hi Georgios, Sounds that we need a reliable tranport for the Response. I think the problem you pointed out could be solved by setting the = criteria of removing of the state to when the RP is successfully forwarded the = next hop, i.e. Router1.=20 Of course, if the transport layer does not support Ack, we may need to resort to the solution you suggested, i.e. disallow restransmission of = RS. What do you think? cheers Cheng Hong=20 > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > Sent: Monday, October 09, 2006 4:50 PM > To: 'Jukka MJ Manner'; Cheng Hong > Cc: nsis@ietf.org > Subject: RE: [NSIS] A question to people about QoS NSLP Tear operation >=20 > Hi Jukka >=20 > The problem that I have with the retransmission of tear RESERVE is the > following: >=20 > Consider the following scenario: >=20 > QNI <----> Ruoter1 <-----> Router2 <------> QNR > =20 > RS RS RS > ----> ------> -----> > RP RP > XX <----- <---- >=20 >=20 > Note that RS is assumed to be a tear RESERVE that carries a RII=20 > object. > RP is assumed to be a RESPONSE. Based on what we have discussed in=20 > previous e-mails, QNR will remove the state and > Router2 will remove the state when the RESPONSE arrives at Router2. >=20 > However, the tear RESPONSE is lost before reaching Router1 (this is=20 > shown by XX in above figure). > This means that the QNI will retransmit the tear RESERVE. =20 > This retransmitted tear RESERVE will be processed by Router1 since the = > state is not released, but when the tear RESERVE is sent to Router2 it = > will not be able to be processed since the state has been removed=20 > earlier. Router2 will generate an error RESPONSE message. > This error RESPONSE message will again not remove the state in=20 > Router1. > I am afraid that this problem cannot be easily solved. >=20 > A solution could be to disalow retransmissions when the tear RESERVE=20 > messages are generated by the QNI. If the QNI does not receive a=20 > RESPONSE for the tear RESERVE then it will assume that an error=20 > occurred, but it will know that the release of all resources is=20 > accomplished by the soft state. >=20 >=20 > Best Regards, > Georgios > =20 >=20 > -----Original Message----- > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > Sent: maandag 9 oktober 2006 10:29 > To: Cheng Hong > Cc: nsis@ietf.org > Subject: RE: [NSIS] A question to people about QoS NSLP Tear operation >=20 >=20 > Sounds like a good plan. >=20 > Jukka >=20 > On Mon, 9 Oct 2006, Cheng Hong wrote: >=20 > > Hi Jukka, > >=20 > > How about when a QNE receives a TEAR, it free the resources of the > reservation (that is a job of RMF), but keep the NSLP state (marked=20 > with a > flag) for the confirmation? In this case, no network resources would=20 > be wasted, and the error message could be still correctly processed by = > the previous hop. Then, the solution you mentioned earlier could be=20 > used, e.g. > the NSLP state to be removed after a timeout, etc. > >=20 > > cheers > >=20 > > Cheng Hong > >=20 > >=20 > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > > Sent: Sunday, October 08, 2006 12:37 AM > > > To: David Palma > > > Cc: nsis@ietf.org > > > Subject: RE: [NSIS] A question to people about QoS NSLP Tear=20 > > > operation > > >=20 > > >=20 > > > Hi, > > >=20 > > > That is exactly what I have written in my editor's copy > currently.=20 > > > Furthermore, I had an idea for a small additional functionality. > > >=20 > > > When a QNE sends forward a tear, how long should it wait for the=20 > > > RESPONSE to come back through towards the QNI? I think we have to=20 > > > have some time limit how long we still keep the resources. I was=20 > > > thinking of "one refresh interval". At the expiry of the time=20 > > > interval, the QNE will remove the reservation. A QNE must > also stop > > > sending periodic refresh messages, even if one was > earlier scheduled > > > to be sent. This should not happen, if we consider that > proper timer > > > management makes sure that if a node gets any RESERVE message, it=20 > > > removes it's pending refresh timer, and possibly restart it. > > >=20 > > > Regards, > > > Jukka > > >=20 > > > On Sat, 7 Oct 2006, David Palma wrote: > > >=20 > > > > Hi Jukka and all, > > > >=20 > > > > I agree with everything said in your previous email but > > > would like to > > > > ask a question and suggest some other option. > > > >=20 > > > > Regarding the second option, by maintaining the reservation > > > state for > > > > a certain period of time (almost like soft stat on the > > > first option), > > > > if there is no error and the QNI has not included the RII > > > object (it > > > > is not mandatory right?). We will have a waste of resources > > > on every > > > > peer except on the QNR for every successful reservation. > > > >=20 > > > > With the first option we only waste some resources when > there is > > > > an error (which is not probable as success) and this waste of > > > resources > > > > only affects the peer that produced the error and forward. > > > >=20 > > > > Although the first option still seems to me less wasteful, > > > none of the > > > > options are perfect. From my point of view a mix of the two=20 > > > > options would be perfect. > > > >=20 > > > > My proposal is: > > > >=20 > > > > If a RESERVE with the TEAR flag set is sent every peer should=20 > > > > check for the presence of the RII object. If this one > exists, the > > > > state should not be removed until it receives a successful > > > REPONSE from the > > > > QNR (after the QOSNSLP_RETRY_MAX it stops waiting, and acts > > > accordingly). > > > >=20 > > > > If it does not exists the state should be immediately > > > removed and if > > > > there is some kind of error the soft state will take care > > > of removing > > > > all the remaining resources on the path. > > > >=20 > > > >=20 > > > > I hope that I have understood everything correctly and that my=20 > > > > proposal makes sense to you. > > > >=20 > > > > Best Regards, > > > > David Palma > > > >=20 > > > >=20 > > > > -----Mensagem original----- > > > > De: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > > > Enviada: s=E1bado, 7 de Outubro de 2006 9:39 > > > > Para: Bernd Schloer > > > > Cc: nsis@ietf.org > > > > Assunto: Re: [NSIS] A question to people about QoS NSLP > > > Tear operation > > > >=20 > > > >=20 > > > > Hi all, > > > >=20 > > > > Actually the proposed solution will not work. When any > QNE gets a > > > > tearing RESERVE without RII, the QNE accepts it, removes the=20 > > > > reservations, and sends it further to the next hop. Now, if > > > this next > > > > hop gets into an error situation, it is basically useless > > > to send an > > > > error message even to its previous hop (not to mention the > > > QNI), since > > > > it has already removed the reservation, and its > associated state - > > > > only GIST MA is probably still available, but not QoS > NSLP state. > > > >=20 > > > > Thus, we seem to have two options: > > > >=20 > > > > a) Just note in the spec, that sending error messages > > > related to the > > > > processing of a tearing RESERVE is uselsss, or > > > >=20 > > > > b) define that a QNE SHOULD keep the reservation state for > > > a period of > > > > X before finally removing the state. This would allow > > > processing of a > > > > error related to tearing. Still, what could a QNE do > different then? > > > >=20 > > > >=20 > > > > Regards, > > > > Jukka > > > >=20 > > > > On Thu, 5 Oct 2006, Bernd Schloer wrote: > > > >=20 > > > > > Sounds good to me. > > > > >=20 > > > > > Bernd > > > > >=20 > > > > >=20 > > > > > Jukka MJ Manner wrote: > > > > > > Hi, > > > > > >=20 > > > > > > Good point, in most cases this would work. And if > there is an > > > > > > error the previous QNEs did not have, most probably the > > > QNI is not > > > > > > anymore able to help either, since it has removed, and > > > lost, all NSLP states it had. > > > > > >=20 > > > > > > Thus, if there is no RII in the tearing RESERVE, any > > > error in the > > > > processing > > > > > > should be propagated to the previous hop, but not further. > > > > > >=20 > > > > > > Jukka > > > > > >=20 > > > > > > On Thu, 5 Oct 2006, Bernd Schloer wrote: > > > > > >=20 > > > > > >=20 > > > > > > >Is it important to send the error message back to the > > > QNI? What > > > > > > >can > > > > the > > > > > > >QNI > > > > > > >do > > > > > > >QNE2 can't do? It would be more scalable for the > > > network to send > > > > > > >the > > > > error > > > > > > >message > > > > > > >not further than QNE2. The QNI has not requested a > > > confirmation.=20 > > > > > > >QNE2 > > > > can > > > > > > >take > > > > > > >over the role of the QNI and take care about > removing state. > > > > > > > > > > > > > >Bernd > > > > > > > > > > > > > > > > > > > > >Jukka MJ Manner wrote: > > > > > > > > > > > > > > >Yes, that is something I was thinking. Still, we have a=20 > > > > > > > >small > > > > performance > > > > > > > >problem if no RESPONSE is requested, but there is an > > > error in > > > > > > > >the processing of a tearing RESERVE. > > > > > > > > > > > > > > > >E.g., we have > > > > > > > > > > > > > > > >QNI <--> QNE1 <--> QNE2 <--> QNE3 <--> QNR > > > > > > > > > > > > > > > >1. QNI asks to remove a reservation, without > confirmation 2.=20 > > > > > > > >QNE1 does that, asks GIST remove the state, and > sends the > > > > > > > >requests > > > > to > > > > > > > >QNE2 > > > > > > > >3. QNE does the same and sends the message to > QNE3 4. QNE3 > > > > > > > >noticies some error situation, and sends an error message > > > > towards > > > > > > > >the QNI > > > > > > > >5. QNE3 still has a GIST MA with QNE2, and QNE3 can send=20 > > > > > > > >the error to > > > > > > > >QNE2 > > > > > > > >6. QNE2 now does not have anymore a GIST MA towards > > > QN1, thus, > > > > > > > >it > > > > needs > > > > > > > >to > > > > > > > >set up one > > > > > > > >7. In turn QNE1 gets the same problem to reach the QNI. > > > > > > > > > > > > > > > >Thus, phases 6 & 7 get us a performance penalty, > but if we > > > > > > > >consider > > > > that > > > > > > > >a > > > > > > > >tear in the common case does not fail in the > middle of the > > > > > > > >network, > > > > then > > > > > > > >we > > > > > > > >could just follow the procedure above. > > > > > > > > > > > > > > > >Anyway, if people are fine with the above, I'll > > > introduce this > > > > > > > >functionality to the spec. Then we are done with it, > > > and ready > > > > > > > >for either another > > > > WGLC, > > > > > > > >or > > > > > > > >AD review. > > > > > > > > > > > > > > > >Jukka > > > > > > > > > > > > > > > >On Wed, 4 Oct 2006, Bernd Schloer wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Hi Jukka, > > > > > > > > > > > > > > > > > >what if the QNE asks GIST to remove routing > state after > > > > > > > > >receiving > > > > the > > > > > > > > >RESPONSE > > > > > > > > >to the tearing RESERVE when requested or > directly when no > > > > > > > > >response > > > > is > > > > > > > > >requested? > > > > > > > > > > > > > > > > > >Bernd > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >3. If either, or both, should be made possible > > > by the spec, > > > > > > > > > >how > > > > would > > > > > > > > > >this > > > > > > > > > > affect GIST? A QNE gets a tearing RESERVE, it > > > removes the > > > > > > > > > >state > > > > > > > > > > (1), > > > > > > > > > > forwards the message towards the next QNE (2), and=20 > > > > > > > > > >may ask GIST > > > > to > > > > > > > > > > remove > > > > > > > > > > any routing state for this session. Now, > if this QNE > > > > > > > > > > later gets back an error message, or a > > > RESPONSE, for a > > > > > > > > > > session it no longer knows, what does > the QNE do?=20 > > > > > > > > > > Re-set up routing state towards the QNI using GIST, > > > > and > > > > > > > > > > send > > > > > > > > > > the message forward? > > > > > > > > > > > > > > > > > > > > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > nsis mailing list > > > > nsis@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > >=20 > > > >=20 > > >=20 > >=20 >=20 >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 09 05:28:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWrQ5-0005hi-U3; Mon, 09 Oct 2006 05:27:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWrQ5-0005fB-1g for nsis@ietf.org; Mon, 09 Oct 2006 05:27:33 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWrQ3-00017m-Be for nsis@ietf.org; Mon, 09 Oct 2006 05:27:33 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k999RI1M010357; Mon, 9 Oct 2006 11:27:23 +0200 (MEST) From: "Georgios Karagiannis" To: "'Cheng Hong'" , "'Jukka MJ Manner'" Subject: RE: [NSIS] A question to people about QoS NSLP Tear operation Date: Mon, 9 Oct 2006 11:27:15 +0200 Message-ID: <001d01c6eb85$1edb8b00$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <001c01c6eb84$abb3b710$4c0d5982@dynamic.ewi.utwente.nl> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcbrfVqYEfX967srTd2bIjB91+4giQAAS0wgAADymCAAAIcDkAAAIYXg X-Spam-Score: -5.69 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Mon, 09 Oct 2006 11:27:27 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ce306e4307a2c0b518ae453b13efdd0 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Cheng Hong Sorry I meant: But we cannot always assume that these criteria are met. That is why we = are using the=20 retransmission procedure for RESERVE messages. Best Regards, Georgios -----Original Message----- From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 Sent: maandag 9 oktober 2006 11:24 To: 'Cheng Hong'; 'Jukka MJ Manner' Cc: nsis@ietf.org Subject: RE: [NSIS] A question to people about QoS NSLP Tear operation Hi Cheng Hong But we cannot always assume that these criteria are met. That is why we = are using the retransmission procedure! Best Regards, Georgios -----Original Message----- From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com] Sent: maandag 9 oktober 2006 11:14 To: Georgios Karagiannis; Jukka MJ Manner Cc: nsis@ietf.org Subject: RE: [NSIS] A question to people about QoS NSLP Tear operation Hi Georgios, Sounds that we need a reliable tranport for the Response. I think the problem you pointed out could be solved by setting the = criteria of removing of the state to when the RP is successfully forwarded the = next hop, i.e. Router1.=20 Of course, if the transport layer does not support Ack, we may need to resort to the solution you suggested, i.e. disallow restransmission of = RS. What do you think? cheers Cheng Hong=20 > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > Sent: Monday, October 09, 2006 4:50 PM > To: 'Jukka MJ Manner'; Cheng Hong > Cc: nsis@ietf.org > Subject: RE: [NSIS] A question to people about QoS NSLP Tear operation >=20 > Hi Jukka >=20 > The problem that I have with the retransmission of tear RESERVE is the > following: >=20 > Consider the following scenario: >=20 > QNI <----> Ruoter1 <-----> Router2 <------> QNR > =20 > RS RS RS > ----> ------> -----> > RP RP > XX <----- <---- >=20 >=20 > Note that RS is assumed to be a tear RESERVE that carries a RII=20 > object. > RP is assumed to be a RESPONSE. Based on what we have discussed in=20 > previous e-mails, QNR will remove the state and > Router2 will remove the state when the RESPONSE arrives at Router2. >=20 > However, the tear RESPONSE is lost before reaching Router1 (this is=20 > shown by XX in above figure). > This means that the QNI will retransmit the tear RESERVE. =20 > This retransmitted tear RESERVE will be processed by Router1 since the = > state is not released, but when the tear RESERVE is sent to Router2 it = > will not be able to be processed since the state has been removed=20 > earlier. Router2 will generate an error RESPONSE message. > This error RESPONSE message will again not remove the state in=20 > Router1. > I am afraid that this problem cannot be easily solved. >=20 > A solution could be to disalow retransmissions when the tear RESERVE=20 > messages are generated by the QNI. If the QNI does not receive a=20 > RESPONSE for the tear RESERVE then it will assume that an error=20 > occurred, but it will know that the release of all resources is=20 > accomplished by the soft state. >=20 >=20 > Best Regards, > Georgios > =20 >=20 > -----Original Message----- > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > Sent: maandag 9 oktober 2006 10:29 > To: Cheng Hong > Cc: nsis@ietf.org > Subject: RE: [NSIS] A question to people about QoS NSLP Tear operation >=20 >=20 > Sounds like a good plan. >=20 > Jukka >=20 > On Mon, 9 Oct 2006, Cheng Hong wrote: >=20 > > Hi Jukka, > >=20 > > How about when a QNE receives a TEAR, it free the resources of the > reservation (that is a job of RMF), but keep the NSLP state (marked=20 > with a > flag) for the confirmation? In this case, no network resources would=20 > be wasted, and the error message could be still correctly processed by = > the previous hop. Then, the solution you mentioned earlier could be=20 > used, e.g. > the NSLP state to be removed after a timeout, etc. > >=20 > > cheers > >=20 > > Cheng Hong > >=20 > >=20 > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > > Sent: Sunday, October 08, 2006 12:37 AM > > > To: David Palma > > > Cc: nsis@ietf.org > > > Subject: RE: [NSIS] A question to people about QoS NSLP Tear=20 > > > operation > > >=20 > > >=20 > > > Hi, > > >=20 > > > That is exactly what I have written in my editor's copy > currently.=20 > > > Furthermore, I had an idea for a small additional functionality. > > >=20 > > > When a QNE sends forward a tear, how long should it wait for the=20 > > > RESPONSE to come back through towards the QNI? I think we have to=20 > > > have some time limit how long we still keep the resources. I was=20 > > > thinking of "one refresh interval". At the expiry of the time=20 > > > interval, the QNE will remove the reservation. A QNE must > also stop > > > sending periodic refresh messages, even if one was > earlier scheduled > > > to be sent. This should not happen, if we consider that > proper timer > > > management makes sure that if a node gets any RESERVE message, it=20 > > > removes it's pending refresh timer, and possibly restart it. > > >=20 > > > Regards, > > > Jukka > > >=20 > > > On Sat, 7 Oct 2006, David Palma wrote: > > >=20 > > > > Hi Jukka and all, > > > >=20 > > > > I agree with everything said in your previous email but > > > would like to > > > > ask a question and suggest some other option. > > > >=20 > > > > Regarding the second option, by maintaining the reservation > > > state for > > > > a certain period of time (almost like soft stat on the > > > first option), > > > > if there is no error and the QNI has not included the RII > > > object (it > > > > is not mandatory right?). We will have a waste of resources > > > on every > > > > peer except on the QNR for every successful reservation. > > > >=20 > > > > With the first option we only waste some resources when > there is > > > > an error (which is not probable as success) and this waste of > > > resources > > > > only affects the peer that produced the error and forward. > > > >=20 > > > > Although the first option still seems to me less wasteful, > > > none of the > > > > options are perfect. From my point of view a mix of the two=20 > > > > options would be perfect. > > > >=20 > > > > My proposal is: > > > >=20 > > > > If a RESERVE with the TEAR flag set is sent every peer should=20 > > > > check for the presence of the RII object. If this one > exists, the > > > > state should not be removed until it receives a successful > > > REPONSE from the > > > > QNR (after the QOSNSLP_RETRY_MAX it stops waiting, and acts > > > accordingly). > > > >=20 > > > > If it does not exists the state should be immediately > > > removed and if > > > > there is some kind of error the soft state will take care > > > of removing > > > > all the remaining resources on the path. > > > >=20 > > > >=20 > > > > I hope that I have understood everything correctly and that my=20 > > > > proposal makes sense to you. > > > >=20 > > > > Best Regards, > > > > David Palma > > > >=20 > > > >=20 > > > > -----Mensagem original----- > > > > De: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > > > Enviada: s=E1bado, 7 de Outubro de 2006 9:39 > > > > Para: Bernd Schloer > > > > Cc: nsis@ietf.org > > > > Assunto: Re: [NSIS] A question to people about QoS NSLP > > > Tear operation > > > >=20 > > > >=20 > > > > Hi all, > > > >=20 > > > > Actually the proposed solution will not work. When any > QNE gets a > > > > tearing RESERVE without RII, the QNE accepts it, removes the=20 > > > > reservations, and sends it further to the next hop. Now, if > > > this next > > > > hop gets into an error situation, it is basically useless > > > to send an > > > > error message even to its previous hop (not to mention the > > > QNI), since > > > > it has already removed the reservation, and its > associated state - > > > > only GIST MA is probably still available, but not QoS > NSLP state. > > > >=20 > > > > Thus, we seem to have two options: > > > >=20 > > > > a) Just note in the spec, that sending error messages > > > related to the > > > > processing of a tearing RESERVE is uselsss, or > > > >=20 > > > > b) define that a QNE SHOULD keep the reservation state for > > > a period of > > > > X before finally removing the state. This would allow > > > processing of a > > > > error related to tearing. Still, what could a QNE do > different then? > > > >=20 > > > >=20 > > > > Regards, > > > > Jukka > > > >=20 > > > > On Thu, 5 Oct 2006, Bernd Schloer wrote: > > > >=20 > > > > > Sounds good to me. > > > > >=20 > > > > > Bernd > > > > >=20 > > > > >=20 > > > > > Jukka MJ Manner wrote: > > > > > > Hi, > > > > > >=20 > > > > > > Good point, in most cases this would work. And if > there is an > > > > > > error the previous QNEs did not have, most probably the > > > QNI is not > > > > > > anymore able to help either, since it has removed, and > > > lost, all NSLP states it had. > > > > > >=20 > > > > > > Thus, if there is no RII in the tearing RESERVE, any > > > error in the > > > > processing > > > > > > should be propagated to the previous hop, but not further. > > > > > >=20 > > > > > > Jukka > > > > > >=20 > > > > > > On Thu, 5 Oct 2006, Bernd Schloer wrote: > > > > > >=20 > > > > > >=20 > > > > > > >Is it important to send the error message back to the > > > QNI? What > > > > > > >can > > > > the > > > > > > >QNI > > > > > > >do > > > > > > >QNE2 can't do? It would be more scalable for the > > > network to send > > > > > > >the > > > > error > > > > > > >message > > > > > > >not further than QNE2. The QNI has not requested a > > > confirmation.=20 > > > > > > >QNE2 > > > > can > > > > > > >take > > > > > > >over the role of the QNI and take care about > removing state. > > > > > > > > > > > > > >Bernd > > > > > > > > > > > > > > > > > > > > >Jukka MJ Manner wrote: > > > > > > > > > > > > > > >Yes, that is something I was thinking. Still, we have a=20 > > > > > > > >small > > > > performance > > > > > > > >problem if no RESPONSE is requested, but there is an > > > error in > > > > > > > >the processing of a tearing RESERVE. > > > > > > > > > > > > > > > >E.g., we have > > > > > > > > > > > > > > > >QNI <--> QNE1 <--> QNE2 <--> QNE3 <--> QNR > > > > > > > > > > > > > > > >1. QNI asks to remove a reservation, without > confirmation 2.=20 > > > > > > > >QNE1 does that, asks GIST remove the state, and > sends the > > > > > > > >requests > > > > to > > > > > > > >QNE2 > > > > > > > >3. QNE does the same and sends the message to > QNE3 4. QNE3 > > > > > > > >noticies some error situation, and sends an error message > > > > towards > > > > > > > >the QNI > > > > > > > >5. QNE3 still has a GIST MA with QNE2, and QNE3 can send=20 > > > > > > > >the error to > > > > > > > >QNE2 > > > > > > > >6. QNE2 now does not have anymore a GIST MA towards > > > QN1, thus, > > > > > > > >it > > > > needs > > > > > > > >to > > > > > > > >set up one > > > > > > > >7. In turn QNE1 gets the same problem to reach the QNI. > > > > > > > > > > > > > > > >Thus, phases 6 & 7 get us a performance penalty, > but if we > > > > > > > >consider > > > > that > > > > > > > >a > > > > > > > >tear in the common case does not fail in the > middle of the > > > > > > > >network, > > > > then > > > > > > > >we > > > > > > > >could just follow the procedure above. > > > > > > > > > > > > > > > >Anyway, if people are fine with the above, I'll > > > introduce this > > > > > > > >functionality to the spec. Then we are done with it, > > > and ready > > > > > > > >for either another > > > > WGLC, > > > > > > > >or > > > > > > > >AD review. > > > > > > > > > > > > > > > >Jukka > > > > > > > > > > > > > > > >On Wed, 4 Oct 2006, Bernd Schloer wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Hi Jukka, > > > > > > > > > > > > > > > > > >what if the QNE asks GIST to remove routing > state after > > > > > > > > >receiving > > > > the > > > > > > > > >RESPONSE > > > > > > > > >to the tearing RESERVE when requested or > directly when no > > > > > > > > >response > > > > is > > > > > > > > >requested? > > > > > > > > > > > > > > > > > >Bernd > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >3. If either, or both, should be made possible > > > by the spec, > > > > > > > > > >how > > > > would > > > > > > > > > >this > > > > > > > > > > affect GIST? A QNE gets a tearing RESERVE, it > > > removes the > > > > > > > > > >state > > > > > > > > > > (1), > > > > > > > > > > forwards the message towards the next QNE (2), and=20 > > > > > > > > > >may ask GIST > > > > to > > > > > > > > > > remove > > > > > > > > > > any routing state for this session. Now, > if this QNE > > > > > > > > > > later gets back an error message, or a > > > RESPONSE, for a > > > > > > > > > > session it no longer knows, what does > the QNE do?=20 > > > > > > > > > > Re-set up routing state towards the QNI using GIST, > > > > and > > > > > > > > > > send > > > > > > > > > > the message forward? > > > > > > > > > > > > > > > > > > > > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > nsis mailing list > > > > nsis@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > >=20 > > > >=20 > > >=20 > >=20 >=20 >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 09 06:29:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWsNV-0007GR-QU; Mon, 09 Oct 2006 06:28:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWsNU-0007GM-Pn for nsis@ietf.org; Mon, 09 Oct 2006 06:28:56 -0400 Received: from smtp.mei.co.jp ([133.183.129.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWsNP-0000aC-OF for nsis@ietf.org; Mon, 09 Oct 2006 06:28:56 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kings) with ESMTP id k99ASZEF015717; Mon, 9 Oct 2006 19:28:35 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id k99ASaA00063; Mon, 9 Oct 2006 19:28:36 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/bluejays) with ESMTP id k99ASZ302698; Mon, 9 Oct 2006 19:28:35 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] A question to people about QoS NSLP Tear operation Date: Mon, 9 Oct 2006 18:27:27 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD01366295@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] A question to people about QoS NSLP Tear operation Thread-Index: AcbrfVqYEfX967srTd2bIjB91+4giQAAS0wgAADymCAAAIcDkAAAIYXgAABlPGA= From: "Cheng Hong" To: "Georgios Karagiannis" , "Jukka MJ Manner" X-Spam-Score: 0.1 (/) X-Scan-Signature: 680445c3afe8c9e96925f2dfef141924 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Georgios, After rethinking about the issue, I have a few questions about the error = case you mentioned.=20 Is this retransmission procedure at NSLP layer or at the transport = layer? For the later case, does it mean the reliable transport is = supported? (that is what the re-transmission is for) Then, it seems that = RP would not be lost(it would be retransmitted from Router2 to Router1). = For the earlier case, does the NSLP layer need a timer to decide when to = do retransmission? In that case, after send RP, the Router2 could just = keep the NSLP state until the timer expires (this should not matter = since the actual resources are already released). Would this avoid the = error case? cheers Cheng Hong =20 > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 > Sent: Monday, October 09, 2006 5:27 PM > To: Cheng Hong; 'Jukka MJ Manner' > Cc: nsis@ietf.org > Subject: RE: [NSIS] A question to people about QoS NSLP Tear operation >=20 > Hi Cheng Hong >=20 > Sorry I meant: > But we cannot always assume that these criteria are met. That=20 > is why we are using the retransmission procedure for RESERVE messages. >=20 > Best Regards, > Georgios >=20 > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > Sent: maandag 9 oktober 2006 11:24 > To: 'Cheng Hong'; 'Jukka MJ Manner' > Cc: nsis@ietf.org > Subject: RE: [NSIS] A question to people about QoS NSLP Tear operation >=20 > Hi Cheng Hong >=20 > But we cannot always assume that these criteria are met. That=20 > is why we are using the retransmission procedure! >=20 > Best Regards, > Georgios >=20 >=20 > -----Original Message----- > From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com] > Sent: maandag 9 oktober 2006 11:14 > To: Georgios Karagiannis; Jukka MJ Manner > Cc: nsis@ietf.org > Subject: RE: [NSIS] A question to people about QoS NSLP Tear operation >=20 > Hi Georgios, >=20 > Sounds that we need a reliable tranport for the Response. >=20 > I think the problem you pointed out could be solved by=20 > setting the criteria of removing of the state to when the RP=20 > is successfully forwarded the next hop, i.e. Router1.=20 >=20 > Of course, if the transport layer does not support Ack, we=20 > may need to resort to the solution you suggested, i.e.=20 > disallow restransmission of RS. >=20 > What do you think? >=20 > cheers >=20 > Cheng Hong=20 >=20 > > -----Original Message----- > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > Sent: Monday, October 09, 2006 4:50 PM > > To: 'Jukka MJ Manner'; Cheng Hong > > Cc: nsis@ietf.org > > Subject: RE: [NSIS] A question to people about QoS NSLP=20 > Tear operation > >=20 > > Hi Jukka > >=20 > > The problem that I have with the retransmission of tear=20 > RESERVE is the > > following: > >=20 > > Consider the following scenario: > >=20 > > QNI <----> Ruoter1 <-----> Router2 <------> QNR > > =20 > > RS RS RS > > ----> ------> -----> > > RP RP > > XX <----- <---- > >=20 > >=20 > > Note that RS is assumed to be a tear RESERVE that carries a RII=20 > > object. > > RP is assumed to be a RESPONSE. Based on what we have discussed in=20 > > previous e-mails, QNR will remove the state and > > Router2 will remove the state when the RESPONSE arrives at Router2. > >=20 > > However, the tear RESPONSE is lost before reaching Router1 (this is=20 > > shown by XX in above figure). > > This means that the QNI will retransmit the tear RESERVE. =20 > > This retransmitted tear RESERVE will be processed by=20 > Router1 since the=20 > > state is not released, but when the tear RESERVE is sent to=20 > Router2 it=20 > > will not be able to be processed since the state has been removed=20 > > earlier. Router2 will generate an error RESPONSE message. > > This error RESPONSE message will again not remove the state in=20 > > Router1. > > I am afraid that this problem cannot be easily solved. > >=20 > > A solution could be to disalow retransmissions when the=20 > tear RESERVE=20 > > messages are generated by the QNI. If the QNI does not receive a=20 > > RESPONSE for the tear RESERVE then it will assume that an error=20 > > occurred, but it will know that the release of all resources is=20 > > accomplished by the soft state. > >=20 > >=20 > > Best Regards, > > Georgios > > =20 > >=20 > > -----Original Message----- > > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > Sent: maandag 9 oktober 2006 10:29 > > To: Cheng Hong > > Cc: nsis@ietf.org > > Subject: RE: [NSIS] A question to people about QoS NSLP=20 > Tear operation > >=20 > >=20 > > Sounds like a good plan. > >=20 > > Jukka > >=20 > > On Mon, 9 Oct 2006, Cheng Hong wrote: > >=20 > > > Hi Jukka, > > >=20 > > > How about when a QNE receives a TEAR, it free the resources of the > > reservation (that is a job of RMF), but keep the NSLP state (marked=20 > > with a > > flag) for the confirmation? In this case, no network=20 > resources would=20 > > be wasted, and the error message could be still correctly=20 > processed by=20 > > the previous hop. Then, the solution you mentioned earlier could be=20 > > used, e.g. > > the NSLP state to be removed after a timeout, etc. > > >=20 > > > cheers > > >=20 > > > Cheng Hong > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > > > Sent: Sunday, October 08, 2006 12:37 AM > > > > To: David Palma > > > > Cc: nsis@ietf.org > > > > Subject: RE: [NSIS] A question to people about QoS NSLP Tear=20 > > > > operation > > > >=20 > > > >=20 > > > > Hi, > > > >=20 > > > > That is exactly what I have written in my editor's copy > > currently.=20 > > > > Furthermore, I had an idea for a small additional functionality. > > > >=20 > > > > When a QNE sends forward a tear, how long should it=20 > wait for the=20 > > > > RESPONSE to come back through towards the QNI? I think=20 > we have to=20 > > > > have some time limit how long we still keep the=20 > resources. I was=20 > > > > thinking of "one refresh interval". At the expiry of the time=20 > > > > interval, the QNE will remove the reservation. A QNE must > > also stop > > > > sending periodic refresh messages, even if one was > > earlier scheduled > > > > to be sent. This should not happen, if we consider that > > proper timer > > > > management makes sure that if a node gets any RESERVE=20 > message, it=20 > > > > removes it's pending refresh timer, and possibly restart it. > > > >=20 > > > > Regards, > > > > Jukka > > > >=20 > > > > On Sat, 7 Oct 2006, David Palma wrote: > > > >=20 > > > > > Hi Jukka and all, > > > > >=20 > > > > > I agree with everything said in your previous email but > > > > would like to > > > > > ask a question and suggest some other option. > > > > >=20 > > > > > Regarding the second option, by maintaining the reservation > > > > state for > > > > > a certain period of time (almost like soft stat on the > > > > first option), > > > > > if there is no error and the QNI has not included the RII > > > > object (it > > > > > is not mandatory right?). We will have a waste of resources > > > > on every > > > > > peer except on the QNR for every successful reservation. > > > > >=20 > > > > > With the first option we only waste some resources when > > there is > > > > > an error (which is not probable as success) and this waste of > > > > resources > > > > > only affects the peer that produced the error and forward. > > > > >=20 > > > > > Although the first option still seems to me less wasteful, > > > > none of the > > > > > options are perfect. From my point of view a mix of the two=20 > > > > > options would be perfect. > > > > >=20 > > > > > My proposal is: > > > > >=20 > > > > > If a RESERVE with the TEAR flag set is sent every peer should=20 > > > > > check for the presence of the RII object. If this one > > exists, the > > > > > state should not be removed until it receives a successful > > > > REPONSE from the > > > > > QNR (after the QOSNSLP_RETRY_MAX it stops waiting, and acts > > > > accordingly). > > > > >=20 > > > > > If it does not exists the state should be immediately > > > > removed and if > > > > > there is some kind of error the soft state will take care > > > > of removing > > > > > all the remaining resources on the path. > > > > >=20 > > > > >=20 > > > > > I hope that I have understood everything correctly=20 > and that my=20 > > > > > proposal makes sense to you. > > > > >=20 > > > > > Best Regards, > > > > > David Palma > > > > >=20 > > > > >=20 > > > > > -----Mensagem original----- > > > > > De: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > > > > Enviada: s=E1bado, 7 de Outubro de 2006 9:39 > > > > > Para: Bernd Schloer > > > > > Cc: nsis@ietf.org > > > > > Assunto: Re: [NSIS] A question to people about QoS NSLP > > > > Tear operation > > > > >=20 > > > > >=20 > > > > > Hi all, > > > > >=20 > > > > > Actually the proposed solution will not work. When any > > QNE gets a > > > > > tearing RESERVE without RII, the QNE accepts it, removes the=20 > > > > > reservations, and sends it further to the next hop. Now, if > > > > this next > > > > > hop gets into an error situation, it is basically useless > > > > to send an > > > > > error message even to its previous hop (not to mention the > > > > QNI), since > > > > > it has already removed the reservation, and its > > associated state - > > > > > only GIST MA is probably still available, but not QoS > > NSLP state. > > > > >=20 > > > > > Thus, we seem to have two options: > > > > >=20 > > > > > a) Just note in the spec, that sending error messages > > > > related to the > > > > > processing of a tearing RESERVE is uselsss, or > > > > >=20 > > > > > b) define that a QNE SHOULD keep the reservation state for > > > > a period of > > > > > X before finally removing the state. This would allow > > > > processing of a > > > > > error related to tearing. Still, what could a QNE do > > different then? > > > > >=20 > > > > >=20 > > > > > Regards, > > > > > Jukka > > > > >=20 > > > > > On Thu, 5 Oct 2006, Bernd Schloer wrote: > > > > >=20 > > > > > > Sounds good to me. > > > > > >=20 > > > > > > Bernd > > > > > >=20 > > > > > >=20 > > > > > > Jukka MJ Manner wrote: > > > > > > > Hi, > > > > > > >=20 > > > > > > > Good point, in most cases this would work. And if > > there is an > > > > > > > error the previous QNEs did not have, most probably the > > > > QNI is not > > > > > > > anymore able to help either, since it has removed, and > > > > lost, all NSLP states it had. > > > > > > >=20 > > > > > > > Thus, if there is no RII in the tearing RESERVE, any > > > > error in the > > > > > processing > > > > > > > should be propagated to the previous hop, but not further. > > > > > > >=20 > > > > > > > Jukka > > > > > > >=20 > > > > > > > On Thu, 5 Oct 2006, Bernd Schloer wrote: > > > > > > >=20 > > > > > > >=20 > > > > > > > >Is it important to send the error message back to the > > > > QNI? What > > > > > > > >can > > > > > the > > > > > > > >QNI > > > > > > > >do > > > > > > > >QNE2 can't do? It would be more scalable for the > > > > network to send > > > > > > > >the > > > > > error > > > > > > > >message > > > > > > > >not further than QNE2. The QNI has not requested a > > > > confirmation.=20 > > > > > > > >QNE2 > > > > > can > > > > > > > >take > > > > > > > >over the role of the QNI and take care about > > removing state. > > > > > > > > > > > > > > > >Bernd > > > > > > > > > > > > > > > > > > > > > > > >Jukka MJ Manner wrote: > > > > > > > > > > > > > > > > >Yes, that is something I was thinking. Still,=20 > we have a=20 > > > > > > > > >small > > > > > performance > > > > > > > > >problem if no RESPONSE is requested, but there is an > > > > error in > > > > > > > > >the processing of a tearing RESERVE. > > > > > > > > > > > > > > > > > >E.g., we have > > > > > > > > > > > > > > > > > >QNI <--> QNE1 <--> QNE2 <--> QNE3 <--> QNR > > > > > > > > > > > > > > > > > >1. QNI asks to remove a reservation, without > > confirmation 2.=20 > > > > > > > > >QNE1 does that, asks GIST remove the state, and > > sends the > > > > > > > > >requests > > > > > to > > > > > > > > >QNE2 > > > > > > > > >3. QNE does the same and sends the message to > > QNE3 4. QNE3 > > > > > > > > >noticies some error situation, and sends an=20 > error message > > > > > towards > > > > > > > > >the QNI > > > > > > > > >5. QNE3 still has a GIST MA with QNE2, and=20 > QNE3 can send=20 > > > > > > > > >the error to > > > > > > > > >QNE2 > > > > > > > > >6. QNE2 now does not have anymore a GIST MA towards > > > > QN1, thus, > > > > > > > > >it > > > > > needs > > > > > > > > >to > > > > > > > > >set up one > > > > > > > > >7. In turn QNE1 gets the same problem to reach the QNI. > > > > > > > > > > > > > > > > > >Thus, phases 6 & 7 get us a performance penalty, > > but if we > > > > > > > > >consider > > > > > that > > > > > > > > >a > > > > > > > > >tear in the common case does not fail in the > > middle of the > > > > > > > > >network, > > > > > then > > > > > > > > >we > > > > > > > > >could just follow the procedure above. > > > > > > > > > > > > > > > > > >Anyway, if people are fine with the above, I'll > > > > introduce this > > > > > > > > >functionality to the spec. Then we are done with it, > > > > and ready > > > > > > > > >for either another > > > > > WGLC, > > > > > > > > >or > > > > > > > > >AD review. > > > > > > > > > > > > > > > > > >Jukka > > > > > > > > > > > > > > > > > >On Wed, 4 Oct 2006, Bernd Schloer wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Hi Jukka, > > > > > > > > > > > > > > > > > > > >what if the QNE asks GIST to remove routing > > state after > > > > > > > > > >receiving > > > > > the > > > > > > > > > >RESPONSE > > > > > > > > > >to the tearing RESERVE when requested or > > directly when no > > > > > > > > > >response > > > > > is > > > > > > > > > >requested? > > > > > > > > > > > > > > > > > > > >Bernd > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >3. If either, or both, should be made possible > > > > by the spec, > > > > > > > > > > >how > > > > > would > > > > > > > > > > >this > > > > > > > > > > > affect GIST? A QNE gets a tearing RESERVE, it > > > > removes the > > > > > > > > > > >state > > > > > > > > > > > (1), > > > > > > > > > > > forwards the message towards the next=20 > QNE (2), and=20 > > > > > > > > > > >may ask GIST > > > > > to > > > > > > > > > > > remove > > > > > > > > > > > any routing state for this session. Now, > > if this QNE > > > > > > > > > > > later gets back an error message, or a > > > > RESPONSE, for a > > > > > > > > > > > session it no longer knows, what does > > the QNE do?=20 > > > > > > > > > > > Re-set up routing state towards the QNI=20 > using GIST, > > > > > and > > > > > > > > > > > send > > > > > > > > > > > the message forward? > > > > > > > > > > > > > > > > > > > > > > > > > >=20 > > > > >=20 > > > > > _______________________________________________ > > > > > nsis mailing list > > > > > nsis@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > >=20 > > > > >=20 > > > >=20 > > >=20 > >=20 > >=20 > >=20 >=20 >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 09 07:40:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWtTZ-0007oo-2Z; Mon, 09 Oct 2006 07:39:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWtTX-0007of-Jd for nsis@ietf.org; Mon, 09 Oct 2006 07:39:15 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWtTT-0001vB-N9 for nsis@ietf.org; Mon, 09 Oct 2006 07:39:15 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k99BcqLP024680; Mon, 9 Oct 2006 13:39:03 +0200 (MEST) From: "Georgios Karagiannis" To: "'Cheng Hong'" , "'Jukka MJ Manner'" Subject: RE: [NSIS] A question to people about QoS NSLP Tear operation Date: Mon, 9 Oct 2006 13:38:48 +0200 Message-ID: <002001c6eb97$8015cfe0$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <5F09D220B62F79418461A978CA0921BD01366295@pslexc01.psl.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcbrfVqYEfX967srTd2bIjB91+4giQAAS0wgAADymCAAAIcDkAAAIYXgAABlPGAAAzNQIA== X-Spam-Score: -5.389 () ALL_TRUSTED,AWL,BAYES_00,J_CHICKENPOX_42 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Mon, 09 Oct 2006 13:39:08 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 90f8d7cac99eccf384c4cdc57475e98c Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Cheng Hong The retransmissions are at the NSLP layer, see Section 5.2.4 in: http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-11.txt Regarding the timer, what you actually mean is to keep the state=20 for a time equal, to a timer, even if a RESPONSE is=20 processed correctly. The question is for how long should this state be kept. Please note that similar errors followed by retransmissions might occur=20 until the time: QOSNSLP_RETRY_MAX, see Section 5.2.4,=20 that is smaller or equal to refresh period. This is because in worst case, similar errors might occur in=20 different locations in the network during different retransmissions=20 of the tear RESERVE message. Thus I do not see many advantages when introducing this=20 additional complexity into the nodes. Best Regards, Georgios > -----Original Message----- > From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com]=20 > Sent: maandag 9 oktober 2006 12:27 > To: Georgios Karagiannis; Jukka MJ Manner > Cc: nsis@ietf.org > Subject: RE: [NSIS] A question to people about QoS NSLP Tear operation >=20 > Hi Georgios, >=20 > After rethinking about the issue, I have a few questions=20 > about the error case you mentioned.=20 >=20 > Is this retransmission procedure at NSLP layer or at the=20 > transport layer? For the later case, does it mean the=20 > reliable transport is supported? (that is what the=20 > re-transmission is for) Then, it seems that RP would not be=20 > lost(it would be retransmitted from Router2 to Router1).=20 >=20 > For the earlier case, does the NSLP layer need a timer to=20 > decide when to do retransmission? In that case, after send=20 > RP, the Router2 could just keep the NSLP state until the=20 > timer expires (this should not matter since the actual=20 > resources are already released). Would this avoid the error case? >=20 > cheers >=20 > Cheng Hong >=20 >=20 > =20 >=20 > > -----Original Message----- > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > Sent: Monday, October 09, 2006 5:27 PM > > To: Cheng Hong; 'Jukka MJ Manner' > > Cc: nsis@ietf.org > > Subject: RE: [NSIS] A question to people about QoS NSLP=20 > Tear operation > >=20 > > Hi Cheng Hong > >=20 > > Sorry I meant: > > But we cannot always assume that these criteria are met.=20 > That is why=20 > > we are using the retransmission procedure for RESERVE messages. > >=20 > > Best Regards, > > Georgios > >=20 > > -----Original Message----- > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > Sent: maandag 9 oktober 2006 11:24 > > To: 'Cheng Hong'; 'Jukka MJ Manner' > > Cc: nsis@ietf.org > > Subject: RE: [NSIS] A question to people about QoS NSLP=20 > Tear operation > >=20 > > Hi Cheng Hong > >=20 > > But we cannot always assume that these criteria are met.=20 > That is why=20 > > we are using the retransmission procedure! > >=20 > > Best Regards, > > Georgios > >=20 > >=20 > > -----Original Message----- > > From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com] > > Sent: maandag 9 oktober 2006 11:14 > > To: Georgios Karagiannis; Jukka MJ Manner > > Cc: nsis@ietf.org > > Subject: RE: [NSIS] A question to people about QoS NSLP=20 > Tear operation > >=20 > > Hi Georgios, > >=20 > > Sounds that we need a reliable tranport for the Response. > >=20 > > I think the problem you pointed out could be solved by setting the=20 > > criteria of removing of the state to when the RP is successfully=20 > > forwarded the next hop, i.e. Router1. > >=20 > > Of course, if the transport layer does not support Ack, we=20 > may need to=20 > > resort to the solution you suggested, i.e. > > disallow restransmission of RS. > >=20 > > What do you think? > >=20 > > cheers > >=20 > > Cheng Hong > >=20 > > > -----Original Message----- > > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > Sent: Monday, October 09, 2006 4:50 PM > > > To: 'Jukka MJ Manner'; Cheng Hong > > > Cc: nsis@ietf.org > > > Subject: RE: [NSIS] A question to people about QoS NSLP > > Tear operation > > >=20 > > > Hi Jukka > > >=20 > > > The problem that I have with the retransmission of tear > > RESERVE is the > > > following: > > >=20 > > > Consider the following scenario: > > >=20 > > > QNI <----> Ruoter1 <-----> Router2 <------> QNR > > > =20 > > > RS RS RS > > > ----> ------> -----> > > > RP RP > > > XX <----- <---- > > >=20 > > >=20 > > > Note that RS is assumed to be a tear RESERVE that carries a RII=20 > > > object. > > > RP is assumed to be a RESPONSE. Based on what we have=20 > discussed in=20 > > > previous e-mails, QNR will remove the state and > > > Router2 will remove the state when the RESPONSE arrives=20 > at Router2. > > >=20 > > > However, the tear RESPONSE is lost before reaching=20 > Router1 (this is=20 > > > shown by XX in above figure). > > > This means that the QNI will retransmit the tear RESERVE. =20 > > > This retransmitted tear RESERVE will be processed by > > Router1 since the > > > state is not released, but when the tear RESERVE is sent to > > Router2 it > > > will not be able to be processed since the state has been removed=20 > > > earlier. Router2 will generate an error RESPONSE message. > > > This error RESPONSE message will again not remove the state in=20 > > > Router1. > > > I am afraid that this problem cannot be easily solved. > > >=20 > > > A solution could be to disalow retransmissions when the > > tear RESERVE > > > messages are generated by the QNI. If the QNI does not receive a=20 > > > RESPONSE for the tear RESERVE then it will assume that an error=20 > > > occurred, but it will know that the release of all resources is=20 > > > accomplished by the soft state. > > >=20 > > >=20 > > > Best Regards, > > > Georgios > > > =20 > > >=20 > > > -----Original Message----- > > > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > > Sent: maandag 9 oktober 2006 10:29 > > > To: Cheng Hong > > > Cc: nsis@ietf.org > > > Subject: RE: [NSIS] A question to people about QoS NSLP > > Tear operation > > >=20 > > >=20 > > > Sounds like a good plan. > > >=20 > > > Jukka > > >=20 > > > On Mon, 9 Oct 2006, Cheng Hong wrote: > > >=20 > > > > Hi Jukka, > > > >=20 > > > > How about when a QNE receives a TEAR, it free the=20 > resources of the > > > reservation (that is a job of RMF), but keep the NSLP=20 > state (marked=20 > > > with a > > > flag) for the confirmation? In this case, no network > > resources would > > > be wasted, and the error message could be still correctly > > processed by > > > the previous hop. Then, the solution you mentioned=20 > earlier could be=20 > > > used, e.g. > > > the NSLP state to be removed after a timeout, etc. > > > >=20 > > > > cheers > > > >=20 > > > > Cheng Hong > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > > -----Original Message----- > > > > > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > > > > Sent: Sunday, October 08, 2006 12:37 AM > > > > > To: David Palma > > > > > Cc: nsis@ietf.org > > > > > Subject: RE: [NSIS] A question to people about QoS NSLP Tear=20 > > > > > operation > > > > >=20 > > > > >=20 > > > > > Hi, > > > > >=20 > > > > > That is exactly what I have written in my editor's copy > > > currently.=20 > > > > > Furthermore, I had an idea for a small additional=20 > functionality. > > > > >=20 > > > > > When a QNE sends forward a tear, how long should it > > wait for the > > > > > RESPONSE to come back through towards the QNI? I think > > we have to > > > > > have some time limit how long we still keep the > > resources. I was > > > > > thinking of "one refresh interval". At the expiry of the time=20 > > > > > interval, the QNE will remove the reservation. A QNE must > > > also stop > > > > > sending periodic refresh messages, even if one was > > > earlier scheduled > > > > > to be sent. This should not happen, if we consider that > > > proper timer > > > > > management makes sure that if a node gets any RESERVE > > message, it > > > > > removes it's pending refresh timer, and possibly restart it. > > > > >=20 > > > > > Regards, > > > > > Jukka > > > > >=20 > > > > > On Sat, 7 Oct 2006, David Palma wrote: > > > > >=20 > > > > > > Hi Jukka and all, > > > > > >=20 > > > > > > I agree with everything said in your previous email but > > > > > would like to > > > > > > ask a question and suggest some other option. > > > > > >=20 > > > > > > Regarding the second option, by maintaining the reservation > > > > > state for > > > > > > a certain period of time (almost like soft stat on the > > > > > first option), > > > > > > if there is no error and the QNI has not included the RII > > > > > object (it > > > > > > is not mandatory right?). We will have a waste of resources > > > > > on every > > > > > > peer except on the QNR for every successful reservation. > > > > > >=20 > > > > > > With the first option we only waste some resources when > > > there is > > > > > > an error (which is not probable as success) and=20 > this waste of > > > > > resources > > > > > > only affects the peer that produced the error and forward. > > > > > >=20 > > > > > > Although the first option still seems to me less wasteful, > > > > > none of the > > > > > > options are perfect. From my point of view a mix of the two=20 > > > > > > options would be perfect. > > > > > >=20 > > > > > > My proposal is: > > > > > >=20 > > > > > > If a RESERVE with the TEAR flag set is sent every=20 > peer should=20 > > > > > > check for the presence of the RII object. If this one > > > exists, the > > > > > > state should not be removed until it receives a successful > > > > > REPONSE from the > > > > > > QNR (after the QOSNSLP_RETRY_MAX it stops waiting, and acts > > > > > accordingly). > > > > > >=20 > > > > > > If it does not exists the state should be immediately > > > > > removed and if > > > > > > there is some kind of error the soft state will take care > > > > > of removing > > > > > > all the remaining resources on the path. > > > > > >=20 > > > > > >=20 > > > > > > I hope that I have understood everything correctly > > and that my > > > > > > proposal makes sense to you. > > > > > >=20 > > > > > > Best Regards, > > > > > > David Palma > > > > > >=20 > > > > > >=20 > > > > > > -----Mensagem original----- > > > > > > De: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > > > > > Enviada: s=E1bado, 7 de Outubro de 2006 9:39 > > > > > > Para: Bernd Schloer > > > > > > Cc: nsis@ietf.org > > > > > > Assunto: Re: [NSIS] A question to people about QoS NSLP > > > > > Tear operation > > > > > >=20 > > > > > >=20 > > > > > > Hi all, > > > > > >=20 > > > > > > Actually the proposed solution will not work. When any > > > QNE gets a > > > > > > tearing RESERVE without RII, the QNE accepts it,=20 > removes the=20 > > > > > > reservations, and sends it further to the next hop. Now, if > > > > > this next > > > > > > hop gets into an error situation, it is basically useless > > > > > to send an > > > > > > error message even to its previous hop (not to mention the > > > > > QNI), since > > > > > > it has already removed the reservation, and its > > > associated state - > > > > > > only GIST MA is probably still available, but not QoS > > > NSLP state. > > > > > >=20 > > > > > > Thus, we seem to have two options: > > > > > >=20 > > > > > > a) Just note in the spec, that sending error messages > > > > > related to the > > > > > > processing of a tearing RESERVE is uselsss, or > > > > > >=20 > > > > > > b) define that a QNE SHOULD keep the reservation state for > > > > > a period of > > > > > > X before finally removing the state. This would allow > > > > > processing of a > > > > > > error related to tearing. Still, what could a QNE do > > > different then? > > > > > >=20 > > > > > >=20 > > > > > > Regards, > > > > > > Jukka > > > > > >=20 > > > > > > On Thu, 5 Oct 2006, Bernd Schloer wrote: > > > > > >=20 > > > > > > > Sounds good to me. > > > > > > >=20 > > > > > > > Bernd > > > > > > >=20 > > > > > > >=20 > > > > > > > Jukka MJ Manner wrote: > > > > > > > > Hi, > > > > > > > >=20 > > > > > > > > Good point, in most cases this would work. And if > > > there is an > > > > > > > > error the previous QNEs did not have, most probably the > > > > > QNI is not > > > > > > > > anymore able to help either, since it has removed, and > > > > > lost, all NSLP states it had. > > > > > > > >=20 > > > > > > > > Thus, if there is no RII in the tearing RESERVE, any > > > > > error in the > > > > > > processing > > > > > > > > should be propagated to the previous hop, but=20 > not further. > > > > > > > >=20 > > > > > > > > Jukka > > > > > > > >=20 > > > > > > > > On Thu, 5 Oct 2006, Bernd Schloer wrote: > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > >Is it important to send the error message back to the > > > > > QNI? What > > > > > > > > >can > > > > > > the > > > > > > > > >QNI > > > > > > > > >do > > > > > > > > >QNE2 can't do? It would be more scalable for the > > > > > network to send > > > > > > > > >the > > > > > > error > > > > > > > > >message > > > > > > > > >not further than QNE2. The QNI has not requested a > > > > > confirmation.=20 > > > > > > > > >QNE2 > > > > > > can > > > > > > > > >take > > > > > > > > >over the role of the QNI and take care about > > > removing state. > > > > > > > > > > > > > > > > > >Bernd > > > > > > > > > > > > > > > > > > > > > > > > > > >Jukka MJ Manner wrote: > > > > > > > > > > > > > > > > > > >Yes, that is something I was thinking. Still, > > we have a > > > > > > > > > >small > > > > > > performance > > > > > > > > > >problem if no RESPONSE is requested, but there is an > > > > > error in > > > > > > > > > >the processing of a tearing RESERVE. > > > > > > > > > > > > > > > > > > > >E.g., we have > > > > > > > > > > > > > > > > > > > >QNI <--> QNE1 <--> QNE2 <--> QNE3 <--> QNR > > > > > > > > > > > > > > > > > > > >1. QNI asks to remove a reservation, without > > > confirmation 2.=20 > > > > > > > > > >QNE1 does that, asks GIST remove the state, and > > > sends the > > > > > > > > > >requests > > > > > > to > > > > > > > > > >QNE2 > > > > > > > > > >3. QNE does the same and sends the message to > > > QNE3 4. QNE3 > > > > > > > > > >noticies some error situation, and sends an > > error message > > > > > > towards > > > > > > > > > >the QNI > > > > > > > > > >5. QNE3 still has a GIST MA with QNE2, and > > QNE3 can send > > > > > > > > > >the error to > > > > > > > > > >QNE2 > > > > > > > > > >6. QNE2 now does not have anymore a GIST MA towards > > > > > QN1, thus, > > > > > > > > > >it > > > > > > needs > > > > > > > > > >to > > > > > > > > > >set up one > > > > > > > > > >7. In turn QNE1 gets the same problem to=20 > reach the QNI. > > > > > > > > > > > > > > > > > > > >Thus, phases 6 & 7 get us a performance penalty, > > > but if we > > > > > > > > > >consider > > > > > > that > > > > > > > > > >a > > > > > > > > > >tear in the common case does not fail in the > > > middle of the > > > > > > > > > >network, > > > > > > then > > > > > > > > > >we > > > > > > > > > >could just follow the procedure above. > > > > > > > > > > > > > > > > > > > >Anyway, if people are fine with the above, I'll > > > > > introduce this > > > > > > > > > >functionality to the spec. Then we are done with it, > > > > > and ready > > > > > > > > > >for either another > > > > > > WGLC, > > > > > > > > > >or > > > > > > > > > >AD review. > > > > > > > > > > > > > > > > > > > >Jukka > > > > > > > > > > > > > > > > > > > >On Wed, 4 Oct 2006, Bernd Schloer wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Hi Jukka, > > > > > > > > > > > > > > > > > > > > > >what if the QNE asks GIST to remove routing > > > state after > > > > > > > > > > >receiving > > > > > > the > > > > > > > > > > >RESPONSE > > > > > > > > > > >to the tearing RESERVE when requested or > > > directly when no > > > > > > > > > > >response > > > > > > is > > > > > > > > > > >requested? > > > > > > > > > > > > > > > > > > > > > >Bernd > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >3. If either, or both, should be made possible > > > > > by the spec, > > > > > > > > > > > >how > > > > > > would > > > > > > > > > > > >this > > > > > > > > > > > > affect GIST? A QNE gets a tearing RESERVE, it > > > > > removes the > > > > > > > > > > > >state > > > > > > > > > > > > (1), > > > > > > > > > > > > forwards the message towards the next > > QNE (2), and > > > > > > > > > > > >may ask GIST > > > > > > to > > > > > > > > > > > > remove > > > > > > > > > > > > any routing state for this session. Now, > > > if this QNE > > > > > > > > > > > > later gets back an error message, or a > > > > > RESPONSE, for a > > > > > > > > > > > > session it no longer knows, what does > > > the QNE do?=20 > > > > > > > > > > > > Re-set up routing state towards the QNI > > using GIST, > > > > > > and > > > > > > > > > > > > send > > > > > > > > > > > > the message forward? > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=20 > > > > > >=20 > > > > > > _______________________________________________ > > > > > > nsis mailing list > > > > > > nsis@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > >=20 > > > > > >=20 > > > > >=20 > > > >=20 > > >=20 > > >=20 > > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > >=20 > >=20 > >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 09 15:52:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX1AB-0002Hb-C9; Mon, 09 Oct 2006 15:51:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX19V-00012V-7L; Mon, 09 Oct 2006 15:51:05 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GX19V-0005p8-4F; Mon, 09 Oct 2006 15:51:05 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GX19U-0004Th-Q4; Mon, 09 Oct 2006 15:51:05 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 1AAF62AC79; Mon, 9 Oct 2006 19:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GX18U-0007S9-Rd; Mon, 09 Oct 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 09 Oct 2006 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : QoS NSLP QSPEC Template Author(s) : J. Ash, et al. Filename : draft-ietf-nsis-qspec-12.txt Pages : 62 Date : 2006-10-9 The QoS NSLP protocol is used to signal QoS reservations and is independent of a specific QoS model (QOSM) such as IntServ or DiffServ. Rather, all information specific to a QOSM is encapsulated in a separate object, the QSPEC. This document defines a template for the QSPEC, which contains both the QoS description and QSPEC control information. The QSPEC format is defined, as are a number of QSPEC parameters. The QSPEC-1 parameters provide a common language to be re-used in several QOSMs. QSPEC-2 parameters aim to ensure the extensibility of QoS NSLP to other QOSMs in the future. To a certain extent QSPEC parameters ensure interoperability of QOSMs. The node initiating the NSIS signaling adds an Initiator QSPEC that must not be removed, thereby ensuring the intention of the NSIS initiator is preserved along the signaling path. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-12.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nsis-qspec-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nsis-qspec-12.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-10-9124946.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-qspec-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-qspec-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-9124946.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --NextPart-- From nsis-bounces@ietf.org Mon Oct 09 18:01:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX3BM-00026x-5A; Mon, 09 Oct 2006 18:01:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX3BG-00022H-Az for nsis@ietf.org; Mon, 09 Oct 2006 18:01:02 -0400 Received: from sbcsmtp3.sbc.com ([144.160.112.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GX39D-00089v-2T for nsis@ietf.org; Mon, 09 Oct 2006 17:58:57 -0400 Received: from enaf.dadc.sbc.com (localhost.localdomain [127.0.0.1]) by sbcsmtp3.sbc.com (8.13.7/8.13.7) with ESMTP id k99LwsXI014753 for ; Mon, 9 Oct 2006 16:58:54 -0500 Received: from flph023.ffdc.sbc.com (flph023.ffdc.sbc.com [150.234.117.36]) by tlph033.enaf.dadc.sbc.com (8.13.7/8.13.7) with ESMTP id k99Lwq8K014739 for ; Mon, 9 Oct 2006 16:58:53 -0500 Received: from ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flph023.ffdc.sbc.com (8.13.7/8.13.7) with ESMTP id k99LwqgA027838 for ; Mon, 9 Oct 2006 14:58:52 -0700 Received: from kcclust06evs1.ugd.att.com (kcst11.ugd.att.com [135.38.164.88]) by flph023.ffdc.sbc.com (8.13.7/8.13.7) with ESMTP id k99LwjQV027797 for ; Mon, 9 Oct 2006 14:58:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Date: Mon, 9 Oct 2006 16:58:45 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7E1A@KCCLUST06EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Thread-Index: Acbr3H9QgWNFGpMZRT2pU0VuDhwfzgADUd0Q From: "Ash, Gerald R \(Jerry\), ALABS" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: "Ash, Gerald R \(Jerry\), ALABS" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi All, The updated 'QoS NSLP QSPEC Template' I-D is available at http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-12.txt. The main changes are as follows: 1. Sections 4, 5, 6: Many editorial changes and rearrangements. 2. Moved example of QSPEC processing to Appendix A. 3. Section 7.2.2: Changed to fixed length parameter. 4. 3 open issues in version -11 resolved as follows: a) Issue #1 (Number of QSPEC-1 Parameters):=20 current number of mandatory parameters retained, as follows: Parameter (Section 7.2.1) Parameter (Section 7.2.2) Parameter (Section 7.2.3) Parameter (Section 7.2.4) b) Issue #2 (Remapping of QSPEC Parameters): no change in examples/requirements for remapping QSPEC parameters (detailed in Section 6.1) c) Issue #3 (Allowing a QSPEC-1 Parameter to be Ignored): the QSPEC-1 concept is retained and all QSPEC-1 parameters, if populated, must be either strictly interpreted or remapped (any remapping must be specified in QOSM specification document).=20 There are no current open issues. Thanks, Jerry -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Monday, October 09, 2006 3:50 PM To: i-d-announce@ietf.org Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : QoS NSLP QSPEC Template Author(s) : J. Ash, et al. Filename : draft-ietf-nsis-qspec-12.txt Pages : 62 Date : 2006-10-9 =09 The QoS NSLP protocol is used to signal QoS reservations and is independent of a specific QoS model (QOSM) such as IntServ or DiffServ. Rather, all information specific to a QOSM is encapsulated in a separate object, the QSPEC. This document defines a template for the QSPEC, which contains both the QoS description and QSPEC control information. The QSPEC format is defined, as are a number of QSPEC parameters. The QSPEC-1 parameters provide a common language to be re-used in several QOSMs. QSPEC-2 parameters aim to ensure the extensibility of QoS NSLP to other QOSMs in the future. To a certain extent QSPEC parameters ensure interoperability of QOSMs.=20 The node initiating the NSIS signaling adds an Initiator QSPEC that must not be removed, thereby ensuring the intention of the NSIS initiator is preserved along the signaling path. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-12.txt _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 09 21:43:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX6dm-0002TG-Jn; Mon, 09 Oct 2006 21:42:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX6dl-0002TB-89 for nsis@ietf.org; Mon, 09 Oct 2006 21:42:41 -0400 Received: from smtp.mei.co.jp ([133.183.129.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GX6dj-0004Lg-VC for nsis@ietf.org; Mon, 09 Oct 2006 21:42:41 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/bulls) with ESMTP id k9A1gI1P009093; Tue, 10 Oct 2006 10:42:19 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id k9A1gJA17206; Tue, 10 Oct 2006 10:42:19 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/indians) with ESMTP id k9A1gE519025; Tue, 10 Oct 2006 10:42:15 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] A question to people about QoS NSLP Tear operation Date: Tue, 10 Oct 2006 09:41:08 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD013662D2@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] A question to people about QoS NSLP Tear operation Thread-Index: AcbrfVqYEfX967srTd2bIjB91+4giQAAS0wgAADymCAAAIcDkAAAIYXgAABlPGAAAzNQIAAdS7dA From: "Cheng Hong" To: "Georgios Karagiannis" , "Jukka MJ Manner" X-Spam-Score: 0.1 (/) X-Scan-Signature: 8104b3fcabb4d2dfaed548848b9dc80f Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Georgios, Thanks for the clarification. Now I got your point. So, the = re-transmission of the RESERVE you mentioned is due to the NSLP Refresh = mechanism (not the transport layer mechanism).=20 What you suggested is for the Router1 to shutdown the Refresh mechanism = when it receives a RS (RESERVE with tear), and therefore no RS will be = retransmitted. Is it correct? (This should be easy, e.g. the Router1 = could free the resources and mark the NSLP state when it first forwards = the RS to Router2). =20 cheers Cheng Hong > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 > Sent: Monday, October 09, 2006 7:39 PM > To: Cheng Hong; 'Jukka MJ Manner' > Cc: nsis@ietf.org > Subject: RE: [NSIS] A question to people about QoS NSLP Tear operation >=20 > Hi Cheng Hong >=20 > The retransmissions are at the NSLP layer, see Section 5.2.4 in: > http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-11.txt >=20 > Regarding the timer, what you actually mean is to keep the=20 > state for a time equal, to a timer, even if a RESPONSE is=20 > processed correctly. > The question is for how long should this state be kept. >=20 > Please note that similar errors followed by retransmissions=20 > might occur until the time: QOSNSLP_RETRY_MAX, see Section=20 > 5.2.4, that is smaller or equal to refresh period. >=20 > This is because in worst case, similar errors might occur in=20 > different locations in the network during different=20 > retransmissions of the tear RESERVE message. >=20 > Thus I do not see many advantages when introducing this=20 > additional complexity into the nodes. >=20 > Best Regards, > Georgios >=20 >=20 >=20 > > -----Original Message----- > > From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com] > > Sent: maandag 9 oktober 2006 12:27 > > To: Georgios Karagiannis; Jukka MJ Manner > > Cc: nsis@ietf.org > > Subject: RE: [NSIS] A question to people about QoS NSLP=20 > Tear operation > >=20 > > Hi Georgios, > >=20 > > After rethinking about the issue, I have a few questions about the=20 > > error case you mentioned. > >=20 > > Is this retransmission procedure at NSLP layer or at the transport=20 > > layer? For the later case, does it mean the reliable transport is=20 > > supported? (that is what the re-transmission is for) Then, it seems=20 > > that RP would not be lost(it would be retransmitted from Router2 to=20 > > Router1). > >=20 > > For the earlier case, does the NSLP layer need a timer to=20 > decide when=20 > > to do retransmission? In that case, after send RP, the=20 > Router2 could=20 > > just keep the NSLP state until the timer expires (this should not=20 > > matter since the actual resources are already released). Would this=20 > > avoid the error case? > >=20 > > cheers > >=20 > > Cheng Hong > >=20 > >=20 > > =20 > >=20 > > > -----Original Message----- > > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > Sent: Monday, October 09, 2006 5:27 PM > > > To: Cheng Hong; 'Jukka MJ Manner' > > > Cc: nsis@ietf.org > > > Subject: RE: [NSIS] A question to people about QoS NSLP > > Tear operation > > >=20 > > > Hi Cheng Hong > > >=20 > > > Sorry I meant: > > > But we cannot always assume that these criteria are met.=20 > > That is why > > > we are using the retransmission procedure for RESERVE messages. > > >=20 > > > Best Regards, > > > Georgios > > >=20 > > > -----Original Message----- > > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > Sent: maandag 9 oktober 2006 11:24 > > > To: 'Cheng Hong'; 'Jukka MJ Manner' > > > Cc: nsis@ietf.org > > > Subject: RE: [NSIS] A question to people about QoS NSLP > > Tear operation > > >=20 > > > Hi Cheng Hong > > >=20 > > > But we cannot always assume that these criteria are met.=20 > > That is why > > > we are using the retransmission procedure! > > >=20 > > > Best Regards, > > > Georgios > > >=20 > > >=20 > > > -----Original Message----- > > > From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com] > > > Sent: maandag 9 oktober 2006 11:14 > > > To: Georgios Karagiannis; Jukka MJ Manner > > > Cc: nsis@ietf.org > > > Subject: RE: [NSIS] A question to people about QoS NSLP > > Tear operation > > >=20 > > > Hi Georgios, > > >=20 > > > Sounds that we need a reliable tranport for the Response. > > >=20 > > > I think the problem you pointed out could be solved by=20 > setting the=20 > > > criteria of removing of the state to when the RP is successfully=20 > > > forwarded the next hop, i.e. Router1. > > >=20 > > > Of course, if the transport layer does not support Ack, we > > may need to > > > resort to the solution you suggested, i.e. > > > disallow restransmission of RS. > > >=20 > > > What do you think? > > >=20 > > > cheers > > >=20 > > > Cheng Hong > > >=20 > > > > -----Original Message----- > > > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > > Sent: Monday, October 09, 2006 4:50 PM > > > > To: 'Jukka MJ Manner'; Cheng Hong > > > > Cc: nsis@ietf.org > > > > Subject: RE: [NSIS] A question to people about QoS NSLP > > > Tear operation > > > >=20 > > > > Hi Jukka > > > >=20 > > > > The problem that I have with the retransmission of tear > > > RESERVE is the > > > > following: > > > >=20 > > > > Consider the following scenario: > > > >=20 > > > > QNI <----> Ruoter1 <-----> Router2 <------> QNR > > > > =20 > > > > RS RS RS > > > > ----> ------> -----> > > > > RP RP > > > > XX <----- <---- > > > >=20 > > > >=20 > > > > Note that RS is assumed to be a tear RESERVE that carries a RII=20 > > > > object. > > > > RP is assumed to be a RESPONSE. Based on what we have > > discussed in > > > > previous e-mails, QNR will remove the state and > > > > Router2 will remove the state when the RESPONSE arrives > > at Router2. > > > >=20 > > > > However, the tear RESPONSE is lost before reaching > > Router1 (this is > > > > shown by XX in above figure). > > > > This means that the QNI will retransmit the tear RESERVE. =20 > > > > This retransmitted tear RESERVE will be processed by > > > Router1 since the > > > > state is not released, but when the tear RESERVE is sent to > > > Router2 it > > > > will not be able to be processed since the state has=20 > been removed=20 > > > > earlier. Router2 will generate an error RESPONSE message. > > > > This error RESPONSE message will again not remove the state in=20 > > > > Router1. > > > > I am afraid that this problem cannot be easily solved. > > > >=20 > > > > A solution could be to disalow retransmissions when the > > > tear RESERVE > > > > messages are generated by the QNI. If the QNI does not=20 > receive a=20 > > > > RESPONSE for the tear RESERVE then it will assume that an error=20 > > > > occurred, but it will know that the release of all resources is=20 > > > > accomplished by the soft state. > > > >=20 > > > >=20 > > > > Best Regards, > > > > Georgios > > > > =20 > > > >=20 > > > > -----Original Message----- > > > > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > > > Sent: maandag 9 oktober 2006 10:29 > > > > To: Cheng Hong > > > > Cc: nsis@ietf.org > > > > Subject: RE: [NSIS] A question to people about QoS NSLP > > > Tear operation > > > >=20 > > > >=20 > > > > Sounds like a good plan. > > > >=20 > > > > Jukka > > > >=20 > > > > On Mon, 9 Oct 2006, Cheng Hong wrote: > > > >=20 > > > > > Hi Jukka, > > > > >=20 > > > > > How about when a QNE receives a TEAR, it free the > > resources of the > > > > reservation (that is a job of RMF), but keep the NSLP > > state (marked > > > > with a > > > > flag) for the confirmation? In this case, no network > > > resources would > > > > be wasted, and the error message could be still correctly > > > processed by > > > > the previous hop. Then, the solution you mentioned > > earlier could be > > > > used, e.g. > > > > the NSLP state to be removed after a timeout, etc. > > > > >=20 > > > > > cheers > > > > >=20 > > > > > Cheng Hong > > > > >=20 > > > > >=20 > > > > >=20 > > > > >=20 > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > > > > > Sent: Sunday, October 08, 2006 12:37 AM > > > > > > To: David Palma > > > > > > Cc: nsis@ietf.org > > > > > > Subject: RE: [NSIS] A question to people about QoS=20 > NSLP Tear=20 > > > > > > operation > > > > > >=20 > > > > > >=20 > > > > > > Hi, > > > > > >=20 > > > > > > That is exactly what I have written in my editor's copy > > > > currently.=20 > > > > > > Furthermore, I had an idea for a small additional > > functionality. > > > > > >=20 > > > > > > When a QNE sends forward a tear, how long should it > > > wait for the > > > > > > RESPONSE to come back through towards the QNI? I think > > > we have to > > > > > > have some time limit how long we still keep the > > > resources. I was > > > > > > thinking of "one refresh interval". At the expiry=20 > of the time=20 > > > > > > interval, the QNE will remove the reservation. A QNE must > > > > also stop > > > > > > sending periodic refresh messages, even if one was > > > > earlier scheduled > > > > > > to be sent. This should not happen, if we consider that > > > > proper timer > > > > > > management makes sure that if a node gets any RESERVE > > > message, it > > > > > > removes it's pending refresh timer, and possibly restart it. > > > > > >=20 > > > > > > Regards, > > > > > > Jukka > > > > > >=20 > > > > > > On Sat, 7 Oct 2006, David Palma wrote: > > > > > >=20 > > > > > > > Hi Jukka and all, > > > > > > >=20 > > > > > > > I agree with everything said in your previous email but > > > > > > would like to > > > > > > > ask a question and suggest some other option. > > > > > > >=20 > > > > > > > Regarding the second option, by maintaining the=20 > reservation > > > > > > state for > > > > > > > a certain period of time (almost like soft stat on the > > > > > > first option), > > > > > > > if there is no error and the QNI has not included the RII > > > > > > object (it > > > > > > > is not mandatory right?). We will have a waste of=20 > resources > > > > > > on every > > > > > > > peer except on the QNR for every successful reservation. > > > > > > >=20 > > > > > > > With the first option we only waste some resources when > > > > there is > > > > > > > an error (which is not probable as success) and > > this waste of > > > > > > resources > > > > > > > only affects the peer that produced the error and forward. > > > > > > >=20 > > > > > > > Although the first option still seems to me less wasteful, > > > > > > none of the > > > > > > > options are perfect. From my point of view a mix=20 > of the two=20 > > > > > > > options would be perfect. > > > > > > >=20 > > > > > > > My proposal is: > > > > > > >=20 > > > > > > > If a RESERVE with the TEAR flag set is sent every > > peer should > > > > > > > check for the presence of the RII object. If this one > > > > exists, the > > > > > > > state should not be removed until it receives a successful > > > > > > REPONSE from the > > > > > > > QNR (after the QOSNSLP_RETRY_MAX it stops=20 > waiting, and acts > > > > > > accordingly). > > > > > > >=20 > > > > > > > If it does not exists the state should be immediately > > > > > > removed and if > > > > > > > there is some kind of error the soft state will take care > > > > > > of removing > > > > > > > all the remaining resources on the path. > > > > > > >=20 > > > > > > >=20 > > > > > > > I hope that I have understood everything correctly > > > and that my > > > > > > > proposal makes sense to you. > > > > > > >=20 > > > > > > > Best Regards, > > > > > > > David Palma > > > > > > >=20 > > > > > > >=20 > > > > > > > -----Mensagem original----- > > > > > > > De: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > > > > > > Enviada: s=E1bado, 7 de Outubro de 2006 9:39 > > > > > > > Para: Bernd Schloer > > > > > > > Cc: nsis@ietf.org > > > > > > > Assunto: Re: [NSIS] A question to people about QoS NSLP > > > > > > Tear operation > > > > > > >=20 > > > > > > >=20 > > > > > > > Hi all, > > > > > > >=20 > > > > > > > Actually the proposed solution will not work. When any > > > > QNE gets a > > > > > > > tearing RESERVE without RII, the QNE accepts it, > > removes the > > > > > > > reservations, and sends it further to the next=20 > hop. Now, if > > > > > > this next > > > > > > > hop gets into an error situation, it is basically useless > > > > > > to send an > > > > > > > error message even to its previous hop (not to mention the > > > > > > QNI), since > > > > > > > it has already removed the reservation, and its > > > > associated state - > > > > > > > only GIST MA is probably still available, but not QoS > > > > NSLP state. > > > > > > >=20 > > > > > > > Thus, we seem to have two options: > > > > > > >=20 > > > > > > > a) Just note in the spec, that sending error messages > > > > > > related to the > > > > > > > processing of a tearing RESERVE is uselsss, or > > > > > > >=20 > > > > > > > b) define that a QNE SHOULD keep the reservation state for > > > > > > a period of > > > > > > > X before finally removing the state. This would allow > > > > > > processing of a > > > > > > > error related to tearing. Still, what could a QNE do > > > > different then? > > > > > > >=20 > > > > > > >=20 > > > > > > > Regards, > > > > > > > Jukka > > > > > > >=20 > > > > > > > On Thu, 5 Oct 2006, Bernd Schloer wrote: > > > > > > >=20 > > > > > > > > Sounds good to me. > > > > > > > >=20 > > > > > > > > Bernd > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > Jukka MJ Manner wrote: > > > > > > > > > Hi, > > > > > > > > >=20 > > > > > > > > > Good point, in most cases this would work. And if > > > > there is an > > > > > > > > > error the previous QNEs did not have, most=20 > probably the > > > > > > QNI is not > > > > > > > > > anymore able to help either, since it has removed, and > > > > > > lost, all NSLP states it had. > > > > > > > > >=20 > > > > > > > > > Thus, if there is no RII in the tearing RESERVE, any > > > > > > error in the > > > > > > > processing > > > > > > > > > should be propagated to the previous hop, but > > not further. > > > > > > > > >=20 > > > > > > > > > Jukka > > > > > > > > >=20 > > > > > > > > > On Thu, 5 Oct 2006, Bernd Schloer wrote: > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > >Is it important to send the error message back to the > > > > > > QNI? What > > > > > > > > > >can > > > > > > > the > > > > > > > > > >QNI > > > > > > > > > >do > > > > > > > > > >QNE2 can't do? It would be more scalable for the > > > > > > network to send > > > > > > > > > >the > > > > > > > error > > > > > > > > > >message > > > > > > > > > >not further than QNE2. The QNI has not requested a > > > > > > confirmation.=20 > > > > > > > > > >QNE2 > > > > > > > can > > > > > > > > > >take > > > > > > > > > >over the role of the QNI and take care about > > > > removing state. > > > > > > > > > > > > > > > > > > > >Bernd > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Jukka MJ Manner wrote: > > > > > > > > > > > > > > > > > > > > >Yes, that is something I was thinking. Still, > > > we have a > > > > > > > > > > >small > > > > > > > performance > > > > > > > > > > >problem if no RESPONSE is requested, but=20 > there is an > > > > > > error in > > > > > > > > > > >the processing of a tearing RESERVE. > > > > > > > > > > > > > > > > > > > > > >E.g., we have > > > > > > > > > > > > > > > > > > > > > >QNI <--> QNE1 <--> QNE2 <--> QNE3 <--> QNR > > > > > > > > > > > > > > > > > > > > > >1. QNI asks to remove a reservation, without > > > > confirmation 2.=20 > > > > > > > > > > >QNE1 does that, asks GIST remove the state, and > > > > sends the > > > > > > > > > > >requests > > > > > > > to > > > > > > > > > > >QNE2 > > > > > > > > > > >3. QNE does the same and sends the message to > > > > QNE3 4. QNE3 > > > > > > > > > > >noticies some error situation, and sends an > > > error message > > > > > > > towards > > > > > > > > > > >the QNI > > > > > > > > > > >5. QNE3 still has a GIST MA with QNE2, and > > > QNE3 can send > > > > > > > > > > >the error to > > > > > > > > > > >QNE2 > > > > > > > > > > >6. QNE2 now does not have anymore a GIST MA towards > > > > > > QN1, thus, > > > > > > > > > > >it > > > > > > > needs > > > > > > > > > > >to > > > > > > > > > > >set up one > > > > > > > > > > >7. In turn QNE1 gets the same problem to > > reach the QNI. > > > > > > > > > > > > > > > > > > > > > >Thus, phases 6 & 7 get us a performance penalty, > > > > but if we > > > > > > > > > > >consider > > > > > > > that > > > > > > > > > > >a > > > > > > > > > > >tear in the common case does not fail in the > > > > middle of the > > > > > > > > > > >network, > > > > > > > then > > > > > > > > > > >we > > > > > > > > > > >could just follow the procedure above. > > > > > > > > > > > > > > > > > > > > > >Anyway, if people are fine with the above, I'll > > > > > > introduce this > > > > > > > > > > >functionality to the spec. Then we are=20 > done with it, > > > > > > and ready > > > > > > > > > > >for either another > > > > > > > WGLC, > > > > > > > > > > >or > > > > > > > > > > >AD review. > > > > > > > > > > > > > > > > > > > > > >Jukka > > > > > > > > > > > > > > > > > > > > > >On Wed, 4 Oct 2006, Bernd Schloer wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Hi Jukka, > > > > > > > > > > > > > > > > > > > > > > > >what if the QNE asks GIST to remove routing > > > > state after > > > > > > > > > > > >receiving > > > > > > > the > > > > > > > > > > > >RESPONSE > > > > > > > > > > > >to the tearing RESERVE when requested or > > > > directly when no > > > > > > > > > > > >response > > > > > > > is > > > > > > > > > > > >requested? > > > > > > > > > > > > > > > > > > > > > > > >Bernd > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >3. If either, or both, should be made possible > > > > > > by the spec, > > > > > > > > > > > > >how > > > > > > > would > > > > > > > > > > > > >this > > > > > > > > > > > > > affect GIST? A QNE gets a tearing RESERVE, it > > > > > > removes the > > > > > > > > > > > > >state > > > > > > > > > > > > > (1), > > > > > > > > > > > > > forwards the message towards the next > > > QNE (2), and > > > > > > > > > > > > >may ask GIST > > > > > > > to > > > > > > > > > > > > > remove > > > > > > > > > > > > > any routing state for this session. Now, > > > > if this QNE > > > > > > > > > > > > > later gets back an error message, or a > > > > > > RESPONSE, for a > > > > > > > > > > > > > session it no longer knows, what does > > > > the QNE do?=20 > > > > > > > > > > > > > Re-set up routing state towards the QNI > > > using GIST, > > > > > > > and > > > > > > > > > > > > > send > > > > > > > > > > > > > the message forward? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=20 > > > > > > >=20 > > > > > > > _______________________________________________ > > > > > > > nsis mailing list > > > > > > > nsis@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > >=20 > > > > > > >=20 > > > > > >=20 > > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > >=20 > > >=20 > > >=20 > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > >=20 > > >=20 > > >=20 > >=20 >=20 >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 10 03:12:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXBmD-0002oD-C8; Tue, 10 Oct 2006 03:11:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXBmC-0002mc-BH for nsis@ietf.org; Tue, 10 Oct 2006 03:11:44 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXBmA-0006HK-RK for nsis@ietf.org; Tue, 10 Oct 2006 03:11:44 -0400 Received: from sbz-30.cs.helsinki.fi (sbz-30.cs.helsinki.fi [128.214.9.98]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Tue, 10 Oct 2006 10:11:37 +0300 id 000AFC83.452B47A9.00004A12 Date: Tue, 10 Oct 2006 10:11:37 +0300 (EEST) From: Jukka MJ Manner To: "Roy, Radhika R." Subject: RE: [NSIS] About the QSPEC 1 vs. 2 discussion In-Reply-To: <62D92A9A02BCC845B202323D49A48426E1CEA9@0591-ITS-EXMP02.us.saic.com> Message-ID: References: <62D92A9A02BCC845B202323D49A48426E1CEA9@0591-ITS-EXMP02.us.saic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, If I understood you correctly, you are suggesting to remove the classes from the list of mandatory parameters? My point is a bit similar, what I would like to be clearly specified is, what value do I put in a QoS class object if I don't know anything about classes? The same goes with priority. The QoS Template should tell me what would be e.g. default values to put in case the application doesn't care, nor understand, anything about classes - or priority, too. Maybe the answer is, "If you don't know, then mark every flow as best effort." (and low priority)? If that is the case, then why would I use a QoS class object in the first place, just to consume bits on the wire. Jukka On Sun, 8 Oct 2006, Roy, Radhika R. wrote: > Hi, Jukka: > > I appreciate that you are trying to solve the problems of QSPEC. I am reacting with reference to QOS Classes of QSPEC as referred in your email. > > However, do you ever recognize the two fundamental things that contradict in mapping/interoperability in NSIS QOS as follows: > > 1. > Parameters that can take any values. > 2. > Parameters that have been "hard-coded" with "specific" values. > > The whole NSIS QOS signaling specification is based on item 1. > > If so, why are we muddling with only two items in QSEPC that deal with item 2? These items in QSPEC are as follows: > > * Y.xxxx QOS Classes and DSTE QOS classes. > * Unlike DiffSev, RSVP, and other QOS schemes these QOS classes are based on item 2 as mentioned above. > > If these two QOS classes, Y.xxxx QOS Classes and DSTE QOS, would have been based on say "GOLD, SILVER, COPPER, or similar to those of like item 1, there would have been no so much problems for interworking/mapping in NSIS signaling schemes. > > What are those Y.xxxx QOS Classes and DSTE QOS classes are based on some "hard-coded" specific values line 50-ms, 100-ms, 150-ms, etc and not like bandwidth, delay, jitter, or packet loss. > > How can one map/interwork between 50-ms class 1 (say Y.xxxx) and 75-ms class Y (say DSTE)? > > Had those QOS classes like RSVP parameters been like "Guaranteed," "Controlled," or "Best-Effort," could we not solve these problems of mapping/interworking easily? If so, why are we not dropping those "peculiar" QOS classes from the QSPEC spec? > > If needed, separate drafts can be written to deal with these Y.xxxx QOS Classes and DSTE QOS classes in NSIS QOS protocol. There is no hurry for the IETF to deal with this now in the NSIS WG. > > I would appreciate your response to deal with these problems. > > Best regards, > > Radhika > > ________________________________ > > From: nsis-bounces@ietf.org on behalf of Jukka MJ Manner > Sent: Sun 10/8/2006 3:30 PM > To: nsis@ietf.org > Subject: [NSIS] About the QSPEC 1 vs. 2 discussion > > > > > Hi all, > > I went through again the long discussion about QSPEC- vs. QSPEC-2. In > order to get people's opinions, it might be good for Jerry as the QSPEC > editor to summarize what is being discussed. ( I think the discussion > ended after Rudi's comment :) ). > > Still, two thoughts about the discussion (I may not have understood all, > though): > > A) How come a QNI making a resource request can dictate ( Treatment>, QSPEC-1) what the network does if the QNI sends illegal > amounts of traffic? How come if I make a reservation for 1 Mbps, and then > send more than that, I can still ask the network something? If I was a > network operator (luckily for us all I'm not ;), I'd drop all packets from > the node that tries to send more than it requested resources for. Thus, I > think the should be QSPEC-2, at most. > > B) For the other QSPEC-1 parameters, how can a QNI figure out, e.g., what > QoS class its flow should be, if it is making a Controlled Load > reservation? Where do I get this information? I want just bandwidth, I > don't know anyting about DiffServ or any other class-based schemes. > > Thus, I'd rather see as more of an optional hint a node > can give. And for the other QSPEC-1 parameters, hopefully I don't need to > figure out values for them if I don't (want to) understand them. > > Regards, > Jukka > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 10 04:12:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXCiB-0001WH-2e; Tue, 10 Oct 2006 04:11:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXCi8-0001VR-1v for nsis@ietf.org; Tue, 10 Oct 2006 04:11:36 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXCcy-0008KX-Vf for nsis@ietf.org; Tue, 10 Oct 2006 04:06:18 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k9A85rsJ004307; Tue, 10 Oct 2006 10:06:07 +0200 (MEST) From: "Georgios Karagiannis" To: "'Cheng Hong'" , "'Jukka MJ Manner'" Subject: RE: [NSIS] A question to people about QoS NSLP Tear operation Date: Tue, 10 Oct 2006 10:05:49 +0200 Message-ID: <000001c6ec42$e9dbca50$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <5F09D220B62F79418461A978CA0921BD013662D2@pslexc01.psl.local> Thread-Index: AcbrfVqYEfX967srTd2bIjB91+4giQAAS0wgAADymCAAAIcDkAAAIYXgAABlPGAAAzNQIAAdS7dAAA6AG9A= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: -5.389 () ALL_TRUSTED,AWL,BAYES_00,J_CHICKENPOX_42 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Tue, 10 Oct 2006 10:06:14 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: dd055ca905b7a8538e016a7989511901 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Cheng Hong Please note that the procedure does not relate to NSLP refresh, but to retransmissions of e.g., RESERVE messages when the RII object is = included in this message and when the QNI does not receive the expected RESPONSE = message in the predefined time. Please see section 5.2.4 in: http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-11.txt Best Regards, Georgios > -----Original Message----- > From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com]=20 > Sent: dinsdag 10 oktober 2006 3:41 > To: Georgios Karagiannis; Jukka MJ Manner > Cc: nsis@ietf.org > Subject: RE: [NSIS] A question to people about QoS NSLP Tear operation >=20 > Hi Georgios, >=20 > Thanks for the clarification. Now I got your point. So, the=20 > re-transmission of the RESERVE you mentioned is due to the=20 > NSLP Refresh mechanism (not the transport layer mechanism).=20 >=20 > What you suggested is for the Router1 to shutdown the Refresh=20 > mechanism when it receives a RS (RESERVE with tear), and=20 > therefore no RS will be retransmitted. Is it correct? (This=20 > should be easy, e.g. the Router1 could free the resources and=20 > mark the NSLP state when it first forwards the RS to Router2). =20 >=20 > cheers >=20 > Cheng Hong >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > Sent: Monday, October 09, 2006 7:39 PM > > To: Cheng Hong; 'Jukka MJ Manner' > > Cc: nsis@ietf.org > > Subject: RE: [NSIS] A question to people about QoS NSLP=20 > Tear operation > >=20 > > Hi Cheng Hong > >=20 > > The retransmissions are at the NSLP layer, see Section 5.2.4 in: > > http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-11.txt > >=20 > > Regarding the timer, what you actually mean is to keep the=20 > state for a=20 > > time equal, to a timer, even if a RESPONSE is processed correctly. > > The question is for how long should this state be kept. > >=20 > > Please note that similar errors followed by retransmissions might=20 > > occur until the time: QOSNSLP_RETRY_MAX, see Section 5.2.4, that is=20 > > smaller or equal to refresh period. > >=20 > > This is because in worst case, similar errors might occur=20 > in different=20 > > locations in the network during different retransmissions=20 > of the tear=20 > > RESERVE message. > >=20 > > Thus I do not see many advantages when introducing this additional=20 > > complexity into the nodes. > >=20 > > Best Regards, > > Georgios > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com] > > > Sent: maandag 9 oktober 2006 12:27 > > > To: Georgios Karagiannis; Jukka MJ Manner > > > Cc: nsis@ietf.org > > > Subject: RE: [NSIS] A question to people about QoS NSLP > > Tear operation > > >=20 > > > Hi Georgios, > > >=20 > > > After rethinking about the issue, I have a few questions=20 > about the=20 > > > error case you mentioned. > > >=20 > > > Is this retransmission procedure at NSLP layer or at the=20 > transport=20 > > > layer? For the later case, does it mean the reliable transport is=20 > > > supported? (that is what the re-transmission is for)=20 > Then, it seems=20 > > > that RP would not be lost(it would be retransmitted from=20 > Router2 to=20 > > > Router1). > > >=20 > > > For the earlier case, does the NSLP layer need a timer to > > decide when > > > to do retransmission? In that case, after send RP, the > > Router2 could > > > just keep the NSLP state until the timer expires (this should not=20 > > > matter since the actual resources are already released).=20 > Would this=20 > > > avoid the error case? > > >=20 > > > cheers > > >=20 > > > Cheng Hong > > >=20 > > >=20 > > > =20 > > >=20 > > > > -----Original Message----- > > > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > > Sent: Monday, October 09, 2006 5:27 PM > > > > To: Cheng Hong; 'Jukka MJ Manner' > > > > Cc: nsis@ietf.org > > > > Subject: RE: [NSIS] A question to people about QoS NSLP > > > Tear operation > > > >=20 > > > > Hi Cheng Hong > > > >=20 > > > > Sorry I meant: > > > > But we cannot always assume that these criteria are met.=20 > > > That is why > > > > we are using the retransmission procedure for RESERVE messages. > > > >=20 > > > > Best Regards, > > > > Georgios > > > >=20 > > > > -----Original Message----- > > > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > > Sent: maandag 9 oktober 2006 11:24 > > > > To: 'Cheng Hong'; 'Jukka MJ Manner' > > > > Cc: nsis@ietf.org > > > > Subject: RE: [NSIS] A question to people about QoS NSLP > > > Tear operation > > > >=20 > > > > Hi Cheng Hong > > > >=20 > > > > But we cannot always assume that these criteria are met.=20 > > > That is why > > > > we are using the retransmission procedure! > > > >=20 > > > > Best Regards, > > > > Georgios > > > >=20 > > > >=20 > > > > -----Original Message----- > > > > From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com] > > > > Sent: maandag 9 oktober 2006 11:14 > > > > To: Georgios Karagiannis; Jukka MJ Manner > > > > Cc: nsis@ietf.org > > > > Subject: RE: [NSIS] A question to people about QoS NSLP > > > Tear operation > > > >=20 > > > > Hi Georgios, > > > >=20 > > > > Sounds that we need a reliable tranport for the Response. > > > >=20 > > > > I think the problem you pointed out could be solved by > > setting the > > > > criteria of removing of the state to when the RP is=20 > successfully=20 > > > > forwarded the next hop, i.e. Router1. > > > >=20 > > > > Of course, if the transport layer does not support Ack, we > > > may need to > > > > resort to the solution you suggested, i.e. > > > > disallow restransmission of RS. > > > >=20 > > > > What do you think? > > > >=20 > > > > cheers > > > >=20 > > > > Cheng Hong > > > >=20 > > > > > -----Original Message----- > > > > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > > > Sent: Monday, October 09, 2006 4:50 PM > > > > > To: 'Jukka MJ Manner'; Cheng Hong > > > > > Cc: nsis@ietf.org > > > > > Subject: RE: [NSIS] A question to people about QoS NSLP > > > > Tear operation > > > > >=20 > > > > > Hi Jukka > > > > >=20 > > > > > The problem that I have with the retransmission of tear > > > > RESERVE is the > > > > > following: > > > > >=20 > > > > > Consider the following scenario: > > > > >=20 > > > > > QNI <----> Ruoter1 <-----> Router2 <------> QNR > > > > > =20 > > > > > RS RS RS > > > > > ----> ------> -----> > > > > > RP RP > > > > > XX <----- <---- > > > > >=20 > > > > >=20 > > > > > Note that RS is assumed to be a tear RESERVE that=20 > carries a RII=20 > > > > > object. > > > > > RP is assumed to be a RESPONSE. Based on what we have > > > discussed in > > > > > previous e-mails, QNR will remove the state and > > > > > Router2 will remove the state when the RESPONSE arrives > > > at Router2. > > > > >=20 > > > > > However, the tear RESPONSE is lost before reaching > > > Router1 (this is > > > > > shown by XX in above figure). > > > > > This means that the QNI will retransmit the tear RESERVE. =20 > > > > > This retransmitted tear RESERVE will be processed by > > > > Router1 since the > > > > > state is not released, but when the tear RESERVE is sent to > > > > Router2 it > > > > > will not be able to be processed since the state has > > been removed > > > > > earlier. Router2 will generate an error RESPONSE message. > > > > > This error RESPONSE message will again not remove the=20 > state in=20 > > > > > Router1. > > > > > I am afraid that this problem cannot be easily solved. > > > > >=20 > > > > > A solution could be to disalow retransmissions when the > > > > tear RESERVE > > > > > messages are generated by the QNI. If the QNI does not > > receive a > > > > > RESPONSE for the tear RESERVE then it will assume=20 > that an error=20 > > > > > occurred, but it will know that the release of all=20 > resources is=20 > > > > > accomplished by the soft state. > > > > >=20 > > > > >=20 > > > > > Best Regards, > > > > > Georgios > > > > > =20 > > > > >=20 > > > > > -----Original Message----- > > > > > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > > > > Sent: maandag 9 oktober 2006 10:29 > > > > > To: Cheng Hong > > > > > Cc: nsis@ietf.org > > > > > Subject: RE: [NSIS] A question to people about QoS NSLP > > > > Tear operation > > > > >=20 > > > > >=20 > > > > > Sounds like a good plan. > > > > >=20 > > > > > Jukka > > > > >=20 > > > > > On Mon, 9 Oct 2006, Cheng Hong wrote: > > > > >=20 > > > > > > Hi Jukka, > > > > > >=20 > > > > > > How about when a QNE receives a TEAR, it free the > > > resources of the > > > > > reservation (that is a job of RMF), but keep the NSLP > > > state (marked > > > > > with a > > > > > flag) for the confirmation? In this case, no network > > > > resources would > > > > > be wasted, and the error message could be still correctly > > > > processed by > > > > > the previous hop. Then, the solution you mentioned > > > earlier could be > > > > > used, e.g. > > > > > the NSLP state to be removed after a timeout, etc. > > > > > >=20 > > > > > > cheers > > > > > >=20 > > > > > > Cheng Hong > > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > > > -----Original Message----- > > > > > > > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > > > > > > Sent: Sunday, October 08, 2006 12:37 AM > > > > > > > To: David Palma > > > > > > > Cc: nsis@ietf.org > > > > > > > Subject: RE: [NSIS] A question to people about QoS > > NSLP Tear > > > > > > > operation > > > > > > >=20 > > > > > > >=20 > > > > > > > Hi, > > > > > > >=20 > > > > > > > That is exactly what I have written in my editor's copy > > > > > currently.=20 > > > > > > > Furthermore, I had an idea for a small additional > > > functionality. > > > > > > >=20 > > > > > > > When a QNE sends forward a tear, how long should it > > > > wait for the > > > > > > > RESPONSE to come back through towards the QNI? I think > > > > we have to > > > > > > > have some time limit how long we still keep the > > > > resources. I was > > > > > > > thinking of "one refresh interval". At the expiry > > of the time > > > > > > > interval, the QNE will remove the reservation. A QNE must > > > > > also stop > > > > > > > sending periodic refresh messages, even if one was > > > > > earlier scheduled > > > > > > > to be sent. This should not happen, if we consider that > > > > > proper timer > > > > > > > management makes sure that if a node gets any RESERVE > > > > message, it > > > > > > > removes it's pending refresh timer, and possibly=20 > restart it. > > > > > > >=20 > > > > > > > Regards, > > > > > > > Jukka > > > > > > >=20 > > > > > > > On Sat, 7 Oct 2006, David Palma wrote: > > > > > > >=20 > > > > > > > > Hi Jukka and all, > > > > > > > >=20 > > > > > > > > I agree with everything said in your previous email but > > > > > > > would like to > > > > > > > > ask a question and suggest some other option. > > > > > > > >=20 > > > > > > > > Regarding the second option, by maintaining the > > reservation > > > > > > > state for > > > > > > > > a certain period of time (almost like soft stat on the > > > > > > > first option), > > > > > > > > if there is no error and the QNI has not=20 > included the RII > > > > > > > object (it > > > > > > > > is not mandatory right?). We will have a waste of > > resources > > > > > > > on every > > > > > > > > peer except on the QNR for every successful reservation. > > > > > > > >=20 > > > > > > > > With the first option we only waste some resources when > > > > > there is > > > > > > > > an error (which is not probable as success) and > > > this waste of > > > > > > > resources > > > > > > > > only affects the peer that produced the error=20 > and forward. > > > > > > > >=20 > > > > > > > > Although the first option still seems to me=20 > less wasteful, > > > > > > > none of the > > > > > > > > options are perfect. From my point of view a mix > > of the two > > > > > > > > options would be perfect. > > > > > > > >=20 > > > > > > > > My proposal is: > > > > > > > >=20 > > > > > > > > If a RESERVE with the TEAR flag set is sent every > > > peer should > > > > > > > > check for the presence of the RII object. If this one > > > > > exists, the > > > > > > > > state should not be removed until it receives a=20 > successful > > > > > > > REPONSE from the > > > > > > > > QNR (after the QOSNSLP_RETRY_MAX it stops > > waiting, and acts > > > > > > > accordingly). > > > > > > > >=20 > > > > > > > > If it does not exists the state should be immediately > > > > > > > removed and if > > > > > > > > there is some kind of error the soft state will=20 > take care > > > > > > > of removing > > > > > > > > all the remaining resources on the path. > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > I hope that I have understood everything correctly > > > > and that my > > > > > > > > proposal makes sense to you. > > > > > > > >=20 > > > > > > > > Best Regards, > > > > > > > > David Palma > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > -----Mensagem original----- > > > > > > > > De: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > > > > > > > Enviada: s=E1bado, 7 de Outubro de 2006 9:39 > > > > > > > > Para: Bernd Schloer > > > > > > > > Cc: nsis@ietf.org > > > > > > > > Assunto: Re: [NSIS] A question to people about QoS NSLP > > > > > > > Tear operation > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > Hi all, > > > > > > > >=20 > > > > > > > > Actually the proposed solution will not work. When any > > > > > QNE gets a > > > > > > > > tearing RESERVE without RII, the QNE accepts it, > > > removes the > > > > > > > > reservations, and sends it further to the next > > hop. Now, if > > > > > > > this next > > > > > > > > hop gets into an error situation, it is=20 > basically useless > > > > > > > to send an > > > > > > > > error message even to its previous hop (not to=20 > mention the > > > > > > > QNI), since > > > > > > > > it has already removed the reservation, and its > > > > > associated state - > > > > > > > > only GIST MA is probably still available, but not QoS > > > > > NSLP state. > > > > > > > >=20 > > > > > > > > Thus, we seem to have two options: > > > > > > > >=20 > > > > > > > > a) Just note in the spec, that sending error messages > > > > > > > related to the > > > > > > > > processing of a tearing RESERVE is uselsss, or > > > > > > > >=20 > > > > > > > > b) define that a QNE SHOULD keep the=20 > reservation state for > > > > > > > a period of > > > > > > > > X before finally removing the state. This would allow > > > > > > > processing of a > > > > > > > > error related to tearing. Still, what could a QNE do > > > > > different then? > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > Regards, > > > > > > > > Jukka > > > > > > > >=20 > > > > > > > > On Thu, 5 Oct 2006, Bernd Schloer wrote: > > > > > > > >=20 > > > > > > > > > Sounds good to me. > > > > > > > > >=20 > > > > > > > > > Bernd > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > Jukka MJ Manner wrote: > > > > > > > > > > Hi, > > > > > > > > > >=20 > > > > > > > > > > Good point, in most cases this would work. And if > > > > > there is an > > > > > > > > > > error the previous QNEs did not have, most > > probably the > > > > > > > QNI is not > > > > > > > > > > anymore able to help either, since it has=20 > removed, and > > > > > > > lost, all NSLP states it had. > > > > > > > > > >=20 > > > > > > > > > > Thus, if there is no RII in the tearing RESERVE, any > > > > > > > error in the > > > > > > > > processing > > > > > > > > > > should be propagated to the previous hop, but > > > not further. > > > > > > > > > >=20 > > > > > > > > > > Jukka > > > > > > > > > >=20 > > > > > > > > > > On Thu, 5 Oct 2006, Bernd Schloer wrote: > > > > > > > > > >=20 > > > > > > > > > >=20 > > > > > > > > > > >Is it important to send the error message=20 > back to the > > > > > > > QNI? What > > > > > > > > > > >can > > > > > > > > the > > > > > > > > > > >QNI > > > > > > > > > > >do > > > > > > > > > > >QNE2 can't do? It would be more scalable for the > > > > > > > network to send > > > > > > > > > > >the > > > > > > > > error > > > > > > > > > > >message > > > > > > > > > > >not further than QNE2. The QNI has not requested a > > > > > > > confirmation.=20 > > > > > > > > > > >QNE2 > > > > > > > > can > > > > > > > > > > >take > > > > > > > > > > >over the role of the QNI and take care about > > > > > removing state. > > > > > > > > > > > > > > > > > > > > > >Bernd > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Jukka MJ Manner wrote: > > > > > > > > > > > > > > > > > > > > > > >Yes, that is something I was thinking. Still, > > > > we have a > > > > > > > > > > > >small > > > > > > > > performance > > > > > > > > > > > >problem if no RESPONSE is requested, but > > there is an > > > > > > > error in > > > > > > > > > > > >the processing of a tearing RESERVE. > > > > > > > > > > > > > > > > > > > > > > > >E.g., we have > > > > > > > > > > > > > > > > > > > > > > > >QNI <--> QNE1 <--> QNE2 <--> QNE3 <--> QNR > > > > > > > > > > > > > > > > > > > > > > > >1. QNI asks to remove a reservation, without > > > > > confirmation 2.=20 > > > > > > > > > > > >QNE1 does that, asks GIST remove the state, and > > > > > sends the > > > > > > > > > > > >requests > > > > > > > > to > > > > > > > > > > > >QNE2 > > > > > > > > > > > >3. QNE does the same and sends the message to > > > > > QNE3 4. QNE3 > > > > > > > > > > > >noticies some error situation, and sends an > > > > error message > > > > > > > > towards > > > > > > > > > > > >the QNI > > > > > > > > > > > >5. QNE3 still has a GIST MA with QNE2, and > > > > QNE3 can send > > > > > > > > > > > >the error to > > > > > > > > > > > >QNE2 > > > > > > > > > > > >6. QNE2 now does not have anymore a GIST=20 > MA towards > > > > > > > QN1, thus, > > > > > > > > > > > >it > > > > > > > > needs > > > > > > > > > > > >to > > > > > > > > > > > >set up one > > > > > > > > > > > >7. In turn QNE1 gets the same problem to > > > reach the QNI. > > > > > > > > > > > > > > > > > > > > > > > >Thus, phases 6 & 7 get us a performance penalty, > > > > > but if we > > > > > > > > > > > >consider > > > > > > > > that > > > > > > > > > > > >a > > > > > > > > > > > >tear in the common case does not fail in the > > > > > middle of the > > > > > > > > > > > >network, > > > > > > > > then > > > > > > > > > > > >we > > > > > > > > > > > >could just follow the procedure above. > > > > > > > > > > > > > > > > > > > > > > > >Anyway, if people are fine with the above, I'll > > > > > > > introduce this > > > > > > > > > > > >functionality to the spec. Then we are > > done with it, > > > > > > > and ready > > > > > > > > > > > >for either another > > > > > > > > WGLC, > > > > > > > > > > > >or > > > > > > > > > > > >AD review. > > > > > > > > > > > > > > > > > > > > > > > >Jukka > > > > > > > > > > > > > > > > > > > > > > > >On Wed, 4 Oct 2006, Bernd Schloer wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Hi Jukka, > > > > > > > > > > > > > > > > > > > > > > > > > >what if the QNE asks GIST to remove routing > > > > > state after > > > > > > > > > > > > >receiving > > > > > > > > the > > > > > > > > > > > > >RESPONSE > > > > > > > > > > > > >to the tearing RESERVE when requested or > > > > > directly when no > > > > > > > > > > > > >response > > > > > > > > is > > > > > > > > > > > > >requested? > > > > > > > > > > > > > > > > > > > > > > > > > >Bernd > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >3. If either, or both, should be=20 > made possible > > > > > > > by the spec, > > > > > > > > > > > > > >how > > > > > > > > would > > > > > > > > > > > > > >this > > > > > > > > > > > > > > affect GIST? A QNE gets a tearing=20 > RESERVE, it > > > > > > > removes the > > > > > > > > > > > > > >state > > > > > > > > > > > > > > (1), > > > > > > > > > > > > > > forwards the message towards the next > > > > QNE (2), and > > > > > > > > > > > > > >may ask GIST > > > > > > > > to > > > > > > > > > > > > > > remove > > > > > > > > > > > > > > any routing state for this session. Now, > > > > > if this QNE > > > > > > > > > > > > > > later gets back an error message, or a > > > > > > > RESPONSE, for a > > > > > > > > > > > > > > session it no longer knows, what does > > > > > the QNE do?=20 > > > > > > > > > > > > > > Re-set up routing state towards the QNI > > > > using GIST, > > > > > > > > and > > > > > > > > > > > > > > send > > > > > > > > > > > > > > the message forward? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > _______________________________________________ > > > > > > > > nsis mailing list > > > > > > > > nsis@ietf.org > > > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > >=20 > > > > > > > >=20 > > > > > > >=20 > > > > > >=20 > > > > >=20 > > > > >=20 > > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > nsis mailing list > > > > nsis@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > >=20 > > > >=20 > > > >=20 > > >=20 > >=20 > >=20 > >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 10 04:22:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXCs6-0006Dj-G5; Tue, 10 Oct 2006 04:21:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXCs4-0006Dd-RB for nsis@ietf.org; Tue, 10 Oct 2006 04:21:52 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXCs1-0003Js-HC for nsis@ietf.org; Tue, 10 Oct 2006 04:21:52 -0400 Received: from sbz-30.cs.helsinki.fi (sbz-30.cs.helsinki.fi [128.214.9.98]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Tue, 10 Oct 2006 11:21:46 +0300 id 000AFD6C.452B581A.000010C7 Date: Tue, 10 Oct 2006 11:21:46 +0300 (EEST) From: Jukka MJ Manner To: Georgios Karagiannis Subject: RE: [NSIS] A question to people about QoS NSLP Tear operation In-Reply-To: <000001c6ec42$e9dbca50$4c0d5982@dynamic.ewi.utwente.nl> Message-ID: References: <000001c6ec42$e9dbca50$4c0d5982@dynamic.ewi.utwente.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: 'Cheng Hong' , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, So what would be proposed behavior, with and without RII? Note that we should not make requirements to the RMF and the QSPEC processing. For example, if we get a tearing RESERVE, we provide it to the RMF, which removes the state. If still keep the QoS NSLP state, but send the message further, and later receive a retransmitted tear, we can't provide that anymore to the RMF. Thus, we keep QoS NSLP state after a tear for some period of time, we need to do some "trick" to avoid an error situation. After the tear procedure, we are done with the spec. Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 10 04:31:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXD0p-0000cK-Nm; Tue, 10 Oct 2006 04:30:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXD0o-0000c9-M5 for nsis@ietf.org; Tue, 10 Oct 2006 04:30:54 -0400 Received: from smtp.mei.co.jp ([133.183.129.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXD0n-0005iN-62 for nsis@ietf.org; Tue, 10 Oct 2006 04:30:54 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kings) with ESMTP id k9A8UOxj021503; Tue, 10 Oct 2006 17:30:24 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id k9A8UPa24561; Tue, 10 Oct 2006 17:30:25 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/astros) with ESMTP id k9A8UOm19209; Tue, 10 Oct 2006 17:30:25 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] A question to people about QoS NSLP Tear operation Date: Tue, 10 Oct 2006 16:29:21 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD0136642C@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] A question to people about QoS NSLP Tear operation Thread-Index: AcbrfVqYEfX967srTd2bIjB91+4giQAAS0wgAADymCAAAIcDkAAAIYXgAABlPGAAAzNQIAAdS7dAAA6AG9AAAGtcIA== From: "Cheng Hong" To: "Georgios Karagiannis" , "Jukka MJ Manner" X-Spam-Score: 0.1 (/) X-Scan-Signature: c8e71861e926d70c1bd2436e580ecf31 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Georgios, You are right. Sorry for looking into the wrong section. So, seems we have two choices: - Allow retransimssion of RS. If a Router1 receives a RP with error = indicating "no state with the specified session/flow", it takes that the = state on previous hop is already torn, and could safely tear its own = state, and forward the RP. - Disallow retransmission of RS. If a RP is lost, soft state takes = effect, or the Router1 generates RP if local timer expires. What do you think? Cheers Cheng Hong =20 > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 > Sent: Tuesday, October 10, 2006 4:06 PM > To: Cheng Hong; 'Jukka MJ Manner' > Cc: nsis@ietf.org > Subject: RE: [NSIS] A question to people about QoS NSLP Tear operation >=20 > Hi Cheng Hong >=20 > Please note that the procedure does not relate to NSLP=20 > refresh, but to retransmissions of e.g., RESERVE messages=20 > when the RII object is included in this message and when the=20 > QNI does not receive the expected RESPONSE message in the=20 > predefined time. Please see section 5.2.4 in: > http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-11.txt >=20 > Best Regards, > Georgios >=20 > > -----Original Message----- > > From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com] > > Sent: dinsdag 10 oktober 2006 3:41 > > To: Georgios Karagiannis; Jukka MJ Manner > > Cc: nsis@ietf.org > > Subject: RE: [NSIS] A question to people about QoS NSLP=20 > Tear operation > >=20 > > Hi Georgios, > >=20 > > Thanks for the clarification. Now I got your point. So, the=20 > > re-transmission of the RESERVE you mentioned is due to the NSLP=20 > > Refresh mechanism (not the transport layer mechanism). > >=20 > > What you suggested is for the Router1 to shutdown the Refresh=20 > > mechanism when it receives a RS (RESERVE with tear), and=20 > therefore no=20 > > RS will be retransmitted. Is it correct? (This should be easy, e.g.=20 > > the Router1 could free the resources and mark the NSLP=20 > state when it=20 > > first forwards the RS to Router2). > >=20 > > cheers > >=20 > > Cheng Hong > >=20 > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > Sent: Monday, October 09, 2006 7:39 PM > > > To: Cheng Hong; 'Jukka MJ Manner' > > > Cc: nsis@ietf.org > > > Subject: RE: [NSIS] A question to people about QoS NSLP > > Tear operation > > >=20 > > > Hi Cheng Hong > > >=20 > > > The retransmissions are at the NSLP layer, see Section 5.2.4 in: > > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-11.txt > > >=20 > > > Regarding the timer, what you actually mean is to keep the > > state for a > > > time equal, to a timer, even if a RESPONSE is processed correctly. > > > The question is for how long should this state be kept. > > >=20 > > > Please note that similar errors followed by retransmissions might=20 > > > occur until the time: QOSNSLP_RETRY_MAX, see Section=20 > 5.2.4, that is=20 > > > smaller or equal to refresh period. > > >=20 > > > This is because in worst case, similar errors might occur > > in different > > > locations in the network during different retransmissions > > of the tear > > > RESERVE message. > > >=20 > > > Thus I do not see many advantages when introducing this=20 > additional=20 > > > complexity into the nodes. > > >=20 > > > Best Regards, > > > Georgios > > >=20 > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com] > > > > Sent: maandag 9 oktober 2006 12:27 > > > > To: Georgios Karagiannis; Jukka MJ Manner > > > > Cc: nsis@ietf.org > > > > Subject: RE: [NSIS] A question to people about QoS NSLP > > > Tear operation > > > >=20 > > > > Hi Georgios, > > > >=20 > > > > After rethinking about the issue, I have a few questions > > about the > > > > error case you mentioned. > > > >=20 > > > > Is this retransmission procedure at NSLP layer or at the > > transport > > > > layer? For the later case, does it mean the reliable=20 > transport is=20 > > > > supported? (that is what the re-transmission is for) > > Then, it seems > > > > that RP would not be lost(it would be retransmitted from > > Router2 to > > > > Router1). > > > >=20 > > > > For the earlier case, does the NSLP layer need a timer to > > > decide when > > > > to do retransmission? In that case, after send RP, the > > > Router2 could > > > > just keep the NSLP state until the timer expires (this=20 > should not=20 > > > > matter since the actual resources are already released). > > Would this > > > > avoid the error case? > > > >=20 > > > > cheers > > > >=20 > > > > Cheng Hong > > > >=20 > > > >=20 > > > > =20 > > > >=20 > > > > > -----Original Message----- > > > > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > > > Sent: Monday, October 09, 2006 5:27 PM > > > > > To: Cheng Hong; 'Jukka MJ Manner' > > > > > Cc: nsis@ietf.org > > > > > Subject: RE: [NSIS] A question to people about QoS NSLP > > > > Tear operation > > > > >=20 > > > > > Hi Cheng Hong > > > > >=20 > > > > > Sorry I meant: > > > > > But we cannot always assume that these criteria are met.=20 > > > > That is why > > > > > we are using the retransmission procedure for RESERVE=20 > messages. > > > > >=20 > > > > > Best Regards, > > > > > Georgios > > > > >=20 > > > > > -----Original Message----- > > > > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > > > Sent: maandag 9 oktober 2006 11:24 > > > > > To: 'Cheng Hong'; 'Jukka MJ Manner' > > > > > Cc: nsis@ietf.org > > > > > Subject: RE: [NSIS] A question to people about QoS NSLP > > > > Tear operation > > > > >=20 > > > > > Hi Cheng Hong > > > > >=20 > > > > > But we cannot always assume that these criteria are met.=20 > > > > That is why > > > > > we are using the retransmission procedure! > > > > >=20 > > > > > Best Regards, > > > > > Georgios > > > > >=20 > > > > >=20 > > > > > -----Original Message----- > > > > > From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com] > > > > > Sent: maandag 9 oktober 2006 11:14 > > > > > To: Georgios Karagiannis; Jukka MJ Manner > > > > > Cc: nsis@ietf.org > > > > > Subject: RE: [NSIS] A question to people about QoS NSLP > > > > Tear operation > > > > >=20 > > > > > Hi Georgios, > > > > >=20 > > > > > Sounds that we need a reliable tranport for the Response. > > > > >=20 > > > > > I think the problem you pointed out could be solved by > > > setting the > > > > > criteria of removing of the state to when the RP is > > successfully > > > > > forwarded the next hop, i.e. Router1. > > > > >=20 > > > > > Of course, if the transport layer does not support Ack, we > > > > may need to > > > > > resort to the solution you suggested, i.e. > > > > > disallow restransmission of RS. > > > > >=20 > > > > > What do you think? > > > > >=20 > > > > > cheers > > > > >=20 > > > > > Cheng Hong > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > > > > Sent: Monday, October 09, 2006 4:50 PM > > > > > > To: 'Jukka MJ Manner'; Cheng Hong > > > > > > Cc: nsis@ietf.org > > > > > > Subject: RE: [NSIS] A question to people about QoS NSLP > > > > > Tear operation > > > > > >=20 > > > > > > Hi Jukka > > > > > >=20 > > > > > > The problem that I have with the retransmission of tear > > > > > RESERVE is the > > > > > > following: > > > > > >=20 > > > > > > Consider the following scenario: > > > > > >=20 > > > > > > QNI <----> Ruoter1 <-----> Router2 <------> QNR > > > > > > =20 > > > > > > RS RS RS > > > > > > ----> ------> -----> > > > > > > RP RP > > > > > > XX <----- <---- > > > > > >=20 > > > > > >=20 > > > > > > Note that RS is assumed to be a tear RESERVE that > > carries a RII > > > > > > object. > > > > > > RP is assumed to be a RESPONSE. Based on what we have > > > > discussed in > > > > > > previous e-mails, QNR will remove the state and > > > > > > Router2 will remove the state when the RESPONSE arrives > > > > at Router2. > > > > > >=20 > > > > > > However, the tear RESPONSE is lost before reaching > > > > Router1 (this is > > > > > > shown by XX in above figure). > > > > > > This means that the QNI will retransmit the tear RESERVE. =20 > > > > > > This retransmitted tear RESERVE will be processed by > > > > > Router1 since the > > > > > > state is not released, but when the tear RESERVE is sent to > > > > > Router2 it > > > > > > will not be able to be processed since the state has > > > been removed > > > > > > earlier. Router2 will generate an error RESPONSE message. > > > > > > This error RESPONSE message will again not remove the > > state in > > > > > > Router1. > > > > > > I am afraid that this problem cannot be easily solved. > > > > > >=20 > > > > > > A solution could be to disalow retransmissions when the > > > > > tear RESERVE > > > > > > messages are generated by the QNI. If the QNI does not > > > receive a > > > > > > RESPONSE for the tear RESERVE then it will assume > > that an error > > > > > > occurred, but it will know that the release of all > > resources is > > > > > > accomplished by the soft state. > > > > > >=20 > > > > > >=20 > > > > > > Best Regards, > > > > > > Georgios > > > > > > =20 > > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > > > > > Sent: maandag 9 oktober 2006 10:29 > > > > > > To: Cheng Hong > > > > > > Cc: nsis@ietf.org > > > > > > Subject: RE: [NSIS] A question to people about QoS NSLP > > > > > Tear operation > > > > > >=20 > > > > > >=20 > > > > > > Sounds like a good plan. > > > > > >=20 > > > > > > Jukka > > > > > >=20 > > > > > > On Mon, 9 Oct 2006, Cheng Hong wrote: > > > > > >=20 > > > > > > > Hi Jukka, > > > > > > >=20 > > > > > > > How about when a QNE receives a TEAR, it free the > > > > resources of the > > > > > > reservation (that is a job of RMF), but keep the NSLP > > > > state (marked > > > > > > with a > > > > > > flag) for the confirmation? In this case, no network > > > > > resources would > > > > > > be wasted, and the error message could be still correctly > > > > > processed by > > > > > > the previous hop. Then, the solution you mentioned > > > > earlier could be > > > > > > used, e.g. > > > > > > the NSLP state to be removed after a timeout, etc. > > > > > > >=20 > > > > > > > cheers > > > > > > >=20 > > > > > > > Cheng Hong > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > > > -----Original Message----- > > > > > > > > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > > > > > > > Sent: Sunday, October 08, 2006 12:37 AM > > > > > > > > To: David Palma > > > > > > > > Cc: nsis@ietf.org > > > > > > > > Subject: RE: [NSIS] A question to people about QoS > > > NSLP Tear > > > > > > > > operation > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > Hi, > > > > > > > >=20 > > > > > > > > That is exactly what I have written in my editor's copy > > > > > > currently.=20 > > > > > > > > Furthermore, I had an idea for a small additional > > > > functionality. > > > > > > > >=20 > > > > > > > > When a QNE sends forward a tear, how long should it > > > > > wait for the > > > > > > > > RESPONSE to come back through towards the QNI? I think > > > > > we have to > > > > > > > > have some time limit how long we still keep the > > > > > resources. I was > > > > > > > > thinking of "one refresh interval". At the expiry > > > of the time > > > > > > > > interval, the QNE will remove the reservation.=20 > A QNE must > > > > > > also stop > > > > > > > > sending periodic refresh messages, even if one was > > > > > > earlier scheduled > > > > > > > > to be sent. This should not happen, if we consider that > > > > > > proper timer > > > > > > > > management makes sure that if a node gets any RESERVE > > > > > message, it > > > > > > > > removes it's pending refresh timer, and possibly > > restart it. > > > > > > > >=20 > > > > > > > > Regards, > > > > > > > > Jukka > > > > > > > >=20 > > > > > > > > On Sat, 7 Oct 2006, David Palma wrote: > > > > > > > >=20 > > > > > > > > > Hi Jukka and all, > > > > > > > > >=20 > > > > > > > > > I agree with everything said in your previous=20 > email but > > > > > > > > would like to > > > > > > > > > ask a question and suggest some other option. > > > > > > > > >=20 > > > > > > > > > Regarding the second option, by maintaining the > > > reservation > > > > > > > > state for > > > > > > > > > a certain period of time (almost like soft stat on the > > > > > > > > first option), > > > > > > > > > if there is no error and the QNI has not > > included the RII > > > > > > > > object (it > > > > > > > > > is not mandatory right?). We will have a waste of > > > resources > > > > > > > > on every > > > > > > > > > peer except on the QNR for every successful=20 > reservation. > > > > > > > > >=20 > > > > > > > > > With the first option we only waste some=20 > resources when > > > > > > there is > > > > > > > > > an error (which is not probable as success) and > > > > this waste of > > > > > > > > resources > > > > > > > > > only affects the peer that produced the error > > and forward. > > > > > > > > >=20 > > > > > > > > > Although the first option still seems to me > > less wasteful, > > > > > > > > none of the > > > > > > > > > options are perfect. From my point of view a mix > > > of the two > > > > > > > > > options would be perfect. > > > > > > > > >=20 > > > > > > > > > My proposal is: > > > > > > > > >=20 > > > > > > > > > If a RESERVE with the TEAR flag set is sent every > > > > peer should > > > > > > > > > check for the presence of the RII object. If this one > > > > > > exists, the > > > > > > > > > state should not be removed until it receives a > > successful > > > > > > > > REPONSE from the > > > > > > > > > QNR (after the QOSNSLP_RETRY_MAX it stops > > > waiting, and acts > > > > > > > > accordingly). > > > > > > > > >=20 > > > > > > > > > If it does not exists the state should be immediately > > > > > > > > removed and if > > > > > > > > > there is some kind of error the soft state will > > take care > > > > > > > > of removing > > > > > > > > > all the remaining resources on the path. > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > I hope that I have understood everything correctly > > > > > and that my > > > > > > > > > proposal makes sense to you. > > > > > > > > >=20 > > > > > > > > > Best Regards, > > > > > > > > > David Palma > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > -----Mensagem original----- > > > > > > > > > De: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > > > > > > > > > Enviada: s=E1bado, 7 de Outubro de 2006 9:39 > > > > > > > > > Para: Bernd Schloer > > > > > > > > > Cc: nsis@ietf.org > > > > > > > > > Assunto: Re: [NSIS] A question to people=20 > about QoS NSLP > > > > > > > > Tear operation > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > Hi all, > > > > > > > > >=20 > > > > > > > > > Actually the proposed solution will not work. When any > > > > > > QNE gets a > > > > > > > > > tearing RESERVE without RII, the QNE accepts it, > > > > removes the > > > > > > > > > reservations, and sends it further to the next > > > hop. Now, if > > > > > > > > this next > > > > > > > > > hop gets into an error situation, it is > > basically useless > > > > > > > > to send an > > > > > > > > > error message even to its previous hop (not to > > mention the > > > > > > > > QNI), since > > > > > > > > > it has already removed the reservation, and its > > > > > > associated state - > > > > > > > > > only GIST MA is probably still available, but not QoS > > > > > > NSLP state. > > > > > > > > >=20 > > > > > > > > > Thus, we seem to have two options: > > > > > > > > >=20 > > > > > > > > > a) Just note in the spec, that sending error messages > > > > > > > > related to the > > > > > > > > > processing of a tearing RESERVE is uselsss, or > > > > > > > > >=20 > > > > > > > > > b) define that a QNE SHOULD keep the > > reservation state for > > > > > > > > a period of > > > > > > > > > X before finally removing the state. This would allow > > > > > > > > processing of a > > > > > > > > > error related to tearing. Still, what could a QNE do > > > > > > different then? > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > Regards, > > > > > > > > > Jukka > > > > > > > > >=20 > > > > > > > > > On Thu, 5 Oct 2006, Bernd Schloer wrote: > > > > > > > > >=20 > > > > > > > > > > Sounds good to me. > > > > > > > > > >=20 > > > > > > > > > > Bernd > > > > > > > > > >=20 > > > > > > > > > >=20 > > > > > > > > > > Jukka MJ Manner wrote: > > > > > > > > > > > Hi, > > > > > > > > > > >=20 > > > > > > > > > > > Good point, in most cases this would work. And if > > > > > > there is an > > > > > > > > > > > error the previous QNEs did not have, most > > > probably the > > > > > > > > QNI is not > > > > > > > > > > > anymore able to help either, since it has > > removed, and > > > > > > > > lost, all NSLP states it had. > > > > > > > > > > >=20 > > > > > > > > > > > Thus, if there is no RII in the tearing=20 > RESERVE, any > > > > > > > > error in the > > > > > > > > > processing > > > > > > > > > > > should be propagated to the previous hop, but > > > > not further. > > > > > > > > > > >=20 > > > > > > > > > > > Jukka > > > > > > > > > > >=20 > > > > > > > > > > > On Thu, 5 Oct 2006, Bernd Schloer wrote: > > > > > > > > > > >=20 > > > > > > > > > > >=20 > > > > > > > > > > > >Is it important to send the error message > > back to the > > > > > > > > QNI? What > > > > > > > > > > > >can > > > > > > > > > the > > > > > > > > > > > >QNI > > > > > > > > > > > >do > > > > > > > > > > > >QNE2 can't do? It would be more scalable for the > > > > > > > > network to send > > > > > > > > > > > >the > > > > > > > > > error > > > > > > > > > > > >message > > > > > > > > > > > >not further than QNE2. The QNI has not=20 > requested a > > > > > > > > confirmation.=20 > > > > > > > > > > > >QNE2 > > > > > > > > > can > > > > > > > > > > > >take > > > > > > > > > > > >over the role of the QNI and take care about > > > > > > removing state. > > > > > > > > > > > > > > > > > > > > > > > >Bernd > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Jukka MJ Manner wrote: > > > > > > > > > > > > > > > > > > > > > > > > >Yes, that is something I was thinking. Still, > > > > > we have a > > > > > > > > > > > > >small > > > > > > > > > performance > > > > > > > > > > > > >problem if no RESPONSE is requested, but > > > there is an > > > > > > > > error in > > > > > > > > > > > > >the processing of a tearing RESERVE. > > > > > > > > > > > > > > > > > > > > > > > > > >E.g., we have > > > > > > > > > > > > > > > > > > > > > > > > > >QNI <--> QNE1 <--> QNE2 <--> QNE3 <--> QNR > > > > > > > > > > > > > > > > > > > > > > > > > >1. QNI asks to remove a reservation, without > > > > > > confirmation 2.=20 > > > > > > > > > > > > >QNE1 does that, asks GIST remove the state, and > > > > > > sends the > > > > > > > > > > > > >requests > > > > > > > > > to > > > > > > > > > > > > >QNE2 > > > > > > > > > > > > >3. QNE does the same and sends the message to > > > > > > QNE3 4. QNE3 > > > > > > > > > > > > >noticies some error situation, and sends an > > > > > error message > > > > > > > > > towards > > > > > > > > > > > > >the QNI > > > > > > > > > > > > >5. QNE3 still has a GIST MA with QNE2, and > > > > > QNE3 can send > > > > > > > > > > > > >the error to > > > > > > > > > > > > >QNE2 > > > > > > > > > > > > >6. QNE2 now does not have anymore a GIST > > MA towards > > > > > > > > QN1, thus, > > > > > > > > > > > > >it > > > > > > > > > needs > > > > > > > > > > > > >to > > > > > > > > > > > > >set up one > > > > > > > > > > > > >7. In turn QNE1 gets the same problem to > > > > reach the QNI. > > > > > > > > > > > > > > > > > > > > > > > > > >Thus, phases 6 & 7 get us a=20 > performance penalty, > > > > > > but if we > > > > > > > > > > > > >consider > > > > > > > > > that > > > > > > > > > > > > >a > > > > > > > > > > > > >tear in the common case does not fail in the > > > > > > middle of the > > > > > > > > > > > > >network, > > > > > > > > > then > > > > > > > > > > > > >we > > > > > > > > > > > > >could just follow the procedure above. > > > > > > > > > > > > > > > > > > > > > > > > > >Anyway, if people are fine with the above, I'll > > > > > > > > introduce this > > > > > > > > > > > > >functionality to the spec. Then we are > > > done with it, > > > > > > > > and ready > > > > > > > > > > > > >for either another > > > > > > > > > WGLC, > > > > > > > > > > > > >or > > > > > > > > > > > > >AD review. > > > > > > > > > > > > > > > > > > > > > > > > > >Jukka > > > > > > > > > > > > > > > > > > > > > > > > > >On Wed, 4 Oct 2006, Bernd Schloer wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Hi Jukka, > > > > > > > > > > > > > > > > > > > > > > > > > > > >what if the QNE asks GIST to remove routing > > > > > > state after > > > > > > > > > > > > > >receiving > > > > > > > > > the > > > > > > > > > > > > > >RESPONSE > > > > > > > > > > > > > >to the tearing RESERVE when requested or > > > > > > directly when no > > > > > > > > > > > > > >response > > > > > > > > > is > > > > > > > > > > > > > >requested? > > > > > > > > > > > > > > > > > > > > > > > > > > > >Bernd > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >3. If either, or both, should be > > made possible > > > > > > > > by the spec, > > > > > > > > > > > > > > >how > > > > > > > > > would > > > > > > > > > > > > > > >this > > > > > > > > > > > > > > > affect GIST? A QNE gets a tearing > > RESERVE, it > > > > > > > > removes the > > > > > > > > > > > > > > >state > > > > > > > > > > > > > > > (1), > > > > > > > > > > > > > > > forwards the message towards the next > > > > > QNE (2), and > > > > > > > > > > > > > > >may ask GIST > > > > > > > > > to > > > > > > > > > > > > > > > remove > > > > > > > > > > > > > > > any routing state for this session. Now, > > > > > > if this QNE > > > > > > > > > > > > > > > later gets back an error message, or a > > > > > > > > RESPONSE, for a > > > > > > > > > > > > > > > session it no longer knows, what does > > > > > > the QNE do?=20 > > > > > > > > > > > > > > > Re-set up routing state towards the QNI > > > > > using GIST, > > > > > > > > > and > > > > > > > > > > > > > > > send > > > > > > > > > > > > > > > the message forward? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > _______________________________________________ > > > > > > > > > nsis mailing list > > > > > > > > > nsis@ietf.org > > > > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > >=20 > > > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > >=20 > > > > >=20 > > > > >=20 > > > > > _______________________________________________ > > > > > nsis mailing list > > > > > nsis@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > >=20 > > > > >=20 > > > > >=20 > > > >=20 > > >=20 > > >=20 > > >=20 > >=20 > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > >=20 >=20 >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 10 04:47:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXDGL-0004AR-Tv; Tue, 10 Oct 2006 04:46:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXDGK-0004AM-Qo for nsis@ietf.org; Tue, 10 Oct 2006 04:46:56 -0400 Received: from sbcsmtp3.sbc.com ([144.160.112.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXDGJ-0001OP-Hx for nsis@ietf.org; Tue, 10 Oct 2006 04:46:56 -0400 Received: from enaf.dadc.sbc.com (localhost.localdomain [127.0.0.1]) by sbcsmtp3.sbc.com (8.13.7/8.13.7) with ESMTP id k9A8khmF023204; Tue, 10 Oct 2006 03:46:43 -0500 Received: from flph023.ffdc.sbc.com (flph023.ffdc.sbc.com [150.234.117.36]) by tlph033.enaf.dadc.sbc.com (8.13.7/8.13.7) with ESMTP id k9A8kfrj023196; Tue, 10 Oct 2006 03:46:42 -0500 Received: from ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flph023.ffdc.sbc.com (8.13.7/8.13.7) with ESMTP id k9A8kfeC020136; Tue, 10 Oct 2006 01:46:41 -0700 Received: from kcclust06evs1.ugd.att.com (kcst11.ugd.att.com [135.38.164.88]) by flph023.ffdc.sbc.com (8.13.7/8.13.7) with ESMTP id k9A8kdHY020117; Tue, 10 Oct 2006 01:46:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] About the QSPEC 1 vs. 2 discussion Date: Tue, 10 Oct 2006 03:46:39 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7E1E@KCCLUST06EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] About the QSPEC 1 vs. 2 discussion Thread-Index: AcbsO29Aoo7lyoDjTkOIQW1cnDQO1QAC8Ycw From: "Ash, Gerald R \(Jerry\), ALABS" To: "Jukka MJ Manner" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: "Ash, Gerald R \(Jerry\), ALABS" , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Jukka, > what I would like to be clearly specified is,=20 > what value do I put in a QoS class object if I don't know > anything about classes? The same goes with priority. The > QoS Template should tell me what would be e.g. default > values to put in case the application doesn't care,=20 > nor understand, anything about classes - or priority, too. As has been said many times on this thread, the QSPEC -1 concept requires that a QSPEC-1 parameter either be a) strictly interpreted, or b) remapped (as specified in the QOSM specification document). =20 There was clear consensus to retain the QSPEC-1 concept and the 4 QSPEC-1 parameters specified. =20 A QNI will not populate a QSPEC-1 (or QSPEC-2) parameter if it doesn't use it. If it uses it, it knows how to populate it. I don't think you are bringing anything new to the table in this discussion, only rehashing what has been said before. Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 10 04:52:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXDLQ-0004Us-Er; Tue, 10 Oct 2006 04:52:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXDLO-0004Um-DZ for nsis@ietf.org; Tue, 10 Oct 2006 04:52:10 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXDLN-0002XM-0E for nsis@ietf.org; Tue, 10 Oct 2006 04:52:10 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k9A8pxdd008070; Tue, 10 Oct 2006 10:52:03 +0200 (MEST) From: "Georgios Karagiannis" To: "'Ash, Gerald R \(Jerry\), ALABS'" , "'Jukka MJ Manner'" Subject: RE: [NSIS] About the QSPEC 1 vs. 2 discussion Date: Tue, 10 Oct 2006 10:51:55 +0200 Message-ID: <001101c6ec49$59847ae0$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC7E1E@KCCLUST06EVS1.ugd.att.com> Thread-Index: AcbsO29Aoo7lyoDjTkOIQW1cnDQO1QAC8YcwAAB+D9A= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: -5.538 () ALL_TRUSTED,AWL,BAYES_00,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Tue, 10 Oct 2006 10:52:04 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jerry >From my point of view there was no consensus on what you are saying! Best Regards, Georgios > -----Original Message----- > From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] > Sent: dinsdag 10 oktober 2006 10:47 > To: Jukka MJ Manner > Cc: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org > Subject: RE: [NSIS] About the QSPEC 1 vs. 2 discussion > > Jukka, > > > what I would like to be clearly specified is, what value do > I put in a > > QoS class object if I don't know anything about classes? > The same goes > > with priority. The QoS Template should tell me what would be e.g. > > default values to put in case the application doesn't care, nor > > understand, anything about classes - or priority, too. > > As has been said many times on this thread, the QSPEC -1 > concept requires that a QSPEC-1 parameter either be a) > strictly interpreted, or > b) remapped (as specified in the QOSM specification document). > > There was clear consensus to retain the QSPEC-1 concept and the 4 > QSPEC-1 parameters specified. > > A QNI will not populate a QSPEC-1 (or QSPEC-2) parameter if > it doesn't use it. If it uses it, it knows how to populate it. > > I don't think you are bringing anything new to the table in > this discussion, only rehashing what has been said before. > > Jerry > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 10 05:17:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXDjK-0008Td-Ab; Tue, 10 Oct 2006 05:16:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXDjJ-0008TY-1F for nsis@ietf.org; Tue, 10 Oct 2006 05:16:53 -0400 Received: from sbcsmtp3.sbc.com ([144.160.112.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXDjG-0008QJ-MV for nsis@ietf.org; Tue, 10 Oct 2006 05:16:53 -0400 Received: from enaf.dadc.sbc.com (localhost.localdomain [127.0.0.1]) by sbcsmtp3.sbc.com (8.13.7/8.13.7) with ESMTP id k9A9Gk4D029787; Tue, 10 Oct 2006 04:16:46 -0500 Received: from flph023.ffdc.sbc.com (flph023.ffdc.sbc.com [150.234.117.36]) by tlph033.enaf.dadc.sbc.com (8.13.7/8.13.7) with ESMTP id k9A9Gil1029784; Tue, 10 Oct 2006 04:16:45 -0500 Received: from ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flph023.ffdc.sbc.com (8.13.7/8.13.7) with ESMTP id k9A9GinB029657; Tue, 10 Oct 2006 02:16:44 -0700 Received: from kcclust06evs1.ugd.att.com (kcst11.ugd.att.com [135.38.164.88]) by flph023.ffdc.sbc.com (8.13.7/8.13.7) with ESMTP id k9A9Gc4W029625; Tue, 10 Oct 2006 02:16:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Date: Tue, 10 Oct 2006 04:16:38 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7E1F@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <452B5BC6.5090108@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Thread-Index: AcbsR1kunFgK5TZoR/qZlI4GDAeliQAAr6uQ From: "Ash, Gerald R \(Jerry\), ALABS" To: "Lars Westberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: "Ash, Gerald R \(Jerry\), ALABS" , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Lars, > You mention in the below e-mail that there are no open issues, > while there is a huge discussion on the nsis mailing list > regarding the QSPEC-1 parameters. John can call a different consensus if he sees one (I've asked him a couple of times to do that). What I saw was 1. Many posts supported the QSPEC-1 concept, only one (or maybe two) I saw opposed. The opposing view was repeated *many* times (and is still being repeated) but it only counts as one opinion.=20 2. Many posts supported retaining the 4 QSPEC-1 parameters, only one I saw opposed. The opposing view was repeated many times. 3. There was only one opinion expressed to be able to ignore QSPEC-1 parameters. That one opinion has been repeated many times but it only counts as one opinion.=20 John asked a while ago for new opinions on these issues, that would be good if there are any *new* opinions. We don't need to hear opinions repeated that we've seen so many times. I invite John once again to make a consensus call so we can move on here. I think it is time to make progress and stop repeating ourselves, we're not generating any new light in this rather endless discussion. Thanks, Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 10 05:24:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXDpn-0002rJ-6g; Tue, 10 Oct 2006 05:23:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXDpm-0002rE-Ky for nsis@ietf.org; Tue, 10 Oct 2006 05:23:34 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXDpl-00038j-7L for nsis@ietf.org; Tue, 10 Oct 2006 05:23:34 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k9A9NN46010683; Tue, 10 Oct 2006 11:23:27 +0200 (MEST) From: "Georgios Karagiannis" To: "'Ash, Gerald R \(Jerry\), ALABS'" , "'Lars Westberg'" Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Date: Tue, 10 Oct 2006 11:23:19 +0200 Message-ID: <001301c6ec4d$bcb715b0$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC7E1F@KCCLUST06EVS1.ugd.att.com> Thread-Index: AcbsR1kunFgK5TZoR/qZlI4GDAeliQAAr6uQAADTWoA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: -5.538 () ALL_TRUSTED,AWL,BAYES_00,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Tue, 10 Oct 2006 11:23:28 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jerry But any time that someone has another opinion than yours then the only argument that you give is that this person restarts a closed discussion. For example, the QSPEC-1 issues emphasized by Jukka! Best Regards, Georgios > -----Original Message----- > From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] > Sent: dinsdag 10 oktober 2006 11:17 > To: Lars Westberg > Cc: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org > Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt > > Lars, > > > You mention in the below e-mail that there are no open > issues, while > > there is a huge discussion on the nsis mailing list regarding the > > QSPEC-1 parameters. > > John can call a different consensus if he sees one (I've > asked him a couple of times to do that). What I saw was > > 1. Many posts supported the QSPEC-1 concept, only one (or > maybe two) I saw opposed. The opposing view was repeated > *many* times (and is still being repeated) but it only counts > as one opinion. > 2. Many posts supported retaining the 4 QSPEC-1 parameters, > only one I saw opposed. The opposing view was repeated many times. > 3. There was only one opinion expressed to be able to ignore > QSPEC-1 parameters. That one opinion has been repeated many > times but it only counts as one opinion. > > John asked a while ago for new opinions on these issues, that > would be good if there are any *new* opinions. We don't need > to hear opinions repeated that we've seen so many times. > > I invite John once again to make a consensus call so we can > move on here. I think it is time to make progress and stop > repeating ourselves, we're not generating any new light in > this rather endless discussion. > > Thanks, > Jerry > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 10 05:25:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXDr1-0003nA-OY; Tue, 10 Oct 2006 05:24:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXDr0-0003kI-Fs for nsis@ietf.org; Tue, 10 Oct 2006 05:24:50 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXDqz-0003Uk-5N for nsis@ietf.org; Tue, 10 Oct 2006 05:24:50 -0400 Received: from sbz-30.cs.helsinki.fi (sbz-30.cs.helsinki.fi [128.214.9.98]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Tue, 10 Oct 2006 12:24:44 +0300 id 000AFD1C.452B66DC.00007FC7 Date: Tue, 10 Oct 2006 12:24:43 +0300 (EEST) From: Jukka MJ Manner To: "Ash, Gerald R \\(Jerry\\), ALABS" Subject: RE: [NSIS] About the QSPEC 1 vs. 2 discussion In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC7E1E@KCCLUST06EVS1.ugd.att.com> Message-ID: References: <9473683187ADC049A855ED2DA739ABCA0DDC7E1E@KCCLUST06EVS1.ugd.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Jerry, Would you kindly provide the rationale to why excess traffic handling is something a QNI should mandate the network to do? Sounds a bad idea in the first place. Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 10 06:07:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXEW1-0005VI-IJ; Tue, 10 Oct 2006 06:07:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXEVz-0005V3-O8 for nsis@ietf.org; Tue, 10 Oct 2006 06:07:11 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXEVy-0000r9-E6 for nsis@ietf.org; Tue, 10 Oct 2006 06:07:11 -0400 Received: from sbz-30.cs.helsinki.fi (sbz-30.cs.helsinki.fi [128.214.9.98]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Tue, 10 Oct 2006 13:07:09 +0300 id 000AFD21.452B70CD.00002A5E Date: Tue, 10 Oct 2006 13:07:08 +0300 (EEST) From: Jukka MJ Manner To: "Ash, Gerald R \\(Jerry\\), ALABS" Subject: RE: [NSIS] About the QSPEC 1 vs. 2 discussion In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC7E1E@KCCLUST06EVS1.ugd.att.com> Message-ID: References: <9473683187ADC049A855ED2DA739ABCA0DDC7E1E@KCCLUST06EVS1.ugd.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org I went through, again, the QSPEC Template draft. The main concern I have is that the spec is somewhat unclear about the processing of QSPEC-1 paremeters. The important information is here and there, but you really need to look for it. One of the critical aspects to really understand is that even though a QNE does not support a QSPEC-1 parameter, it can just decide to ignore or remap it. This is _not_ a critical error, the QNI will eventually get to know that not all nodes on the path support the QNI's wishes, but the reservation was still succesful. So, at the end, the only difference between QSPEC-1 and QSPEC-2 are, when a QNE does not support the object: - QSPEC-1: raise a flag, and continue as if all is well, the QNI will get to know this, and decide how much it wants exactly what was signaled. The question here is, what can it do then? If I ask some bandwidth, and some node on the path does not understand it, then how do I know which QoS Class to use, then?This is a similar case than we have had discussions on with the QoS NSLP error signaling with a tear. - QSPEC-2: A QNE can just skip it, if it doesn't like it. QNI will never know. Some examples would help a reader a lot, e.g., some scenario, where the e2e path includes different QoS Models: what happens on the edges of domains, what flags/bits are set when/where/why, and what will the QNI eventually get as reply? What can the QNI do, if something was remapped/skipped? Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 10 06:08:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXEWj-0005h0-0B; Tue, 10 Oct 2006 06:07:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXEWh-0005gq-Rb for nsis@ietf.org; Tue, 10 Oct 2006 06:07:55 -0400 Received: from sbcsmtp3.sbc.com ([144.160.112.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXEWf-0000zR-J2 for nsis@ietf.org; Tue, 10 Oct 2006 06:07:55 -0400 Received: from enaf.dadc.sbc.com (localhost.localdomain [127.0.0.1]) by sbcsmtp3.sbc.com (8.13.7/8.13.7) with ESMTP id k9AA7ow5009548; Tue, 10 Oct 2006 05:07:50 -0500 Received: from flph023.ffdc.sbc.com (flph023.ffdc.sbc.com [150.234.117.36]) by tlph033.enaf.dadc.sbc.com (8.13.7/8.13.7) with ESMTP id k9AA7lcB009540; Tue, 10 Oct 2006 05:07:48 -0500 Received: from ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flph023.ffdc.sbc.com (8.13.7/8.13.7) with ESMTP id k9AA7ltW011938; Tue, 10 Oct 2006 03:07:47 -0700 Received: from kcclust06evs1.ugd.att.com (kcst11.ugd.att.com [135.38.164.88]) by flph023.ffdc.sbc.com (8.13.7/8.13.7) with ESMTP id k9AA7f0B011911; Tue, 10 Oct 2006 03:07:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] About the QSPEC 1 vs. 2 discussion Date: Tue, 10 Oct 2006 05:07:40 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7E23@KCCLUST06EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] About the QSPEC 1 vs. 2 discussion Thread-Index: AcbsTfDNOXsbZqnJTr6qjxrq1V5dbAABUjPg From: "Ash, Gerald R \(Jerry\), ALABS" To: "Jukka MJ Manner" X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: "Ash, Gerald R \(Jerry\), ALABS" , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Jukka, > Would you kindly provide the rationale to why excess traffic > handling is something a QNI should mandate the network to do? > Sounds a bad idea in the first place. I don't see any problem RE excess treatment. E.g., if a QNI specifies bandwidth I don't see what possible problem there might be in specifying excess treatment? Please note that a QNI does *not* have to populate excess treatment if its QOSM doesn't use it. Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 10 06:15:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXEdA-0006MT-Qb; Tue, 10 Oct 2006 06:14:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXEd9-0006MO-Ba for nsis@ietf.org; Tue, 10 Oct 2006 06:14:35 -0400 Received: from sbcsmtp3.sbc.com ([144.160.112.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXEd8-0002Zr-3E for nsis@ietf.org; Tue, 10 Oct 2006 06:14:35 -0400 Received: from enaf.dadc.sbc.com (localhost.localdomain [127.0.0.1]) by sbcsmtp3.sbc.com (8.13.7/8.13.7) with ESMTP id k9AAEUHY011343; Tue, 10 Oct 2006 05:14:30 -0500 Received: from flph023.ffdc.sbc.com (flph023.ffdc.sbc.com [150.234.117.36]) by tlph033.enaf.dadc.sbc.com (8.13.7/8.13.7) with ESMTP id k9AAESn6011338; Tue, 10 Oct 2006 05:14:29 -0500 Received: from ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flph023.ffdc.sbc.com (8.13.7/8.13.7) with ESMTP id k9AAESOW013916; Tue, 10 Oct 2006 03:14:28 -0700 Received: from kcclust06evs1.ugd.att.com (kcst11.ugd.att.com [135.38.164.88]) by flph023.ffdc.sbc.com (8.13.7/8.13.7) with ESMTP id k9AAELYg013884; Tue, 10 Oct 2006 03:14:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] About the QSPEC 1 vs. 2 discussion Date: Tue, 10 Oct 2006 05:14:23 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7E24@KCCLUST06EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] About the QSPEC 1 vs. 2 discussion Thread-Index: AcbsU93ceDB2VSSQSTy6Gxh6QELXZQAAGX8g From: "Ash, Gerald R \(Jerry\), ALABS" To: "Jukka MJ Manner" X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: "Ash, Gerald R \(Jerry\), ALABS" , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org > If I ask some bandwidth, and some node on the path does not understand > it, then how do I know which QoS Class to use, then? If QoS Class is not populated by the QNI in the initiator QSPEC, then a QNE has nothing to decide. If QoS class is populated, the QNE knows what to decide. > Some examples would help a reader a lot, e.g., some scenario, where > the e2e path includes different QoS Models: what happens on the > edges of domains, what flags/bits are set when/where/why, and what > will the QNI eventually get as reply? What can the QNI do, if > something was remapped/skipped? See Appendix A. Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 10 06:20:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXEht-0000T7-Fh; Tue, 10 Oct 2006 06:19:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXEhs-0000T2-MQ for nsis@ietf.org; Tue, 10 Oct 2006 06:19:28 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXEhr-0003sc-91 for nsis@ietf.org; Tue, 10 Oct 2006 06:19:28 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k9AAJJ2k015443; Tue, 10 Oct 2006 12:19:22 +0200 (MEST) From: "Georgios Karagiannis" To: "'Ash, Gerald R \(Jerry\), ALABS'" , "'Jukka MJ Manner'" Subject: RE: [NSIS] About the QSPEC 1 vs. 2 discussion Date: Tue, 10 Oct 2006 12:19:15 +0200 Message-ID: <001801c6ec55$8cf43df0$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC7E24@KCCLUST06EVS1.ugd.att.com> Thread-Index: AcbsU93ceDB2VSSQSTy6Gxh6QELXZQAAGX8gAAA+zsA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: -5.537 () ALL_TRUSTED,AWL,BAYES_00,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Tue, 10 Oct 2006 12:19:23 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jerry Please see below! > -----Original Message----- > From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] > Sent: dinsdag 10 oktober 2006 12:14 > To: Jukka MJ Manner > Cc: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org > Subject: RE: [NSIS] About the QSPEC 1 vs. 2 discussion > > > If I ask some bandwidth, and some node on the path does not > understand > > it, then how do I know which QoS Class to use, then? > > If QoS Class is not populated by the QNI in the initiator > QSPEC, then a QNE has nothing to decide. If QoS class is > populated, the QNE knows what to decide. Georgios: How the QNE knows what to decide? Suppose that the QNE is a diffserv node and it receives a parameter. > > > Some examples would help a reader a lot, e.g., some scenario, where > > the e2e path includes different QoS Models: what happens on > the edges > > of domains, what flags/bits are set when/where/why, and > what will the > > QNI eventually get as reply? What can the QNI do, if something was > > remapped/skipped? > > See Appendix A. > > Jerry > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 10 06:23:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXElF-0002ZV-BK; Tue, 10 Oct 2006 06:22:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXElE-0002ZQ-K6 for nsis@ietf.org; Tue, 10 Oct 2006 06:22:56 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXElD-0004P8-Aq for nsis@ietf.org; Tue, 10 Oct 2006 06:22:56 -0400 Received: from sbz-30.cs.helsinki.fi (sbz-30.cs.helsinki.fi [128.214.9.98]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Tue, 10 Oct 2006 13:22:54 +0300 id 000AFD50.452B747E.000037BD Date: Tue, 10 Oct 2006 13:22:54 +0300 (EEST) From: Jukka MJ Manner To: "Ash, Gerald R \\\\(Jerry\\\\), ALABS" Subject: RE: [NSIS] About the QSPEC 1 vs. 2 discussion In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC7E24@KCCLUST06EVS1.ugd.att.com> Message-ID: References: <9473683187ADC049A855ED2DA739ABCA0DDC7E24@KCCLUST06EVS1.ugd.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org On Tue, 10 Oct 2006, Ash, Gerald R \(Jerry\), ALABS wrote: > > Some examples would help a reader a lot, e.g., some scenario, where > > the e2e path includes different QoS Models: what happens on the > > edges of domains, what flags/bits are set when/where/why, and what > > will the QNI eventually get as reply? What can the QNI do, if > > something was remapped/skipped? > > See Appendix A. > > Jerry That is a 4.5 page example, at the end of the spec as an appendix. What is needed, is a short, simple, example at the very beginning of the spec, where the concepts are introduced. Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 10 06:36:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXExt-0007zQ-3t; Tue, 10 Oct 2006 06:36:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXExq-0007uR-FC for nsis@ietf.org; Tue, 10 Oct 2006 06:35:58 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXExp-000752-5Y for nsis@ietf.org; Tue, 10 Oct 2006 06:35:58 -0400 Received: from sbz-30.cs.helsinki.fi (sbz-30.cs.helsinki.fi [128.214.9.98]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Tue, 10 Oct 2006 13:35:54 +0300 id 000AFD2B.452B778A.000016B2 Date: Tue, 10 Oct 2006 13:35:53 +0300 (EEST) From: Jukka MJ Manner To: "Ash, Gerald R \\(Jerry\\), ALABS" Subject: RE: [NSIS] About the QSPEC 1 vs. 2 discussion In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC7E24@KCCLUST06EVS1.ugd.att.com> Message-ID: References: <9473683187ADC049A855ED2DA739ABCA0DDC7E24@KCCLUST06EVS1.ugd.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org In my example, "I" meant QNI. The main point is the spec should give the reader some ideas on what the QNI can do, if its request (some of the QSPEC-1 parameters) was not fully accepted. Is there anything the QNI can do? Jukka On Tue, 10 Oct 2006, Ash, Gerald R \(Jerry\), ALABS wrote: > > If I ask some bandwidth, and some node on the path does not understand > > it, then how do I know which QoS Class to use, then? > > If QoS Class is not populated by the QNI in the initiator QSPEC, then a > QNE has nothing to decide. If QoS class is populated, the QNE knows > what to decide. > > > Some examples would help a reader a lot, e.g., some scenario, where > > the e2e path includes different QoS Models: what happens on the > > edges of domains, what flags/bits are set when/where/why, and what > > will the QNI eventually get as reply? What can the QNI do, if > > something was remapped/skipped? > > See Appendix A. > > Jerry > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 10 09:52:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXI1i-0005Ag-Ah; Tue, 10 Oct 2006 09:52:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXI1g-0005AQ-IE for nsis@ietf.org; Tue, 10 Oct 2006 09:52:08 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXI1Y-0001yK-UP for nsis@ietf.org; Tue, 10 Oct 2006 09:52:08 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 31F3E1838; Tue, 10 Oct 2006 15:51:58 +0200 (CEST) Received: from esealmw116.eemea.ericsson.se ([153.88.200.7]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Oct 2006 15:51:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] About the QSPEC 1 vs. 2 discussion Date: Tue, 10 Oct 2006 15:51:49 +0200 Message-ID: <05F34B6959F19F43BBD78FFCD4C15D055DFF70@esealmw116.eemea.ericsson.se> In-Reply-To: <001801c6ec55$8cf43df0$4c0d5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] About the QSPEC 1 vs. 2 discussion Thread-Index: AcbsU93ceDB2VSSQSTy6Gxh6QELXZQAAGX8gAAA+zsAABsVuYA== From: =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= To: "Georgios Karagiannis" , "Ash, Gerald R \(Jerry\), ALABS" , "Jukka MJ Manner" X-OriginalArrivalTime: 10 Oct 2006 13:51:57.0743 (UTC) FILETIME=[40B1DBF0:01C6EC73] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi All, we had extensive discussions regarding this issue and we did not = reach a consensus. I think it is less important what QNI includes. The = main question here is that Qspec 1 parameters must be implemented in all = NSIS node. So in the current description an NSIS node must implement = Diffserv, DSTE, Y.1541 QoS classes, different priorities and excess = treatment. Are we happy with this? Best regards, Attila >-----Original Message----- >From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 >Sent: Tuesday, October 10, 2006 12:19 PM >To: 'Ash, Gerald R (Jerry), ALABS'; 'Jukka MJ Manner' >Cc: nsis@ietf.org >Subject: RE: [NSIS] About the QSPEC 1 vs. 2 discussion > >Hi Jerry >=20 >Please see below! > >> -----Original Message----- >> From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] >> Sent: dinsdag 10 oktober 2006 12:14 >> To: Jukka MJ Manner >> Cc: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org >> Subject: RE: [NSIS] About the QSPEC 1 vs. 2 discussion >>=20 >> > If I ask some bandwidth, and some node on the path does not >> understand >> > it, then how do I know which QoS Class to use, then? >>=20 >> If QoS Class is not populated by the QNI in the initiator=20 >QSPEC, then=20 >> a QNE has nothing to decide. If QoS class is populated, the=20 >QNE knows=20 >> what to decide. > >Georgios: How the QNE knows what to decide? > Suppose that the QNE is a diffserv node and it receives a > parameter. > > >>=20 >> > Some examples would help a reader a lot, e.g., some=20 >scenario, where=20 >> > the e2e path includes different QoS Models: what happens on=20 >> the edges=20 >> > of domains, what flags/bits are set when/where/why, and=20 >> what will the=20 >> > QNI eventually get as reply? What can the QNI do, if something was=20 >> > remapped/skipped? >>=20 >> See Appendix A. >>=20 >> Jerry >>=20 >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis >>=20 > > > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 10 10:46:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXIrI-00014v-IH; Tue, 10 Oct 2006 10:45:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXIrH-00014g-4U for nsis@ietf.org; Tue, 10 Oct 2006 10:45:27 -0400 Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXIrE-00038S-Lm for nsis@ietf.org; Tue, 10 Oct 2006 10:45:27 -0400 Received: from 0015-its-ieg01.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx.mail.saic.com; Tue, 10 Oct 2006 10:45:10 -0400 Received: from 0015-ITS-EXBH01.us.saic.com ([10.43.229.18]) by 0015-its-ieg01.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006101010450903417 ; Tue, 10 Oct 2006 10:45:09 -0400 Received: from 0591-ITS-EXMP02.us.saic.com ([10.42.81.248]) by 0015-ITS-EXBH01.us.saic.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Oct 2006 10:45:07 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [NSIS] About the QSPEC 1 vs. 2 discussion Date: Tue, 10 Oct 2006 10:45:04 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426E1CEC5@0591-ITS-EXMP02.us.saic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] About the QSPEC 1 vs. 2 discussion Thread-Index: AcbsU93ceDB2VSSQSTy6Gxh6QELXZQAAGX8gAAA+zsAABsVuYAACVQvM References: <05F34B6959F19F43BBD78FFCD4C15D055DFF70@esealmw116.eemea.ericsson.se> From: "Roy, Radhika R." To: =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= , "Georgios Karagiannis" , "Jukka MJ Manner" X-OriginalArrivalTime: 10 Oct 2006 14:45:07.0831 (UTC) FILETIME=[AE22A870:01C6EC7A] X-Spam-Score: 0.1 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0536683026==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0536683026== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6EC7A.AC0A097E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6EC7A.AC0A097E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable What a funny thing: =20 ".NSIS node must implement ...DSTE, Y.1541 QoS classes, .. " =20 Why it is so? =20 How the values (e.g., 50-ms class 1 of so-called Y.xxxx) of one QOS = class can interwork with another (e.g., say 100-ms class Y of so-called = DSTE) QOS class for implementation? =20 Are people comparing apples with oranges: One set of parameters are = based on values (e.g., so-called Y.xxxx, DSTE) and another set of = parameter based on without values (e.g., DiffServ)? =20 It speaks for itself what is going on ... Are we going on circle? =20 BR/Radhika ________________________________ From: nsis-bounces@ietf.org on behalf of Attila B=E1der (IJ/ETH) Sent: Tue 10/10/2006 9:51 AM To: Georgios Karagiannis; Ash, Gerald R (Jerry), ALABS; Jukka MJ Manner Cc: nsis@ietf.org Subject: RE: [NSIS] About the QSPEC 1 vs. 2 discussion Hi All, we had extensive discussions regarding this issue and we did not = reach a consensus. I think it is less important what QNI includes. The = main question here is that Qspec 1 parameters must be implemented in all = NSIS node. So in the current description an NSIS node must implement = Diffserv, DSTE, Y.1541 QoS classes, different priorities and excess = treatment. Are we happy with this? Best regards, Attila >-----Original Message----- >From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >Sent: Tuesday, October 10, 2006 12:19 PM >To: 'Ash, Gerald R (Jerry), ALABS'; 'Jukka MJ Manner' >Cc: nsis@ietf.org >Subject: RE: [NSIS] About the QSPEC 1 vs. 2 discussion > >Hi Jerry > >Please see below! > >> -----Original Message----- >> From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] >> Sent: dinsdag 10 oktober 2006 12:14 >> To: Jukka MJ Manner >> Cc: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org >> Subject: RE: [NSIS] About the QSPEC 1 vs. 2 discussion >> >> > If I ask some bandwidth, and some node on the path does not >> understand >> > it, then how do I know which QoS Class to use, then? >> >> If QoS Class is not populated by the QNI in the initiator >QSPEC, then >> a QNE has nothing to decide. If QoS class is populated, the >QNE knows >> what to decide. > >Georgios: How the QNE knows what to decide? > Suppose that the QNE is a diffserv node and it receives a > parameter. > > >> >> > Some examples would help a reader a lot, e.g., some >scenario, where >> > the e2e path includes different QoS Models: what happens on >> the edges >> > of domains, what flags/bits are set when/where/why, and >> what will the >> > QNI eventually get as reply? What can the QNI do, if something was >> > remapped/skipped? >> >> See Appendix A. >> >> Jerry >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis >> > > > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis ------_=_NextPart_001_01C6EC7A.AC0A097E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [NSIS] About the QSPEC 1 vs. 2 = discussion=0A= =0A= =0A= =0A=
=0A=
What a funny = thing:
=0A=
 
=0A=
".NSIS node must implement ...DSTE, Y.1541 QoS classes, .. = "
=0A=
 
=0A=
Why it is so?
=0A=
 
=0A=
How the values (e.g., 50-ms class 1 of = so-called Y.xxxx) of one QOS class can interwork with another (e.g., say = 100-ms class Y of so-called DSTE) QOS class for = implementation?
=0A=
 
=0A=
Are people comparing apples with oranges: = One set of parameters are based on values (e.g., so-called Y.xxxx, DSTE) = and another set of parameter based on without values (e.g., = DiffServ)?
=0A=
 
=0A=
It speaks for itself what is going on ... = Are we going on circle?
=0A=
 
=0A=
BR/Radhika
=0A=

=0A=
=0A= From: nsis-bounces@ietf.org on = behalf of Attila B=E1der (IJ/ETH)
Sent: Tue 10/10/2006 9:51 = AM
To: Georgios Karagiannis; Ash, Gerald R (Jerry), ALABS; = Jukka MJ Manner
Cc: nsis@ietf.org
Subject: RE: = [NSIS] About the QSPEC 1 vs. 2 discussion

=0A=
=0A=

Hi All, we had extensive discussions regarding this = issue and we did not reach a consensus. I think it is less important = what QNI includes. The main question here is that Qspec 1 parameters = must be implemented in all NSIS node. So in the current description an = NSIS node must implement Diffserv, DSTE, Y.1541 QoS classes, different = priorities and excess treatment. Are we happy with this?

Best = regards, Attila


>-----Original Message-----
>From: = Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=
>Sent: Tuesday, October 10, 2006 12:19 PM
>To: 'Ash, Gerald = R (Jerry), ALABS'; 'Jukka MJ Manner'
>Cc: = nsis@ietf.org
>Subject: RE: [NSIS] About the QSPEC 1 vs. 2 = discussion
>
>Hi Jerry
>
>Please see = below!
>
>> -----Original Message-----
>> From: = Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com]
>> Sent: = dinsdag 10 oktober 2006 12:14
>> To: Jukka MJ = Manner
>> Cc: Ash, Gerald R (Jerry), ALABS; = nsis@ietf.org
>> Subject: RE: [NSIS] About the QSPEC 1 vs. 2 = discussion
>>
>> > If I ask some bandwidth, and = some node on the path does not
>> understand
>> > = it, then how do I know which QoS Class to use, = then?
>>
>> If QoS Class is not populated by the QNI = in the initiator
>QSPEC, then
>> a QNE has nothing to = decide.  If QoS class is populated, the
>QNE = knows
>> what to decide.
>
>Georgios: How the QNE = knows what to decide?
> Suppose that the QNE is a diffserv node = and it receives a
><Y.1541 QoS Class> = parameter.
>
>
>>
>> > Some examples = would help a reader a lot, e.g., some
>scenario, where
>> = > the e2e path includes different QoS Models: what happens = on
>> the edges
>> > of domains, what flags/bits = are set when/where/why, and
>> what will the
>> > = QNI eventually get as reply? What can the QNI do, if something = was
>> > remapped/skipped?
>>
>> See = Appendix A.
>>
>> Jerry
>>
>> = _______________________________________________
>> nsis mailing = list
>> nsis@ietf.org
>> https://www1.ietf.or= g/mailman/listinfo/nsis
>>
>
>
>
>__= _____________________________________________
>nsis mailing = list
>nsis@ietf.org
>https://www1.ietf.or= g/mailman/listinfo/nsis
>

______________________________= _________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.or= g/mailman/listinfo/nsis

------_=_NextPart_001_01C6EC7A.AC0A097E-- --===============0536683026== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0536683026==-- From nsis-bounces@ietf.org Tue Oct 10 13:11:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXL7d-0002Hp-1b; Tue, 10 Oct 2006 13:10:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXL7c-0002Gw-4l for nsis@ietf.org; Tue, 10 Oct 2006 13:10:28 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXL2v-0000lB-PC for nsis@ietf.org; Tue, 10 Oct 2006 13:05:39 -0400 Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Tue, 10 Oct 2006 20:05:34 +0300 id 000AFF30.452BD2DE.00007D5C Date: Tue, 10 Oct 2006 20:05:33 +0300 (EEST) From: Jukka MJ Manner To: "=?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?=" Subject: RE: [NSIS] About the QSPEC 1 vs. 2 discussion In-Reply-To: <05F34B6959F19F43BBD78FFCD4C15D055DFF70@esealmw116.eemea.ericsson.se> Message-ID: References: <05F34B6959F19F43BBD78FFCD4C15D055DFF70@esealmw116.eemea.ericsson.se> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_courier-32105-1160499937-0001-2" X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: "Ash, Gerald R \\\(Jerry\\\), ALABS" , Georgios Karagiannis , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_courier-32105-1160499937-0001-2 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from 8bit to quoted-printable by courier 0.47 Hi Attila, I think that is not what the spec says, really. If I read the (unclear) spec right, a QoS Model does not need to make use of QSPEC-1 parameters.= It only needs to be able to parse them, and say "I'm going to ignore thi= s" by writing a flag in the object. Section 5 says: "In this document the term 'interpret' means, in relation to RMF processing of QSPEC parameters, either that the RMF a) strictly interprets a QSPEC parameter, or b) remaps, approximates, or otherwise does not strictly interpret the parameter." Thus, a QNE running a certain QoS Model can decide to "remap to NULL" or= "approximate to NULL" or "not strictly interpret =3D just skip". So, basically, there is very little difference in practise between QSPEC= -1 and QSPEC-2 parameters. That is one of things that leaves we wonder why the spec is as it is. Jukka On Tue, 10 Oct 2006, Attila B=E1der (IJ/ETH) wrote: > Hi All, we had extensive discussions regarding this issue and we did n= ot > reach a consensus. I think it is less important what QNI includes. The= > main question here is that Qspec 1 parameters must be implemented in a= ll > NSIS node. So in the current description an NSIS node must implement > Diffserv, DSTE, Y.1541 QoS classes, different priorities and excess > treatment. Are we happy with this? > > Best regards, Attila > > > >-----Original Message----- > >From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > >Sent: Tuesday, October 10, 2006 12:19 PM > >To: 'Ash, Gerald R (Jerry), ALABS'; 'Jukka MJ Manner' > >Cc: nsis@ietf.org > >Subject: RE: [NSIS] About the QSPEC 1 vs. 2 discussion > > > >Hi Jerry > > > >Please see below! > > > >> -----Original Message----- > >> From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] > >> Sent: dinsdag 10 oktober 2006 12:14 > >> To: Jukka MJ Manner > >> Cc: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org > >> Subject: RE: [NSIS] About the QSPEC 1 vs. 2 discussion > >> > >> > If I ask some bandwidth, and some node on the path does not > >> understand > >> > it, then how do I know which QoS Class to use, then? > >> > >> If QoS Class is not populated by the QNI in the initiator > >QSPEC, then > >> a QNE has nothing to decide. If QoS class is populated, the > >QNE knows > >> what to decide. > > > >Georgios: How the QNE knows what to decide? > > Suppose that the QNE is a diffserv node and it receives a > > parameter. > > > > > >> > >> > Some examples would help a reader a lot, e.g., some > >scenario, where > >> > the e2e path includes different QoS Models: what happens on > >> the edges > >> > of domains, what flags/bits are set when/where/why, and > >> what will the > >> > QNI eventually get as reply? What can the QNI do, if something wa= s > >> > remapped/skipped? > >> > >> See Appendix A. > >> > >> Jerry > >> > >> _______________________________________________ > >> nsis mailing list > >> nsis@ietf.org > >> https://www1.ietf.org/mailman/listinfo/nsis > >> > > > > > > > >_______________________________________________ > >nsis mailing list > >nsis@ietf.org > >https://www1.ietf.org/mailman/listinfo/nsis > > > --=_courier-32105-1160499937-0001-2 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --=_courier-32105-1160499937-0001-2-- From nsis-bounces@ietf.org Tue Oct 10 15:20:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXN8e-0006Lp-St; Tue, 10 Oct 2006 15:19:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXN8c-0006KN-KL for nsis@ietf.org; Tue, 10 Oct 2006 15:19:38 -0400 Received: from sbcsmtp3.sbc.com ([144.160.112.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXN10-0001xH-45 for nsis@ietf.org; Tue, 10 Oct 2006 15:11:47 -0400 Received: from enaf.dadc.sbc.com (localhost.localdomain [127.0.0.1]) by sbcsmtp3.sbc.com (8.13.7/8.13.7) with ESMTP id k9AJBgfx014595; Tue, 10 Oct 2006 14:11:43 -0500 Received: from flph023.ffdc.sbc.com (flph023.ffdc.sbc.com [150.234.117.36]) by tlph033.enaf.dadc.sbc.com (8.13.7/8.13.7) with ESMTP id k9AJBeM3014579; Tue, 10 Oct 2006 14:11:40 -0500 Received: from ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flph023.ffdc.sbc.com (8.13.7/8.13.7) with ESMTP id k9AJBdvL016119; Tue, 10 Oct 2006 12:11:39 -0700 Received: from kcclust06evs1.ugd.att.com (kcst11.ugd.att.com [135.38.164.88]) by flph023.ffdc.sbc.com (8.13.7/8.13.7) with ESMTP id k9AJBYGR016084; Tue, 10 Oct 2006 12:11:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] About the QSPEC 1 vs. 2 discussion Date: Tue, 10 Oct 2006 14:11:34 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7E2B@KCCLUST06EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] About the QSPEC 1 vs. 2 discussion Thread-Index: AcbsjlSwqanp0hbWTLCl2GINMfIqJgAELkBA From: "Ash, Gerald R \(Jerry\), ALABS" To: "Jukka MJ Manner" X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: "Ash, Gerald R \(Jerry\), ALABS" , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org > "In this document the term 'interpret' means, in relation to RMF > processing of QSPEC parameters, either that the RMF a) strictly > interprets a QSPEC parameter, or b) remaps, approximates, or > otherwise does not strictly interpret the parameter." > >Thus, a QNE running a certain QoS Model can decide to "remap to NULL" or=20 > "approximate to NULL" or "not strictly interpret =3D just skip". 'Remap to NULL', 'just skip', or otherwise 'ignore' QSPEC-1 parameters is *not* allowed, as is spelled out in the current document.=20 > So, basically, there is very little difference in practise between QSPEC-1=20 > and QSPEC-2 parameters. That is one of things that leaves we wonder why=20 > the spec is as it is. Not so. QSPEC-1 must be interpreted if populated, QSPEC-2 can be ignored if populated. Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 10 15:41:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXNSv-0008Gj-CN; Tue, 10 Oct 2006 15:40:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXNSt-0008Gd-Lx for nsis@ietf.org; Tue, 10 Oct 2006 15:40:35 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXNSs-0006Bo-36 for nsis@ietf.org; Tue, 10 Oct 2006 15:40:35 -0400 Received: from [192.168.2.155] (host81-137-225-30.in-addr.btopenworld.com [81.137.225.30]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 4B57D1BAC9F for ; Tue, 10 Oct 2006 21:40:33 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v752.2) References: <86A92449-6906-4CA6-80A8-518E1BF9D239@netlab.nec.de> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3E52D83D-03CC-4EE7-97A8-DCD9D329AB85@netlab.nec.de> Content-Transfer-Encoding: 7bit From: Martin Stiemerling Subject: Fwd: [NSIS] Voting: REA Naming Contest (reanco) - the candidates Date: Tue, 10 Oct 2006 10:24:30 +0200 To: nsis X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.2 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Just a reminder. Martin Anfang der weitergeleiteten E-Mail: > Von: Martin Stiemerling > Datum: 6. Oktober 2006 16:21:36 MESZ > An: nsis > Betreff: [NSIS] Voting: REA Naming Contest (reanco) - the candidates > > Dear all, > > Even though the REA naming contest (reanco) got stuck for a while, > it's still running. > > The deadline for submitting proposals was Aug 3rd and the final > decision should be made before the next IETF meeting for two > reasons: a) getting the name in the draft and b) some beer for the > winner at the IETF. > > The candidates for the name we have (given order is **NO** ranking!): > > a) Open Internal Path (OIP) message <-- my favourite > b) Configure Internal Path (CIP) message > c) Prepare For Ucreate (PFU) message (where UCREATE is actually now > REA) > d) Internal Network Configuration (INC) message > e) EXT (for playing with the external address and opening firewall > holes for external data senders (incoming streams)) > f) Open Path Interactive (OPI) message > g) Open Interactive Path (OIP) message > h) Path Opening Interactive (POI) message > i) Interactive Path Opening (IPO) message > j) CREATE -> ICREATE (Initiator CREATE); REA -> RCREATE (Responder > CREATE) > k) CREATE -> SCREATE (Sender CREATE); REA -> RCREATE (Receiver CREATE) > > **Please send me directly an email with your vote, stating whether > you prefer any out of a) to k)! > > **All votes MUST be done, i.e., in my inbox, by October 12th, 11pm > Pacific Time. > > **If there is no voting at all, the authors will rule the new name. > > > Happy voting!! > > Martin > > Am 13.07.2006 um 15:32 schrieb Martin Stiemerling: > >> Dear All, >> >> We have discussed about the naming issues for the NATFW NSLP's >> RESERVE-EXTERNAL-ADDRESS (REA) message. >> >> In the past revisions of the NATFW NSLP REA has been used to >> obtain an >> external IP address/port at the outermost NAT (and at in between NATs >> too). >> But the semantics of REA changed over time from purely NAT usage to a >> combined NAT and firewall usage, i.e., a combination of the old >> REA and >> the old UCREATE. >> >> REA is used for: >> - Used to get external address/port at NAT >> - Used to install firewall rules for inbound traffic >> - Used in proxy mode usage >> >> So the current name is not really describing the semantics/usage >> anymore >> and we need to something different. Since the authors haven't had any >> good idea and some off-line discussions didn't bring a good name, we >> are starting the >> >> REA naming contest (reanco) >> >> This contest calls the NSIS WG for input on name suggestions for the >> message currently called REA. >> >> The contest starts today (actually already yesterday during the >> session) >> and will run until August 3rd 8am EST. Suggestion made after >> August 3rd EST are not accepted anymore. All suggestions must be sent >> to the NSIS working group list (nsis@ietf.org). It is not valid to >> use a >> naming generator that simply tries combinations of characters. >> >> The one who has suggested the name that will be finally taken as >> the new >> name for REA will be awarded with a six-pack of local beer at next >> IETF in >> San Diego. If there are multiple people suggesting the same name, >> they >> must share the six pack (sorry for that, but not enough money for >> it ;-) >> >> Of course all things apply here: participants must be older than 18 >> or 21 years >> (depending on location of IETF and the local laws), no guarantees, >> not entitled >> for anything, must be at the next IETF meeting in San Diego in >> November 2006, >> no monetary refunding, etc... >> >> >> So, looking forward to many suggestion for a "new REA". >> >> Martin for the NATFW NSLP authors. >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 10 16:53:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXOag-0000ww-DR; Tue, 10 Oct 2006 16:52:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXOae-0000wm-Op for nsis@ietf.org; Tue, 10 Oct 2006 16:52:40 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXOad-0005g3-G0 for nsis@ietf.org; Tue, 10 Oct 2006 16:52:40 -0400 Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Tue, 10 Oct 2006 23:52:38 +0300 id 000AFD67.452C0816.00004085 Date: Tue, 10 Oct 2006 23:52:37 +0300 (EEST) From: Jukka MJ Manner To: Xiaoming Fu , "Kappler, Cornelia" Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: nsis@ietf.org Subject: [NSIS] Question to the CL QoS Model authors X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Xiaoming and Cornelia, I was wondering if you have some ideas on how the CL QoS Model would handle all the current QSPEC-1 parameters? Your draft lists that as an open issue. Cheers, Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 10 22:53:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXUCP-00047Z-TV; Tue, 10 Oct 2006 22:52:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXUCO-00047T-VD for nsis@ietf.org; Tue, 10 Oct 2006 22:52:00 -0400 Received: from smtp.mei.co.jp ([133.183.129.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXUCM-0003Zw-Ag for nsis@ietf.org; Tue, 10 Oct 2006 22:52:00 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/bulls) with ESMTP id k9B2pSvG007886; Wed, 11 Oct 2006 11:51:28 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id k9B2pSQ14248; Wed, 11 Oct 2006 11:51:28 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/redsox) with ESMTP id k9B2pQY27763; Wed, 11 Oct 2006 11:51:26 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] A question to people about QoS NSLP Tear operation Date: Wed, 11 Oct 2006 10:47:06 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD01366516@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] A question to people about QoS NSLP Tear operation Thread-Index: AcbsRP5MOt1vrdXBQl+DEAXSn9JICgAl/Jhw From: "Cheng Hong" To: "Jukka MJ Manner" , "Georgios Karagiannis" X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jukka, > later receive a retransmitted tear, we can't provide that=20 > anymore to the RMF. Thus, we keep QoS NSLP state after a tear=20 > for some period of time, we need to do some "trick" to avoid=20 > an error situation. That is correct. So, the Qos NSLP state should have a flag to indicate its state, i.e. tear already issued to RMF. Thus, following tear will not result in sending it again to RMF. cheers Cheng Hong =20 > -----Original Message----- > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI]=20 > Sent: Tuesday, October 10, 2006 4:22 PM > To: Georgios Karagiannis > Cc: Cheng Hong; nsis@ietf.org > Subject: RE: [NSIS] A question to people about QoS NSLP Tear operation >=20 >=20 > Hi, >=20 > So what would be proposed behavior, with and without RII? >=20 > Note that we should not make requirements to the RMF and the=20 > QSPEC processing. For example, if we get a tearing RESERVE,=20 > we provide it to the RMF, which removes the state. If still=20 > keep the QoS NSLP state, but send the message further, and=20 > later receive a retransmitted tear, we can't provide that=20 > anymore to the RMF. Thus, we keep QoS NSLP state after a tear=20 > for some period of time, we need to do some "trick" to avoid=20 > an error situation. >=20 > After the tear procedure, we are done with the spec. >=20 > Jukka >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 10 23:24:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXUhf-0002ND-SJ; Tue, 10 Oct 2006 23:24:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXUhd-0002JH-AG for nsis@ietf.org; Tue, 10 Oct 2006 23:24:17 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXUYj-0006o7-B1 for nsis@ietf.org; Tue, 10 Oct 2006 23:15:06 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9B3F0LX009126 for ; Wed, 11 Oct 2006 06:15:04 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Oct 2006 06:14:45 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Oct 2006 06:14:44 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Oct 2006 06:14:44 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Resolving discussion on the QSPEC document Thread-Index: AcbsWB90twD2v9/ERmKNo8QiPRS6aAAijjpA From: To: X-OriginalArrivalTime: 11 Oct 2006 03:14:44.0938 (UTC) FILETIME=[66948AA0:01C6ECE3] X-Spam-Score: 0.2 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Subject: [NSIS] Resolving discussion on the QSPEC document X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, I've tried to go through the volumes of mail on this the open issues, and it is quite=20 confusing to try to figure out any sort of consensus. The lack of formal issues being filed with suggested text and lack error tracking has contributed to the unclear situation. Finally, most of the discussion is quite circular, which has not be helpful either. In order to come to consensus, I ask everyone with any open concerns on the QSPEC draft to file an issue in the format below by close of business on Friday. I will then ask the QSPEC authors to consider the issue and look at resolving it, and see if there is consensus that I can then call. I expect this should take next week to resolve. After this, I think we will be able to complete this draft. Issue submission format: Description of issue Submitter name: Your_Name_Here Submitter email address: Your_Email_Address_Here Date first submitted: Insert_Date_Here Reference: URL to e-mail describing problem, if available Comment type: ['T'echnical | 'E'ditorial] Priority: ['S' Must fix | '1' Should fix | '2' May fix ] Section: Insert_Section_Number_Here Rationale/Explanation of issue: Length description of problem Requested change: Proposed changes to the document. Please be specific about what text you want to change,=20 add or delete. Issues cannot be considered until specific text is provided. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 11 02:10:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXXHc-0000y5-58; Wed, 11 Oct 2006 02:09:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXXHR-0000oW-Vr for nsis@ietf.org; Wed, 11 Oct 2006 02:09:26 -0400 Received: from mailer.gwdg.de ([134.76.10.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXXBE-0002uT-TR for nsis@ietf.org; Wed, 11 Oct 2006 02:03:02 -0400 Received: from 27hl-10s.tsinghua.edu.cn ([166.111.250.233] helo=[192.168.0.111]) by mailer.gwdg.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1GXX5W-0000mB-Jo; Wed, 11 Oct 2006 07:57:12 +0200 Message-ID: <452C87AD.1080702@cs.uni-goettingen.de> Date: Wed, 11 Oct 2006 07:57:01 +0200 From: Xiaoming Fu Organization: University of Goettingen, Germany User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Jukka MJ Manner Subject: Re: [NSIS] Question to the CL QoS Model authors References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-Id: xfu X-Virus-Scanned: (clean) by exiscan+sophie X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: nsis@ietf.org, "Kappler, Cornelia" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jukka, The CLS draft is actually a remapping of RSVP CLS parameters (and procedures) to NSIS. In the QSPEC-1 parameters specified in [draft-ietf-nsis-qspec], there are the following two types: - is an optional parameter in QNI, namely it can be included or excluded in the CLS control information. If it is included in a message, then CLS QNE must interpret and populate it. - and are mandatory for all (QNI QNEs QNR) including other QoSMs; mandatory for receiver-initiated reservation, but optional for sender-initiated reservation. however, we didn't discuss how exactly the objects other than Token Bucket(s) inside the QoS Desired etc should be handled. We thought a QNE doesn't need to include (for QNI/QNR) nor interpret any of them. Any remarks on this? Xiaoming Jukka MJ Manner wrote: > Hi Xiaoming and Cornelia, > > I was wondering if you have some ideas on how the CL QoS Model would > handle all the current QSPEC-1 parameters? Your draft lists that as an > open issue. > > Cheers, > Jukka > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis -- Cheers, Xiaoming -- http://user.informatik.uni-goettingen.de/~fu _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 11 03:05:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXY8Z-0007a9-6P; Wed, 11 Oct 2006 03:04:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXY8Y-0007a4-4e for nsis@ietf.org; Wed, 11 Oct 2006 03:04:18 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXY8W-00054t-Mm for nsis@ietf.org; Wed, 11 Oct 2006 03:04:18 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9B74Cob018457 for ; Wed, 11 Oct 2006 10:04:15 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Oct 2006 10:04:13 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Oct 2006 10:04:12 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Oct 2006 10:04:13 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NSIS Agenda items Thread-Index: AcbtA3M3q0sxVyvtQZeBHCtk9LCLhA== From: To: X-OriginalArrivalTime: 11 Oct 2006 07:04:12.0956 (UTC) FILETIME=[74F55DC0:01C6ED03] X-Spam-Score: 0.2 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [NSIS] NSIS Agenda items X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, We have a slot at the next IETF meeting. We have not made much progress on our core set of documents, so we have essentially stalled on revising our charter. I would hope we can wrap up things on the NSLPs, QSPEC and QoS Model documents. If you have something to discuss at the next IETF, please let me know. For existing WG items, please respond with the person who will be doing the discussing. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 11 04:55:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXZrB-0005su-Vj; Wed, 11 Oct 2006 04:54:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXZrA-0005so-Mf for nsis@ietf.org; Wed, 11 Oct 2006 04:54:28 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXZr9-0000ym-DM for nsis@ietf.org; Wed, 11 Oct 2006 04:54:28 -0400 Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Wed, 11 Oct 2006 11:54:24 +0300 id 000AFE04.452CB140.00007919 Date: Wed, 11 Oct 2006 11:54:24 +0300 (EEST) From: Jukka MJ Manner To: nsis@ietf.org Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [NSIS] QPECC-issue (JM-1) X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Clarification for "interpret" Submitter name: Jukka Manner Submitter email address: jmanner@cs.helsinki.fi Date first submitted: 11.10.2006 Reference: URL to e-mail describing problem, if available Comment type: E Priority: S Section: Various Rationale/Explanation of issue: The draft is not clear enough about what can or can not a QNE do if it receives a QSPEC-1 parameter, which it is not able to make use of. What is exactly allowed or not for "strictly interpret". Clarification is needed, early enough in the document so that it is clear to the reader what is allowed from the very beginning. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 11 04:59:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXZuz-0007Zr-0B; Wed, 11 Oct 2006 04:58:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXZux-0007Zk-HQ for nsis@ietf.org; Wed, 11 Oct 2006 04:58:23 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXZuw-0001Wg-7A for nsis@ietf.org; Wed, 11 Oct 2006 04:58:23 -0400 Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Wed, 11 Oct 2006 11:58:10 +0300 id 000AFD32.452CB222.0000597E Date: Wed, 11 Oct 2006 11:58:10 +0300 (EEST) From: Jukka MJ Manner To: nsis@ietf.org Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [NSIS] QSPEC-issue (JM-2) X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Earlier examples Submitter name: Jukka Manner Submitter email address: jmanner@cs.helsinki.fi Date first submitted: 11.10.2006 Reference: http://www1.ietf.org/mail-archive/web/nsis/current/msg06819.html Comment type: E Priority: 1 Section: somewhere in the beginning Rationale/Explanation of issue: A simple example of QOSM interworking and handling of QSPEC-1 vs. QSPEC-2 is needed in the very beginning of the draft. Now there is one such example, 4.5 pages as an appendix. A simple example in the very begining would help the reader. Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 11 05:05:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXa1e-0001tG-Vy; Wed, 11 Oct 2006 05:05:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXa1d-0001t6-Bg for nsis@ietf.org; Wed, 11 Oct 2006 05:05:17 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXa1c-0002WN-1p for nsis@ietf.org; Wed, 11 Oct 2006 05:05:17 -0400 Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Wed, 11 Oct 2006 12:05:15 +0300 id 000AFD50.452CB3CB.00000C67 Date: Wed, 11 Oct 2006 12:05:13 +0300 (EEST) From: Jukka MJ Manner To: nsis@ietf.org Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [NSIS] QSPEC-issue (JM-3) X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Rationale for Excess Treatment Submitter name: Jukka Manner Submitter email address: jmanner@cs.helsinki.fi Date first submitted: 11.10.2006 Reference: http://www1.ietf.org/mail-archive/web/nsis/current/msg06793.html Comment type: T Priority: 1 Section: Various Rationale/Explanation of issue: Why can a QNI dictate the way the network elements handle out of profile data, packets that violate the reservation asked by the QNI. Can the QNI also disallow any policing, thus, it would be able to send more than it asked for, and ask the network just accept that: Value for Excess Treatment: "3: no metering or policing is permitted" _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 11 05:41:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXaaN-0000qK-8H; Wed, 11 Oct 2006 05:41:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXaaL-0000qD-Vf for nsis@ietf.org; Wed, 11 Oct 2006 05:41:09 -0400 Received: from mail.uc.pt ([193.137.200.38] helo=mail-2.ci.uc.pt) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXaaG-0002Tx-5g for nsis@ietf.org; Wed, 11 Oct 2006 05:41:09 -0400 Received: from mail-2.ci.uc.pt (mail.uc.pt [127.0.0.1]) by localhost.mail.uc.pt (Postfix) with ESMTP id 3FA7388DE2F; Wed, 11 Oct 2006 10:40:44 +0100 (WEST) Received: from zoing (unknown [193.136.236.188]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail-2.ci.uc.pt (Postfix) with ESMTP id 07C5688DE2E; Wed, 11 Oct 2006 10:40:43 +0100 (WEST) From: =?iso-8859-1?Q?Lu=EDs_Cordeiro?= To: , Subject: RE: [NSIS] NSIS Agenda items Date: Wed, 11 Oct 2006 10:40:43 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcbtA3M3q0sxVyvtQZeBHCtk9LCLhAAFNWBQ In-Reply-To: Message-Id: <20061011094044.07C5688DE2E@mail-2.ci.uc.pt> X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org John and all, I propose to have a slot to present some results about the interop = meeting that will happen tomorrow and Friday. We can discuss Friday after the = tests what to present and by whom. I would like also to make an update about the HyPath ID, especially to = show some of the HyPath implementation tests results. So it's like this: Presentation: Interop meeting Responsible: [to decide] Time: [20-30 min?] Desc: Results of the interop meeting about GIST, QoS NSLP, QSPEC and = NATFW NSLP Presentation: HyPath Responsible: Lu=EDs Cordeiro Time: 5-10 min Desc: ID updates and implementation tests results Do you agree? BR, Lu=EDs Cordeiro -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 Sent: quarta-feira, 11 de Outubro de 2006 8:04 To: nsis@ietf.org Subject: [NSIS] NSIS Agenda items Hi all, We have a slot at the next IETF meeting. We have not made much progress on our core set of documents, so we have essentially stalled on revising our charter. I would hope we can wrap up things on the NSLPs, QSPEC and QoS Model documents. If you have something to discuss at the next IETF, please let me know. For existing WG items, please respond with the person who will be doing the discussing. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 11 06:48:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXbcs-00066C-N7; Wed, 11 Oct 2006 06:47:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXbcr-000667-RF for nsis@ietf.org; Wed, 11 Oct 2006 06:47:49 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXbco-0002jo-De for nsis@ietf.org; Wed, 11 Oct 2006 06:47:49 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k9BAlT8F021311 for ; Wed, 11 Oct 2006 11:47:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Oct 2006 11:47:29 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: GIST issue on Error Message Formatting Thread-Index: AcbtIq8CwOsksXEMQf+G26OClNeRIQ== From: "Hancock, Robert" To: "nsis" X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Subject: [NSIS] GIST issue on Error Message Formatting X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, An issue has been raised on error message formatting. It is in the tracker as issue #130 (http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue130), and the summary text is included below. This is a solicitation for input, especially from the implementors, on this matter. In the absence of input, my preference would be to leave to spec unchanged, but if people feel (even not particularly strongly) that a more structured syntax would be preferable it is not that much effort to change. It would be very good to see change/no change comments either way. cheers, robert h. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D The current error message formats are essentially fixed and predefined for each error code; that is: - if you know the error code, you know precisely what should be in the message and you can parse it completely. Someone generating the error has no freedom about what information to include (cannot include other Additional Info fields, for example). - if you don't know the error code (typically because it is a new error), you cannot parse anything about it beyond the MRI - you cannot parse any additional info field or the debugging comment. It's been suggested that it would be possible to make the additional info fields some kind of object in their own right, in which case there would be some kind of TLV format for them, and probably a registry for their type codes.=20 The advantage of this is that every message can always be parsed. (However, without knowing the semantics of the error code, it still may be hard to do anything useful with the information.) The disadvantage is that there is a minor change in protocol specification complexity. It isn't clear what the impact is on implementation complexity. The error message parser might be a little more complex but would be more future proof and with less special cases. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 11 06:48:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXbdM-0006D6-Ej; Wed, 11 Oct 2006 06:48:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXbdK-0006Cz-Q9 for nsis@ietf.org; Wed, 11 Oct 2006 06:48:18 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXbdI-0002np-9E for nsis@ietf.org; Wed, 11 Oct 2006 06:48:18 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9BAmCoH010098; Wed, 11 Oct 2006 13:48:12 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Oct 2006 13:48:12 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Oct 2006 13:48:12 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] QPECC-issue (JM-1) Date: Wed, 11 Oct 2006 13:48:12 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QPECC-issue (JM-1) Thread-Index: AcbtE2UCPoe5LQk4TmiTUfDb9k0T3gADzrlQ From: To: , X-OriginalArrivalTime: 11 Oct 2006 10:48:12.0539 (UTC) FILETIME=[BF92FCB0:01C6ED22] X-Spam-Score: 0.2 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Jukka, Can you give some suggestions on what text or where the text belongs? If you don't, it is far to easy for the authors to say that the text is there, you just haven't read the draft well enough. thanks, John=20 >-----Original Message----- >From: ext Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI]=20 >Sent: 11 October, 2006 11:54 >To: nsis@ietf.org >Subject: [NSIS] QPECC-issue (JM-1) > > >Clarification for "interpret" > > >Submitter name: Jukka Manner >Submitter email address: jmanner@cs.helsinki.fi Date first=20 >submitted: 11.10.2006 >Reference: URL to e-mail describing problem, if available=20 >Comment type: E >Priority: S >Section: Various >Rationale/Explanation of issue: > >The draft is not clear enough about what can or can not a QNE=20 >do if it receives a QSPEC-1 parameter, which it is not able to=20 >make use of. What is exactly allowed or not for "strictly=20 >interpret". Clarification is needed, early enough in the=20 >document so that it is clear to the reader what is allowed=20 >from the very beginning. > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 11 06:49:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXbdm-0006Fr-0A; Wed, 11 Oct 2006 06:48:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXbdl-0006Fm-47 for nsis@ietf.org; Wed, 11 Oct 2006 06:48:45 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXbdj-0002uW-JP for nsis@ietf.org; Wed, 11 Oct 2006 06:48:45 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9BAme0F025640; Wed, 11 Oct 2006 13:48:41 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Oct 2006 13:48:41 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Oct 2006 13:48:40 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] QSPEC-issue (JM-2) Date: Wed, 11 Oct 2006 13:48:40 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QSPEC-issue (JM-2) Thread-Index: AcbtE5gGlbVaJT9PTVu0a7jpV5PlwwADy6RA From: To: , X-OriginalArrivalTime: 11 Oct 2006 10:48:40.0822 (UTC) FILETIME=[D06EA160:01C6ED22] X-Spam-Score: 0.2 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Jukka, Where would the example best fit, in your opinion? John=20 >-----Original Message----- >From: ext Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI]=20 >Sent: 11 October, 2006 11:58 >To: nsis@ietf.org >Subject: [NSIS] QSPEC-issue (JM-2) > > >Earlier examples > >Submitter name: Jukka Manner >Submitter email address: jmanner@cs.helsinki.fi >Date first submitted: 11.10.2006 =20 >Reference:=20 >http://www1.ietf.org/mail-archive/web/nsis/current/msg06819.html >Comment type: E >Priority: 1 >Section: somewhere in the beginning >Rationale/Explanation of issue: > >A simple example of QOSM interworking and handling of QSPEC-1=20 >vs. QSPEC-2 is needed in the very beginning of the draft. Now=20 >there is one such example, 4.5 pages as an appendix. A simple=20 >example in the very begining would help the reader. > >Jukka > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 11 06:50:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXbeO-0006Ti-C8; Wed, 11 Oct 2006 06:49:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXbeM-0006Pp-Rj for nsis@ietf.org; Wed, 11 Oct 2006 06:49:23 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXbeL-00038s-G5 for nsis@ietf.org; Wed, 11 Oct 2006 06:49:22 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k9BAnCO7013191 for ; Wed, 11 Oct 2006 12:49:16 +0200 (MEST) From: "Georgios Karagiannis" To: Date: Wed, 11 Oct 2006 12:49:08 +0200 Message-ID: <000f01c6ed22$e3f4cca0$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcbtIuDB+scLK0BoRGuE9Ju7MtwviQ== X-Spam-Score: -5.537 () ALL_TRUSTED,AWL,BAYES_00,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Wed, 11 Oct 2006 12:49:18 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [NSIS] QSPEC-issue (GK-1) X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Description of issue Change to QSPEC-2 parameter Submitter name: Georgios Karagiannis Submitter email address: karagian@cs.utwente.nl Date first submitted: 11.10.2006 Reference: Comment type: T Priority: 'S' Section: Various Rationale/Explanation of issue: This issue is additional to the issue JM-3 submitted by Jukka. It is not realistic to assume that the "Excess treatment" parameter can dictate to all QNEs how to handle the excess traffic. For example, in situations of severe congestion the network operator must be able to ignore the parameter and apply a solution that efficiently solves the severe congestion. Diffserv aware QNEs usually have to support a Per Hop Behaviour (PHB). A PHB specification defines already how the excess traffic should be handled. Therefore, a QNI cannot dicate how a Diffserv aware QNE must handle the excess traffic. Requested change: The parameter must be a QSPEC-2 parameter. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 11 07:05:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXbtJ-0005WI-J0; Wed, 11 Oct 2006 07:04:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXbtI-0005WB-Bi for nsis@ietf.org; Wed, 11 Oct 2006 07:04:48 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXbtG-0006G5-Vt for nsis@ietf.org; Wed, 11 Oct 2006 07:04:48 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k9BB4dWG014613 for ; Wed, 11 Oct 2006 13:04:43 +0200 (MEST) From: "Georgios Karagiannis" To: Date: Wed, 11 Oct 2006 13:04:34 +0200 Message-ID: <001001c6ed25$0bda5a30$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcbtJQjBxLciY7zzSeKpBYf6LPOaYQ== X-Spam-Score: -5.536 () ALL_TRUSTED,AWL,BAYES_00,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Wed, 11 Oct 2006 13:04:44 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [NSIS] QSPEC-issue (GK-2) X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Description of issue Change to QSPEC-2 parameter Submitter name: Georgios Karagiannis Submitter email address: karagian@cs.utwente.nl Date first submitted: 11.10.2006 Reference: Comment type: T Priority: 'S' Section: Various Rationale/Explanation of issue: It is not realistic to assume that the QNI is able to know which network technologies (Diffserv, MPLS, Y.1541) are supported on the end-to-end path. If the "QoS Class" parameter is considered to be a QSPEC-1 parameter then it will mean that all QNEs located on the end-to-end path must support the Diffserv and MPLS and Y.1541 technologies. This is unrealistic. Requested change: The parameter must be a QSPEC-2 parameter. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 11 07:27:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXcEM-0007Vd-FK; Wed, 11 Oct 2006 07:26:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXcEK-0007VX-Le for nsis@ietf.org; Wed, 11 Oct 2006 07:26:32 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXcEI-00038f-Jo for nsis@ietf.org; Wed, 11 Oct 2006 07:26:32 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9BBQMU1022649; Wed, 11 Oct 2006 14:26:22 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Oct 2006 14:26:22 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Oct 2006 14:26:21 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] NSIS Agenda items Date: Wed, 11 Oct 2006 14:26:22 +0300 Message-ID: In-Reply-To: <20061011094044.07C5688DE2E@mail-2.ci.uc.pt> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] NSIS Agenda items Thread-Index: AcbtA3M3q0sxVyvtQZeBHCtk9LCLhAAFNWBQAAPxHwA= From: To: , X-OriginalArrivalTime: 11 Oct 2006 11:26:21.0973 (UTC) FILETIME=[142EE450:01C6ED28] X-Spam-Score: 0.2 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Yes, that is fine. John=20 >-----Original Message----- >From: ext Lu=EDs Cordeiro [mailto:cordeiro@dei.uc.pt]=20 >Sent: 11 October, 2006 12:41 >To: Loughney John (Nokia-NRC/Helsinki); nsis@ietf.org >Subject: RE: [NSIS] NSIS Agenda items > >John and all, > >I propose to have a slot to present some results about the=20 >interop meeting that will happen tomorrow and Friday. We can=20 >discuss Friday after the tests what to present and by whom. > >I would like also to make an update about the HyPath ID,=20 >especially to show some of the HyPath implementation tests results. > >So it's like this: > >Presentation: Interop meeting >Responsible: [to decide] >Time: [20-30 min?] >Desc: Results of the interop meeting about GIST, QoS NSLP,=20 >QSPEC and NATFW NSLP > >Presentation: HyPath >Responsible: Lu=EDs Cordeiro >Time: 5-10 min >Desc: ID updates and implementation tests results > > >Do you agree? > >BR, >Lu=EDs Cordeiro > >-----Original Message----- >From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] >Sent: quarta-feira, 11 de Outubro de 2006 8:04 >To: nsis@ietf.org >Subject: [NSIS] NSIS Agenda items > >Hi all, > >We have a slot at the next IETF meeting. We have not made=20 >much progress on our core set of documents, so we have=20 >essentially stalled on revising our charter. I would hope we=20 >can wrap up things on the NSLPs, QSPEC and QoS Model documents. > >If you have something to discuss at the next IETF, please let me know. >For existing WG items, please respond with the person who will=20 >be doing the discussing. > >thanks, >John > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 11 08:16:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXczn-00053a-LV; Wed, 11 Oct 2006 08:15:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXczm-00053U-4o for nsis@ietf.org; Wed, 11 Oct 2006 08:15:34 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXczk-0003jo-QT for nsis@ietf.org; Wed, 11 Oct 2006 08:15:34 -0400 Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Wed, 11 Oct 2006 15:15:31 +0300 id 000AFDF8.452CE063.00003812 Date: Wed, 11 Oct 2006 15:15:30 +0300 (EEST) From: Jukka MJ Manner To: nsis@ietf.org Subject: RE: [NSIS] QSPEC-issue (JM-2) In-Reply-To: Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org I would propose to have an example at the end of Section 4. The earlier the better. The example does not need to mentioned what parameters exactly are Q-1 or Q-2, just how the concept and their processing works with paths where there are more than one QOSM in use. Jukka On Wed, 11 Oct 2006, john.loughney@nokia.com wrote: > Jukka, > > Where would the example best fit, in your opinion? > > John > > >-----Original Message----- > >From: ext Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > >Sent: 11 October, 2006 11:58 > >To: nsis@ietf.org > >Subject: [NSIS] QSPEC-issue (JM-2) > > > > > >Earlier examples > > > >Submitter name: Jukka Manner > >Submitter email address: jmanner@cs.helsinki.fi > >Date first submitted: 11.10.2006 > >Reference: > >http://www1.ietf.org/mail-archive/web/nsis/current/msg06819.html > >Comment type: E > >Priority: 1 > >Section: somewhere in the beginning > >Rationale/Explanation of issue: > > > >A simple example of QOSM interworking and handling of QSPEC-1 > >vs. QSPEC-2 is needed in the very beginning of the draft. Now > >there is one such example, 4.5 pages as an appendix. A simple > >example in the very begining would help the reader. > > > >Jukka > > > >_______________________________________________ > >nsis mailing list > >nsis@ietf.org > >https://www1.ietf.org/mailman/listinfo/nsis > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 11 08:22:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXd5d-0007ET-6q; Wed, 11 Oct 2006 08:21:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXd5c-0007EN-1f for nsis@ietf.org; Wed, 11 Oct 2006 08:21:36 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXd5a-00050J-Im for nsis@ietf.org; Wed, 11 Oct 2006 08:21:36 -0400 Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Wed, 11 Oct 2006 15:21:34 +0300 id 000AFDDC.452CE1CE.000078D2 Date: Wed, 11 Oct 2006 15:21:33 +0300 (EEST) From: Jukka MJ Manner To: "Hancock, Robert" Subject: Re: [NSIS] GIST issue on Error Message Formatting In-Reply-To: Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Rob, I feel giving more structure to the error messages would help implementations and deployment. I guess we have something like that in the QoS NSLP spec, and at least so far no one has complained. :) Jukka On Wed, 11 Oct 2006, Hancock, Robert wrote: > Hi all, > > An issue has been raised on error message formatting. It is in the > tracker as issue #130 > (http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue130), > and the summary text is included below. > > This is a solicitation for input, especially from the implementors, on > this matter. In the absence of input, my preference would be to leave to > spec unchanged, but if people feel (even not particularly strongly) that > a more structured syntax would be preferable it is not that much effort > to change. It would be very good to see change/no change comments either > way. > > cheers, > > robert h. > > ======================================================================== > === > The current error message formats are essentially fixed and predefined > for each > error code; that is: > - if you know the error code, you know precisely what should be in the > message > and you can parse it completely. Someone generating the error has no > freedom > about what information to include (cannot include other Additional Info > fields, > for example). > - if you don't know the error code (typically because it is a new > error), you > cannot parse anything about it beyond the MRI - you cannot parse any > additional > info field or the debugging comment. > > It's been suggested that it would be possible to make the additional > info fields > some kind of object in their own right, in which case there would be > some kind > of TLV format for them, and probably a registry for their type codes. > > The advantage of this is that every message can always be parsed. > (However, > without knowing the semantics of the error code, it still may be hard to > do > anything useful with the information.) > > The disadvantage is that there is a minor change in protocol > specification > complexity. > > It isn't clear what the impact is on implementation complexity. The > error > message parser might be a little more complex but would be more future > proof and > with less special cases. > ======================================================================== > == > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 11 12:52:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXhJW-00061t-9E; Wed, 11 Oct 2006 12:52:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXhJV-00061o-Rp for nsis@ietf.org; Wed, 11 Oct 2006 12:52:13 -0400 Received: from mclmx2.mail.saic.com ([149.8.64.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXhJU-0001Mi-GZ for nsis@ietf.org; Wed, 11 Oct 2006 12:52:13 -0400 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com for nsis@ietf.org; Wed, 11 Oct 2006 12:51:56 -0400 Received: from 0015-ITS-EXBH01.us.saic.com ([10.43.229.18]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006101112515730378 for ; Wed, 11 Oct 2006 12:51:57 -0400 Received: from 0591-ITS-EXMP02.us.saic.com ([10.42.81.248]) by 0015-ITS-EXBH01.us.saic.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Oct 2006 12:51:57 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [NSIS] QSPEC-issue (RRR-1) Date: Wed, 11 Oct 2006 12:51:55 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426E1CECE@0591-ITS-EXMP02.us.saic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QSPEC-issue (RRR-1) Thread-Index: AcbtJQjBxLciY7zzSeKpBYf6LPOaYQALHjUQ References: <001001c6ed25$0bda5a30$4c0d5982@dynamic.ewi.utwente.nl> From: "Roy, Radhika R." To: X-OriginalArrivalTime: 11 Oct 2006 16:51:57.0149 (UTC) FILETIME=[900E30D0:01C6ED55] X-Spam-Score: 0.1 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0942113131==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0942113131== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6ED55.8EF70836" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6ED55.8EF70836 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Description of issue: Delete the value-based to parameter of = Y.1541 and DSTE from QSPEC Submitter name: Radhika R. Roy Submitter email address: radhika.r.roy@saic.com=20 Date first submitted: 11.10.2006 Reference:=20 Comment type: T Priority: 'S' Section: Various Rationale/Explanation of issue: The value-based QOS Classes of Y.1541 and DSTE are incompatible with = non-value based QOS classes of DiffServ interoperability. Moreover, this = spec deal with non-value-based generic parameters, not any = implementation-specific value-base parameters. The = implementation-specific values of any parameters that the users will use = as they deem to be necessary are the not the objectives of this draft to = start with. =20 Why does the draft will deal with implementation-specific value-based = QOS classes in this generic QSPEC any implementation is not for = standardization? =20 To deal with so-called value-based QOS class parameters, the stand-alone = separate drafts need to be written as they are non-interoperable.=20 =20 The mixing of interoperable items with the non-interoperable items in = the same draft is a serious problem of QSPEC, and it breaks all norms of = standardization because interoperability the main purpose for all = standards. If the standard itself creates non-interoperability problems = unnecessarily, it is against the norms of IETF. =20 Requested change: Any reference of the value-based parameter of Y.1541 and = DSTE must be removed from QSPEC. ------_=_NextPart_001_01C6ED55.8EF70836 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [NSIS] QSPEC-issue (GK-2)=0A= =0A= =0A= =0A=
Description of issue: Delete the = value-based <QoS Class> to parameter of = Y.1541 and DSTE  from QSPEC


Submitter name: Radhika R. = Roy
Submitter email address: radhika.r.roy@saic.com =
=0A=
Date first submitted: 11.10.2006
Reference: 
Comment type: T
Priority: = 'S'
Section: Various
Rationale/Explanation of issue:

The = value-based QOS Classes of Y.1541 and DSTE are incompatible with = non-value based QOS classes of DiffServ interoperability. = Moreover, this spec deal with non-value-based generic parameters, = not any implementation-specific value-base parameters. The = implementation-specific values of any parameters that the users = will use as they deem to be necessary are the not the objectives of this = draft to start with.
=0A=
 
=0A=
Why does the draft will deal with = implementation-specific value-based QOS classes in this generic QSPEC = any implementation is not for standardization?
=0A=
 
=0A=
To deal with so-called value-based QOS = class parameters, the stand-alone separate drafts need to be written as = they are non-interoperable.
=0A=
 
=0A=
The mixing of interoperable items with the = non-interoperable items in the same draft is a serious problem of QSPEC, = and it breaks all norms of standardization because interoperability the = main purpose for all standards. If the standard itself creates = non-interoperability problems unnecessarily, it is against the = norms of IETF.
=0A=
 
=0A=
Requested change:
=0A=

Any reference of the value-based = <QoS Class> parameter of Y.1541 and DSTE must be removed from = QSPEC.
------_=_NextPart_001_01C6ED55.8EF70836-- --===============0942113131== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0942113131==-- From nsis-bounces@ietf.org Wed Oct 11 12:55:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXhMK-0006pH-Et; Wed, 11 Oct 2006 12:55:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXhMK-0006pB-1Y for nsis@ietf.org; Wed, 11 Oct 2006 12:55:08 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GXhMI-0001pg-LH for nsis@ietf.org; Wed, 11 Oct 2006 12:55:08 -0400 Received: (qmail invoked by alias); 11 Oct 2006 16:55:05 -0000 Received: from ip-80-226-253-50.vodafone-net.de (EHLO [10.227.167.26]) [80.226.253.50] by mail.gmx.net (mp030) with SMTP; 11 Oct 2006 18:55:05 +0200 X-Authenticated: #29516787 Message-ID: <452D21EC.3040302@gmx.net> Date: Wed, 11 Oct 2006 18:55:08 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: john.loughney@nokia.com, NSIS References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Subject: [NSIS] QoS Discussions X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi John, Hi all, I think we need to have a face-to-face discussion about the QoS work (in particular about the QSPEC document) in order to make some progress. I suggest to meet already on Saturday or Sunday. I assume that at least the QoS NSLP, the QSPEC, QoSM authors and John are interested. I will setup a Jabber chat room to allow remote participation. Who would be available? Ciao Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 11 12:56:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXhNU-0007C6-RV; Wed, 11 Oct 2006 12:56:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXhNT-0007Ap-2X for nsis@ietf.org; Wed, 11 Oct 2006 12:56:19 -0400 Received: from amer-mta07.csc.com ([20.137.52.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXhNR-0002Gt-Ow for nsis@ietf.org; Wed, 11 Oct 2006 12:56:19 -0400 Received: from amer-gw09.csc.com (amer-gw09.csc.com [20.6.39.245]) by amer-mta07.csc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id k9BGuBSP019415 for ; Wed, 11 Oct 2006 12:56:11 -0400 (EDT) In-Reply-To: Subject: Re: [NSIS] Resolving discussion on the QSPEC document To: X-Mailer: Lotus Notes 652HF83 November 04, 2004 Message-ID: From: Janet P Gunn Date: Wed, 11 Oct 2006 12:56:09 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 6.5.3|September 14, 2004) at 10/11/2006 12:54:52 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org John, Is there a mechanism by which we can say that we concur that something (raised by someone else) is an issue, without having to fully document the issue again? Janet wrote on 10/10/2006 11:14:44 PM: > Hi all, > > I've tried to go through the volumes of mail on this the open issues, > and it is quite > confusing to try to figure out any sort of consensus. The lack of > formal issues > being filed with suggested text and lack error tracking has contributed > to the > unclear situation. Finally, most of the discussion is quite circular, > which has > not be helpful either. > > In order to come to consensus, I ask everyone with any open concerns on > the QSPEC > draft to file an issue in the format below by close of business on > Friday. I will then > ask the QSPEC authors to consider the issue and look at resolving it, > and see > if there is consensus that I can then call. I expect this should take > next > week to resolve. After this, I think we will be able to complete this > draft. > > Issue submission format: > > Description of issue > Submitter name: Your_Name_Here > Submitter email address: Your_Email_Address_Here > Date first submitted: Insert_Date_Here > Reference: URL to e-mail describing problem, if available > Comment type: ['T'echnical | 'E'ditorial] > Priority: ['S' Must fix | '1' Should fix | '2' May fix ] > Section: Insert_Section_Number_Here > Rationale/Explanation of issue: > Length description of problem > > Requested change: > Proposed changes to the document. Please be specific about what text you > want to change, > add or delete. Issues cannot be considered until specific text is > provided. > > thanks, > John > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 11 13:07:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXhY7-0005nE-M2; Wed, 11 Oct 2006 13:07:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXhY6-0005m2-IX for nsis@ietf.org; Wed, 11 Oct 2006 13:07:18 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXhY5-00049b-1y for nsis@ietf.org; Wed, 11 Oct 2006 13:07:18 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9BH63f9025718; Wed, 11 Oct 2006 20:06:03 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Oct 2006 20:06:03 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Oct 2006 20:06:02 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Resolving discussion on the QSPEC document Date: Wed, 11 Oct 2006 20:06:02 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Resolving discussion on the QSPEC document Thread-Index: AcbtVi0nIEtzBRMdSYiBMX7R9IchbAAALJ/Q From: To: X-OriginalArrivalTime: 11 Oct 2006 17:06:02.0782 (UTC) FILETIME=[88178BE0:01C6ED57] X-Spam-Score: 0.2 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org If you agree with an issue, just respond to the issue stating that you agree (or even disagreeing). This is a very good thing to do and helps me to judge consensus. thanks, John >-----Original Message----- >From: ext Janet P Gunn [mailto:jgunn6@csc.com]=20 >Sent: 11 October, 2006 19:56 >To: Loughney John (Nokia-NRC/Helsinki) >Cc: nsis@ietf.org >Subject: Re: [NSIS] Resolving discussion on the QSPEC document > > > > > > >John, > >Is there a mechanism by which we can say that we concur that=20 >something (raised by someone else) is an issue, without having=20 >to fully document the issue again? > >Janet > > > wrote on 10/10/2006 11:14:44 PM: > >> Hi all, >> >> I've tried to go through the volumes of mail on this the=20 >open issues,=20 >> and it is quite confusing to try to figure out any sort of=20 >consensus. =20 >> The lack of formal issues being filed with suggested text and lack=20 >> error tracking has contributed to the unclear situation. Finally,=20 >> most of the discussion is quite circular, which has not be helpful=20 >> either. >> >> In order to come to consensus, I ask everyone with any open concerns=20 >> on the QSPEC draft to file an issue in the format below by close of=20 >> business on Friday. I will then ask the QSPEC authors to=20 >consider the=20 >> issue and look at resolving it, and see if there is consensus that I=20 >> can then call. I expect this should take next week to=20 >resolve. After=20 >> this, I think we will be able to complete this draft. >> >> Issue submission format: >> >> Description of issue >> Submitter name: Your_Name_Here >> Submitter email address: Your_Email_Address_Here Date first=20 >submitted:=20 >> Insert_Date_Here >> Reference: URL to e-mail describing problem, if available Comment=20 >> type: ['T'echnical | 'E'ditorial] >> Priority: ['S' Must fix | '1' Should fix | '2' May fix ] >> Section: Insert_Section_Number_Here >> Rationale/Explanation of issue: >> Length description of problem >> >> Requested change: >> Proposed changes to the document. Please be specific about what text=20 >> you want to change, add or delete. Issues cannot be considered until=20 >> specific text is provided. >> >> thanks, >> John >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 11 13:07:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXhYC-0005s4-85; Wed, 11 Oct 2006 13:07:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXhYB-0005qa-D9 for nsis@ietf.org; Wed, 11 Oct 2006 13:07:23 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXhYA-00049l-2S for nsis@ietf.org; Wed, 11 Oct 2006 13:07:23 -0400 Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Wed, 11 Oct 2006 20:07:16 +0300 id 000AFCF4.452D24C4.000055B0 Date: Wed, 11 Oct 2006 20:07:15 +0300 (EEST) From: Jukka MJ Manner To: Hannes Tschofenig Subject: Re: [NSIS] QoS Discussions In-Reply-To: <452D21EC.3040302@gmx.net> Message-ID: References: <452D21EC.3040302@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: john.loughney@nokia.com, NSIS X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Hannes, Good idea. I'm flying in during Saturday, so I can attend only on Sunday. I'm staying at the Hilton. Jukka On Wed, 11 Oct 2006, Hannes Tschofenig wrote: > Hi John, > Hi all, > > I think we need to have a face-to-face discussion about the QoS work (in > particular about the QSPEC document) in order to make some progress. > > I suggest to meet already on Saturday or Sunday. I assume that at least the > QoS NSLP, the QSPEC, QoSM authors and John are interested. I will setup a > Jabber chat room to allow remote participation. > > Who would be available? > > Ciao > Hannes > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 11 13:11:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXhbU-0000C4-FT; Wed, 11 Oct 2006 13:10:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXhbT-0000Ba-Cq for nsis@ietf.org; Wed, 11 Oct 2006 13:10:47 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXhbQ-0004XJ-WB for nsis@ietf.org; Wed, 11 Oct 2006 13:10:47 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k9BHAVur025188; Wed, 11 Oct 2006 19:10:34 +0200 (MEST) From: "Georgios Karagiannis" To: "'Jukka MJ Manner'" , "'Hannes Tschofenig'" Subject: RE: [NSIS] QoS Discussions Date: Wed, 11 Oct 2006 19:10:28 +0200 Message-ID: <003a01c6ed58$29b572a0$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcbtV8iYFqOkp3uzSbWk1jJIoAYC7gAACvJA X-Spam-Score: -5.686 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Wed, 11 Oct 2006 19:10:40 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: john.loughney@nokia.com, 'NSIS' X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Hannes I will also be able to have the meeting on Sunday! Best regards, Georgios > -----Original Message----- > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > Sent: woensdag 11 oktober 2006 19:07 > To: Hannes Tschofenig > Cc: john.loughney@nokia.com; NSIS > Subject: Re: [NSIS] QoS Discussions > > > Hi Hannes, > > Good idea. I'm flying in during Saturday, so I can attend > only on Sunday. > I'm staying at the Hilton. > > Jukka > > On Wed, 11 Oct 2006, Hannes Tschofenig wrote: > > > Hi John, > > Hi all, > > > > I think we need to have a face-to-face discussion about the > QoS work > > (in particular about the QSPEC document) in order to make > some progress. > > > > I suggest to meet already on Saturday or Sunday. I assume that at > > least the QoS NSLP, the QSPEC, QoSM authors and John are > interested. I > > will setup a Jabber chat room to allow remote participation. > > > > Who would be available? > > > > Ciao > > Hannes > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 11 13:19:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXhjZ-0003Ao-Lg; Wed, 11 Oct 2006 13:19:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXhjX-0003AO-SF for nsis@ietf.org; Wed, 11 Oct 2006 13:19:07 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXhjW-00061h-DO for nsis@ietf.org; Wed, 11 Oct 2006 13:19:07 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9BHJ1jq015174; Wed, 11 Oct 2006 20:19:04 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Oct 2006 20:19:02 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Oct 2006 20:19:02 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] QoS Discussions Date: Wed, 11 Oct 2006 20:19:02 +0300 Message-ID: In-Reply-To: <452D21EC.3040302@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QoS Discussions Thread-Index: AcbtVh04tR5SPSGsSkmQk9YE8RvFBAAAunOw From: To: , X-OriginalArrivalTime: 11 Oct 2006 17:19:02.0196 (UTC) FILETIME=[58A8AF40:01C6ED59] X-Spam-Score: 0.2 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org I think we need to do a little work first. If people have open issues, we need to have issues filed. I am tired of the back and forth which never seems to suggest text and gets us nowhere. We should put the issues into an issue tracker, add supporting text where appropriate, so that way the authors know what text is needed. Often, authors understand the document or the intents of document, but if others do not understand or agree with the document, then it is hard to make progress without suggested text. If we cannot resolve these issues via this mechanism, then we will need to discuss this face-to-face in San Diego, but I really hope we do that before hand, otherwise we cannot do anything new. John=20 >-----Original Message----- >From: ext Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 >Sent: 11 October, 2006 19:55 >To: Loughney John (Nokia-NRC/Helsinki); NSIS >Subject: [NSIS] QoS Discussions > >Hi John, >Hi all, > >I think we need to have a face-to-face discussion about the=20 >QoS work (in particular about the QSPEC document) in order to=20 >make some progress. > >I suggest to meet already on Saturday or Sunday. I assume that=20 >at least the QoS NSLP, the QSPEC, QoSM authors and John are=20 >interested. I will setup a Jabber chat room to allow remote=20 >participation. > >Who would be available? > >Ciao >Hannes > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 11 13:49:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXiC3-0002RC-Io; Wed, 11 Oct 2006 13:48:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXiC2-0002R7-Mz for nsis@ietf.org; Wed, 11 Oct 2006 13:48:34 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXiC1-0003oO-Ah for nsis@ietf.org; Wed, 11 Oct 2006 13:48:34 -0400 Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Wed, 11 Oct 2006 20:48:30 +0300 id 000AFDE2.452D2E6E.00005EAB Date: Wed, 11 Oct 2006 20:48:29 +0300 (EEST) From: Jukka MJ Manner To: nsis@ietf.org Subject: RE: [NSIS] QPECC-issue (JM-1) In-Reply-To: Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, At least: - some short statement to Section 1, 6th paragraph. - some overall examples of what to do, and what not to do into Section 5, 3rd paragraphs. Related to this, a previous thread on this topic had also discussions about when a QNE could actually _ignore_ a QSPEC-1 parameter (the preemption priority), was between Janet and Jerry in July. Jukka On Wed, 11 Oct 2006, john.loughney@nokia.com wrote: > Jukka, > > Can you give some suggestions on what text or where the text > belongs? If you don't, it is far to easy for the authors to > say that the text is there, you just haven't read the draft > well enough. > > thanks, > John > > >-----Original Message----- > >From: ext Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > >Sent: 11 October, 2006 11:54 > >To: nsis@ietf.org > >Subject: [NSIS] QPECC-issue (JM-1) > > > > > >Clarification for "interpret" > > > > > >Submitter name: Jukka Manner > >Submitter email address: jmanner@cs.helsinki.fi Date first > >submitted: 11.10.2006 > >Reference: URL to e-mail describing problem, if available > >Comment type: E > >Priority: S > >Section: Various > >Rationale/Explanation of issue: > > > >The draft is not clear enough about what can or can not a QNE > >do if it receives a QSPEC-1 parameter, which it is not able to > >make use of. What is exactly allowed or not for "strictly > >interpret". Clarification is needed, early enough in the > >document so that it is clear to the reader what is allowed > >from the very beginning. > > > >_______________________________________________ > >nsis mailing list > >nsis@ietf.org > >https://www1.ietf.org/mailman/listinfo/nsis > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 11 14:41:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXj0G-0005Br-Jb; Wed, 11 Oct 2006 14:40:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXj0F-00059N-G4 for nsis@ietf.org; Wed, 11 Oct 2006 14:40:27 -0400 Received: from mclmx2.mail.saic.com ([149.8.64.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXj0E-0001Oi-6G for nsis@ietf.org; Wed, 11 Oct 2006 14:40:27 -0400 Received: from 0015-its-ieg01.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com; Wed, 11 Oct 2006 14:40:15 -0400 Received: from 0015-ITS-EXBH01.us.saic.com ([10.43.229.18]) by 0015-its-ieg01.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006101114401513589 ; Wed, 11 Oct 2006 14:40:15 -0400 Received: from 0591-ITS-EXMP02.us.saic.com ([10.42.81.248]) by 0015-ITS-EXBH01.us.saic.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Oct 2006 14:40:15 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [NSIS] QoS Discussions Date: Wed, 11 Oct 2006 14:39:39 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426E1CECF@0591-ITS-EXMP02.us.saic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QoS Discussions Thread-Index: AcbtVhl0NC+MCUgGSQyheL2p1l5BWAADoIui References: <452D21EC.3040302@gmx.net> From: "Roy, Radhika R." To: "Hannes Tschofenig" , , "NSIS" X-OriginalArrivalTime: 11 Oct 2006 18:40:15.0188 (UTC) FILETIME=[B1304140:01C6ED64] X-Spam-Score: 0.1 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1480563334==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============1480563334== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6ED64.B014AF8A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6ED64.B014AF8A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I will NOT be available for face-to-face meeting. Radhika ________________________________ From: nsis-bounces@ietf.org on behalf of Hannes Tschofenig Sent: Wed 10/11/2006 12:55 PM To: john.loughney@nokia.com; NSIS Subject: [NSIS] QoS Discussions Hi John, Hi all, I think we need to have a face-to-face discussion about the QoS work (in particular about the QSPEC document) in order to make some progress. I suggest to meet already on Saturday or Sunday. I assume that at least the QoS NSLP, the QSPEC, QoSM authors and John are interested. I will setup a Jabber chat room to allow remote participation. Who would be available? Ciao Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis ------_=_NextPart_001_01C6ED64.B014AF8A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [NSIS] QoS Discussions=0A= =0A= =0A= =0A=
=0A=
I will NOT be = available for face-to-face meeting. Radhika
=0A=

=0A=
=0A= From: nsis-bounces@ietf.org on = behalf of Hannes Tschofenig
Sent: Wed 10/11/2006 12:55 = PM
To: john.loughney@nokia.com; NSIS
Subject: [NSIS] = QoS Discussions

=0A=
=0A=

Hi John,
Hi all,

I think we need to have a = face-to-face discussion about the QoS work (in
particular about the = QSPEC document) in order to make some progress.

I suggest to meet = already on Saturday or Sunday. I assume that at least
the QoS NSLP, = the QSPEC, QoSM authors and John are interested. I will
setup a = Jabber chat room to allow remote participation.

Who would be = available?

Ciao
Hannes

_________________________________= ______________
nsis mailing list
nsis@ietf.org
https://www1.ietf.or= g/mailman/listinfo/nsis

------_=_NextPart_001_01C6ED64.B014AF8A-- --===============1480563334== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============1480563334==-- From nsis-bounces@ietf.org Wed Oct 11 14:52:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXjBV-0003HM-8n; Wed, 11 Oct 2006 14:52:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXjBT-0003HB-Ud for nsis@ietf.org; Wed, 11 Oct 2006 14:52:03 -0400 Received: from mailer.gwdg.de ([134.76.10.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXjBS-0002cE-DK for nsis@ietf.org; Wed, 11 Oct 2006 14:52:03 -0400 Received: from [210.72.28.251] (helo=[172.31.13.12]) by mailer.gwdg.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1GXjBQ-0004gg-Hk for nsis@ietf.org; Wed, 11 Oct 2006 20:52:01 +0200 Message-ID: <452D3D4A.7000806@cs.uni-goettingen.de> Date: Wed, 11 Oct 2006 20:51:54 +0200 From: Xiaoming Fu Organization: University of Goettingen, Germany User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "nsis@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-Id: xfu X-Virus-Scanned: (clean) by exiscan+sophie X-Spam-Score: 0.5 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [NSIS] QSPEC example 1 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, Let's try to consider what about a virtual network scenario that consists of the following nodes: QNI-a: supports QoSM-a, which uses QSPEC-a (composed of QSPEC-1 parameters P11 and P12, and QSPEC-2 parameter P21 and P22). QNE-b: supports QoSM-b, which uses QSPEC-b (composed of QSPEC-1 parameters P12 and P13, and QSPEC-2 parameters P21 and P23). QNE-c: supports QoSM-c, which uses QSPEC-c (composed of QSPEC-1 parameter P14 and QSPEC-2 parameter P24). QNR-d: supports QoSM-b. First, for simplicity, let's assume the reservation is made via a sender-initiated way; no QSPEC remapping/tunneling/stacking is used in all nodes; QSPEC-2 parameters will be ignored in a non-aware node; and the e2e resource is enough for this reservation (i.e., admission control succeeds). Note interpreting a QSPEC parameter does not imply the parameter will be forwarded onto a next node. What will happen? 1) Certainly QNI-a will initialize with a Resv message carrying all its support QSPEC parameters (P11, P12; P21, P22). 2) Upon receipt of this message, QNE-b will interpret P11 (likely approximate), P12, and P21, and ignore P22. Then it will forward the Resv containing QSPEC (P11, P12, P21). 3) Upon receipt of this message, QNE-c will interpret P11 and P12 (both likely approximate) and ignore P21. Then it will forward the Resv containing QSPEC (P11, P12) 4) Upon receipt of this message, QNR-c will interpret P11 and P12 (likely approximate). Then it will issue a Response towards the QNI, containing QSPEC (P11, P12, or???!). This implies to me that either a tunneling/stacking should be used, or a remapping of all possible QSPEC-1s to a more generic, small set of QSPEC-1 parameters for all QOSMs may be provided. However, reading through currently documented QoSMs, only Token Bucket (CL/Y1541/draft-jeong-nsis-3gpp-qosm) or bandwidth (RMD) is common for all. As tunneling/stacking may be too strong for many QoSMs for deployment issues, one more general approach maybe to let QSPEC-1 only limit to bandwidth/token bucket.... Is this a too stupid/radical/simple conclusion? Xiaoming _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 11 15:05:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXjNR-0008Pb-7j; Wed, 11 Oct 2006 15:04:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXjNP-0008PW-NJ for nsis@ietf.org; Wed, 11 Oct 2006 15:04:24 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GXjNO-00045J-A0 for nsis@ietf.org; Wed, 11 Oct 2006 15:04:23 -0400 Received: (qmail invoked by alias); 11 Oct 2006 19:04:20 -0000 Received: from ip-80-226-145-146.vodafone-net.de (EHLO [10.227.149.67]) [80.226.145.146] by mail.gmx.net (mp035) with SMTP; 11 Oct 2006 21:04:20 +0200 X-Authenticated: #29516787 Message-ID: <452D403A.1020800@gmx.net> Date: Wed, 11 Oct 2006 21:04:26 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: john.loughney@nokia.com Subject: Re: [NSIS] QoS Discussions References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi John, I fully agree with you. This face-to-face meeting is not a replacement for issue tracking. I prefer to clarify everything in the next days/weeks and to drink coffee in San Diego instead. Ciao Hannes john.loughney@nokia.com schrieb: > I think we need to do a little work first. If people have open > issues, we need to have issues filed. I am tired of the back > and forth which never seems to suggest text and gets us nowhere. > > We should put the issues into an issue tracker, add supporting > text where appropriate, so that way the authors know what > text is needed. Often, authors understand the document or > the intents of document, but if others do not understand or > agree with the document, then it is hard to make progress without > suggested text. > > If we cannot resolve these issues via this mechanism, then we will > need to discuss this face-to-face in San Diego, but I really hope > we do that before hand, otherwise we cannot do anything new. > > John > >> -----Original Message----- >> From: ext Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: 11 October, 2006 19:55 >> To: Loughney John (Nokia-NRC/Helsinki); NSIS >> Subject: [NSIS] QoS Discussions >> >> Hi John, >> Hi all, >> >> I think we need to have a face-to-face discussion about the >> QoS work (in particular about the QSPEC document) in order to >> make some progress. >> >> I suggest to meet already on Saturday or Sunday. I assume that >> at least the QoS NSLP, the QSPEC, QoSM authors and John are >> interested. I will setup a Jabber chat room to allow remote >> participation. >> >> Who would be available? >> >> Ciao >> Hannes >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis >> > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 11 15:05:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXjOC-0000IA-B4; Wed, 11 Oct 2006 15:05:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXjOB-0000I4-6H for nsis@ietf.org; Wed, 11 Oct 2006 15:05:11 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GXjO9-00049j-0j for nsis@ietf.org; Wed, 11 Oct 2006 15:05:11 -0400 Received: (qmail invoked by alias); 11 Oct 2006 19:05:07 -0000 Received: from ip-80-226-145-146.vodafone-net.de (EHLO [10.227.149.67]) [80.226.145.146] by mail.gmx.net (mp026) with SMTP; 11 Oct 2006 21:05:07 +0200 X-Authenticated: #29516787 Message-ID: <452D406A.3020200@gmx.net> Date: Wed, 11 Oct 2006 21:05:14 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Georgios Karagiannis Subject: Re: [NSIS] QSPEC-issue (GK-2) References: <001001c6ed25$0bda5a30$4c0d5982@dynamic.ewi.utwente.nl> In-Reply-To: <001001c6ed25$0bda5a30$4c0d5982@dynamic.ewi.utwente.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org I support Georgios. I think it is unrealistic to assume that Y.1541 and DSTE behavior (as required for strictly interpreting these parameters) is implemented in every QNE. Ciao Hannes Georgios Karagiannis schrieb: > Description of issue > Change to QSPEC-2 parameter > > > Submitter name: Georgios Karagiannis > Submitter email address: karagian@cs.utwente.nl Date first submitted: > 11.10.2006 > Reference: > Comment type: T > Priority: 'S' > Section: Various > Rationale/Explanation of issue: > > It is not realistic to assume that the QNI is able to know which > network technologies (Diffserv, MPLS, Y.1541) are supported > on the end-to-end path. > If the "QoS Class" parameter is considered to be a QSPEC-1 parameter > then it will mean that all QNEs located on the > end-to-end path must support the Diffserv and MPLS and Y.1541 technologies. > This is unrealistic. > > Requested change: > The parameter must be a QSPEC-2 parameter. > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 11 15:05:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXjOJ-0000Mg-JY; Wed, 11 Oct 2006 15:05:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXjOI-0000LG-Es for nsis@ietf.org; Wed, 11 Oct 2006 15:05:18 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GXjOH-0004DE-21 for nsis@ietf.org; Wed, 11 Oct 2006 15:05:18 -0400 Received: (qmail invoked by alias); 11 Oct 2006 19:05:15 -0000 Received: from ip-80-226-145-146.vodafone-net.de (EHLO [10.227.149.67]) [80.226.145.146] by mail.gmx.net (mp004) with SMTP; 11 Oct 2006 21:05:15 +0200 X-Authenticated: #29516787 Message-ID: <452D4071.2010807@gmx.net> Date: Wed, 11 Oct 2006 21:05:21 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Xiaoming Fu Subject: Re: [NSIS] Question to the CL QoS Model authors References: <452C87AD.1080702@cs.uni-goettingen.de> In-Reply-To: <452C87AD.1080702@cs.uni-goettingen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: Jukka MJ Manner , nsis@ietf.org, "Kappler, Cornelia" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Xiaoming, I think Jukka was trying to find a QOSM that provides some information about the mapping of the mandatory QSPEC parameters to the one used by a QoSM. I also tried to find some guidance in existing QOSMs a couple of months ago as well and I couldn't find a lot. Ciao Hannes Xiaoming Fu schrieb: > Hi Jukka, > > The CLS draft is actually a remapping of RSVP CLS parameters (and > procedures) to NSIS. > > In the QSPEC-1 parameters specified in [draft-ietf-nsis-qspec], there > are the following two types: > > - is an optional parameter in QNI, namely it can be > included or excluded in the CLS control information. If it is included > in a message, then CLS QNE must interpret and populate it. > > - and are mandatory for all (QNI QNEs QNR) > including other QoSMs; mandatory for receiver-initiated > reservation, but optional for sender-initiated reservation. > > however, we didn't discuss how exactly the objects other than Token > Bucket(s) inside the QoS Desired etc should be handled. We thought a QNE > doesn't need to include (for QNI/QNR) nor interpret any of them. > > Any remarks on this? > Xiaoming > > Jukka MJ Manner wrote: >> Hi Xiaoming and Cornelia, >> >> I was wondering if you have some ideas on how the CL QoS Model would >> handle all the current QSPEC-1 parameters? Your draft lists that as an >> open issue. >> >> Cheers, >> Jukka >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 11 15:41:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXjwL-00019N-Pj; Wed, 11 Oct 2006 15:40:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXjwK-00018j-EE for nsis@ietf.org; Wed, 11 Oct 2006 15:40:28 -0400 Received: from mailer.gwdg.de ([134.76.10.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXjwI-0007Pq-0K for nsis@ietf.org; Wed, 11 Oct 2006 15:40:28 -0400 Received: from [210.72.28.251] (helo=[172.31.13.12]) by mailer.gwdg.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1GXjwG-0004ab-2d; Wed, 11 Oct 2006 21:40:24 +0200 Message-ID: <452D48A2.1000507@cs.uni-goettingen.de> Date: Wed, 11 Oct 2006 21:40:18 +0200 From: Xiaoming Fu Organization: University of Goettingen, Germany User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [NSIS] Question to the CL QoS Model authors References: <452C87AD.1080702@cs.uni-goettingen.de> <452D4071.2010807@gmx.net> In-Reply-To: <452D4071.2010807@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-Id: xfu X-Virus-Scanned: (clean) by exiscan+sophie X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Jukka MJ Manner , nsis@ietf.org, "Kappler, Cornelia" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Well, for such an issue, I think in general it is hard for QOSMa to other non-QOSMa QSPEC-1 parameters defined by [draft-ietf-nsis-qspec-12] to (re)map QOSMa QSPEC-1 parameters. At least in CLS case I think one QNE can simply forward them without processing. Xiaoming Hannes Tschofenig wrote: > Hi Xiaoming, > > I think Jukka was trying to find a QOSM that provides some information > about the mapping of the mandatory QSPEC parameters to the one used by a > QoSM. I also tried to find some guidance in existing QOSMs a couple of > months ago as well and I couldn't find a lot. > > Ciao > Hannes > > Xiaoming Fu schrieb: >> Hi Jukka, >> >> The CLS draft is actually a remapping of RSVP CLS parameters (and >> procedures) to NSIS. >> >> In the QSPEC-1 parameters specified in [draft-ietf-nsis-qspec], there >> are the following two types: >> >> - is an optional parameter in QNI, namely it can be >> included or excluded in the CLS control information. If it is included >> in a message, then CLS QNE must interpret and populate it. >> >> - and are mandatory for all (QNI QNEs QNR) >> including other QoSMs; mandatory for >> receiver-initiated reservation, but optional for sender-initiated >> reservation. >> >> however, we didn't discuss how exactly the objects other than Token >> Bucket(s) inside the QoS Desired etc should be handled. We thought a >> QNE doesn't need to include (for QNI/QNR) nor interpret any of them. >> >> Any remarks on this? >> Xiaoming >> >> Jukka MJ Manner wrote: >>> Hi Xiaoming and Cornelia, >>> >>> I was wondering if you have some ideas on how the CL QoS Model would >>> handle all the current QSPEC-1 parameters? Your draft lists that as >>> an open issue. >>> >>> Cheers, >>> Jukka >>> _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 11 15:50:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXk5D-0003Pj-CG; Wed, 11 Oct 2006 15:49:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXk5B-0003Pb-Hq for nsis@ietf.org; Wed, 11 Oct 2006 15:49:37 -0400 Received: from mailer.gwdg.de ([134.76.10.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXk5A-0007y4-7z for nsis@ietf.org; Wed, 11 Oct 2006 15:49:37 -0400 Received: from [210.72.28.251] (helo=[172.31.13.12]) by mailer.gwdg.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1GXk55-000588-5H for nsis@ietf.org; Wed, 11 Oct 2006 21:49:34 +0200 Message-ID: <452D4AC5.4010806@cs.uni-goettingen.de> Date: Wed, 11 Oct 2006 21:49:25 +0200 From: Xiaoming Fu Organization: University of Goettingen, Germany User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "nsis@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-Id: xfu X-Virus-Scanned: (clean) by exiscan+sophie X-Spam-Score: 0.5 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [NSIS] GIST over GIST-unaware NATs X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, There were some IESG discussions on GIST over GIST-unaware NATs. I read through draft-pashalidis-nsis-gist-legacynats-00 and found it makes a number of clarifications on this issue: - The presence of a GIST-unaware NAT can be detected by comparing headers of the GIST query-response procedure message in the two adjacent non-NAT GIST nodes. - Upon the detection of such a NAT (and affiliated rules), these two GIST nodes can then establish a UDP tunnel between them, and encapsulate the GIST messages (query-response-...) into the tunnel, and the outgoing tunnel endpoints decapsulate the messages into the desired format. - The draft also gives detailed description on GIST signaling and data traffic processing in both the case where a NAT is located close to the NI and the case where a NAT is close to the NR. The rationale looks fine to me. If there is an implementation demoing this, it would be even nicer. What do others think? Xiaoming _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 11 23:15:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXr2G-000350-Qb; Wed, 11 Oct 2006 23:15:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXr2E-00034P-5D for nsis@ietf.org; Wed, 11 Oct 2006 23:15:02 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXr2C-0004IT-KX for nsis@ietf.org; Wed, 11 Oct 2006 23:15:02 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9C3Eguk019421; Thu, 12 Oct 2006 06:14:43 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Oct 2006 06:14:42 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Oct 2006 06:14:42 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] GIST over GIST-unaware NATs Date: Thu, 12 Oct 2006 06:14:40 +0300 Message-ID: In-Reply-To: <452D4AC5.4010806@cs.uni-goettingen.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] GIST over GIST-unaware NATs Thread-Index: Acbtbo0ImRPyODS+T/i5w1PvhD9vVgAPeu9Q From: To: , X-OriginalArrivalTime: 12 Oct 2006 03:14:42.0587 (UTC) FILETIME=[8F978EB0:01C6EDAC] X-Spam-Score: 0.2 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Actually, I think this should be added as a WG document. =20 Comments? John=20 >-----Original Message----- >From: ext Xiaoming Fu [mailto:fu@cs.uni-goettingen.de]=20 >Sent: 11 October, 2006 22:49 >To: nsis@ietf.org >Subject: [NSIS] GIST over GIST-unaware NATs > >Hi all, > >There were some IESG discussions on GIST over GIST-unaware=20 >NATs. I read through draft-pashalidis-nsis-gist-legacynats-00=20 >and found it makes a number of clarifications on this issue: > >- The presence of a GIST-unaware NAT can be detected by=20 >comparing headers of the GIST query-response procedure message=20 >in the two adjacent non-NAT GIST nodes. > >- Upon the detection of such a NAT (and affiliated rules),=20 >these two GIST nodes can then establish a UDP tunnel between=20 >them, and encapsulate the GIST messages (query-response-...)=20 >into the tunnel, and the outgoing tunnel endpoints decapsulate=20 >the messages into the desired format. > >- The draft also gives detailed description on GIST signaling=20 >and data traffic processing in both the case where a NAT is=20 >located close to the NI and the case where a NAT is close to=20 >the NR. The rationale looks fine to me. If there is an=20 >implementation demoing this, it would be even nicer. > >What do others think? >Xiaoming > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 12 01:43:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXtKn-0003dR-3m; Thu, 12 Oct 2006 01:42:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXtKm-0003dL-Ab for nsis@ietf.org; Thu, 12 Oct 2006 01:42:20 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXtKi-0001Fi-PL for nsis@ietf.org; Thu, 12 Oct 2006 01:42:20 -0400 Received: from zeus.cs.utwente.nl (zeus.ewi.utwente.nl [130.89.10.12]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k9C5gD2D021208 for ; Thu, 12 Oct 2006 07:42:13 +0200 (MEST) Received: from janus.ewi.utwente.nl (janus [130.89.10.26]) by zeus.cs.utwente.nl (8.12.10/8.12.10) with ESMTP id k9C5gCL0008892 for ; Thu, 12 Oct 2006 07:42:12 +0200 (MEST) Received: (from nobody@localhost) by janus.ewi.utwente.nl (8.11.7p1+Sun/8.10.2) id k9C5g9n04029; Thu, 12 Oct 2006 07:42:09 +0200 (MEST) Date: Thu, 12 Oct 2006 07:42:09 +0200 (MEST) X-Authentication-Warning: janus.ewi.utwente.nl: nobody set sender to karagian@cs.utwente.nl using -f To: nsis@ietf.org Received: from 84.82.109.231 (auth. user karagian@imap2.cs.utwente.nl) by webmail.cs.utwente.nl with HTTP; Thu, 12 Oct 2006 05:42:08 +0000 X-IlohaMail-Blah: karagian@ewi.utwente.nl X-IlohaMail-Method: mail() [mem] X-IlohaMail-Dummy: moo X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <001001c6ed25$0bda5a30$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -5.535 () ALL_TRUSTED,AWL,BAYES_00,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Thu, 12 Oct 2006 07:42:14 +0200 (MEST) X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [NSIS] QSPEC-issue (GK-3) X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Description of issue NOTIFY may carry a QSPEC object Submitter name: Georgios Karagiannis Submitter email address: karagian@cs.utwente.nl Date first submitted: 12.10.2006 Reference: Comment type: T Priority: 'S' Section: 6.4.5 Rationale/Explanation of issue: In Section 6.4.5 it is mentioned: "No QSPEC is carried in the NOTIFY message. The NOTIFY message carries only the Session ID and a INFO_SPEC with the error code as described in [QOS-SIG]." Note that a NOTIFY is allowed to carry a QSPEC, see QoS-NSLP draft. Therefore, it should be allowed for QOSMs to specify, alo in the case of preemption, to send a QSPEC together with the INFO_SPEC object. Furthermore please note that a NOTIFY does not carry a Session ID. Requested change: Modify text in Section 6.4.5 (Preemption): From: "No QSPEC is carried in the NOTIFY message. The NOTIFY message carries only the Session ID and a INFO_SPEC with the error code as described in [QOS-SIG]." INTO: "The NOTIFY message carries an INFO_SPEC with the error code as described in [QOS-SIG]. A QOSM specification document may specify wheter a NOTIFY also carries a QSPEC object." _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 12 02:55:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXuSm-0003vZ-LD; Thu, 12 Oct 2006 02:54:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXuSl-0003vP-3n for nsis@ietf.org; Thu, 12 Oct 2006 02:54:39 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXuSj-0002FU-N2 for nsis@ietf.org; Thu, 12 Oct 2006 02:54:39 -0400 Received: from zeus.cs.utwente.nl (zeus.ewi.utwente.nl [130.89.10.12]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k9C6sYph025811 for ; Thu, 12 Oct 2006 08:54:34 +0200 (MEST) Received: from janus.ewi.utwente.nl (janus [130.89.10.26]) by zeus.cs.utwente.nl (8.12.10/8.12.10) with ESMTP id k9C6sXL0014438 for ; Thu, 12 Oct 2006 08:54:33 +0200 (MEST) Received: (from nobody@localhost) by janus.ewi.utwente.nl (8.11.7p1+Sun/8.10.2) id k9C6sYi19871; Thu, 12 Oct 2006 08:54:34 +0200 (MEST) Date: Thu, 12 Oct 2006 08:54:34 +0200 (MEST) X-Authentication-Warning: janus.ewi.utwente.nl: nobody set sender to karagian@cs.utwente.nl using -f To: nsis@ietf.org Subject: [NSIS] QSPEC-issue (GK-4) Received: from 84.82.109.231 (auth. user karagian@imap2.cs.utwente.nl) by webmail.cs.utwente.nl with HTTP; Thu, 12 Oct 2006 06:54:33 +0000 X-IlohaMail-Blah: karagian@ewi.utwente.nl X-IlohaMail-Method: mail() [mem] X-IlohaMail-Dummy: moo X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <001001c6ed25$0bda5a30$4c0d5982@dynamic.ewi.utwente.nl> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -4.532 () ALL_TRUSTED,AWL,BAYES_00,FVGT_s_OBFU_Q1,WEIRD_QUOTING X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Thu, 12 Oct 2006 08:54:35 +0200 (MEST) X-Spam-Score: 2.0 (++) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Description of issue Setting "R" and "Q" flags for during QSPEC Stacking & Tunneling Submitter name: Georgios Karagiannis Submitter email address: karagian@cs.utwente.nl Date first submitted: 12.10.2006 Reference: Comment type: T Priority: 'S' Section: 6.2 & 6.3.2 Rationale/Explanation of issue: In case of QSPEC tunneling & stacking there are situations where the parameter carried by an Initiator QSPEC is strictly interpreted by the edges of a local QOSM domain. The local QSPEC assoiated with this QOSM does not carry the parameter, but the local QOSM domain by using procedures specified in the QOSM can solve the preemption issue by using the parameter stored at the edges of the loal QOSM domain. It is not lear if in this case the ""R"" and "Q" flags carried by the parameter have to be set. In my opinion, in this case the R and Q fags should not be set. Requested change: Include in Section 6.2 the following paragraph. "In the situation that a parameter carried by an Initiator QSPEC is strictly interpreted by the edges of a local QOSM aware domain and the local QOSM defines how the preemption issue is solved within the local QOSM aware domain, then the "R" and "Q" flags carried by the parameter in the Initiator QSPEC SHOULD NOT be set, even if the parameter is not carried by the stacked local QSPEC, which is associated with the local QOSM." _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 12 03:03:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXuaf-0008Lo-GP; Thu, 12 Oct 2006 03:02:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXuaa-0008Lg-MC for nsis@ietf.org; Thu, 12 Oct 2006 03:02:44 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXuaZ-000346-7w for nsis@ietf.org; Thu, 12 Oct 2006 03:02:44 -0400 Received: from [192.168.2.155] (host81-137-225-30.in-addr.btopenworld.com [81.137.225.30]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 4F83C1BAC4D; Thu, 12 Oct 2006 09:02:42 +0200 (CEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <21F028D3-B3F5-4AD9-9523-00650A01F444@netlab.nec.de> Content-Transfer-Encoding: 7bit From: Martin Stiemerling Subject: Re: [NSIS] GIST over GIST-unaware NATs Date: Thu, 12 Oct 2006 09:02:39 +0200 To: X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: fu@cs.uni-goettingen.de, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org I'm in favour of having such document dealing with GIST-unaware NAT traversal. However, I haven't read the latest version of draft- pashalidis-nsis-gist-legacynats-00 by now (on my record for the next days). Martin Am 12.10.2006 um 05:14 schrieb : > Actually, I think this should be added as a WG document. > > Comments? > John > >> -----Original Message----- >> From: ext Xiaoming Fu [mailto:fu@cs.uni-goettingen.de] >> Sent: 11 October, 2006 22:49 >> To: nsis@ietf.org >> Subject: [NSIS] GIST over GIST-unaware NATs >> >> Hi all, >> >> There were some IESG discussions on GIST over GIST-unaware >> NATs. I read through draft-pashalidis-nsis-gist-legacynats-00 >> and found it makes a number of clarifications on this issue: >> >> - The presence of a GIST-unaware NAT can be detected by >> comparing headers of the GIST query-response procedure message >> in the two adjacent non-NAT GIST nodes. >> >> - Upon the detection of such a NAT (and affiliated rules), >> these two GIST nodes can then establish a UDP tunnel between >> them, and encapsulate the GIST messages (query-response-...) >> into the tunnel, and the outgoing tunnel endpoints decapsulate >> the messages into the desired format. >> >> - The draft also gives detailed description on GIST signaling >> and data traffic processing in both the case where a NAT is >> located close to the NI and the case where a NAT is close to >> the NR. The rationale looks fine to me. If there is an >> implementation demoing this, it would be even nicer. >> >> What do others think? >> Xiaoming >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis >> > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 12 03:16:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXunf-0007Pp-TW; Thu, 12 Oct 2006 03:16:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXunf-0007Pk-5Y for nsis@ietf.org; Thu, 12 Oct 2006 03:16:15 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXund-0004aO-OW for nsis@ietf.org; Thu, 12 Oct 2006 03:16:15 -0400 Received: from zeus.cs.utwente.nl (zeus.ewi.utwente.nl [130.89.10.12]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k9C7G961027800 for ; Thu, 12 Oct 2006 09:16:09 +0200 (MEST) Received: from janus.ewi.utwente.nl (janus [130.89.10.26]) by zeus.cs.utwente.nl (8.12.10/8.12.10) with ESMTP id k9C7G8L0017961 for ; Thu, 12 Oct 2006 09:16:08 +0200 (MEST) Received: (from nobody@localhost) by janus.ewi.utwente.nl (8.11.7p1+Sun/8.10.2) id k9C7G9O02585; Thu, 12 Oct 2006 09:16:09 +0200 (MEST) Date: Thu, 12 Oct 2006 09:16:09 +0200 (MEST) X-Authentication-Warning: janus.ewi.utwente.nl: nobody set sender to karagian@cs.utwente.nl using -f To: nsis@ietf.org Subject: [NSIS] QSPEC-issue (GK-5) Received: from 84.82.109.231 (auth. user karagian@imap2.cs.utwente.nl) by webmail.cs.utwente.nl with HTTP; Thu, 12 Oct 2006 07:16:08 +0000 X-IlohaMail-Blah: karagian@ewi.utwente.nl X-IlohaMail-Method: mail() [mem] X-IlohaMail-Dummy: moo X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -4.525 () ALL_TRUSTED,AWL,BAYES_00,FVGT_s_OBFU_Q1,WEIRD_QUOTING X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Thu, 12 Oct 2006 09:16:11 +0200 (MEST) X-Spam-Score: 2.0 (++) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Description of issue Unclear how "R" and "Q" are set during QSPEC Stacking & Tunneling Submitter name: Georgios Karagiannis Submitter email address: karagian@cs.utwente.nl Date first submitted: 12.10.2006 Reference: Comment type: T Priority: 'S' Section: 6.2 & 6.3.2 Rationale/Explanation of issue: This issue is somehow also related to QSPEC issue (GK-4). Section 6.3.2 is unclear on defining how the "R" flags and "Q" flags of QSPEC-1 parameters carried by the Initiator QSPEC are set during QSPEC Stacking & Tunneling. Section 6.2 includes some more information but it is still unclear. This is also related to QSPEC issue (GK-4), see below: In case of QSPEC tunneling & stacking there are situations where the parameter carried by an Initiator QSPEC is strictly interpreted by the edges of a local QOSM domain. The local QSPEC assoiated with this QOSM does not carry the parameter, but the local QOSM domain by using procedures specified in the QOSM can solve the preemption issue by using the parameter stored at the edges of the loal QOSM domain. It is not lear if in this case the ""R"" and "Q" flags carried by the parameter have to be set. In my opinion, in this case the R and Q fags should not be set. Requested change: Specify in Sections 6.2 and 6.3.2, in a more clear way, when and how the "R" and "Q" flags are set when QSPEC Stacking & Tunneling is used. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 12 04:04:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXvXe-0008DN-2E; Thu, 12 Oct 2006 04:03:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXvXd-0008DI-PF for nsis@ietf.org; Thu, 12 Oct 2006 04:03:45 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXvXb-0001ND-9A for nsis@ietf.org; Thu, 12 Oct 2006 04:03:45 -0400 Received: from zeus.cs.utwente.nl (zeus.ewi.utwente.nl [130.89.10.12]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k9C83d1G002292 for ; Thu, 12 Oct 2006 10:03:39 +0200 (MEST) Received: from janus.ewi.utwente.nl (janus [130.89.10.26]) by zeus.cs.utwente.nl (8.12.10/8.12.10) with ESMTP id k9C83cL0026746 for ; Thu, 12 Oct 2006 10:03:38 +0200 (MEST) Received: (from nobody@localhost) by janus.ewi.utwente.nl (8.11.7p1+Sun/8.10.2) id k9C83ZP25556; Thu, 12 Oct 2006 10:03:35 +0200 (MEST) Date: Thu, 12 Oct 2006 10:03:35 +0200 (MEST) X-Authentication-Warning: janus.ewi.utwente.nl: nobody set sender to karagian@cs.utwente.nl using -f To: nsis@ietf.org Subject: [NSIS] QSPEC-issue (GK-6) Received: from 84.82.109.231 (auth. user karagian@imap2.cs.utwente.nl) by webmail.cs.utwente.nl with HTTP; Thu, 12 Oct 2006 08:03:34 +0000 X-IlohaMail-Blah: karagian@ewi.utwente.nl X-IlohaMail-Method: mail() [mem] X-IlohaMail-Dummy: moo X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -5.519 () ALL_TRUSTED,AWL,BAYES_00,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Thu, 12 Oct 2006 10:03:40 +0200 (MEST) X-Spam-Score: 0.1 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Description of issue Possibilty for a QNI to include and send a QSPEC-1 parameter as an optional parameter, i.e., with "M" and "N" flags unset. Submitter name: Georgios Karagiannis Submitter email address: karagian@cs.utwente.nl Date first submitted: 12.10.2006 Reference: Comment type: T Priority: 'S' Section: Various Rationale/Explanation of issue: Currently is specified that QSPEC-1 parameters are always initiated by QNI as being mandatory parameters. In some situations this might not be efficient and useful enough. Suppose that a QNI can provide a remapping between QSPEC-1 parameter, say Token Bucket to another QSPEC-1 parameter, say Bandwidth. Then the QNI can for example include the Tocken Bucket parameter as QSPEC-1 parameter and in addition it can inlcude the Bandwidth parameter as QSPEC-2 parameter, the M flag is set to 0 and the N flag is not yet set. The on path QNEs could then, if possible use the Token Bucket parameter, but if not then it can use the available Bandwidth parameter and set the "R" and "Q" flags associated with the Tocken Bucket parameter. In this way the remapping is actually done by the QNI, which is a cleaner way to solve the remapping problem. However, if a QOSM defines to remap the Token Bucket to another parameter, then the N flag in the available Bandwidth parameter is set and also the "R" and "Q" flags associated with the Tocken Bucket parameter are set. In this way the QNI will have more information on how the remapping of the parameter took place. If the N flag in the Bandwidth is not set and the "R" and "Q" flags associated with the Tocken Bucket parameter are set then the QNI knows that the remapping of the Tocken Bucket parameter has been done by using the available Bandwidth value provided by QNI. The QNI could then be more certain about what kind of Token Bucket remapping took place. Requested change: This issue is related to various sections: * Specify that QNI is allowed to use the "N" flag and to set the "M" flag to "0" for QSPEC-1 parameters. * A QNI may remap an initial QSPEC-1 parameter to another QSPEC-1 parameter, say remapped QSPEC-1 parameter. The remapped QSPEC-1 parameter carries the "M" flag set to "0" and the "N" flag is unset. Both QSPEC-1 parameters may be included in the QSPEC. However, the remapped QSPEC-1 parameter is included only when the initial QSPEC-1 parameter is available. * A QNE that receives the QSPEC uses, if possible, the initial QSPEC-1 parameter, otherwise it can use the remapped QSPEC-1 parameter and set the "R" and "Q" flags associated with the initial QSPEC-1 parameter. In this way the remapping is actually done by the QNI. However, if a QOSM defines to remap the initial QSPEC-1 parameter to another parameter, then the "N" flag in the remapped QSPEC-1 parameter is set. Furthermore, also the "R" and "Q" flags associated with the initial QSPEC-1 parameter are set. In this way the QNI will receive more information on how the remapping of the initial QSPEC-1 parameter took place. If the "N" flag in the remapped QSPEC-1 parameter is not set and the "R" and "Q" flags associated with the initial QSPEC-1 parameter are set then the QNI knows that the remapping of the initial QSPEC-1 parameter has been done by using the remapped QSPEC-1 parameter value provided by QNI. The QNI is then more certain about the way of how the initial QSPEC-1 parameter is remapped. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 12 04:43:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXw96-00057F-VF; Thu, 12 Oct 2006 04:42:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXw95-000568-JN for nsis@ietf.org; Thu, 12 Oct 2006 04:42:27 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXw93-0002AF-61 for nsis@ietf.org; Thu, 12 Oct 2006 04:42:27 -0400 Received: from zeus.cs.utwente.nl (zeus.ewi.utwente.nl [130.89.10.12]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k9C8gJsO005722 for ; Thu, 12 Oct 2006 10:42:19 +0200 (MEST) Received: from janus.ewi.utwente.nl (janus [130.89.10.26]) by zeus.cs.utwente.nl (8.12.10/8.12.10) with ESMTP id k9C8gIL0003073 for ; Thu, 12 Oct 2006 10:42:18 +0200 (MEST) Received: (from nobody@localhost) by janus.ewi.utwente.nl (8.11.7p1+Sun/8.10.2) id k9C8gFP17397; Thu, 12 Oct 2006 10:42:15 +0200 (MEST) Date: Thu, 12 Oct 2006 10:42:15 +0200 (MEST) X-Authentication-Warning: janus.ewi.utwente.nl: nobody set sender to karagian@cs.utwente.nl using -f To: nsis@ietf.org Subject: [NSIS] QSPEC-issue (GK-7) Received: from 84.82.109.231 (auth. user karagian@imap2.cs.utwente.nl) by webmail.cs.utwente.nl with HTTP; Thu, 12 Oct 2006 08:42:14 +0000 X-IlohaMail-Blah: karagian@ewi.utwente.nl X-IlohaMail-Method: mail() [mem] X-IlohaMail-Dummy: moo X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: <2xXdNmoT.1160642534.4287290.karagian@ewi.utwente.nl> In-Reply-To: From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -5.517 () ALL_TRUSTED,AWL,BAYES_00,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Thu, 12 Oct 2006 10:42:22 +0200 (MEST) X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Description of issue Allow to set preemption priority to normal priority when preemption parameter is illegal Submitter name: Georgios Karagiannis Submitter email address: karagian@cs.utwente.nl Date first submitted: 12.10.2006 Reference: Comment type: T Priority: 'S' Section: 6.1 Rationale/Explanation of issue: In last paragraph of Section 6.1 is emphasized that: "In some casee a ONE may need to reject a reservation because of possible inompatibilities among QSPEC parameters. One example is that some parameters may be illegal (e.g., preemption in the U.S. PSTN). In such a case a QNE must reject a reservation where preemption cannot be accomodated." Why should the QNE always reject the reservations in these cases. I think that this should be decided by the QOSM specifications. Requested change: Please change the last paragraph in Section 6.1: FROM: "In some casee a ONE may need to reject a reservation because of possible inompatibilities among QSPEC parameters. One example is that some parameters may be illegal (e.g., preemption in the U.S. PSTN). In such a case a QNE must reject a reservation where preemption cannot be accomodated." INTO: "In some cases a ONE may need to reject or remap a reservation request because of possible incompatibilities among QSPEC parameters. One example is that some parameters may be illegal (e.g., preemption in the U.S. PSTN). In such a case a QNE must either reject the reservation request or consider that the reservation request does not carry a preemption priority parameter, i.e., remap to normal priority, when the requested preemption priority cannot be accomodated. This procedure must be specified by the QOSM specification." _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 12 05:24:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXwmf-00037x-Ky; Thu, 12 Oct 2006 05:23:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXwme-00037n-JK for nsis@ietf.org; Thu, 12 Oct 2006 05:23:20 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXwmb-0000TI-52 for nsis@ietf.org; Thu, 12 Oct 2006 05:23:20 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k9C9N7EV015160 for ; Thu, 12 Oct 2006 10:23:07 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Oct 2006 10:23:07 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: GIST issue on MA-Hold-Time Thread-Index: AcbtIq8CwOsksXEMQf+G26OClNeRIQADRGlg From: "Hancock, Robert" To: "nsis" X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Subject: [NSIS] GIST issue on MA-Hold-Time X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, An issue has been raised on MA-Hold-Time negotiation. It is in=20 the tracker as issue #131 (http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue131) and the summary text is included below. =20 This is a solicitation for input, especially from the implementors, on this matter. In the absence of input, my=20 preference would be to leave to spec unchanged, but if people=20 feel that this level of flexibility is necessary please speak up and say so. It would be very good to see change/no change=20 comments either way. cheers, robert h. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [Following Routing Area Directorate comments from Adrian Farrel] At the moment, the MA-Hold-Time in a proposal applies to all possible configurations of the messaging association. There is no way to indicate that (for example) one would prefer 30 seconds for TCP, but 120 seconds for TLS/SCTP. In principle, different hold time possibilities could be indicated in the Query, but this would require some changes in the Stack-Proposal or Stack-Configuration-Data objects. The SCD syntax does not allow one to specify a value which applies to a whole proposal, only to a MA-protocol in a proposal; the SP syntax does not allow one to specify MA-Hold-Time at all. One option would be to tag the MA-Hold-Time value in the SCD so that there was a single value (tagged 0) possibly overridden by alternative values for particular proposals (rather like we do for the other protocol options). The SCD would get another count field in the header, and we could steal a byte from the MA-Hold-Time field for the tag. However, it is not clear whether the value of this sophistication outweighs the cost. The policy for choosing an MA-Hold-Time presumably is a tradeoff between 3 variables: a) the extent to which an MA is being used or is going to be used b) the cost of keeping the MA open (in stored protocol state inside the protocols that make up the MA itself) c) the cost of re-setting up the MA if it is needed again Of these, (a) is totally independent of the protocol configuration, (b) is weakly dependent on it, and (c) is definitely dependent on it. But the strength of the dependence is not that great. If you just chose the largest hold-time value for all possible MA configurations and used that as the single value in the negotiation, the net affect would not be much different from what could be achieved with a more granular mechanism. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 12 05:36:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXwyP-0000pa-Pp; Thu, 12 Oct 2006 05:35:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXwyO-0000of-Jj for nsis@ietf.org; Thu, 12 Oct 2006 05:35:28 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXwyN-0002aU-3I for nsis@ietf.org; Thu, 12 Oct 2006 05:35:28 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k9C9Wi8d017510; Thu, 12 Oct 2006 10:32:44 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] GIST over GIST-unaware NATs Date: Thu, 12 Oct 2006 10:32:44 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] GIST over GIST-unaware NATs Thread-Index: AcbtzINuofKr9XHaT36po+kF3ZZMtAAFDl8Q From: "Hancock, Robert" To: "Martin Stiemerling" , X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: fu@cs.uni-goettingen.de, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi, just a note to the effect that I was planning to cover point (1) below (detection of the unaware NAT by header analysis) in the GIST spec in section 7.2 (see email discussions at http://www1.ietf.org/mail-archive/web/nsis/current/msg06710.html) and include an informative reference to andreas' draft. r. > -----Original Message----- > From: Martin Stiemerling [mailto:stiemerling@netlab.nec.de]=20 > Sent: 12 October 2006 08:03 > To: > Cc: fu@cs.uni-goettingen.de; nsis@ietf.org > Subject: Re: [NSIS] GIST over GIST-unaware NATs >=20 >=20 > I'm in favour of having such document dealing with GIST-unaware NAT =20 > traversal. However, I haven't read the latest version of draft-=20 > pashalidis-nsis-gist-legacynats-00 by now (on my record for the next =20 > days). >=20 > Martin >=20 > Am 12.10.2006 um 05:14 schrieb =20 > : >=20 > > Actually, I think this should be added as a WG document. > > > > Comments? > > John > > > >> -----Original Message----- > >> From: ext Xiaoming Fu [mailto:fu@cs.uni-goettingen.de] > >> Sent: 11 October, 2006 22:49 > >> To: nsis@ietf.org > >> Subject: [NSIS] GIST over GIST-unaware NATs > >> > >> Hi all, > >> > >> There were some IESG discussions on GIST over GIST-unaware=20 > NATs. I=20 > >> read through draft-pashalidis-nsis-gist-legacynats-00 > >> and found it makes a number of clarifications on this issue: > >> > >> - The presence of a GIST-unaware NAT can be detected by comparing=20 > >> headers of the GIST query-response procedure message in the two=20 > >> adjacent non-NAT GIST nodes. > >> > >> - Upon the detection of such a NAT (and affiliated rules),=20 > these two=20 > >> GIST nodes can then establish a UDP tunnel between them, and=20 > >> encapsulate the GIST messages (query-response-...) into=20 > the tunnel,=20 > >> and the outgoing tunnel endpoints decapsulate the messages=20 > into the=20 > >> desired format. > >> > >> - The draft also gives detailed description on GIST signaling and=20 > >> data traffic processing in both the case where a NAT is=20 > located close=20 > >> to the NI and the case where a NAT is close to the NR. The=20 > rationale=20 > >> looks fine to me. If there is an implementation demoing this, it=20 > >> would be even nicer. > >> > >> What do others think? > >> Xiaoming > >> > >> _______________________________________________ > >> nsis mailing list > >> nsis@ietf.org > >> https://www1.ietf.org/mailman/listinfo/nsis > >> > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 12 06:27:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXxlq-0003cb-1m; Thu, 12 Oct 2006 06:26:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXxlp-0003c5-7v for nsis@ietf.org; Thu, 12 Oct 2006 06:26:33 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXxlm-0001bD-Pg for nsis@ietf.org; Thu, 12 Oct 2006 06:26:33 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k9CAQApA030490 for ; Thu, 12 Oct 2006 11:26:10 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Oct 2006 11:26:10 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: GIST issue on forwarders introducing errors Thread-Index: AcbtIq8CwOsksXEMQf+G26OClNeRIQADRGlgAC4gYRA= From: "Hancock, Robert" To: "nsis" X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Subject: [NSIS] GIST issue on forwarders introducing errors X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, An issue has been raised on GIST nodes that process and forward messages introducing errors, and how to diagnose such errors.=20 It is in the tracker as issue #132 (http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue132) and the summary text=20 is included below. =20 This is a solicitation for input, especially from the=20 implementors, on this matter. In the absence of input, my=20 preference would be to leave the current protocol unchanged, but put stronger guidance in about it - this is essentially (a) below, pointing to (c) or (d) as possible future extensions. Or, we could extend the current specification along the lines of (b) or (c'). Please provide your preferences! cheers, robert h. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [Following Routing Area Directorate comments from Adrian Farrel] The GIST specification allows nodes to forward messages, either after consultation with the NSLP (section 4.3.2) or if there is no local NSLP (4.3.4). However, the forwarding process does not change the IP header or included Network-Layer-Information object. This means that any errors introduced by the forwarding node will get reported back to the node that first originated the message; this will get confused because it is being told about error conditions which it was not responsible for. There are several possible approaches for dealing with this: a) note more strongly in the text that the forwarder is supposed not to change any of the GIST payloads, so it should not introduce any errors. Disadvantage of this: we have to trust implementations which do forwarding to be correctly written so that they do not introduce message changes in the process. b) allow or force the forwarding node to introduce a new object to indicate that it has processed the message in some non-trivial way (effectively introducing route recording). Probably one would still want to report errors to the originator, but the error reporter would also include the recorded route to make diagnostics easier. Disadvantage of this approach: it makes the implementation of forwarding more complex, and in particular rules out implementations which do simple in-place modifications of the message (the goal for RMD for example). c) allow the originating node to include an object which records the route taken through any forwarding nodes. this object would be of extensibility class AB=3D10 (forward unchanged) or possibly AB=3D00 = (reject if unknown). Typically, the originating node would only include such an object for diagnostic purposes (to avoid putting additional processing load on the forwarders). c') same as (c), but define the object as part of the base specification (so all nodes would support it from the start). d) depend on a future GIST traceroute capability (e.g. the NSIS ping approach) to discover such forwarding nodes and find out what they are doing. So, the diagnostics would not be built into the base protocol, but would be available as an extension to support investigations if message mangling by forwarders turns out to be a problem. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 12 09:25:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY0YI-0006Bg-1c; Thu, 12 Oct 2006 09:24:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY0YG-0006Bb-Pw for nsis@ietf.org; Thu, 12 Oct 2006 09:24:44 -0400 Received: from [2001:610:1908:1000:204:23ff:feb7:ef56] (helo=smtp.utwente.nl) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY0YC-00058h-U3 for nsis@ietf.org; Thu, 12 Oct 2006 09:24:44 -0400 Received: from tsort.student.utwente.nl (tsort.student.utwente.nl [130.89.166.82]) by smtp.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id k9CDOCZS030489 for ; Thu, 12 Oct 2006 15:24:14 +0200 Date: Thu, 12 Oct 2006 15:24:11 +0200 From: Ruud Klaver X-Mailer: The Bat! (v1.52) Organization: Universiteit Twente X-Priority: 3 (Normal) Message-ID: <1157935453.20061012152411@student.utwente.nl> To: "nsis" Subject: Re: [NSIS] GIST issue on Error Message Formatting In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact helpdesk@ITBE.utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: r.klaver@student.utwente.nl X-Spam-Status: No X-Spam-Score: -2.8 (--) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ruud Klaver List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert, Wednesday, October 11, 2006, 12:47:29, you wrote: > Hi all, > An issue has been raised on error message formatting. It is in the > tracker as issue #130 > (http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue130), > and the summary text is included below. > This is a solicitation for input, especially from the implementors, on > this matter. In the absence of input, my preference would be to leave to > spec unchanged, but if people feel (even not particularly strongly) that > a more structured syntax would be preferable it is not that much effort > to change. It would be very good to see change/no change comments either > way. > cheers, > robert h. Comments inline below. > ======================================================================== > === > The current error message formats are essentially fixed and predefined > for each > error code; that is: > - if you know the error code, you know precisely what should be in the > message > and you can parse it completely. Someone generating the error has no > freedom > about what information to include (cannot include other Additional Info > fields, > for example). If you are suggesting that the error generating node should be free in what information to include, I think it is a good idea to have the specification at least dictate what information SHOULD be included. The infos mandated right now make sense for the errors they are included with. The current situation however is that certain information MUST be included, because not including it would make full message parsing impossible. > - if you don't know the error code (typically because it is a new > error), you > cannot parse anything about it beyond the MRI - you cannot parse any > additional > info field or the debugging comment. Except for the case where the number of info fields is 0. > It's been suggested that it would be possible to make the additional > info fields > some kind of object in their own right, in which case there would be > some kind > of TLV format for them, and probably a registry for their type codes. > The advantage of this is that every message can always be parsed. > (However, > without knowing the semantics of the error code, it still may be hard to > do > anything useful with the information.) If a node does get an error code that it does not know about, the best thing it can hope for is printing all received infos and the debugging comment to a log somewhere for human inspection. The hope in this case of course is that the error generating node is smart enough to realize that it is using an error code that may be unknown and provides a descriptive debug message just in case. Because of the situation you are describing exactly this would be impossible at the moment, as the knowledge of the infos included is directly coupled to the knowledge of the existence of the error message. For this reason I think that giving the infos some sort of TLV header would be a good idea. If we look at existing error messages, I think that your proposal increases flexibility, as in the case of the SHOULD/MUST comment above. If an error generating node for some reason decides to include more/less/other info than that which is dictated, this is not an error condition anymore. And if there's one thing you want to avoid it's errors causing errors... > The disadvantage is that there is a minor change in protocol > specification > complexity. > It isn't clear what the impact is on implementation complexity. The > error > message parser might be a little more complex but would be more future > proof and > with less special cases. > ======================================================================== > == Quite a bit of my error message parsing code right now is dedicated to strict checking of the infos based on the value of the error code and subcode. In case of a more flexible TLV solution this would no longer be needed. It will however need to be replaced with something to parse the TLV. In my particular case, because of the code structure, I woudld say that the complexity of the proposal would be roughly equal to what I have now. As for future proofness, the complexity of adding new error codes that should contain infos will indeed be decreased. In conclusion, to me it sounds like a good idea, provided that the specification dictates which infos SHOULD be included with each error message. One last comment, I've hard more problems with the QoS-NSLP Info objects than with GIST. None are dictated and there is no way to glean which info object is included except for object length. It would be a good idea to have something similar for QoS-NSLP error messages. -- Best regards, Ruud mailto:r.klaver@student.utwente.nl _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 12 09:32:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY0fH-0004Jg-Lc; Thu, 12 Oct 2006 09:31:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY0fG-0004Jb-3U for nsis@ietf.org; Thu, 12 Oct 2006 09:31:58 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY0fD-0006Fq-Lx for nsis@ietf.org; Thu, 12 Oct 2006 09:31:58 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k9CDTcqr002400; Thu, 12 Oct 2006 15:29:42 +0200 (MEST) From: "Georgios Karagiannis" To: , , Subject: RE: [NSIS] GIST over GIST-unaware NATs Date: Thu, 12 Oct 2006 15:29:35 +0200 Message-ID: <001001c6ee02$79136fa0$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: Acbtbo0ImRPyODS+T/i5w1PvhD9vVgAPeu9QABVp33A= X-Spam-Score: -5.636 () ALL_TRUSTED,AWL,BAYES_00,FVGT_s_MIXCASEWORDS X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Thu, 12 Oct 2006 15:29:46 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi I agree with John on this! It is important to provide (next steps) solutions on this and therefore it is good to have it as a WG document. Best regards, Georgios > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: donderdag 12 oktober 2006 5:15 > To: fu@cs.uni-goettingen.de; nsis@ietf.org > Subject: RE: [NSIS] GIST over GIST-unaware NATs > > Actually, I think this should be added as a WG document. > > Comments? > John > > >-----Original Message----- > >From: ext Xiaoming Fu [mailto:fu@cs.uni-goettingen.de] > >Sent: 11 October, 2006 22:49 > >To: nsis@ietf.org > >Subject: [NSIS] GIST over GIST-unaware NATs > > > >Hi all, > > > >There were some IESG discussions on GIST over GIST-unaware NATs. I > >read through draft-pashalidis-nsis-gist-legacynats-00 > >and found it makes a number of clarifications on this issue: > > > >- The presence of a GIST-unaware NAT can be detected by comparing > >headers of the GIST query-response procedure message in the two > >adjacent non-NAT GIST nodes. > > > >- Upon the detection of such a NAT (and affiliated rules), these two > >GIST nodes can then establish a UDP tunnel between them, and > >encapsulate the GIST messages (query-response-...) into the > tunnel, and > >the outgoing tunnel endpoints decapsulate the messages into > the desired > >format. > > > >- The draft also gives detailed description on GIST > signaling and data > >traffic processing in both the case where a NAT is located > close to the > >NI and the case where a NAT is close to the NR. The rationale looks > >fine to me. If there is an implementation demoing this, it would be > >even nicer. > > > >What do others think? > >Xiaoming > > > >_______________________________________________ > >nsis mailing list > >nsis@ietf.org > >https://www1.ietf.org/mailman/listinfo/nsis > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 12 09:53:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY0zb-0007Z9-CN; Thu, 12 Oct 2006 09:52:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY0za-0007Z4-FU for nsis@ietf.org; Thu, 12 Oct 2006 09:52:58 -0400 Received: from [2001:610:1908:1000:204:23ff:feb7:ef56] (helo=smtp.utwente.nl) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY0zZ-0000lB-0g for nsis@ietf.org; Thu, 12 Oct 2006 09:52:58 -0400 Received: from tsort.student.utwente.nl (tsort.student.utwente.nl [130.89.166.82]) by smtp.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id k9CDqpZS003189 for ; Thu, 12 Oct 2006 15:52:51 +0200 Date: Thu, 12 Oct 2006 15:52:52 +0200 From: Ruud Klaver X-Mailer: The Bat! (v1.52) Organization: Universiteit Twente X-Priority: 3 (Normal) Message-ID: <859655937.20061012155252@student.utwente.nl> To: nsis@ietf.org Subject: Re: [NSIS] GIST issue on forwarders introducing errors In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact helpdesk@ITBE.utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: r.klaver@student.utwente.nl X-Spam-Status: No X-Spam-Score: -2.8 (--) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ruud Klaver List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert, Thursday, October 12, 2006, 12:26:10, you wrote: > Hi all, > An issue has been raised on GIST nodes that process and forward > messages introducing errors, and how to diagnose such errors. > It is in the tracker as issue #132 > (http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue132) > and the summary text > is included below. > This is a solicitation for input, especially from the > implementors, on this matter. In the absence of input, my > preference would be to leave the current protocol unchanged, > but put stronger guidance in about it - this is essentially > (a) below, pointing to (c) or (d) as possible future extensions. > Or, we could extend the current specification along the lines of > (b) or (c'). Please provide your preferences! > cheers, > robert h. > ============================================================== > [Following Routing Area Directorate comments from Adrian Farrel] > The GIST specification allows nodes to forward messages, either after > consultation with the NSLP (section 4.3.2) or if there is no local NSLP > (4.3.4). However, the forwarding process does not change the IP header > or > included Network-Layer-Information object. This means that any errors > introduced by the forwarding node will get reported back to the node > that first originated the message; this will get confused because it is > being told about error conditions which it was not responsible for. > There are several possible approaches for dealing with this: > a) note more strongly in the text that the forwarder is supposed not to > change > any of the GIST payloads, so it should not introduce any errors. > Disadvantage of this: we have to trust implementations which do > forwarding to be correctly > written so that they do not introduce message changes in the process. I would think it to be quite obvious from the text right now that only the NSLP payload can be changed when forwarding messages, at least that's the only thing my implementation allows right now. Could you give a practical example of a node changing part of the GIST payload of forwarded message? Is there any non-malicious point to this? -- Best regards, Ruud Klaver mailto:r.klaver@student.utwente.nl _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 12 10:06:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY1Br-0005yO-UP; Thu, 12 Oct 2006 10:05:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY1Bq-0005vd-L4 for nsis@ietf.org; Thu, 12 Oct 2006 10:05:38 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY1Bo-0002UQ-Gh for nsis@ietf.org; Thu, 12 Oct 2006 10:05:38 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k9CE5Suv015461; Thu, 12 Oct 2006 15:05:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] GIST issue on forwarders introducing errors Date: Thu, 12 Oct 2006 15:05:28 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] GIST issue on forwarders introducing errors Thread-Index: AcbuBdtkNOu6bOBDQNS8X/yO2TUgcwAAUPHQ From: "Hancock, Robert" To: "Ruud Klaver" , X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Ruud, to be clear (it may be clearer from the full text in the issue=20 tracker), the point we are talking about here is how to handle the case of implementation errors in the forwarding node. A correctly implemented forwarder would never cause this problem. However (as Adrian pointed out), a correctly implemented=20 originating node would never generate erroneous messages either, but we still have the error messages to report about them when they do. So, the question is, can we make ourselves sufficiently confident that this (forwarders mangling messages) is a class=20 of implementation error that we do not have to deal with. hope this helps, r. > -----Original Message----- > From: Ruud Klaver [mailto:r.klaver@student.utwente.nl]=20 > Sent: 12 October 2006 14:53 > To: nsis@ietf.org > Subject: Re: [NSIS] GIST issue on forwarders introducing errors >=20 >=20 > Hi Robert, >=20 > Thursday, October 12, 2006, 12:26:10, you wrote: >=20 > > Hi all, >=20 > > An issue has been raised on GIST nodes that process and forward=20 > > messages introducing errors, and how to diagnose such=20 > errors. It is in=20 > > the tracker as issue #132 > >=20 > (http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue132) > > and the summary text > > is included below. > =20 > > This is a solicitation for input, especially from the > > implementors, on this matter. In the absence of input, my=20 > > preference would be to leave the current protocol unchanged, > > but put stronger guidance in about it - this is essentially > > (a) below, pointing to (c) or (d) as possible future extensions. > > Or, we could extend the current specification along the lines of > > (b) or (c'). Please provide your preferences! >=20 > > cheers, >=20 > > robert h. >=20 > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > [Following Routing Area Directorate comments from Adrian Farrel] >=20 > > The GIST specification allows nodes to forward messages,=20 > either after=20 > > consultation with the NSLP (section 4.3.2) or if there is no local=20 > > NSLP (4.3.4). However, the forwarding process does not=20 > change the IP=20 > > header or included Network-Layer-Information object. This=20 > means that=20 > > any errors introduced by the forwarding node will get=20 > reported back to=20 > > the node that first originated the message; this will get confused=20 > > because it is being told about error conditions which it was not=20 > > responsible for. >=20 > > There are several possible approaches for dealing with this: >=20 > > a) note more strongly in the text that the forwarder is=20 > supposed not=20 > > to change any of the GIST payloads, so it should not introduce any=20 > > errors. Disadvantage of this: we have to trust=20 > implementations which=20 > > do forwarding to be correctly > > written so that they do not introduce message changes in=20 > the process. >=20 > I would think it to be quite obvious from the text right now=20 > that only the NSLP payload can be changed when forwarding=20 > messages, at least that's the only thing my implementation=20 > allows right now. >=20 > Could you give a practical example of a node changing part of=20 > the GIST payload of forwarded message? Is there any=20 > non-malicious point to this? >=20 > --=20 > Best regards, > Ruud Klaver mailto:r.klaver@student.utwente.nl >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 12 12:16:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY3Dn-00051P-FV; Thu, 12 Oct 2006 12:15:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY3Dm-00051J-Fq for nsis@ietf.org; Thu, 12 Oct 2006 12:15:46 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY3Dk-00074t-1T for nsis@ietf.org; Thu, 12 Oct 2006 12:15:46 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k9CGF4Ps017225; Thu, 12 Oct 2006 18:15:08 +0200 (MEST) From: "Georgios Karagiannis" To: "'Xiaoming Fu'" , Subject: RE: [NSIS] QSPEC example 1 Date: Thu, 12 Oct 2006 18:15:01 +0200 Message-ID: <003401c6ee19$95291b10$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <452D3D4A.7000806@cs.uni-goettingen.de> x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcbtZnkNTtlBdXq9T9qw64/jPjxoCgAsuSEg X-Spam-Score: -5.535 () ALL_TRUSTED,AWL,BAYES_00,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Thu, 12 Oct 2006 18:15:10 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Xiaoming I support your following conclusion/proposal! > one more general approach > maybe to let QSPEC-1 only limit to bandwidth/token bucket.... > Is this a too stupid/radical/simple conclusion? Best Regards, Georgios > > -----Original Message----- > From: Xiaoming Fu [mailto:fu@cs.uni-goettingen.de] > Sent: woensdag 11 oktober 2006 20:52 > To: nsis@ietf.org > Subject: [NSIS] QSPEC example 1 > > Hi all, > > Let's try to consider what about a virtual network scenario > that consists of the following nodes: > > QNI-a: supports QoSM-a, which uses QSPEC-a (composed of > QSPEC-1 parameters P11 and P12, and QSPEC-2 parameter P21 and P22). > QNE-b: supports QoSM-b, which uses QSPEC-b (composed of > QSPEC-1 parameters P12 and P13, and QSPEC-2 parameters P21 and P23). > QNE-c: supports QoSM-c, which uses QSPEC-c (composed of > QSPEC-1 parameter P14 and QSPEC-2 parameter P24). > QNR-d: supports QoSM-b. > > First, for simplicity, let's assume the reservation is made > via a sender-initiated way; no QSPEC > remapping/tunneling/stacking is used in all nodes; QSPEC-2 > parameters will be ignored in a non-aware node; and the e2e > resource is enough for this reservation (i.e., admission > control succeeds). Note interpreting a QSPEC parameter does > not imply the parameter will be forwarded onto a next node. > What will happen? > > 1) Certainly QNI-a will initialize with a Resv message > carrying all its support QSPEC parameters (P11, P12; P21, P22). > 2) Upon receipt of this message, QNE-b will interpret P11 > (likely approximate), P12, and P21, and ignore P22. Then it > will forward the Resv containing QSPEC (P11, P12, P21). > 3) Upon receipt of this message, QNE-c will interpret P11 and > P12 (both likely approximate) and ignore P21. Then it will > forward the Resv containing QSPEC (P11, P12) > 4) Upon receipt of this message, QNR-c will interpret P11 and > P12 (likely approximate). Then it will issue a Response > towards the QNI, containing QSPEC (P11, P12, or???!). > > This implies to me that either a tunneling/stacking should be > used, or a remapping of all possible QSPEC-1s to a more > generic, small set of > QSPEC-1 parameters for all QOSMs may be provided. However, > reading through currently documented QoSMs, only Token Bucket > (CL/Y1541/draft-jeong-nsis-3gpp-qosm) or bandwidth (RMD) is > common for all. As tunneling/stacking may be too strong for > many QoSMs for deployment issues, one more general approach > maybe to let QSPEC-1 only limit to bandwidth/token bucket.... > Is this a too stupid/radical/simple conclusion? > Xiaoming > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Oct 13 07:53:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYLab-0000hp-KV; Fri, 13 Oct 2006 07:52:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYLaZ-0000fp-Tn for nsis@ietf.org; Fri, 13 Oct 2006 07:52:31 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYLaS-0000RN-Ff for nsis@ietf.org; Fri, 13 Oct 2006 07:52:31 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E88441C5 for ; Fri, 13 Oct 2006 13:52:23 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Oct 2006 13:52:23 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Oct 2006 13:52:23 +0200 Message-ID: <452F7DF7.8020709@ericsson.com> Date: Fri, 13 Oct 2006 13:52:23 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: NSIS Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Oct 2006 11:52:23.0131 (UTC) FILETIME=[0B8832B0:01C6EEBE] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [NSIS] Announcement: New WG chair X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org I hereby announce that I have selected Martin Stiemerling (stiemerling@netlab.nec.de) as the second co-chair to help John run the WG. Congratulations and good luck in your efforts to help the WG. I would also like to thank all the other volunteers. Best Regards Magnus Westerlund TSV AD _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 16 06:02:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZPHw-0001Zy-Si; Mon, 16 Oct 2006 06:01:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZPHv-0001UT-3K for nsis@ietf.org; Mon, 16 Oct 2006 06:01:39 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZP8K-0006W8-FX for nsis@ietf.org; Mon, 16 Oct 2006 05:51:52 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B26114F0002; Mon, 16 Oct 2006 11:51:37 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Oct 2006 11:51:37 +0200 Received: from ericsson.com ([147.214.26.58]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Oct 2006 11:51:36 +0200 Message-ID: <45335629.1030301@ericsson.com> Date: Mon, 16 Oct 2006 11:51:37 +0200 From: Lars Westberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Ash, Gerald R \(Jerry\), ALABS" , nsis@ietf.org Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt References: <9473683187ADC049A855ED2DA739ABCA0DDC7E1F@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC7E1F@KCCLUST06EVS1.ugd.att.com> X-OriginalArrivalTime: 16 Oct 2006 09:51:36.0790 (UTC) FILETIME=[AB9D8F60:01C6F108] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1513795431==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============1513795431== Content-Type: multipart/alternative; boundary="------------010400060904060506090406" This is a multi-part message in MIME format. --------------010400060904060506090406 Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Hi, The template seems not to be a template because the mandatory part is more or less the same as Intserv. The main idea with QoS-template was to make an modular solution that could allow flexibillity for different Qos-models Therefore, I do not understand the scope of the specification. I suggest that we move the major part of the parameters to a separate "Int.serv. over NSIS" specification. Int.serv. can be seen as a common bearer service. regards Lasse Ash, Gerald R (Jerry), ALABS wrote: > Lars, > > > You mention in the below e-mail that there are no open issues, > > while there is a huge discussion on the nsis mailing list > > regarding the QSPEC-1 parameters. > > John can call a different consensus if he sees one (I've asked him a > couple of times to do that). What I saw was > > 1. Many posts supported the QSPEC-1 concept, only one (or maybe two) I > saw opposed. The opposing view was repeated *many* times (and is still > being repeated) but it only counts as one opinion. > 2. Many posts supported retaining the 4 QSPEC-1 parameters, only one I > saw opposed. The opposing view was repeated many times. > 3. There was only one opinion expressed to be able to ignore QSPEC-1 > parameters. That one opinion has been repeated many times but it only > counts as one opinion. > > John asked a while ago for new opinions on these issues, that would be > good if there are any *new* opinions. We don't need to hear opinions > repeated that we've seen so many times. > > I invite John once again to make a consensus call so we can move on > here. I think it is time to make progress and stop repeating ourselves, > we're not generating any new light in this rather endless discussion. > > Thanks, > Jerry > --------------010400060904060506090406 Content-Type: text/html; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Hi,
=A0The template seems not to be a template because the mandatory part=A0 = is more or less the same as Intserv.
The main idea with QoS-template was to make an modular solution that could allow flexibillity for different Qos-models

Therefore, I do not understand the scope of the specification.

I suggest that we move the major part of the parameters to a separate "Int.serv. over NSIS" specification.
Int.serv. can be seen as a common bearer service.

regards Lasse

Ash, Gerald R (Jerry), ALABS wrote:
RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

Lars,

> You mention in the below e-mail that there are no open issues,
> while there is a huge discussion on the nsis mailing list
> regarding the QSPEC-1 parameters.

John can call a different consensus if he sees one (I've asked him a
couple of times to do that).=A0 What I saw was

1. Many posts supported the QSPEC-1 concept, only one (or maybe two) I saw opposed.=A0 The opposing view was repeated *many* times (and is still=
being repeated) but it only counts as one opinion.
2. Many posts supported retaining the 4 QSPEC-1 parameters, only one I saw opposed.=A0 The opposing view was repeated many times.
3. There was only one opinion expressed to be able to ignore QSPEC-1
parameters.=A0 That one opinion has been repeated many times but it only<= br> counts as one opinion.

John asked a while ago for new opinions on these issues, that would be good if there are any *new* opinions.=A0 We don't need to hear opinions repeated that we've seen so many times.

I invite John once again to make a consensus call so we can move on
here.=A0 I think it is time to make progress and stop repeating ourselves= ,
we're not generating any new light in this rather endless discussion.

Thanks,
Jerry

--------------010400060904060506090406-- --===============1513795431== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============1513795431==-- From nsis-bounces@ietf.org Mon Oct 16 09:15:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZSIi-0008S3-Cx; Mon, 16 Oct 2006 09:14:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZSIg-0008Rx-P4 for nsis@ietf.org; Mon, 16 Oct 2006 09:14:38 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZSIV-000237-BJ for nsis@ietf.org; Mon, 16 Oct 2006 09:14:38 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 56D7D4F0003; Mon, 16 Oct 2006 15:12:50 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Oct 2006 15:12:49 +0200 Received: from ericsson.com ([147.214.26.58]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Oct 2006 15:12:49 +0200 Message-ID: <45338551.10707@ericsson.com> Date: Mon, 16 Oct 2006 15:12:49 +0200 From: Lars Westberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hancock, Robert" References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Oct 2006 13:12:49.0783 (UTC) FILETIME=[C7AE1870:01C6F124] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: nsis@ietf.org Subject: [NSIS] messages content X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi, I am trying to make understand how NTLP-works in more detail. I am missing a more detailed description about the explicit message format of the mandatory part of the messages. Can somone help me with a pointer to such information ? regards Lasse _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 16 10:50:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZTmQ-0001ar-Dl; Mon, 16 Oct 2006 10:49:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZTmP-0001am-0W for nsis@ietf.org; Mon, 16 Oct 2006 10:49:25 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZTmL-0005jh-Hh for nsis@ietf.org; Mon, 16 Oct 2006 10:49:24 -0400 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1GZTlz-00017M-UA; Mon, 16 Oct 2006 16:49:10 +0200 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1GZTlz-0004bI-IW; Mon, 16 Oct 2006 16:48:59 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 2DDB0B587; Mon, 16 Oct 2006 16:48:57 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1GZTlw-0002sW-RI; Mon, 16 Oct 2006 16:48:56 +0200 Message-ID: <45339BD8.4040308@tm.uka.de> Date: Mon, 16 Oct 2006 16:48:56 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: "Hancock, Robert" Subject: Re: [NSIS] GIST issue on Error Message Formatting References: In-Reply-To: X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.0 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.4 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, > This is a solicitation for input, especially from the implementors, on > this matter. In the absence of input, my preference would be to leave to The error object caused indeed some implementation pain. While the current definition for additional info contents makes sense, I agree to the comments in general: - the format is not very extensible and robust due to a missing TLV structure, e.g. cannot skip additional info and give out debug comment. - if a node generates a malformed error message, recovering from wrong syntax in the additional info field is difficult. - Having a normal TLV format for objects in the additional info section would make implementations easier (you don't have to construct a structure depending on the error type) and implementation errors less harmful (e.g., if you forgot to include mandatory additional info objects). So according to implementation complexity: at least for us it would be easier to parse a list of TLV objects, because that's already done for other PDU objects. The implementation would be simpler on the parsing side due to less special handling, so I would state: "The error message parser is less complex and would be more future proof and with less special cases." Hope that helped. Roland > spec unchanged, but if people feel (even not particularly strongly) that > a more structured syntax would be preferable it is not that much effort > to change. It would be very good to see change/no change comments either > way. > > cheers, > > robert h. > > ======================================================================== > === > The current error message formats are essentially fixed and predefined > for each > error code; that is: > - if you know the error code, you know precisely what should be in the > message > and you can parse it completely. Someone generating the error has no > freedom > about what information to include (cannot include other Additional Info > fields, > for example). > - if you don't know the error code (typically because it is a new > error), you > cannot parse anything about it beyond the MRI - you cannot parse any > additional > info field or the debugging comment. > > It's been suggested that it would be possible to make the additional > info fields > some kind of object in their own right, in which case there would be > some kind > of TLV format for them, and probably a registry for their type codes. > > The advantage of this is that every message can always be parsed. > (However, > without knowing the semantics of the error code, it still may be hard to > do > anything useful with the information.) > > The disadvantage is that there is a minor change in protocol > specification > complexity. > > It isn't clear what the impact is on implementation complexity. The > error > message parser might be a little more complex but would be more future > proof and > with less special cases. > ======================================================================== _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 16 11:43:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZUc4-0004UX-M7; Mon, 16 Oct 2006 11:42:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZUc3-0004UR-HP for nsis@ietf.org; Mon, 16 Oct 2006 11:42:47 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZUbz-0003wQ-Sx for nsis@ietf.org; Mon, 16 Oct 2006 11:42:47 -0400 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1GZUbs-0004VK-GY; Mon, 16 Oct 2006 17:42:43 +0200 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1GZUbs-0003kU-3Q; Mon, 16 Oct 2006 17:42:36 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 07110B5A6; Mon, 16 Oct 2006 17:42:35 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1GZUbq-0002vR-NF; Mon, 16 Oct 2006 17:42:34 +0200 Message-ID: <4533A86A.4010404@tm.uka.de> Date: Mon, 16 Oct 2006 17:42:34 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: "Hancock, Robert" Subject: Re: [NSIS] GIST issue on MA-Hold-Time References: In-Reply-To: X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: -4.0 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.4 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert and all, Hancock, Robert wrote: > An issue has been raised on MA-Hold-Time negotiation. It is in > the tracker as issue #131 > (http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue131) > and the summary text is included below. > > This is a solicitation for input, especially from the > implementors, on this matter. In the absence of input, my > preference would be to leave to spec unchanged, but if people > feel that this level of flexibility is necessary please speak > up and say so. It would be very good to see change/no change > comments either way. I'm not really sure whether it's indeed required to have an own MA-Hold-Time per protocol. On the one hand the negotiation is already complex enough, on the other hand it would be more consistent to provide it per proposal. Currently, I would vote for no change. However, I have more issues that came up with the MA-Hold-Time during the interop test: * What does an MA-Hold-Time of 0 mean (keep open forever)? * Should very small values, e.g., below one or several seconds be always ignored and forced to be set to a predefined lower bound? (In order to avoid a flooding with MA-Hellos) * The MA-Hold-Time must be repeated in the first Confirm message due to the need for having this value available even if late state installation is used. => What should be done if the MA-Hold-Time is missing? Sending back an Object-Type error with mandatory object missing is probably the right thing to do. Furthermore, the specification in 5.1 of the Confirm message is confusing in this respect and should be clarified. Confirm = Common-Header Message-Routing-Information Session-Identification Network-Layer-Information [ Responder-Cookie [ Stack-Proposal [ Stack-Configuration-Data ] ] ] [ NSLP-Data ] While the example in fig.4 sheds more lighty on how it is intended, one would think that Stack-Proposal _and_ SCD of the Responder are repeated in the Confirm (so I guess nesting with brackets must be fixed). Therefore, clarification is needed that only the R-Node SP is repeated (w/o R-Node SCD) and the Q-Node SCD with MA-Hold-Time is mandatory in the very first Confirm. Thus, also the MAY on top of p. 30 (sec 4.4.1) should be a MUST. Regards, Roland > [Following Routing Area Directorate comments from Adrian Farrel] > > At the moment, the MA-Hold-Time in a proposal applies to all possible > configurations of the messaging association. There is no way to indicate > that > (for example) one would prefer 30 seconds for TCP, but 120 seconds for > TLS/SCTP. > > In principle, different hold time possibilities could be indicated in > the Query, > but this would require some changes in the Stack-Proposal or > Stack-Configuration-Data objects. The SCD syntax does not allow one to > specify a > value which applies to a whole proposal, only to a MA-protocol in a > proposal; > the SP syntax does not allow one to specify MA-Hold-Time at all. One > option > would be to tag the MA-Hold-Time value in the SCD so that there was a > single > value (tagged 0) possibly overridden by alternative values for > particular > proposals (rather like we do for the other protocol options). The SCD > would get > another count field in the header, and we could steal a byte from the > MA-Hold-Time field for the tag. > > However, it is not clear whether the value of this sophistication > outweighs the > cost. The policy for choosing an MA-Hold-Time presumably is a tradeoff > between 3 > variables: > a) the extent to which an MA is being used or is going to be used > b) the cost of keeping the MA open (in stored protocol state inside the > protocols that make up the MA itself) > c) the cost of re-setting up the MA if it is needed again > Of these, (a) is totally independent of the protocol configuration, (b) > is > weakly dependent on it, and (c) is definitely dependent on it. But the > strength > of the dependence is not that great. If you just chose the largest > hold-time > value for all possible MA configurations and used that as the single > value in > the negotiation, the net affect would not be much different from what > could be > achieved with a more granular mechanism. > ======================================================================== > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > -- Dr. Roland Bless -- WWW: http://www.tm.uka.de/~bless Institut für Telematik, Universität Karlsruhe (TH), Germany Zirkel 2, D-76128 Karlsruhe -- Geb. 20.20, 3.OG, Raum 358 Tel.: +49 721 608-6413 Fax: +49 721 608-6789 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 17 02:29:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZiRy-0006bu-6t; Tue, 17 Oct 2006 02:29:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZiRx-0006bp-82 for nsis@ietf.org; Tue, 17 Oct 2006 02:29:17 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZiRv-0004L6-Qe for nsis@ietf.org; Tue, 17 Oct 2006 02:29:17 -0400 Received: from zeus.cs.utwente.nl (zeus.ewi.utwente.nl [130.89.10.12]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k9H6TAfa029341; Tue, 17 Oct 2006 08:29:10 +0200 (MEST) Received: from janus.ewi.utwente.nl (janus [130.89.10.26]) by zeus.cs.utwente.nl (8.12.10/8.12.10) with ESMTP id k9H6TAL0021603; Tue, 17 Oct 2006 08:29:10 +0200 (MEST) Received: (from nobody@localhost) by janus.ewi.utwente.nl (8.11.7p1+Sun/8.10.2) id k9H6TAc17316; Tue, 17 Oct 2006 08:29:10 +0200 (MEST) Date: Tue, 17 Oct 2006 08:29:10 +0200 (MEST) X-Authentication-Warning: janus.ewi.utwente.nl: nobody set sender to karagian@cs.utwente.nl using -f To: Lars.westberg@ericsson.com, gash@att.com, nsis@ietf.org Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Received: from 84.82.109.231 (auth. user karagian@imap2.cs.utwente.nl) by webmail.cs.utwente.nl with HTTP; Tue, 17 Oct 2006 06:29:09 +0000 X-IlohaMail-Blah: karagian@ewi.utwente.nl X-IlohaMail-Method: mail() [mem] X-IlohaMail-Dummy: moo X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <45335629.1030301@ericsson.com> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -5.515 () ALL_TRUSTED,AWL,BAYES_00,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Tue, 17 Oct 2006 08:29:11 +0200 (MEST) X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Lars Do you mean that the QSPEC template must not contain any mandatory (QSPEC-1) parameters? Best Regards, Georgios On 10/16/2006, "Lars Westberg" wrote: >Hi, > The template seems not to be a template because the mandatory part is >more or less the same as Intserv. >The main idea with QoS-template was to make an modular solution that >could allow flexibillity for different Qos-models > >Therefore, I do not understand the scope of the specification. > >I suggest that we move the major part of the parameters to a separate >"Int.serv. over NSIS" specification. >Int.serv. can be seen as a common bearer service. > >regards Lasse > >Ash, Gerald R (Jerry), ALABS wrote: > >> Lars, >> >> > You mention in the below e-mail that there are no open issues, >> > while there is a huge discussion on the nsis mailing list >> > regarding the QSPEC-1 parameters. >> >> John can call a different consensus if he sees one (I've asked him a >> couple of times to do that). What I saw was >> >> 1. Many posts supported the QSPEC-1 concept, only one (or maybe two) I >> saw opposed. The opposing view was repeated *many* times (and is still >> being repeated) but it only counts as one opinion. >> 2. Many posts supported retaining the 4 QSPEC-1 parameters, only one I >> saw opposed. The opposing view was repeated many times. >> 3. There was only one opinion expressed to be able to ignore QSPEC-1 >> parameters. That one opinion has been repeated many times but it only >> counts as one opinion. >> >> John asked a while ago for new opinions on these issues, that would be >> good if there are any *new* opinions. We don't need to hear opinions >> repeated that we've seen so many times. >> >> I invite John once again to make a consensus call so we can move on >> here. I think it is time to make progress and stop repeating ourselves, >> we're not generating any new light in this rather endless discussion. >> >> Thanks, >> Jerry >> _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 17 02:46:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZihy-00010W-JB; Tue, 17 Oct 2006 02:45:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZihx-00010Q-9G for nsis@ietf.org; Tue, 17 Oct 2006 02:45:49 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZiho-0006rp-9F for nsis@ietf.org; Tue, 17 Oct 2006 02:45:49 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7D08016D; Tue, 17 Oct 2006 08:45:37 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 08:45:37 +0200 Received: from ericsson.com ([147.214.26.58]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 08:45:36 +0200 Message-ID: <45347C10.6090602@ericsson.com> Date: Tue, 17 Oct 2006 08:45:36 +0200 From: Lars Westberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Georgios Karagiannis Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt References: In-Reply-To: X-OriginalArrivalTime: 17 Oct 2006 06:45:36.0517 (UTC) FILETIME=[D9FCCB50:01C6F1B7] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.6 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd Cc: gash@att.com, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0828460777==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0828460777== Content-Type: multipart/alternative; boundary="------------080909080307030807090907" This is a multi-part message in MIME format. --------------080909080307030807090907 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit yes. the main problem is that IETF is not the only Standardization organization that like to discuss "bearer services". Just as an example : If we specify the those parameters, How can we use NSIS for SLAs specified by MEF???? How can we use it for 3GPP-Qos definitiions ? In the draft I also see that we the draft specify a new bearer service. It is not compliant to old Int.serv architecture. This is a completely new one with new parameters like priority. I can sure that we can have a never-ending discussion about the "optimal"-set of parameters. I think we agree in beggining the working group discussion that we should not specify any "bearer-service" because NSIS should be a modular architecture with more flexibillity than RSVP. Therefore, I am surprised that we are doing the same mistake as in RSVP: Integrating a bearer service definition into the NSIS-architecture. If we go this track, the QoS-part of NSIS has much less use. RSVP is in this case significantly better in terms of performance and have the same functionality than NSIS. If have to choose I would select RSVP rather than a much more complex three layer protocol stack. regards Lasse Georgios Karagiannis wrote: >Hi Lars > >Do you mean that the QSPEC template must not contain any mandatory >(QSPEC-1) parameters? > > >Best Regards, >Georgios > > > >On 10/16/2006, "Lars Westberg" wrote: > > > >>Hi, >>The template seems not to be a template because the mandatory part is >>more or less the same as Intserv. >>The main idea with QoS-template was to make an modular solution that >>could allow flexibillity for different Qos-models >> >>Therefore, I do not understand the scope of the specification. >> >>I suggest that we move the major part of the parameters to a separate >>"Int.serv. over NSIS" specification. >>Int.serv. can be seen as a common bearer service. >> >>regards Lasse >> >>Ash, Gerald R (Jerry), ALABS wrote: >> >> >> >>>Lars, >>> >>> >>> >>>>You mention in the below e-mail that there are no open issues, >>>>while there is a huge discussion on the nsis mailing list >>>>regarding the QSPEC-1 parameters. >>>> >>>> >>>John can call a different consensus if he sees one (I've asked him a >>>couple of times to do that). What I saw was >>> >>>1. Many posts supported the QSPEC-1 concept, only one (or maybe two) I >>>saw opposed. The opposing view was repeated *many* times (and is still >>>being repeated) but it only counts as one opinion. >>>2. Many posts supported retaining the 4 QSPEC-1 parameters, only one I >>>saw opposed. The opposing view was repeated many times. >>>3. There was only one opinion expressed to be able to ignore QSPEC-1 >>>parameters. That one opinion has been repeated many times but it only >>>counts as one opinion. >>> >>>John asked a while ago for new opinions on these issues, that would be >>>good if there are any *new* opinions. We don't need to hear opinions >>>repeated that we've seen so many times. >>> >>>I invite John once again to make a consensus call so we can move on >>>here. I think it is time to make progress and stop repeating ourselves, >>>we're not generating any new light in this rather endless discussion. >>> >>>Thanks, >>>Jerry >>> >>> >>> > > > --------------080909080307030807090907 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit yes.
the main problem is that IETF is not the only Standardization organization that like to discuss "bearer services". Just as an example :
If we specify the those parameters, How can we use NSIS for SLAs specified by MEF????

How can we use it for 3GPP-Qos definitiions ?


In the draft I also see  that we the draft specify a new bearer service. It is not compliant to old Int.serv architecture.  This is a completely new one with new parameters like priority.

I can sure that we can have a never-ending discussion about the "optimal"-set of parameters.

I think we agree in beggining the working group discussion that we should not specify any "bearer-service" because NSIS should be a modular architecture with  more flexibillity than RSVP.  Therefore, I am surprised that we are doing the same mistake as in RSVP: Integrating a bearer service definition into the NSIS-architecture.

If we go this track, the QoS-part of NSIS has much less use. RSVP is in this case significantly better in terms of performance and have the same functionality than NSIS.
If have to choose I would select RSVP rather than a much more complex  three layer protocol stack.

regards Lasse

Georgios Karagiannis wrote:
Hi Lars

Do you mean that the QSPEC template must not contain any mandatory
(QSPEC-1) parameters?


Best Regards,
Georgios



On 10/16/2006, "Lars Westberg" <Lars.westberg@ericsson.com> wrote:

  
Hi,
The template seems not to be a template because the mandatory part  is
more or less the same as Intserv.
The main idea with QoS-template was to make an modular solution that
could allow flexibillity for different Qos-models

Therefore, I do not understand the scope of the specification.

I suggest that we move the major part of the parameters to a separate
"Int.serv. over NSIS" specification.
Int.serv. can be seen as a common bearer service.

regards Lasse

Ash, Gerald R (Jerry), ALABS wrote:

    
Lars,

      
You mention in the below e-mail that there are no open issues,
while there is a huge discussion on the nsis mailing list
regarding the QSPEC-1 parameters.
        
John can call a different consensus if he sees one (I've asked him a
couple of times to do that).  What I saw was

1. Many posts supported the QSPEC-1 concept, only one (or maybe two) I
saw opposed.  The opposing view was repeated *many* times (and is still
being repeated) but it only counts as one opinion.
2. Many posts supported retaining the 4 QSPEC-1 parameters, only one I
saw opposed.  The opposing view was repeated many times.
3. There was only one opinion expressed to be able to ignore QSPEC-1
parameters.  That one opinion has been repeated many times but it only
counts as one opinion.

John asked a while ago for new opinions on these issues, that would be
good if there are any *new* opinions.  We don't need to hear opinions
repeated that we've seen so many times.

I invite John once again to make a consensus call so we can move on
here.  I think it is time to make progress and stop repeating ourselves,
we're not generating any new light in this rather endless discussion.

Thanks,
Jerry
--------------080909080307030807090907-- --===============0828460777== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0828460777==-- From nsis-bounces@ietf.org Tue Oct 17 03:25:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZjKB-00043a-Q0; Tue, 17 Oct 2006 03:25:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZjKA-00042j-EO for nsis@ietf.org; Tue, 17 Oct 2006 03:25:18 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZjK9-0004d3-58 for nsis@ietf.org; Tue, 17 Oct 2006 03:25:18 -0400 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1GZjJo-0001j8-7w; Tue, 17 Oct 2006 09:25:02 +0200 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1GZjJn-0006AY-VI; Tue, 17 Oct 2006 09:24:55 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 86B63B555; Tue, 17 Oct 2006 09:24:55 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1GZjJm-0004FX-FS; Tue, 17 Oct 2006 09:24:54 +0200 Message-ID: <45348545.70904@tm.uka.de> Date: Tue, 17 Oct 2006 09:24:53 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Lars Westberg Subject: Re: [NSIS] messages content References: <45338551.10707@ericsson.com> In-Reply-To: <45338551.10707@ericsson.com> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.1 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.3 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: nsis@ietf.org, "Hancock, Robert" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Lars, Lars Westberg wrote: > I am trying to make understand how NTLP-works in more detail. > I am missing a more detailed description about the explicit message > format of the mandatory part of the messages. Sorry, I don't get the point. It's all in the draft, see below. > Can somone help me with a pointer to such information ? You can find the GIST message format in section 5.1 (p.35) and the binary formats in Appendix A or draft-ietf-nsis-ntlp-11.txt. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 17 03:31:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZjPJ-0006W6-92; Tue, 17 Oct 2006 03:30:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZjPI-0006Vw-0M for nsis@ietf.org; Tue, 17 Oct 2006 03:30:36 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZjPF-0005Km-Mk for nsis@ietf.org; Tue, 17 Oct 2006 03:30:35 -0400 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1GZjP9-00033t-Ak; Tue, 17 Oct 2006 09:30:33 +0200 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1GZjP8-0006mw-VH; Tue, 17 Oct 2006 09:30:27 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 61BCEB555; Tue, 17 Oct 2006 09:30:26 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1GZjP8-0004G8-3B; Tue, 17 Oct 2006 09:30:26 +0200 Message-ID: <45348691.1030509@tm.uka.de> Date: Tue, 17 Oct 2006 09:30:25 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Lars Westberg Subject: Re: [NSIS] messages content References: <45338551.10707@ericsson.com> <45348545.70904@tm.uka.de> In-Reply-To: <45348545.70904@tm.uka.de> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.1 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.3 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org > Lars Westberg wrote: >> I am trying to make understand how NTLP-works in more detail. >> I am missing a more detailed description about the explicit message >> format of the mandatory part of the messages. > > Sorry, I don't get the point. It's all in the draft, see below. > >> Can somone help me with a pointer to such information ? > > You can find the GIST message format in section 5.1 (p.35) > and the binary formats in Appendix A or draft-ietf-nsis-ntlp-11.txt. Typo: s/or/of (or should be read of) and its on p. 100. Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 17 03:38:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZjWW-0005Lj-4f; Tue, 17 Oct 2006 03:38:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZjWU-0005L4-GC for nsis@ietf.org; Tue, 17 Oct 2006 03:38:02 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZjWN-0006RL-SY for nsis@ietf.org; Tue, 17 Oct 2006 03:38:02 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 408F0CC1; Tue, 17 Oct 2006 09:37:55 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 09:37:54 +0200 Received: from ericsson.com ([147.214.26.58]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 09:37:54 +0200 Message-ID: <45348852.1020202@ericsson.com> Date: Tue, 17 Oct 2006 09:37:54 +0200 From: Lars Westberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roland Bless Subject: Re: [NSIS] messages content References: <45338551.10707@ericsson.com> <45348545.70904@tm.uka.de> In-Reply-To: <45348545.70904@tm.uka.de> X-OriginalArrivalTime: 17 Oct 2006 07:37:54.0306 (UTC) FILETIME=[28416620:01C6F1BF] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: nsis@ietf.org, "Hancock, Robert" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0209561328==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0209561328== Content-Type: multipart/alternative; boundary="------------050605060402090208010306" This is a multi-part message in MIME format. --------------050605060402090208010306 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I have looked through the documet and it's very difficult to interprete the all statements. It is too many options an features in the the specification. I am after examples of message structures and sequence diagram so I can verify my assumptions. I would be very happy if someone can help me with such information. regards Lasse Roland Bless wrote: > Hi Lars, > > Lars Westberg wrote: > > I am trying to make understand how NTLP-works in more detail. > > I am missing a more detailed description about the explicit message > > format of the mandatory part of the messages. > > Sorry, I don't get the point. It's all in the draft, see below. > > > Can somone help me with a pointer to such information ? > > You can find the GIST message format in section 5.1 (p.35) > and the binary formats in Appendix A or draft-ietf-nsis-ntlp-11.txt. > > Regards, > Roland > --------------050605060402090208010306 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I have looked through the documet and it's very difficult to interprete the all statements. It is too many options an features in the the specification.

I am after examples of message structures and sequence diagram so I can verify my assumptions.
I would be very happy if someone can help me with such information.


regards Lasse

Roland Bless wrote:
Re: [NSIS] messages content

Hi Lars,

Lars Westberg wrote:
> I am trying to make understand how NTLP-works in more detail.
> I am missing a more detailed description about the explicit message
> format of the mandatory part of the messages.

Sorry, I don't get the point. It's all in the draft, see below.

> Can somone help me with a pointer to such information ?

You can find the GIST message format in section 5.1 (p.35)
and the binary formats in Appendix A or draft-ietf-nsis-ntlp-11.txt.

Regards,
 Roland

--------------050605060402090208010306-- --===============0209561328== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0209561328==-- From nsis-bounces@ietf.org Tue Oct 17 03:47:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZjek-00029Y-Qx; Tue, 17 Oct 2006 03:46:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZjej-00029Q-Vm for nsis@ietf.org; Tue, 17 Oct 2006 03:46:33 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZjei-0007lW-M7 for nsis@ietf.org; Tue, 17 Oct 2006 03:46:33 -0400 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1GZjea-0006XO-Ae; Tue, 17 Oct 2006 09:46:31 +0200 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1GZjeZ-000198-Up; Tue, 17 Oct 2006 09:46:23 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 54DE9B555; Tue, 17 Oct 2006 09:46:23 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1GZjeY-0004HC-L1; Tue, 17 Oct 2006 09:46:23 +0200 Message-ID: <45348A4D.9010001@tm.uka.de> Date: Tue, 17 Oct 2006 09:46:21 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Lars Westberg Subject: Re: [NSIS] messages content References: <45338551.10707@ericsson.com> <45348545.70904@tm.uka.de> <45348852.1020202@ericsson.com> In-Reply-To: <45348852.1020202@ericsson.com> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.1 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.3 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: nsis@ietf.org, "Hancock, Robert" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Lars, Lars Westberg wrote: > I have looked through the documet and it's very difficult to interprete > the all statements. It is too many options an features in the the > specification. It's somewhat complex, but implementable. A student of mine was able to do a full implementation within 6 months. > I am after examples of message structures and sequence diagram so I can > verify my assumptions. > I would be very happy if someone can help me with such information. Protocol state machines are in Chapter 6 (see p. 62 and 65) and message structures in Chapter 5. If this doesn't help you may ask your question on the list. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 17 03:52:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZjjp-0006oE-CN; Tue, 17 Oct 2006 03:51:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZjjo-0006o7-9R for nsis@ietf.org; Tue, 17 Oct 2006 03:51:48 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZjji-00009A-VP for nsis@ietf.org; Tue, 17 Oct 2006 03:51:48 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2478BD42; Tue, 17 Oct 2006 09:51:40 +0200 (CEST) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 09:51:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] messages content Date: Tue, 17 Oct 2006 09:51:39 +0200 Message-ID: <0CDAE977A7172A40A2A3A1C20C12BD650488B0C6@esealmw106.eemea.ericsson.se> In-Reply-To: <45348A4D.9010001@tm.uka.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] messages content Thread-Index: AcbxwF7BYqo2J+IMR/qyyTNLzAib8AAABZuw From: "Lars Westberg \(KI/EAB\)" To: "Roland Bless" X-OriginalArrivalTime: 17 Oct 2006 07:51:39.0544 (UTC) FILETIME=[1422B980:01C6F1C1] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: nsis@ietf.org, "Hancock, Robert" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org comments inline -----Original Message----- From: Roland Bless [mailto:bless@tm.uka.de]=20 Sent: den 17 oktober 2006 09:46 To: Lars Westberg (KI/EAB) Cc: nsis@ietf.org; Hancock, Robert Subject: Re: [NSIS] messages content Hi Lars, Lars Westberg wrote: > I have looked through the documet and it's very difficult to=20 > interprete the all statements. It is too many options an features in=20 > the the specification. It's somewhat complex, but implementable. A student of mine was able to do a full implementation within 6 months. I do not have six-months to spend of it. I would rather prefer a fast-track solution. > I am after examples of message structures and sequence diagram so I=20 > can verify my assumptions. > I would be very happy if someone can help me with such information. Protocol state machines are in Chapter 6 (see p. 62 and 65) and message structures in Chapter 5. If this doesn't help you may ask your question on the list. I can't all questions on the list. I would rather appreciate an example implementation of it with message shown in text-format. Does the implementation showing the messages in text ?? If so, I am interested in it. Is it possible to get a copy ??? Regards, Roland -Lasse _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 17 04:36:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZkQT-0004zP-Fm; Tue, 17 Oct 2006 04:35:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZkQP-0004ty-8S for nsis@ietf.org; Tue, 17 Oct 2006 04:35:49 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZkJp-0007eK-Ob for nsis@ietf.org; Tue, 17 Oct 2006 04:29:05 -0400 Received: from mail1.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id k9H8SAva032305; Tue, 17 Oct 2006 10:28:10 +0200 Received: from mchp7wta.ww002.siemens.net (mchp7wta.ww002.siemens.net [139.25.131.193]) by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id k9H8SA7T006726; Tue, 17 Oct 2006 10:28:10 +0200 Received: from blns00fa.ww002.siemens.net ([147.54.45.102]) by mchp7wta.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 10:28:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Date: Tue, 17 Oct 2006 10:28:08 +0200 Message-ID: In-Reply-To: <45347C10.6090602@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Thread-Index: Acbxt/yek9+ogLijS7eVJkU/EgmjdAADaGOA From: "Kappler, Cornelia" To: "Lars Westberg" , "Georgios Karagiannis" X-OriginalArrivalTime: 17 Oct 2006 08:28:09.0836 (UTC) FILETIME=[2DA6C2C0:01C6F1C6] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7e267523e0685e5aa2dbbdde4b659686 Cc: gash@att.com, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0653674818==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0653674818== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F1C6.2D3207AC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F1C6.2D3207AC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Lars,=20 =20 could you explain why the qspec draft defines a new bearer service?=20 =20 What is a bearer service? This concept exists in 3GPP, but it does not exist in IETF I dont think, and I dont think the 3GPP definition is transferrable to IETF. So what exactly are you stating? =20 Cornelia ________________________________ Von: Lars Westberg [mailto:Lars.westberg@ericsson.com]=20 Gesendet: Dienstag, 17. Oktober 2006 08:46 An: Georgios Karagiannis Cc: gash@att.com; nsis@ietf.org Betreff: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt =09 =09 yes.=20 the main problem is that IETF is not the only Standardization organization that like to discuss "bearer services". Just as an example : If we specify the those parameters, How can we use NSIS for SLAs specified by MEF???? =09 How can we use it for 3GPP-Qos definitiions ? =09 =09 In the draft I also see that we the draft specify a new bearer service. It is not compliant to old Int.serv architecture. This is a completely new one with new parameters like priority. =09 I can sure that we can have a never-ending discussion about the "optimal"-set of parameters. =09 I think we agree in beggining the working group discussion that we should not specify any "bearer-service" because NSIS should be a modular architecture with more flexibillity than RSVP. Therefore, I am surprised that we are doing the same mistake as in RSVP: Integrating a bearer service definition into the NSIS-architecture. =09 If we go this track, the QoS-part of NSIS has much less use. RSVP is in this case significantly better in terms of performance and have the same functionality than NSIS. If have to choose I would select RSVP rather than a much more complex three layer protocol stack. =09 regards Lasse =09 Georgios Karagiannis wrote: =09 Hi Lars =09 Do you mean that the QSPEC template must not contain any mandatory (QSPEC-1) parameters? =09 =09 Best Regards, Georgios =09 =09 =09 On 10/16/2006, "Lars Westberg" wrote: =09 =20 Hi, The template seems not to be a template because the mandatory part is more or less the same as Intserv. The main idea with QoS-template was to make an modular solution that could allow flexibillity for different Qos-models =09 Therefore, I do not understand the scope of the specification. =09 I suggest that we move the major part of the parameters to a separate "Int.serv. over NSIS" specification. Int.serv. can be seen as a common bearer service. =09 regards Lasse =09 Ash, Gerald R (Jerry), ALABS wrote: =09 =20 Lars, =09 =20 You mention in the below e-mail that there are no open issues, while there is a huge discussion on the nsis mailing list regarding the QSPEC-1 parameters. =20 John can call a different consensus if he sees one (I've asked him a couple of times to do that). What I saw was =09 1. Many posts supported the QSPEC-1 concept, only one (or maybe two) I saw opposed. The opposing view was repeated *many* times (and is still being repeated) but it only counts as one opinion. 2. Many posts supported retaining the 4 QSPEC-1 parameters, only one I saw opposed. The opposing view was repeated many times. 3. There was only one opinion expressed to be able to ignore QSPEC-1 parameters. That one opinion has been repeated many times but it only counts as one opinion. =09 John asked a while ago for new opinions on these issues, that would be good if there are any *new* opinions. We don't need to hear opinions repeated that we've seen so many times. =09 I invite John once again to make a consensus call so we can move on here. I think it is time to make progress and stop repeating ourselves, we're not generating any new light in this rather endless discussion. =09 Thanks, Jerry =09 =20 =09 =20 ------_=_NextPart_001_01C6F1C6.2D3207AC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Lars,
 
could you explain why the qspec draft defines a = new bearer=20 service?
 
What is a bearer service? This concept exists = in 3GPP, but=20 it does not exist in IETF I dont think, and I dont think the 3GPP = definition is=20 transferrable to IETF. So what exactly are you = stating?
 
Cornelia

Von: Lars Westberg=20 [mailto:Lars.westberg@ericsson.com]
Gesendet: Dienstag, 17. = Oktober=20 2006 08:46
An: Georgios Karagiannis
Cc: = gash@att.com;=20 nsis@ietf.org
Betreff: Re: [NSIS] I-D=20 ACTION:draft-ietf-nsis-qspec-12.txt

yes.
the main problem is that IETF is not the only=20 Standardization organization that like to discuss "bearer services". = Just as=20 an example :
If we specify the those parameters, How can we use = NSIS for=20 SLAs specified by MEF????

How can we use it for 3GPP-Qos = definitiions=20 ?


In the draft I also see  that we the draft specify a = new=20 bearer service. It is not compliant to old Int.serv = architecture.  This=20 is a completely new one with new parameters like priority.

I = can sure=20 that we can have a never-ending discussion about the "optimal"-set of=20 parameters.

I think we agree in beggining the working group = discussion=20 that we should not specify any "bearer-service" because NSIS should be = a=20 modular architecture with  more flexibillity than RSVP.  = Therefore,=20 I am surprised that we are doing the same mistake as in RSVP: = Integrating a=20 bearer service definition into the NSIS-architecture.

If we go = this=20 track, the QoS-part of NSIS has much less use. RSVP is in this case=20 significantly better in terms of performance and have the same = functionality=20 than NSIS.
If have to choose I would select RSVP rather than a much = more=20 complex  three layer protocol stack.

regards = Lasse

Georgios=20 Karagiannis wrote:
Hi Lars

Do you mean that the QSPEC template must not contain any mandatory
(QSPEC-1) parameters?


Best Regards,
Georgios



On 10/16/2006, "Lars Westberg" <Lars.westberg@ericsson.com=
> wrote:

  
Hi,
The template seems not to be a template because the mandatory part  is
more or less the same as Intserv.
The main idea with QoS-template was to make an modular solution that
could allow flexibillity for different Qos-models

Therefore, I do not understand the scope of the specification.

I suggest that we move the major part of the parameters to a separate
"Int.serv. over NSIS" specification.
Int.serv. can be seen as a common bearer service.

regards Lasse

Ash, Gerald R (Jerry), ALABS wrote:

    
Lars,

      
You mention in the =
below e-mail that there are no open issues,
while there is a huge discussion on the nsis mailing list
regarding the QSPEC-1 parameters.
        
John can call a different =
consensus if he sees one (I've asked him a
couple of times to do that).  What I saw was

1. Many posts supported the QSPEC-1 concept, only one (or maybe two) I
saw opposed.  The opposing view was repeated *many* times (and is still
being repeated) but it only counts as one opinion.
2. Many posts supported retaining the 4 QSPEC-1 parameters, only one I
saw opposed.  The opposing view was repeated many times.
3. There was only one opinion expressed to be able to ignore QSPEC-1
parameters.  That one opinion has been repeated many times but it only
counts as one opinion.

John asked a while ago for new opinions on these issues, that would be
good if there are any *new* opinions.  We don't need to hear opinions
repeated that we've seen so many times.

I invite John once again to make a consensus call so we can move on
here.  I think it is time to make progress and stop repeating ourselves,
we're not generating any new light in this rather endless discussion.

Thanks,
Jerry
------_=_NextPart_001_01C6F1C6.2D3207AC-- --===============0653674818== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0653674818==-- From nsis-bounces@ietf.org Tue Oct 17 04:37:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZkRB-0005az-9k; Tue, 17 Oct 2006 04:36:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZkRA-0005au-Rh for nsis@ietf.org; Tue, 17 Oct 2006 04:36:36 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZkR8-00019G-5q for nsis@ietf.org; Tue, 17 Oct 2006 04:36:36 -0400 Received: from mail2.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id k9H8ZxNu005411; Tue, 17 Oct 2006 10:35:59 +0200 Received: from mchp7wta.ww002.siemens.net (mchp7wta.ww002.siemens.net [139.25.131.193]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id k9H8ZwMZ015162; Tue, 17 Oct 2006 10:35:58 +0200 Received: from blns00fa.ww002.siemens.net ([147.54.45.102]) by mchp7wta.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 10:35:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Date: Tue, 17 Oct 2006 10:35:56 +0200 Message-ID: In-Reply-To: <45335629.1030301@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Thread-Index: AcbxCl0QtgjKCWiuRAq4PLBz5B66lAAu9zZw From: "Kappler, Cornelia" To: "Lars Westberg" , "Ash, Gerald R \(Jerry\), ALABS" , X-OriginalArrivalTime: 17 Oct 2006 08:35:58.0264 (UTC) FILETIME=[44DB3380:01C6F1C7] X-Spam-Score: 0.1 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1238563537==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============1238563537== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F1C7.44807AEB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F1C7.44807AEB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Lars,=20 =20 what you call "mandatory" does _overlap_ with IntServ because this was the WG requirement when we started the QSPEC work. If the WG removes this requirement we can remove these parameter(s). =20 Note that we in fact included just _one_ out of about six IntServ parameters, namely the Token Bucket. Most IntServ paras (C_tot, D_tot, S etc) are not included (at least not in the interesting qspec-1 parameter category).=20 =20 So anyway I dont think your statement is correct. =20 Cornelia ________________________________ Von: Lars Westberg [mailto:Lars.westberg@ericsson.com]=20 Gesendet: Montag, 16. Oktober 2006 11:52 An: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org Betreff: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt =09 =09 Hi, The template seems not to be a template because the mandatory part is more or less the same as Intserv. The main idea with QoS-template was to make an modular solution that could allow flexibillity for different Qos-models =09 Therefore, I do not understand the scope of the specification.=20 =09 I suggest that we move the major part of the parameters to a separate "Int.serv. over NSIS" specification. Int.serv. can be seen as a common bearer service. =09 regards Lasse =09 Ash, Gerald R (Jerry), ALABS wrote: =09 Lars, =09 > You mention in the below e-mail that there are no open issues, > while there is a huge discussion on the nsis mailing list > regarding the QSPEC-1 parameters. =09 John can call a different consensus if he sees one (I've asked him a couple of times to do that). What I saw was =09 1. Many posts supported the QSPEC-1 concept, only one (or maybe two) I saw opposed. The opposing view was repeated *many* times (and is still being repeated) but it only counts as one opinion. 2. Many posts supported retaining the 4 QSPEC-1 parameters, only one I saw opposed. The opposing view was repeated many times. 3. There was only one opinion expressed to be able to ignore QSPEC-1 parameters. That one opinion has been repeated many times but it only counts as one opinion. =09 John asked a while ago for new opinions on these issues, that would be good if there are any *new* opinions. We don't need to hear opinions repeated that we've seen so many times. =09 I invite John once again to make a consensus call so we can move on here. I think it is time to make progress and stop repeating ourselves, we're not generating any new light in this rather endless discussion. =09 Thanks, Jerry =09 ------_=_NextPart_001_01C6F1C7.44807AEB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Lars,
 
what you call "mandatory" does _overlap_ with = IntServ=20 because this was the WG requirement when we started the QSPEC work. If = the WG=20 removes this requirement we can remove these = parameter(s).
 
Note that we in fact included just _one_ out of = about six=20 IntServ parameters, namely the Token Bucket. Most IntServ paras (C_tot, = D_tot, S=20 etc) are not included (at least not in the interesting qspec-1 parameter = category).
 
So anyway I dont think your statement is=20 correct.
 
Cornelia

Von: Lars Westberg=20 [mailto:Lars.westberg@ericsson.com]
Gesendet: Montag, 16. = Oktober=20 2006 11:52
An: Ash, Gerald R (Jerry), ALABS;=20 nsis@ietf.org
Betreff: Re: [NSIS] I-D=20 ACTION:draft-ietf-nsis-qspec-12.txt

Hi,
 The template seems not to be a template = because the=20 mandatory part  is more or less the same as Intserv.
The main = idea=20 with QoS-template was to make an modular solution that could allow=20 flexibillity for different Qos-models

Therefore, I do not = understand=20 the scope of the specification.

I suggest that we move the = major part=20 of the parameters to a separate "Int.serv. over NSIS"=20 specification.
Int.serv. can be seen as a common bearer=20 service.

regards Lasse

Ash, Gerald R (Jerry), ALABS = wrote:

Lars,

> You mention in the below e-mail = that there=20 are no open issues,
> while there is a huge discussion on the = nsis=20 mailing list
> regarding the QSPEC-1 parameters.

John = can call=20 a different consensus if he sees one (I've asked him a
couple of = times to=20 do that).  What I saw was

1. Many posts supported the = QSPEC-1=20 concept, only one (or maybe two) I
saw opposed.  The = opposing view=20 was repeated *many* times (and is still
being repeated) but it = only=20 counts as one opinion.
2. Many posts supported retaining the 4 = QSPEC-1=20 parameters, only one I
saw opposed.  The opposing view was = repeated=20 many times.
3. There was only one opinion expressed to be able to = ignore=20 QSPEC-1
parameters.  That one opinion has been repeated many = times=20 but it only
counts as one opinion.

John asked a while ago = for new=20 opinions on these issues, that would be
good if there are any = *new*=20 opinions.  We don't need to hear opinions
repeated that = we've seen=20 so many times.

I invite John once again to make a consensus = call so=20 we can move on
here.  I think it is time to make progress = and stop=20 repeating ourselves,
we're not generating any new light in this = rather=20 endless=20 discussion.

Thanks,
Jerry

------_=_NextPart_001_01C6F1C7.44807AEB-- --===============1238563537== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============1238563537==-- From nsis-bounces@ietf.org Tue Oct 17 04:41:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZkVE-0006hk-PJ; Tue, 17 Oct 2006 04:40:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZkVD-0006ha-2h for nsis@ietf.org; Tue, 17 Oct 2006 04:40:47 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZkVC-0001yA-FN for nsis@ietf.org; Tue, 17 Oct 2006 04:40:47 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k9H8eCF0012072; Tue, 17 Oct 2006 10:40:17 +0200 (MEST) From: "Georgios Karagiannis" To: "'Lars Westberg'" Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Date: Tue, 17 Oct 2006 10:40:10 +0200 Message-ID: <001301c6f1c7$de6d2a80$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <45347C10.6090602@ericsson.com> Thread-Index: Acbxt9rfPVXjqLj+T5uusDQMgUBvPwADy3pQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: -5.216 () ALL_TRUSTED, AWL, BAYES_00, FVGT_s_OBFU_Q1, HTML_40_50, HTML_MESSAGE, HTML_TITLE_EMPTY, J_CHICKENPOX_34 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Tue, 17 Oct 2006 10:40:41 +0200 (MEST) X-Spam-Score: 0.1 (/) X-Scan-Signature: efb5d987e2484f3d9a304cc31a003441 Cc: gash@att.com, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0851389656==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0851389656== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0014_01C6F1D8.A1F5FA80" This is a multi-part message in MIME format. ------=_NextPart_000_0014_01C6F1D8.A1F5FA80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Lars I think that I agree with you! However, we may just need one QSPEC parameter, say Traffic (Tocken Bucket and Bandwidth) that can be mandatory. In this way we will provide the required interoperability between the QoS models. Actually this was also the conclusion that Xiaoming deduced after studying a couple of examples. Furthermore, we could however provide the ability to QoS models to specify which QSPEC parameters should be mandatory or not. What do you think? Best regards, Georgios _____ From: Lars Westberg [mailto:Lars.westberg@ericsson.com] Sent: dinsdag 17 oktober 2006 8:46 To: Georgios Karagiannis Cc: gash@att.com; nsis@ietf.org Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt yes. the main problem is that IETF is not the only Standardization organization that like to discuss "bearer services". Just as an example : If we specify the those parameters, How can we use NSIS for SLAs specified by MEF???? How can we use it for 3GPP-Qos definitiions ? In the draft I also see that we the draft specify a new bearer service. It is not compliant to old Int.serv architecture. This is a completely new one with new parameters like priority. I can sure that we can have a never-ending discussion about the "optimal"-set of parameters. I think we agree in beggining the working group discussion that we should not specify any "bearer-service" because NSIS should be a modular architecture with more flexibillity than RSVP. Therefore, I am surprised that we are doing the same mistake as in RSVP: Integrating a bearer service definition into the NSIS-architecture. If we go this track, the QoS-part of NSIS has much less use. RSVP is in this case significantly better in terms of performance and have the same functionality than NSIS. If have to choose I would select RSVP rather than a much more complex three layer protocol stack. regards Lasse Georgios Karagiannis wrote: Hi Lars Do you mean that the QSPEC template must not contain any mandatory (QSPEC-1) parameters? Best Regards, Georgios On 10/16/2006, "Lars Westberg" wrote: Hi, The template seems not to be a template because the mandatory part is more or less the same as Intserv. The main idea with QoS-template was to make an modular solution that could allow flexibillity for different Qos-models Therefore, I do not understand the scope of the specification. I suggest that we move the major part of the parameters to a separate "Int.serv. over NSIS" specification. Int.serv. can be seen as a common bearer service. regards Lasse Ash, Gerald R (Jerry), ALABS wrote: Lars, You mention in the below e-mail that there are no open issues, while there is a huge discussion on the nsis mailing list regarding the QSPEC-1 parameters. John can call a different consensus if he sees one (I've asked him a couple of times to do that). What I saw was 1. Many posts supported the QSPEC-1 concept, only one (or maybe two) I saw opposed. The opposing view was repeated *many* times (and is still being repeated) but it only counts as one opinion. 2. Many posts supported retaining the 4 QSPEC-1 parameters, only one I saw opposed. The opposing view was repeated many times. 3. There was only one opinion expressed to be able to ignore QSPEC-1 parameters. That one opinion has been repeated many times but it only counts as one opinion. John asked a while ago for new opinions on these issues, that would be good if there are any *new* opinions. We don't need to hear opinions repeated that we've seen so many times. I invite John once again to make a consensus call so we can move on here. I think it is time to make progress and stop repeating ourselves, we're not generating any new light in this rather endless discussion. Thanks, Jerry ------=_NextPart_000_0014_01C6F1D8.A1F5FA80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Lars
 
I think that I agree with = you!
 
However, we may=20 just need one QSPEC parameter, say Traffic (Tocken Bucket and Bandwidth) =
that can be=20 mandatory. In this way we will provide the required interoperability = between the=20
QoS=20 models.
Actually this was=20 also the conclusion that Xiaoming deduced after studying a couple of=20 examples.
 
Furthermore, we could however provide the = ability to QoS=20 models to specify which
QSPEC parameters should be mandatory or=20 not.
What do you think?
 
Best regards,
Georgios
 
 

From: Lars Westberg=20 [mailto:Lars.westberg@ericsson.com]
Sent: dinsdag 17 = oktober 2006=20 8:46
To: Georgios Karagiannis
Cc: gash@att.com;=20 nsis@ietf.org
Subject: Re: [NSIS] I-D=20 ACTION:draft-ietf-nsis-qspec-12.txt

yes.
the main problem is that IETF is not the only=20 Standardization organization that like to discuss "bearer services". = Just as=20 an example :
If we specify the those parameters, How can we use = NSIS for=20 SLAs specified by MEF????

How can we use it for 3GPP-Qos = definitiions=20 ?


In the draft I also see  that we the draft specify a = new=20 bearer service. It is not compliant to old Int.serv = architecture.  This=20 is a completely new one with new parameters like priority.

I = can sure=20 that we can have a never-ending discussion about the "optimal"-set of=20 parameters.

I think we agree in beggining the working group = discussion=20 that we should not specify any "bearer-service" because NSIS should be = a=20 modular architecture with  more flexibillity than RSVP.  = Therefore,=20 I am surprised that we are doing the same mistake as in RSVP: = Integrating a=20 bearer service definition into the NSIS-architecture.

If we go = this=20 track, the QoS-part of NSIS has much less use. RSVP is in this case=20 significantly better in terms of performance and have the same = functionality=20 than NSIS.
If have to choose I would select RSVP rather than a much = more=20 complex  three layer protocol stack.

regards = Lasse

Georgios=20 Karagiannis wrote:
Hi Lars

Do you mean that the QSPEC template must not contain any mandatory
(QSPEC-1) parameters?


Best Regards,
Georgios



On 10/16/2006, "Lars Westberg" <Lars.westberg@ericsson.com=
> wrote:

  
Hi,
The template seems not to be a template because the mandatory part  is
more or less the same as Intserv.
The main idea with QoS-template was to make an modular solution that
could allow flexibillity for different Qos-models

Therefore, I do not understand the scope of the specification.

I suggest that we move the major part of the parameters to a separate
"Int.serv. over NSIS" specification.
Int.serv. can be seen as a common bearer service.

regards Lasse

Ash, Gerald R (Jerry), ALABS wrote:

    
Lars,

      
You mention in the =
below e-mail that there are no open issues,
while there is a huge discussion on the nsis mailing list
regarding the QSPEC-1 parameters.
        
John can call a different =
consensus if he sees one (I've asked him a
couple of times to do that).  What I saw was

1. Many posts supported the QSPEC-1 concept, only one (or maybe two) I
saw opposed.  The opposing view was repeated *many* times (and is still
being repeated) but it only counts as one opinion.
2. Many posts supported retaining the 4 QSPEC-1 parameters, only one I
saw opposed.  The opposing view was repeated many times.
3. There was only one opinion expressed to be able to ignore QSPEC-1
parameters.  That one opinion has been repeated many times but it only
counts as one opinion.

John asked a while ago for new opinions on these issues, that would be
good if there are any *new* opinions.  We don't need to hear opinions
repeated that we've seen so many times.

I invite John once again to make a consensus call so we can move on
here.  I think it is time to make progress and stop repeating ourselves,
we're not generating any new light in this rather endless discussion.

Thanks,
Jerry
------=_NextPart_000_0014_01C6F1D8.A1F5FA80-- --===============0851389656== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0851389656==-- From nsis-bounces@ietf.org Tue Oct 17 04:43:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZkXG-0001xL-MB; Tue, 17 Oct 2006 04:42:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZkXF-0001ut-Cm for nsis@ietf.org; Tue, 17 Oct 2006 04:42:53 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZkXD-0002KK-U1 for nsis@ietf.org; Tue, 17 Oct 2006 04:42:53 -0400 Received: from mail1.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id k9H8gRFX011421; Tue, 17 Oct 2006 10:42:27 +0200 Received: from mchp7wta.ww002.siemens.net (mchp7wta.ww002.siemens.net [139.25.131.193]) by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id k9H8gRYx020179; Tue, 17 Oct 2006 10:42:27 +0200 Received: from blns00fa.ww002.siemens.net ([147.54.45.102]) by mchp7wta.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 10:42:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [NSIS] Question to the CL QoS Model authors Date: Tue, 17 Oct 2006 10:42:25 +0200 Message-ID: In-Reply-To: <452D4071.2010807@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Question to the CL QoS Model authors Thread-Index: AcbtaGxE/tacrYNZQuOqpoUVo9tXSwEXvN6w From: "Kappler, Cornelia" To: "Hannes Tschofenig" , "Xiaoming Fu" X-OriginalArrivalTime: 17 Oct 2006 08:42:27.0139 (UTC) FILETIME=[2CA4D130:01C6F1C8] X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: Jukka MJ Manner , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Hannes,=20 this is not yet included in the draft. According to the discussions we = had so far I think we'll state something along these lines: - bandwidth is mapped to token bucket (we'll have to come up with a = proposal for values for the missing TB parameters) - the high-valued QoS Class parameters will receive CLS treatment (we = expect the QNI includes a bandwidth parameter in the QSPEC, otherwise we = cant do anything). The low-value QoS Class parameters get best-effort. - Excess Treatment and Priority is orthogonal to the CLS concept, so CLS = QNEs just have to deal with it.=20 What you see from this is that a CLS QNE must be able to map the QoS = Class parameters onto "high" and "low". This is the extent to which they = must understand QoS class. Cornelia > -----Urspr=FCngliche Nachricht----- > Von: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Gesendet: Mittwoch, 11. Oktober 2006 21:05 > An: Xiaoming Fu > Cc: Jukka MJ Manner; nsis@ietf.org; Kappler, Cornelia > Betreff: Re: [NSIS] Question to the CL QoS Model authors >=20 > Hi Xiaoming, >=20 > I think Jukka was trying to find a QOSM that provides some=20 > information=20 > about the mapping of the mandatory QSPEC parameters to the=20 > one used by a=20 > QoSM. I also tried to find some guidance in existing QOSMs a=20 > couple of=20 > months ago as well and I couldn't find a lot. >=20 > Ciao > Hannes >=20 > Xiaoming Fu schrieb: > > Hi Jukka, > >=20 > > The CLS draft is actually a remapping of RSVP CLS parameters (and=20 > > procedures) to NSIS. > >=20 > > In the QSPEC-1 parameters specified in=20 > [draft-ietf-nsis-qspec], there=20 > > are the following two types: > >=20 > > - is an optional parameter in QNI,=20 > namely it can be=20 > > included or excluded in the CLS control information. If it=20 > is included=20 > > in a message, then CLS QNE must interpret and populate it. > >=20 > > - and are mandatory for all=20 > (QNI QNEs QNR) > > including other QoSMs; mandatory for=20 > receiver-initiated=20 > > reservation, but optional for sender-initiated reservation. > >=20 > > however, we didn't discuss how exactly the objects other than Token=20 > > Bucket(s) inside the QoS Desired etc should be handled. We=20 > thought a QNE=20 > > doesn't need to include (for QNI/QNR) nor interpret any of them. > >=20 > > Any remarks on this? > > Xiaoming > >=20 > > Jukka MJ Manner wrote: > >> Hi Xiaoming and Cornelia, > >> > >> I was wondering if you have some ideas on how the CL QoS=20 > Model would=20 > >> handle all the current QSPEC-1 parameters? Your draft=20 > lists that as an=20 > >> open issue. > >> > >> Cheers, > >> Jukka > >> > >> _______________________________________________ > >> nsis mailing list > >> nsis@ietf.org > >> https://www1.ietf.org/mailman/listinfo/nsis > >=20 >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 17 04:52:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZkg4-0007DM-BR; Tue, 17 Oct 2006 04:52:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZkg3-0007AG-Gz for nsis@ietf.org; Tue, 17 Oct 2006 04:51:59 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZkfv-0004FU-BE for nsis@ietf.org; Tue, 17 Oct 2006 04:51:59 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 83F274F0001; Tue, 17 Oct 2006 10:51:48 +0200 (CEST) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 10:51:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Date: Tue, 17 Oct 2006 10:51:47 +0200 Message-ID: <0CDAE977A7172A40A2A3A1C20C12BD650488B248@esealmw106.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Thread-Index: Acbxt/yek9+ogLijS7eVJkU/EgmjdAADaGOAAAAvFFA= From: "Lars Westberg \(KI/EAB\)" To: "Kappler, Cornelia" , "Georgios Karagiannis" X-OriginalArrivalTime: 17 Oct 2006 08:51:47.0811 (UTC) FILETIME=[7AD49330:01C6F1C9] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 231d7929942febf3be8fd5be2903302f Cc: gash@att.com, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0016070972==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0016070972== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F1C9.7AC7FA6C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F1C9.7AC7FA6C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable let's try to understand my concern.=20 =20 During years, many people have spend a huge set of effort on Qos. Especially specification of parameters and the outcome resulted in "over"-specified definitions. =20 We will se many operators that trying to specify SLA:s of different kinds and they will have their own opinion. These SLAs may not be end-2-end within Internet like MEF but instead used for specific use. With this concept with a specified bearer service, noone can apply a new concept without having the overhead of the mandatory specification.=20 =20 The major problem is that NSIS building exactly the same architecture as RSVP based on the assumption that everything has to be equal. So, what is the gain with NSIS ????? Where is the flexibillity ???? =20 How can we handle other standards bodies if they would like to have their own specification ? if you can't use the flexibillity, the answer is that they will develop their own QoS-signalling. =20 I think it is very important to let the Qos-template to become a template and not a "beaer-service" specification. We have a lot of optional parameters that should be moved from the specification, because that is also causing the confusion. =20 I suggest that we have one encapsulation of controlled based on the previous RFCs and not specify new objects. This Controlled Load can be used for end-2-end interoperabillity but should not be mandatory. =20 =20 =20 regards Lasse ________________________________ From: Kappler, Cornelia [mailto:cornelia.kappler@siemens.com]=20 Sent: den 17 oktober 2006 10:28 To: Lars Westberg (KI/EAB); Georgios Karagiannis Cc: gash@att.com; nsis@ietf.org Subject: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Hi Lars,=20 =20 could you explain why the qspec draft defines a new bearer service?=20 =20 What is a bearer service? This concept exists in 3GPP, but it does not exist in IETF I dont think, and I dont think the 3GPP definition is transferrable to IETF. So what exactly are you stating? =20 Cornelia ________________________________ Von: Lars Westberg [mailto:Lars.westberg@ericsson.com]=20 Gesendet: Dienstag, 17. Oktober 2006 08:46 An: Georgios Karagiannis Cc: gash@att.com; nsis@ietf.org Betreff: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt =09 =09 yes.=20 the main problem is that IETF is not the only Standardization organization that like to discuss "bearer services". Just as an example : If we specify the those parameters, How can we use NSIS for SLAs specified by MEF???? =09 How can we use it for 3GPP-Qos definitiions ? =09 =09 In the draft I also see that we the draft specify a new bearer service. It is not compliant to old Int.serv architecture. This is a completely new one with new parameters like priority. =09 I can sure that we can have a never-ending discussion about the "optimal"-set of parameters. =09 I think we agree in beggining the working group discussion that we should not specify any "bearer-service" because NSIS should be a modular architecture with more flexibillity than RSVP. Therefore, I am surprised that we are doing the same mistake as in RSVP: Integrating a bearer service definition into the NSIS-architecture. =09 If we go this track, the QoS-part of NSIS has much less use. RSVP is in this case significantly better in terms of performance and have the same functionality than NSIS. If have to choose I would select RSVP rather than a much more complex three layer protocol stack. =09 regards Lasse =09 Georgios Karagiannis wrote: =09 Hi Lars =09 Do you mean that the QSPEC template must not contain any mandatory (QSPEC-1) parameters? =09 =09 Best Regards, Georgios =09 =09 =09 On 10/16/2006, "Lars Westberg" wrote: =09 =20 Hi, The template seems not to be a template because the mandatory part is more or less the same as Intserv. The main idea with QoS-template was to make an modular solution that could allow flexibillity for different Qos-models =09 Therefore, I do not understand the scope of the specification. =09 I suggest that we move the major part of the parameters to a separate "Int.serv. over NSIS" specification. Int.serv. can be seen as a common bearer service. =09 regards Lasse =09 Ash, Gerald R (Jerry), ALABS wrote: =09 =20 Lars, =09 =20 You mention in the below e-mail that there are no open issues, while there is a huge discussion on the nsis mailing list regarding the QSPEC-1 parameters. =20 John can call a different consensus if he sees one (I've asked him a couple of times to do that). What I saw was =09 1. Many posts supported the QSPEC-1 concept, only one (or maybe two) I saw opposed. The opposing view was repeated *many* times (and is still being repeated) but it only counts as one opinion. 2. Many posts supported retaining the 4 QSPEC-1 parameters, only one I saw opposed. The opposing view was repeated many times. 3. There was only one opinion expressed to be able to ignore QSPEC-1 parameters. That one opinion has been repeated many times but it only counts as one opinion. =09 John asked a while ago for new opinions on these issues, that would be good if there are any *new* opinions. We don't need to hear opinions repeated that we've seen so many times. =09 I invite John once again to make a consensus call so we can move on here. I think it is time to make progress and stop repeating ourselves, we're not generating any new light in this rather endless discussion. =09 Thanks, Jerry =09 =20 =09 =20 ------_=_NextPart_001_01C6F1C9.7AC7FA6C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
let's=20 try to understand my concern.
 
During=20 years, many people have spend a huge set of effort on Qos. Especially=20 specification of parameters and the outcome resulted in = "over"-specified=20 definitions.
 
We=20 will se many operators that trying to specify SLA:s of different kinds = and they=20 will have their own opinion. These SLAs may not be end-2-end within = Internet=20 like MEF but instead used for specific use. With this concept=20 with a specified bearer service, noone can apply a new concept = without=20 having the overhead of the mandatory specification.
 
The=20 major problem is that NSIS building exactly the same architecture as = RSVP based=20 on the assumption that everything has to be equal. So, what is the gain = with=20 NSIS ?????
Where=20 is the flexibillity ????
 
How=20 can we handle other standards bodies if they would like to have their = own=20 specification ?
if you=20 can't use the flexibillity, the answer is that they will develop their = own=20 QoS-signalling.
 
I=20 think it is very important to let the Qos-template to become a template = and not=20 a "beaer-service" specification. We have a lot of optional parameters = that=20 should be moved from the specification, because that is also causing the = confusion.
 
I=20 suggest that we have one encapsulation of controlled based on the = previous RFCs=20 and not specify new objects. This Controlled Load can be used for = end-2-end=20 interoperabillity but should not be mandatory.
 
 
 
regards Lasse

From: Kappler, Cornelia=20 [mailto:cornelia.kappler@siemens.com]
Sent: den 17 oktober = 2006=20 10:28
To: Lars Westberg (KI/EAB); Georgios = Karagiannis
Cc:=20 gash@att.com; nsis@ietf.org
Subject: AW: [NSIS] I-D=20 ACTION:draft-ietf-nsis-qspec-12.txt

Hi Lars,
 
could you explain why the qspec draft defines a = new bearer=20 service?
 
What is a bearer service? This concept exists = in 3GPP, but=20 it does not exist in IETF I dont think, and I dont think the 3GPP = definition is=20 transferrable to IETF. So what exactly are you = stating?
 
Cornelia

Von: Lars Westberg=20 [mailto:Lars.westberg@ericsson.com]
Gesendet: Dienstag, 17. = Oktober=20 2006 08:46
An: Georgios Karagiannis
Cc: = gash@att.com;=20 nsis@ietf.org
Betreff: Re: [NSIS] I-D=20 ACTION:draft-ietf-nsis-qspec-12.txt

yes.
the main problem is that IETF is not the only=20 Standardization organization that like to discuss "bearer services". = Just as=20 an example :
If we specify the those parameters, How can we use = NSIS for=20 SLAs specified by MEF????

How can we use it for 3GPP-Qos = definitiions=20 ?


In the draft I also see  that we the draft specify a = new=20 bearer service. It is not compliant to old Int.serv = architecture.  This=20 is a completely new one with new parameters like priority.

I = can sure=20 that we can have a never-ending discussion about the "optimal"-set of=20 parameters.

I think we agree in beggining the working group = discussion=20 that we should not specify any "bearer-service" because NSIS should be = a=20 modular architecture with  more flexibillity than RSVP.  = Therefore,=20 I am surprised that we are doing the same mistake as in RSVP: = Integrating a=20 bearer service definition into the NSIS-architecture.

If we go = this=20 track, the QoS-part of NSIS has much less use. RSVP is in this case=20 significantly better in terms of performance and have the same = functionality=20 than NSIS.
If have to choose I would select RSVP rather than a much = more=20 complex  three layer protocol stack.

regards = Lasse

Georgios=20 Karagiannis wrote:
Hi Lars

Do you mean that the QSPEC template must not contain any mandatory
(QSPEC-1) parameters?


Best Regards,
Georgios



On 10/16/2006, "Lars Westberg" <Lars.westberg@ericsson.com=
> wrote:

  
Hi,
The template seems not to be a template because the mandatory part  is
more or less the same as Intserv.
The main idea with QoS-template was to make an modular solution that
could allow flexibillity for different Qos-models

Therefore, I do not understand the scope of the specification.

I suggest that we move the major part of the parameters to a separate
"Int.serv. over NSIS" specification.
Int.serv. can be seen as a common bearer service.

regards Lasse

Ash, Gerald R (Jerry), ALABS wrote:

    
Lars,

      
You mention in the =
below e-mail that there are no open issues,
while there is a huge discussion on the nsis mailing list
regarding the QSPEC-1 parameters.
        
John can call a different =
consensus if he sees one (I've asked him a
couple of times to do that).  What I saw was

1. Many posts supported the QSPEC-1 concept, only one (or maybe two) I
saw opposed.  The opposing view was repeated *many* times (and is still
being repeated) but it only counts as one opinion.
2. Many posts supported retaining the 4 QSPEC-1 parameters, only one I
saw opposed.  The opposing view was repeated many times.
3. There was only one opinion expressed to be able to ignore QSPEC-1
parameters.  That one opinion has been repeated many times but it only
counts as one opinion.

John asked a while ago for new opinions on these issues, that would be
good if there are any *new* opinions.  We don't need to hear opinions
repeated that we've seen so many times.

I invite John once again to make a consensus call so we can move on
here.  I think it is time to make progress and stop repeating ourselves,
we're not generating any new light in this rather endless discussion.

Thanks,
Jerry
------_=_NextPart_001_01C6F1C9.7AC7FA6C-- --===============0016070972== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0016070972==-- From nsis-bounces@ietf.org Tue Oct 17 04:52:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZkg3-00077B-0Q; Tue, 17 Oct 2006 04:51:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZkg2-00073a-6b for nsis@ietf.org; Tue, 17 Oct 2006 04:51:58 -0400 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZkfz-0004GE-Fo for nsis@ietf.org; Tue, 17 Oct 2006 04:51:58 -0400 Received: from mail1.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id k9H8ppPQ030042; Tue, 17 Oct 2006 10:51:51 +0200 Received: from mchp771a.ww002.siemens.net (mchp771a.ww002.siemens.net [139.25.131.189]) by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id k9H8ppXY029771; Tue, 17 Oct 2006 10:51:51 +0200 Received: from blns00fa.ww002.siemens.net ([147.54.45.102]) by mchp771a.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 10:51:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [NSIS] QSPEC-issue (GK-2) Date: Tue, 17 Oct 2006 10:51:49 +0200 Message-ID: In-Reply-To: <452D406A.3020200@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QSPEC-issue (GK-2) Thread-Index: AcbtanD6fn22GI49QTOs4tcmcnPXswEXnjhg From: "Kappler, Cornelia" To: "Hannes Tschofenig" , "Georgios Karagiannis" X-OriginalArrivalTime: 17 Oct 2006 08:51:50.0888 (UTC) FILETIME=[7CAA1680:01C6F1C9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Georgios and Hannes,=20 see my previous post regarding how to handle these parameters in CL.=20 The proposal for CL is that a CL QNE has an algorithm that tells it = which QoS Class parameters are "high class" and whcih are "low class". = If they are high class, they will receive CL treatment. If they are low = class, they receive best effort.=20 This way QSPECs based on "QoS Class" QOSMs get as reasonable a treatment = as one can expect, and at the same time I dont see a CL QNE being = overburdened by this task. Cornelia=20 > -----Urspr=FCngliche Nachricht----- > Von: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Gesendet: Mittwoch, 11. Oktober 2006 21:05 > An: Georgios Karagiannis > Cc: nsis@ietf.org > Betreff: Re: [NSIS] QSPEC-issue (GK-2) >=20 > I support Georgios. >=20 > I think it is unrealistic to assume that Y.1541 and DSTE behavior (as=20 > required for strictly interpreting these parameters) is=20 > implemented in=20 > every QNE. >=20 > Ciao > Hannes >=20 > Georgios Karagiannis schrieb: > > Description of issue > > Change to QSPEC-2 parameter > >=20 > >=20 > > Submitter name: Georgios Karagiannis > > Submitter email address: karagian@cs.utwente.nl Date first=20 > submitted: > > 11.10.2006 > > Reference: =20 > > Comment type: T > > Priority: 'S' > > Section: Various > > Rationale/Explanation of issue: > >=20 > > It is not realistic to assume that the QNI is able to know which=20 > > network technologies (Diffserv, MPLS, Y.1541) are supported=20 > > on the end-to-end path. > > If the "QoS Class" parameter is considered to be a QSPEC-1 parameter > > then it will mean that all QNEs located on the=20 > > end-to-end path must support the Diffserv and MPLS and=20 > Y.1541 technologies.=20 > > This is unrealistic. > >=20 > > Requested change: > > The parameter must be a QSPEC-2 parameter. > >=20 > >=20 > >=20 > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > >=20 > >=20 >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 17 04:58:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZkla-0003xR-IO; Tue, 17 Oct 2006 04:57:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZklZ-0003xM-08 for nsis@ietf.org; Tue, 17 Oct 2006 04:57:41 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZklX-0005Dl-I5 for nsis@ietf.org; Tue, 17 Oct 2006 04:57:40 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k9H8vSme014031; Tue, 17 Oct 2006 10:57:35 +0200 (MEST) From: "Georgios Karagiannis" To: "'Kappler, Cornelia'" , "'Hannes Tschofenig'" Subject: RE: [NSIS] QSPEC-issue (GK-2) Date: Tue, 17 Oct 2006 10:57:24 +0200 Message-ID: <002d01c6f1ca$46a564d0$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcbtanD6fn22GI49QTOs4tcmcnPXswEXnjhgAABCSLA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: -5.535 () ALL_TRUSTED,AWL,BAYES_00,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Tue, 17 Oct 2006 10:57:36 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Cornelia This is not possible! How a QNE will know how to map a PHB class into a Y.1541 class? It is impossible to come up with a reasonable mapping. The only solution on this is to mandate that all QNEs implement Diffserv = and MPLS and Y.1541. In this way NSIS will never be used and deployed. Best regards, Georgios > -----Original Message----- > From: Kappler, Cornelia [mailto:cornelia.kappler@siemens.com]=20 > Sent: dinsdag 17 oktober 2006 10:52 > To: Hannes Tschofenig; Georgios Karagiannis > Cc: nsis@ietf.org > Subject: AW: [NSIS] QSPEC-issue (GK-2) >=20 > Hi Georgios and Hannes,=20 >=20 > see my previous post regarding how to handle these parameters in CL.=20 >=20 > The proposal for CL is that a CL QNE has an algorithm that=20 > tells it which QoS Class parameters are "high class" and=20 > whcih are "low class". If they are high class, they will=20 > receive CL treatment. If they are low class, they receive=20 > best effort.=20 >=20 > This way QSPECs based on "QoS Class" QOSMs get as reasonable=20 > a treatment as one can expect, and at the same time I dont=20 > see a CL QNE being overburdened by this task. >=20 > Cornelia=20 >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > Gesendet: Mittwoch, 11. Oktober 2006 21:05 > > An: Georgios Karagiannis > > Cc: nsis@ietf.org > > Betreff: Re: [NSIS] QSPEC-issue (GK-2) > >=20 > > I support Georgios. > >=20 > > I think it is unrealistic to assume that Y.1541 and DSTE=20 > behavior (as=20 > > required for strictly interpreting these parameters) is=20 > implemented in=20 > > every QNE. > >=20 > > Ciao > > Hannes > >=20 > > Georgios Karagiannis schrieb: > > > Description of issue > > > Change to QSPEC-2 parameter > > >=20 > > >=20 > > > Submitter name: Georgios Karagiannis Submitter email address:=20 > > > karagian@cs.utwente.nl Date first > > submitted: > > > 11.10.2006 > > > Reference: =20 > > > Comment type: T > > > Priority: 'S' > > > Section: Various > > > Rationale/Explanation of issue: > > >=20 > > > It is not realistic to assume that the QNI is able to know which=20 > > > network technologies (Diffserv, MPLS, Y.1541) are=20 > supported on the=20 > > > end-to-end path. > > > If the "QoS Class" parameter is considered to be a=20 > QSPEC-1 parameter=20 > > > then it will mean that all QNEs located on the end-to-end=20 > path must=20 > > > support the Diffserv and MPLS and > > Y.1541 technologies.=20 > > > This is unrealistic. > > >=20 > > > Requested change: > > > The parameter must be a QSPEC-2 parameter. > > >=20 > > >=20 > > >=20 > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > >=20 > > >=20 > >=20 > >=20 > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 17 04:59:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZkmN-0004ee-6Q; Tue, 17 Oct 2006 04:58:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZkmM-0004eZ-3E for nsis@ietf.org; Tue, 17 Oct 2006 04:58:30 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZkmF-0005Mv-4v for nsis@ietf.org; Tue, 17 Oct 2006 04:58:30 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CF9115BD; Tue, 17 Oct 2006 10:55:46 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 10:55:46 +0200 Received: from ericsson.com ([147.214.26.58]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 10:55:46 +0200 Message-ID: <45349A92.50403@ericsson.com> Date: Tue, 17 Oct 2006 10:55:46 +0200 From: Lars Westberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kappler, Cornelia" Subject: Re: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt References: In-Reply-To: X-OriginalArrivalTime: 17 Oct 2006 08:55:46.0168 (UTC) FILETIME=[08E6F780:01C6F1CA] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 7e267523e0685e5aa2dbbdde4b659686 Cc: gash@att.com, Georgios Karagiannis , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0937535707==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0937535707== Content-Type: multipart/alternative; boundary="------------060404070402050901050706" This is a multi-part message in MIME format. --------------060404070402050901050706 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit comments inline Kappler, Cornelia wrote: > Hi Lars, > > could you explain why the qspec draft defines a new bearer service? > let's define it as "Specification of the Controlled-Load Network Element Service" =>a specifiaction of treatment of a "flow". > What is a bearer service? This concept exists in 3GPP, but it does not > exist in IETF I dont think, and I dont think the 3GPP definition is > transferrable to IETF. So what exactly are you stating? > see above. > Cornelia > > ------------------------------------------------------------------------ > Von: Lars Westberg [mailto:Lars.westberg@ericsson.com] > Gesendet: Dienstag, 17. Oktober 2006 08:46 > An: Georgios Karagiannis > Cc: gash@att.com; nsis@ietf.org > Betreff: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt > > yes. > the main problem is that IETF is not the only Standardization > organization that like to discuss "bearer services". Just as an > example : > If we specify the those parameters, How can we use NSIS for SLAs > specified by MEF???? > > How can we use it for 3GPP-Qos definitiions ? > > > In the draft I also see that we the draft specify a new bearer > service. It is not compliant to old Int.serv architecture. This > is a completely new one with new parameters like priority. > > I can sure that we can have a never-ending discussion about the > "optimal"-set of parameters. > > I think we agree in beggining the working group discussion that we > should not specify any "bearer-service" because NSIS should be a > modular architecture with more flexibillity than RSVP. > Therefore, I am surprised that we are doing the same mistake as in > RSVP: Integrating a bearer service definition into the > NSIS-architecture. > > If we go this track, the QoS-part of NSIS has much less use. RSVP > is in this case significantly better in terms of performance and > have the same functionality than NSIS. > If have to choose I would select RSVP rather than a much more > complex three layer protocol stack. > > regards Lasse > > Georgios Karagiannis wrote: > >>Hi Lars >> >>Do you mean that the QSPEC template must not contain any mandatory >>(QSPEC-1) parameters? >> >> >>Best Regards, >>Georgios >> >> >> >>On 10/16/2006, "Lars Westberg" wrote: >> >> >> >>>Hi, >>>The template seems not to be a template because the mandatory part is >>>more or less the same as Intserv. >>>The main idea with QoS-template was to make an modular solution that >>>could allow flexibillity for different Qos-models >>> >>>Therefore, I do not understand the scope of the specification. >>> >>>I suggest that we move the major part of the parameters to a separate >>>"Int.serv. over NSIS" specification. >>>Int.serv. can be seen as a common bearer service. >>> >>>regards Lasse >>> >>>Ash, Gerald R (Jerry), ALABS wrote: >>> >>> >>> >>>>Lars, >>>> >>>> >>>> >>>>>You mention in the below e-mail that there are no open issues, >>>>>while there is a huge discussion on the nsis mailing list >>>>>regarding the QSPEC-1 parameters. >>>>> >>>>> >>>>John can call a different consensus if he sees one (I've asked him a >>>>couple of times to do that). What I saw was >>>> >>>>1. Many posts supported the QSPEC-1 concept, only one (or maybe two) I >>>>saw opposed. The opposing view was repeated *many* times (and is still >>>>being repeated) but it only counts as one opinion. >>>>2. Many posts supported retaining the 4 QSPEC-1 parameters, only one I >>>>saw opposed. The opposing view was repeated many times. >>>>3. There was only one opinion expressed to be able to ignore QSPEC-1 >>>>parameters. That one opinion has been repeated many times but it only >>>>counts as one opinion. >>>> >>>>John asked a while ago for new opinions on these issues, that would be >>>>good if there are any *new* opinions. We don't need to hear opinions >>>>repeated that we've seen so many times. >>>> >>>>I invite John once again to make a consensus call so we can move on >>>>here. I think it is time to make progress and stop repeating ourselves, >>>>we're not generating any new light in this rather endless discussion. >>>> >>>>Thanks, >>>>Jerry >>>> >>>> >>>> >> >> >> --------------060404070402050901050706 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit comments inline

Kappler, Cornelia wrote:
Hi Lars,
 
could you explain why the qspec draft defines a new bearer service?
 
let's define it as "Specification of the Controlled-Load Network Element Service"
=>a specifiaction of treatment of a "flow".
What is a bearer service? This concept exists in 3GPP, but it does not exist in IETF I dont think, and I dont think the 3GPP definition is transferrable to IETF. So what exactly are you stating?
 
see above.
Cornelia

Von: Lars Westberg [mailto:Lars.westberg@ericsson.com]
Gesendet: Dienstag, 17. Oktober 2006 08:46
An: Georgios Karagiannis
Cc: gash@att.com; nsis@ietf.org
Betreff: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

yes.
the main problem is that IETF is not the only Standardization organization that like to discuss "bearer services". Just as an example :
If we specify the those parameters, How can we use NSIS for SLAs specified by MEF????

How can we use it for 3GPP-Qos definitiions ?


In the draft I also see  that we the draft specify a new bearer service. It is not compliant to old Int.serv architecture.  This is a completely new one with new parameters like priority.

I can sure that we can have a never-ending discussion about the "optimal"-set of parameters.

I think we agree in beggining the working group discussion that we should not specify any "bearer-service" because NSIS should be a modular architecture with  more flexibillity than RSVP.  Therefore, I am surprised that we are doing the same mistake as in RSVP: Integrating a bearer service definition into the NSIS-architecture.

If we go this track, the QoS-part of NSIS has much less use. RSVP is in this case significantly better in terms of performance and have the same functionality than NSIS.
If have to choose I would select RSVP rather than a much more complex  three layer protocol stack.

regards Lasse

Georgios Karagiannis wrote:
Hi Lars

Do you mean that the QSPEC template must not contain any mandatory
(QSPEC-1) parameters?


Best Regards,
Georgios



On 10/16/2006, "Lars Westberg" <Lars.westberg@ericsson.com> wrote:

  
Hi,
The template seems not to be a template because the mandatory part  is
more or less the same as Intserv.
The main idea with QoS-template was to make an modular solution that
could allow flexibillity for different Qos-models

Therefore, I do not understand the scope of the specification.

I suggest that we move the major part of the parameters to a separate
"Int.serv. over NSIS" specification.
Int.serv. can be seen as a common bearer service.

regards Lasse

Ash, Gerald R (Jerry), ALABS wrote:

    
Lars,

      
You mention in the below e-mail that there are no open issues,
while there is a huge discussion on the nsis mailing list
regarding the QSPEC-1 parameters.
        
John can call a different consensus if he sees one (I've asked him a
couple of times to do that).  What I saw was

1. Many posts supported the QSPEC-1 concept, only one (or maybe two) I
saw opposed.  The opposing view was repeated *many* times (and is still
being repeated) but it only counts as one opinion.
2. Many posts supported retaining the 4 QSPEC-1 parameters, only one I
saw opposed.  The opposing view was repeated many times.
3. There was only one opinion expressed to be able to ignore QSPEC-1
parameters.  That one opinion has been repeated many times but it only
counts as one opinion.

John asked a while ago for new opinions on these issues, that would be
good if there are any *new* opinions.  We don't need to hear opinions
repeated that we've seen so many times.

I invite John once again to make a consensus call so we can move on
here.  I think it is time to make progress and stop repeating ourselves,
we're not generating any new light in this rather endless discussion.

Thanks,
Jerry
--------------060404070402050901050706-- --===============0937535707== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0937535707==-- From nsis-bounces@ietf.org Tue Oct 17 05:11:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZkxv-0002iY-WE; Tue, 17 Oct 2006 05:10:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZkxu-0002iS-Co for nsis@ietf.org; Tue, 17 Oct 2006 05:10:26 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZkxq-0007UP-OQ for nsis@ietf.org; Tue, 17 Oct 2006 05:10:26 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k9H99Wuf028171; Tue, 17 Oct 2006 10:09:32 +0100 Received: from victor ([193.118.192.66]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 10:09:32 +0100 From: "Robert Hancock" To: "'Lars Westberg \(KI/EAB\)'" , "'Roland Bless'" Subject: RE: [NSIS] messages content Date: Tue, 17 Oct 2006 11:09:50 +0200 Message-ID: <005301c6f1cc$00bce680$946b0a0a@comm.ad.roke.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <0CDAE977A7172A40A2A3A1C20C12BD650488B0C6@esealmw106.eemea.ericsson.se> Importance: Normal X-OriginalArrivalTime: 17 Oct 2006 09:09:32.0579 (UTC) FILETIME=[F57B4730:01C6F1CB] X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org lars, if you want examples, then the handshake is in section 4.4.1 just listing the message objects, and an example with textual versions of the fields is in appendix C. if you want to understand the basic concepts, read section 3. if you want something else, please say what it is. cheers, robert h. > -----Original Message----- > From: Lars Westberg (KI/EAB) [mailto:lars.westberg@ericsson.com] > Sent: 17 October 2006 09:52 > To: Roland Bless > Cc: nsis@ietf.org; Hancock, Robert > Subject: RE: [NSIS] messages content > > > comments inline > > -----Original Message----- > From: Roland Bless [mailto:bless@tm.uka.de] > Sent: den 17 oktober 2006 09:46 > To: Lars Westberg (KI/EAB) > Cc: nsis@ietf.org; Hancock, Robert > Subject: Re: [NSIS] messages content > > Hi Lars, > > Lars Westberg wrote: > > I have looked through the documet and it's very difficult to > > interprete the all statements. It is too many options an > features in > > the the specification. > > It's somewhat complex, but implementable. A student of mine > was able to do a full implementation within 6 months. > > I do not have six-months to spend of it. I would rather > prefer a fast-track solution. > > > I am after examples of message structures and sequence diagram so I > > can verify my assumptions. > > I would be very happy if someone can help me with such information. > > Protocol state machines are in Chapter 6 (see p. 62 and 65) > and message structures in Chapter 5. If this doesn't help you > may ask your question on the list. > > I can't all questions on the list. I would rather appreciate > an example implementation of it with message shown in > text-format. Does the implementation showing the messages in text ?? > > If so, I am interested in it. Is it possible to get a copy ??? > > Regards, > Roland > > -Lasse > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 17 05:24:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZlAZ-0004JF-Sb; Tue, 17 Oct 2006 05:23:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZlAY-0004J9-Uy for nsis@ietf.org; Tue, 17 Oct 2006 05:23:30 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZlAU-0001nY-4N for nsis@ietf.org; Tue, 17 Oct 2006 05:23:30 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5DFBF4F0001; Tue, 17 Oct 2006 11:23:23 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 11:23:22 +0200 Received: from ericsson.com ([147.214.26.58]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 11:23:22 +0200 Message-ID: <4534A10A.1050708@ericsson.com> Date: Tue, 17 Oct 2006 11:23:22 +0200 From: Lars Westberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kappler, Cornelia" Subject: Re: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt References: In-Reply-To: X-OriginalArrivalTime: 17 Oct 2006 09:23:22.0672 (UTC) FILETIME=[E4416B00:01C6F1CD] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 Cc: "Ash, Gerald R \(Jerry\), ALABS" , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0399066902==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0399066902== Content-Type: multipart/alternative; boundary="------------080101020405090208020406" This is a multi-part message in MIME format. --------------080101020405090208020406 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit first of all, the specification defines a lot of parameters that have never ben discussed in Int-serv (not as far as I know) like Priority. I do not know about any of these in the history of Controlled Load. All of these parameters can be put in another specification. the DSCP is not a part of IntServ-architecture because is is added afterwards. If we should add those, why not re-use the DCLASS-object??? Why specify a new one ???? I am confused. We are re-specifying objects for something that have already been specified before and we insert new parameters that make the specification les usefull in other context. I thought that NSIS should be applicable for future use where RSVP can not handle the modularity. I suggest that we divide the template into two parts: one template and one specification for "IntServ over NSIS". If this is not be done, I do not see how we can handle Metroethernetforums parameters set in MEF7. check http://www.metroethernetforum.org/TechSpec.htm. regards Lasse Kappler, Cornelia wrote: > Hi Lars, > > what you call "mandatory" does _overlap_ with IntServ because this was > the WG requirement when we started the QSPEC work. If the WG removes > this requirement we can remove these parameter(s). > > Note that we in fact included just _one_ out of about six IntServ > parameters, namely the Token Bucket. Most IntServ paras (C_tot, D_tot, > S etc) are not included (at least not in the interesting qspec-1 > parameter category). > > So anyway I dont think your statement is correct. > > Cornelia > > ------------------------------------------------------------------------ > Von: Lars Westberg [mailto:Lars.westberg@ericsson.com] > Gesendet: Montag, 16. Oktober 2006 11:52 > An: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org > Betreff: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt > > Hi, > The template seems not to be a template because the mandatory > part is more or less the same as Intserv. > The main idea with QoS-template was to make an modular solution > that could allow flexibillity for different Qos-models > > Therefore, I do not understand the scope of the specification. > > I suggest that we move the major part of the parameters to a > separate "Int.serv. over NSIS" specification. > Int.serv. can be seen as a common bearer service. > > regards Lasse > > Ash, Gerald R (Jerry), ALABS wrote: > >> Lars, >> >> > You mention in the below e-mail that there are no open issues, >> > while there is a huge discussion on the nsis mailing list >> > regarding the QSPEC-1 parameters. >> >> John can call a different consensus if he sees one (I've asked him a >> couple of times to do that). What I saw was >> >> 1. Many posts supported the QSPEC-1 concept, only one (or maybe >> two) I >> saw opposed. The opposing view was repeated *many* times (and is >> still >> being repeated) but it only counts as one opinion. >> 2. Many posts supported retaining the 4 QSPEC-1 parameters, only >> one I >> saw opposed. The opposing view was repeated many times. >> 3. There was only one opinion expressed to be able to ignore QSPEC-1 >> parameters. That one opinion has been repeated many times but it >> only >> counts as one opinion. >> >> John asked a while ago for new opinions on these issues, that >> would be >> good if there are any *new* opinions. We don't need to hear opinions >> repeated that we've seen so many times. >> >> I invite John once again to make a consensus call so we can move on >> here. I think it is time to make progress and stop repeating >> ourselves, >> we're not generating any new light in this rather endless discussion. >> >> Thanks, >> Jerry >> --------------080101020405090208020406 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit first of all, the specification defines a lot of parameters that have never ben discussed in Int-serv (not as far as I know) like Priority. I do not know about any of these in the history of Controlled Load. All of these parameters can be put in another specification.

the DSCP is not a part of IntServ-architecture because is is added afterwards. If we should add those, why not re-use the DCLASS-object???
Why specify a new one ????

I am confused. We are re-specifying objects for something that have already been specified before and we insert new parameters that make the specification les usefull in other context. I thought that NSIS should be applicable for future use where RSVP can not handle the modularity.

I suggest that we divide the template into two parts: one template and one specification for "IntServ over NSIS".
If this is not be done, I do not see how we can handle Metroethernetforums parameters set in MEF7.
check http://www.metroethernetforum.org/TechSpec.htm.

regards Lasse
Kappler, Cornelia wrote:
Hi Lars,
 
what you call "mandatory" does _overlap_ with IntServ because this was the WG requirement when we started the QSPEC work. If the WG removes this requirement we can remove these parameter(s).
 
Note that we in fact included just _one_ out of about six IntServ parameters, namely the Token Bucket. Most IntServ paras (C_tot, D_tot, S etc) are not included (at least not in the interesting qspec-1 parameter category).
 
So anyway I dont think your statement is correct.
 
Cornelia

Von: Lars Westberg [mailto:Lars.westberg@ericsson.com]
Gesendet: Montag, 16. Oktober 2006 11:52
An: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org
Betreff: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

Hi,
 The template seems not to be a template because the mandatory part  is more or less the same as Intserv.
The main idea with QoS-template was to make an modular solution that could allow flexibillity for different Qos-models

Therefore, I do not understand the scope of the specification.

I suggest that we move the major part of the parameters to a separate "Int.serv. over NSIS" specification.
Int.serv. can be seen as a common bearer service.

regards Lasse

Ash, Gerald R (Jerry), ALABS wrote:

Lars,

> You mention in the below e-mail that there are no open issues,
> while there is a huge discussion on the nsis mailing list
> regarding the QSPEC-1 parameters.

John can call a different consensus if he sees one (I've asked him a
couple of times to do that).  What I saw was

1. Many posts supported the QSPEC-1 concept, only one (or maybe two) I
saw opposed.  The opposing view was repeated *many* times (and is still
being repeated) but it only counts as one opinion.
2. Many posts supported retaining the 4 QSPEC-1 parameters, only one I
saw opposed.  The opposing view was repeated many times.
3. There was only one opinion expressed to be able to ignore QSPEC-1
parameters.  That one opinion has been repeated many times but it only
counts as one opinion.

John asked a while ago for new opinions on these issues, that would be
good if there are any *new* opinions.  We don't need to hear opinions
repeated that we've seen so many times.

I invite John once again to make a consensus call so we can move on
here.  I think it is time to make progress and stop repeating ourselves,
we're not generating any new light in this rather endless discussion.

Thanks,
Jerry

--------------080101020405090208020406-- --===============0399066902== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0399066902==-- From nsis-bounces@ietf.org Tue Oct 17 05:25:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZlCB-0007Xj-VX; Tue, 17 Oct 2006 05:25:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZlCA-0007Oe-ID for nsis@ietf.org; Tue, 17 Oct 2006 05:25:10 -0400 Received: from emailer.gwdg.de ([134.76.10.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZlC4-00023w-16 for nsis@ietf.org; Tue, 17 Oct 2006 05:25:10 -0400 Received: from [218.80.168.246] (helo=[192.168.1.62]) by mailer.gwdg.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1GZlAD-0001zw-VO; Tue, 17 Oct 2006 11:23:11 +0200 Message-ID: <4534A0EC.5010603@cs.uni-goettingen.de> Date: Tue, 17 Oct 2006 11:22:52 +0200 From: Xiaoming Fu Organization: University of Goettingen, Germany User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Georgios Karagiannis Subject: Re: [NSIS] QSPEC-issue (GK-2) References: <002d01c6f1ca$46a564d0$4c0d5982@dynamic.ewi.utwente.nl> In-Reply-To: <002d01c6f1ca$46a564d0$4c0d5982@dynamic.ewi.utwente.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Authenticated-Id: xfu X-Virus-Scanned: (clean) by exiscan+sophie X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: nsis@ietf.org, "'Kappler, Cornelia'" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org i share the same oppinion as georgios. xiaoming Georgios Karagiannis wrote: > Hi Cornelia > > This is not possible! > How a QNE will know how to map a PHB class into a Y.1541 class? > It is impossible to come up with a reasonable mapping. > > The only solution on this is to mandate that all QNEs implement Diffserv and > MPLS and Y.1541. > In this way NSIS will never be used and deployed. > > Best regards, > Georgios > > >> -----Original Message----- >> From: Kappler, Cornelia [mailto:cornelia.kappler@siemens.com] >> Sent: dinsdag 17 oktober 2006 10:52 >> To: Hannes Tschofenig; Georgios Karagiannis >> Cc: nsis@ietf.org >> Subject: AW: [NSIS] QSPEC-issue (GK-2) >> >> Hi Georgios and Hannes, >> >> see my previous post regarding how to handle these parameters in CL. >> >> The proposal for CL is that a CL QNE has an algorithm that >> tells it which QoS Class parameters are "high class" and >> whcih are "low class". If they are high class, they will >> receive CL treatment. If they are low class, they receive >> best effort. >> >> This way QSPECs based on "QoS Class" QOSMs get as reasonable >> a treatment as one can expect, and at the same time I dont >> see a CL QNE being overburdened by this task. >> >> Cornelia >> >>> -----Ursprüngliche Nachricht----- >>> Von: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>> Gesendet: Mittwoch, 11. Oktober 2006 21:05 >>> An: Georgios Karagiannis >>> Cc: nsis@ietf.org >>> Betreff: Re: [NSIS] QSPEC-issue (GK-2) >>> >>> I support Georgios. >>> >>> I think it is unrealistic to assume that Y.1541 and DSTE >> behavior (as >>> required for strictly interpreting these parameters) is >> implemented in >>> every QNE. >>> >>> Ciao >>> Hannes >>> >>> Georgios Karagiannis schrieb: >>>> Description of issue >>>> Change to QSPEC-2 parameter >>>> >>>> >>>> Submitter name: Georgios Karagiannis Submitter email address: >>>> karagian@cs.utwente.nl Date first >>> submitted: >>>> 11.10.2006 >>>> Reference: >>>> Comment type: T >>>> Priority: 'S' >>>> Section: Various >>>> Rationale/Explanation of issue: >>>> >>>> It is not realistic to assume that the QNI is able to know which >>>> network technologies (Diffserv, MPLS, Y.1541) are >> supported on the >>>> end-to-end path. >>>> If the "QoS Class" parameter is considered to be a >> QSPEC-1 parameter >>>> then it will mean that all QNEs located on the end-to-end >> path must >>>> support the Diffserv and MPLS and >>> Y.1541 technologies. >>>> This is unrealistic. >>>> >>>> Requested change: >>>> The parameter must be a QSPEC-2 parameter. >>>> >>>> >>>> >>>> _______________________________________________ >>>> nsis mailing list >>>> nsis@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/nsis >>>> >>>> >>> >>> _______________________________________________ >>> nsis mailing list >>> nsis@ietf.org >>> https://www1.ietf.org/mailman/listinfo/nsis >>> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis >> > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis -- Cheers, Xiaoming -- http://user.informatik.uni-goettingen.de/~fu _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 17 05:29:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZlFc-00087g-Fp; Tue, 17 Oct 2006 05:28:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZlFb-00087b-7N for nsis@ietf.org; Tue, 17 Oct 2006 05:28:43 -0400 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZlFZ-0002iF-Lp for nsis@ietf.org; Tue, 17 Oct 2006 05:28:43 -0400 Received: from mail3.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id k9H9Sapk027661; Tue, 17 Oct 2006 11:28:36 +0200 Received: from mchp7wta.ww002.siemens.net (mchp7wta.ww002.siemens.net [139.25.131.193]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id k9H9SaFm013868; Tue, 17 Oct 2006 11:28:36 +0200 Received: from blns00fa.ww002.siemens.net ([147.54.45.102]) by mchp7wta.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 11:28:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [NSIS] QSPEC-issue (GK-2) Date: Tue, 17 Oct 2006 11:28:34 +0200 Message-ID: In-Reply-To: <002d01c6f1ca$46a564d0$4c0d5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QSPEC-issue (GK-2) Thread-Index: AcbtanD6fn22GI49QTOs4tcmcnPXswEXnjhgAABCSLAAAPaEgA== From: "Kappler, Cornelia" To: "Georgios Karagiannis" , "Hannes Tschofenig" X-OriginalArrivalTime: 17 Oct 2006 09:28:35.0904 (UTC) FILETIME=[9EF4D400:01C6F1CE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Georgios,=20 it is a matter of interpreting what "reasonable mapping" means.=20 For me, reasonable means that (i) the original idea of the parameter = value should be preserved as much as possible, but on (ii) a QNE = implementing a different set of paraemeters (QOSM) should not be = burdened with too much knowledge / processing that is outside its own = QOSM. Regarding CLS I gave a possible answer balancing (i) and (ii) which is = deployable (in fact it is quite simple). I cannot answer how to map PHB class into Y.1541 class since I am not an = expert in this. =20 Cornelia=20 > -----Urspr=FCngliche Nachricht----- > Von: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 > Gesendet: Dienstag, 17. Oktober 2006 10:57 > An: Kappler, Cornelia; 'Hannes Tschofenig' > Cc: nsis@ietf.org > Betreff: RE: [NSIS] QSPEC-issue (GK-2) >=20 > Hi Cornelia >=20 > This is not possible! > How a QNE will know how to map a PHB class into a Y.1541 class? > It is impossible to come up with a reasonable mapping. >=20 > The only solution on this is to mandate that all QNEs=20 > implement Diffserv and > MPLS and Y.1541. > In this way NSIS will never be used and deployed. >=20 > Best regards, > Georgios >=20 >=20 > > -----Original Message----- > > From: Kappler, Cornelia [mailto:cornelia.kappler@siemens.com]=20 > > Sent: dinsdag 17 oktober 2006 10:52 > > To: Hannes Tschofenig; Georgios Karagiannis > > Cc: nsis@ietf.org > > Subject: AW: [NSIS] QSPEC-issue (GK-2) > >=20 > > Hi Georgios and Hannes,=20 > >=20 > > see my previous post regarding how to handle these=20 > parameters in CL.=20 > >=20 > > The proposal for CL is that a CL QNE has an algorithm that=20 > > tells it which QoS Class parameters are "high class" and=20 > > whcih are "low class". If they are high class, they will=20 > > receive CL treatment. If they are low class, they receive=20 > > best effort.=20 > >=20 > > This way QSPECs based on "QoS Class" QOSMs get as reasonable=20 > > a treatment as one can expect, and at the same time I dont=20 > > see a CL QNE being overburdened by this task. > >=20 > > Cornelia=20 > >=20 > > > -----Urspr=FCngliche Nachricht----- > > > Von: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > Gesendet: Mittwoch, 11. Oktober 2006 21:05 > > > An: Georgios Karagiannis > > > Cc: nsis@ietf.org > > > Betreff: Re: [NSIS] QSPEC-issue (GK-2) > > >=20 > > > I support Georgios. > > >=20 > > > I think it is unrealistic to assume that Y.1541 and DSTE=20 > > behavior (as=20 > > > required for strictly interpreting these parameters) is=20 > > implemented in=20 > > > every QNE. > > >=20 > > > Ciao > > > Hannes > > >=20 > > > Georgios Karagiannis schrieb: > > > > Description of issue > > > > Change to QSPEC-2 parameter > > > >=20 > > > >=20 > > > > Submitter name: Georgios Karagiannis Submitter email address:=20 > > > > karagian@cs.utwente.nl Date first > > > submitted: > > > > 11.10.2006 > > > > Reference: =20 > > > > Comment type: T > > > > Priority: 'S' > > > > Section: Various > > > > Rationale/Explanation of issue: > > > >=20 > > > > It is not realistic to assume that the QNI is able to=20 > know which=20 > > > > network technologies (Diffserv, MPLS, Y.1541) are=20 > > supported on the=20 > > > > end-to-end path. > > > > If the "QoS Class" parameter is considered to be a=20 > > QSPEC-1 parameter=20 > > > > then it will mean that all QNEs located on the end-to-end=20 > > path must=20 > > > > support the Diffserv and MPLS and > > > Y.1541 technologies.=20 > > > > This is unrealistic. > > > >=20 > > > > Requested change: > > > > The parameter must be a QSPEC-2 parameter. > > > >=20 > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > nsis mailing list > > > > nsis@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > >=20 > > > >=20 > > >=20 > > >=20 > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > >=20 > >=20 > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > >=20 >=20 >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 17 05:34:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZlKL-00048b-6a; Tue, 17 Oct 2006 05:33:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZlKJ-00048S-Ia for nsis@ietf.org; Tue, 17 Oct 2006 05:33:35 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZlKI-0003rh-0b for nsis@ietf.org; Tue, 17 Oct 2006 05:33:35 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k9H9XNiU018058; Tue, 17 Oct 2006 11:33:27 +0200 (MEST) From: "Georgios Karagiannis" To: "'Kappler, Cornelia'" , "'Hannes Tschofenig'" Subject: RE: [NSIS] QSPEC-issue (GK-2) Date: Tue, 17 Oct 2006 11:33:20 +0200 Message-ID: <004801c6f1cf$4b60b0b0$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcbtanD6fn22GI49QTOs4tcmcnPXswEXnjhgAABCSLAAAPaEgAAAPjkQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: -5.535 () ALL_TRUSTED,AWL,BAYES_00,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Tue, 17 Oct 2006 11:33:30 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Cornelia The reasonable maping can only be accomplished between: Token Bucket (peak rate) =3D> Bandwidth Higher (than normal) priority =3D> Normal priority Lower (than normal) priority =3D> Normal priority In my opinion other types of remappings (of other parameters)=20 are either impossible or useless! Best Regards, Georgios > -----Original Message----- > From: Kappler, Cornelia [mailto:cornelia.kappler@siemens.com]=20 > Sent: dinsdag 17 oktober 2006 11:29 > To: Georgios Karagiannis; Hannes Tschofenig > Cc: nsis@ietf.org > Subject: AW: [NSIS] QSPEC-issue (GK-2) >=20 > Hi Georgios,=20 >=20 > it is a matter of interpreting what "reasonable mapping" means.=20 >=20 > For me, reasonable means that (i) the original idea of the=20 > parameter value should be preserved as much as possible, but=20 > on (ii) a QNE implementing a different set of paraemeters=20 > (QOSM) should not be burdened with too much knowledge /=20 > processing that is outside its own QOSM. >=20 > Regarding CLS I gave a possible answer balancing (i) and (ii)=20 > which is deployable (in fact it is quite simple). >=20 > I cannot answer how to map PHB class into Y.1541 class since=20 > I am not an expert in this. =20 >=20 > Cornelia=20 >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > Gesendet: Dienstag, 17. Oktober 2006 10:57 > > An: Kappler, Cornelia; 'Hannes Tschofenig' > > Cc: nsis@ietf.org > > Betreff: RE: [NSIS] QSPEC-issue (GK-2) > >=20 > > Hi Cornelia > >=20 > > This is not possible! > > How a QNE will know how to map a PHB class into a Y.1541 class? > > It is impossible to come up with a reasonable mapping. > >=20 > > The only solution on this is to mandate that all QNEs implement=20 > > Diffserv and MPLS and Y.1541. > > In this way NSIS will never be used and deployed. > >=20 > > Best regards, > > Georgios > >=20 > >=20 > > > -----Original Message----- > > > From: Kappler, Cornelia [mailto:cornelia.kappler@siemens.com] > > > Sent: dinsdag 17 oktober 2006 10:52 > > > To: Hannes Tschofenig; Georgios Karagiannis > > > Cc: nsis@ietf.org > > > Subject: AW: [NSIS] QSPEC-issue (GK-2) > > >=20 > > > Hi Georgios and Hannes, > > >=20 > > > see my previous post regarding how to handle these > > parameters in CL.=20 > > >=20 > > > The proposal for CL is that a CL QNE has an algorithm=20 > that tells it=20 > > > which QoS Class parameters are "high class" and whcih are "low=20 > > > class". If they are high class, they will receive CL=20 > treatment. If=20 > > > they are low class, they receive best effort. > > >=20 > > > This way QSPECs based on "QoS Class" QOSMs get as reasonable a=20 > > > treatment as one can expect, and at the same time I dont see a CL=20 > > > QNE being overburdened by this task. > > >=20 > > > Cornelia > > >=20 > > > > -----Urspr=FCngliche Nachricht----- > > > > Von: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > > Gesendet: Mittwoch, 11. Oktober 2006 21:05 > > > > An: Georgios Karagiannis > > > > Cc: nsis@ietf.org > > > > Betreff: Re: [NSIS] QSPEC-issue (GK-2) > > > >=20 > > > > I support Georgios. > > > >=20 > > > > I think it is unrealistic to assume that Y.1541 and DSTE > > > behavior (as > > > > required for strictly interpreting these parameters) is > > > implemented in > > > > every QNE. > > > >=20 > > > > Ciao > > > > Hannes > > > >=20 > > > > Georgios Karagiannis schrieb: > > > > > Description of issue > > > > > Change to QSPEC-2 parameter > > > > >=20 > > > > >=20 > > > > > Submitter name: Georgios Karagiannis Submitter email address:=20 > > > > > karagian@cs.utwente.nl Date first > > > > submitted: > > > > > 11.10.2006 > > > > > Reference: =20 > > > > > Comment type: T > > > > > Priority: 'S' > > > > > Section: Various > > > > > Rationale/Explanation of issue: > > > > >=20 > > > > > It is not realistic to assume that the QNI is able to > > know which > > > > > network technologies (Diffserv, MPLS, Y.1541) are > > > supported on the > > > > > end-to-end path. > > > > > If the "QoS Class" parameter is considered to be a > > > QSPEC-1 parameter > > > > > then it will mean that all QNEs located on the end-to-end > > > path must > > > > > support the Diffserv and MPLS and > > > > Y.1541 technologies.=20 > > > > > This is unrealistic. > > > > >=20 > > > > > Requested change: > > > > > The parameter must be a QSPEC-2 parameter. > > > > >=20 > > > > >=20 > > > > >=20 > > > > > _______________________________________________ > > > > > nsis mailing list > > > > > nsis@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > >=20 > > > > >=20 > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > nsis mailing list > > > > nsis@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > >=20 > > >=20 > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 17 05:38:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZlOJ-0005X8-OA; Tue, 17 Oct 2006 05:37:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZlOI-0005X2-Lp for nsis@ietf.org; Tue, 17 Oct 2006 05:37:42 -0400 Received: from emailer.gwdg.de ([134.76.10.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZlOD-0004gY-6i for nsis@ietf.org; Tue, 17 Oct 2006 05:37:42 -0400 Received: from [218.80.168.246] (helo=[192.168.1.62]) by mailer.gwdg.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1GZlO3-00053J-UZ; Tue, 17 Oct 2006 11:37:28 +0200 Message-ID: <4534A44D.6030506@cs.uni-goettingen.de> Date: Tue, 17 Oct 2006 11:37:17 +0200 From: Xiaoming Fu Organization: University of Goettingen, Germany User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Lars Westberg (KI/EAB)" Subject: Re: [NSIS] messages content References: <0CDAE977A7172A40A2A3A1C20C12BD650488B0C6@esealmw106.eemea.ericsson.se> In-Reply-To: <0CDAE977A7172A40A2A3A1C20C12BD650488B0C6@esealmw106.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-Id: xfu X-Virus-Scanned: (clean) by exiscan+sophie X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: Roland Bless , nsis@ietf.org, "Hancock, Robert" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi lars, according to our experience, a state machine based description helps towards an easy implementation and maintenance. we have implemented the ntlp according to the fsm specified in http://tools.ietf.org/wg/nsis/draft-ietf-nsis-ntlp-statemachine/ more implementation-specific guidelines are planned to be provided in a few update of the doc. as you might know, the code is available at http://user.informatik.uni-goettingen.de/~nsis/ cheers, xiaoming Lars Westberg (KI/EAB) wrote: > comments inline > > -----Original Message----- > From: Roland Bless [mailto:bless@tm.uka.de] > Sent: den 17 oktober 2006 09:46 > To: Lars Westberg (KI/EAB) > Cc: nsis@ietf.org; Hancock, Robert > Subject: Re: [NSIS] messages content > > Hi Lars, > > Lars Westberg wrote: >> I have looked through the documet and it's very difficult to >> interprete the all statements. It is too many options an features in >> the the specification. > > It's somewhat complex, but implementable. A student of mine was able to > do a full implementation within 6 months. > > I do not have six-months to spend of it. I would rather prefer a > fast-track solution. > >> I am after examples of message structures and sequence diagram so I >> can verify my assumptions. >> I would be very happy if someone can help me with such information. > > Protocol state machines are in Chapter 6 (see p. 62 and 65) and message > structures in Chapter 5. If this doesn't help you may ask your question > on the list. > > I can't all questions on the list. I would rather appreciate an example > implementation of it with message shown in text-format. Does the > implementation showing the messages in text ?? > > If so, I am interested in it. Is it possible to get a copy ??? > > Regards, > Roland > > -Lasse > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis -- Cheers, Xiaoming -- http://user.informatik.uni-goettingen.de/~fu _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 17 05:55:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZleL-0000sl-AG; Tue, 17 Oct 2006 05:54:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZleK-0000sg-EW for nsis@ietf.org; Tue, 17 Oct 2006 05:54:16 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZleI-0008EH-UE for nsis@ietf.org; Tue, 17 Oct 2006 05:54:16 -0400 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1GZle6-0000kz-Ks; Tue, 17 Oct 2006 11:54:03 +0200 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1GZle6-0003HP-3L; Tue, 17 Oct 2006 11:54:02 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id B059A881E; Tue, 17 Oct 2006 11:54:00 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1GZle4-0004Qv-Cy; Tue, 17 Oct 2006 11:54:00 +0200 Message-ID: <4534A837.8010606@tm.uka.de> Date: Tue, 17 Oct 2006 11:53:59 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: "Lars Westberg (KI/EAB)" Subject: Re: [NSIS] messages content References: <0CDAE977A7172A40A2A3A1C20C12BD650488B0C6@esealmw106.eemea.ericsson.se> In-Reply-To: <0CDAE977A7172A40A2A3A1C20C12BD650488B0C6@esealmw106.eemea.ericsson.se> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.1 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.3 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: nsis@ietf.org, "Hancock, Robert" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Lars, Lars Westberg (KI/EAB) wrote: > comments inline dito >> It's somewhat complex, but implementable. A student of mine was able to >> do a full implementation within 6 months. > > I do not have six-months to spend of it. I would rather prefer a > fast-track solution. I guess you don't need 6 months to read and understand the spec, I meant a full implementation including writing and testing the code. >> I am after examples of message structures and sequence diagram so I >> can verify my assumptions. >> I would be very happy if someone can help me with such information. > > Protocol state machines are in Chapter 6 (see p. 62 and 65) and message > structures in Chapter 5. If this doesn't help you may ask your question > on the list. > > I can't all questions on the list. I would rather appreciate an example > implementation of it with message shown in text-format. Does the > implementation showing the messages in text ?? Yep, e.g.: an incoming connection with query/response/confirm (C-Mode setup) may look like this: 2006-10-13 14:10:43.626-20911- EVENT /4: GIST Processing Received message #5 (SigInd) from: Signaling, signaling peer: 193.136.212.219, PDU: : NSLP ID: 1 Message Routing Information : (0) MRM-ID: IP-Version: 4 Flags: PAB Source Address: 193.136.212.219 Destination Address: 193.136.212.216 Source Prefixlen: 27 Destination Prefixlen: 27 IP-Protocol: udp Destination Port: 8080 Source Port: 8080 Direction: Downstream SessionID : 666f6f62-61727769-62626c65-00000000 NLI : (0) PI length: 4 IP_TTL: 0 IP_Version: 4 RSV_Time: 150000 PI: IF_Address: 193.136.212.219 Query Cookie : <0x517565727920436f6f6b69652066726f6d20616631000000> StackProposal Profiles: 1 1 MA fields: <1> StackConfigurationData Profiles: 1 MA-Hold Time: 10000 ms Protocol: 1 Profile: 0 Configuration Data: ---------------------------------------------------------------------------- 2006-10-13 14:10:43.640-20911- DEBUG /4: GIST Signaling Sending: : NSLP ID: 1 Message Routing Information : (0) MRM-ID: IP-Version: 4 Flags: PABD Source Address: 193.136.212.219 Destination Address: 193.136.212.216 Source Prefixlen: 27 Destination Prefixlen: 27 IP-Protocol: udp Destination Port: 8080 Source Port: 8080 Direction: Upstream SessionID : 666f6f62-61727769-62626c65-00000000 NLI : (0) PI length: 16 IP_TTL: 0 IP_Version: 4 RSV_Time: 60000 PI: IF_Address: 193.136.212.216 Query Cookie : <0x517565727920436f6f6b69652066726f6d20616631000000> Responder Cookie : <0x31850f42b79f123151eac346592934685ab8ef5772b0112f> StackProposal Profiles: 2 1 MA fields: <1> 2 MA fields: <2> <1> StackConfigurationData Profiles: 2 MA-Hold Time: 180000 ms Protocol: 1 Profile: 1 Configuration Data: <75> <30> (30000) Protocol: 1 Profile: 2 Configuration Data: <75> <31> (30001) -------------------------------------------------------------------- 2006-10-13 14:10:43.748-20911- EVENT /4: GIST Processing Received message #12 (SigInd) from: Signaling, signaling peer: ::ffff:193.136.212.219, PDU: : Message Routing Information : (0) MRM-ID: IP-Version: 4 Flags: PAB Source Address: 193.136.212.219 Destination Address: 193.136.212.216 Source Prefixlen: 27 Destination Prefixlen: 27 IP-Protocol: udp Destination Port: 8080 Source Port: 8080 Direction: Downstream SessionID : 666f6f62-61727769-62626c65-00000000 NLI : (0) PI length: 4 IP_TTL: 0 IP_Version: 4 RSV_Time: 150000 PI: IF_Address: 193.136.212.219 Responder Cookie : <0x31850f42b79f123151eac346592934685ab8ef5772b0112f> StackProposal Profiles: 2 1 MA fields: <1> 2 MA fields: <2> <1> StackConfigurationData Profiles: 0 MA-Hold Time: 10000 ms ----------------------------------------------------------------- > If so, I am interested in it. Is it possible to get a copy ??? I can sent you a full copy of our log output from one of our recent interop-tests if that helps. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 17 05:58:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZlhM-0003Gm-TL; Tue, 17 Oct 2006 05:57:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZlhL-0003Gc-MD for nsis@ietf.org; Tue, 17 Oct 2006 05:57:23 -0400 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZlhK-0000G1-RS for nsis@ietf.org; Tue, 17 Oct 2006 05:57:23 -0400 Received: from mail1.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id k9H9vFjq029204; Tue, 17 Oct 2006 11:57:15 +0200 Received: from mchp771a.ww002.siemens.net (mchp771a.ww002.siemens.net [139.25.131.189]) by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id k9H9vEdY027841; Tue, 17 Oct 2006 11:57:15 +0200 Received: from blns00fa.ww002.siemens.net ([147.54.45.102]) by mchp771a.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 11:57:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Date: Tue, 17 Oct 2006 11:57:13 +0200 Message-ID: In-Reply-To: <45349A92.50403@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Thread-Index: Acbxymmrqi77gQSmQ4Ode5w+MSLtVgAB0MyA From: "Kappler, Cornelia" To: "Lars Westberg" X-OriginalArrivalTime: 17 Oct 2006 09:57:14.0804 (UTC) FILETIME=[9F802740:01C6F1D2] X-Spam-Score: 0.1 (/) X-Scan-Signature: 94962611154c8404498b19f744990308 Cc: gash@att.com, Georgios Karagiannis , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0511717368==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0511717368== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F1D2.9F12B93C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F1D2.9F12B93C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Lasse, =20 "specification of treatment of a flow" should be done in the QOSM Specs (e.g. RMD, CLS), it is not at an issue of the QSPEC.=20 =20 The job of the QSPEC draft is to define a set of parameters that QOSM specs can choose from to define this treatment. (Would you agree this is a reasonable approach?) =20 Could you more concretely point out where in the QSPEC a specific flow treatment is defined - beyond the (necessary) description of how a particular parameter should be dealt with? =20 Cornelia ________________________________ Von: Lars Westberg [mailto:Lars.westberg@ericsson.com]=20 Gesendet: Dienstag, 17. Oktober 2006 10:56 An: Kappler, Cornelia Cc: Georgios Karagiannis; gash@att.com; nsis@ietf.org Betreff: Re: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt =09 =09 comments inline =09 Kappler, Cornelia wrote: =09 Hi Lars,=20 =20 could you explain why the qspec draft defines a new bearer service?=20 =20 let's define it as "Specification of the Controlled-Load Network Element Service" =3D>a specifiaction of treatment of a "flow".=20 =09 What is a bearer service? This concept exists in 3GPP, but it does not exist in IETF I dont think, and I dont think the 3GPP definition is transferrable to IETF. So what exactly are you stating? =20 see above.=20 =09 Cornelia ________________________________ Von: Lars Westberg [mailto:Lars.westberg@ericsson.com]=20 Gesendet: Dienstag, 17. Oktober 2006 08:46 An: Georgios Karagiannis Cc: gash@att.com; nsis@ietf.org Betreff: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt =09 =09 yes.=20 the main problem is that IETF is not the only Standardization organization that like to discuss "bearer services". Just as an example : If we specify the those parameters, How can we use NSIS for SLAs specified by MEF???? =09 How can we use it for 3GPP-Qos definitiions ? =09 =09 In the draft I also see that we the draft specify a new bearer service. It is not compliant to old Int.serv architecture. This is a completely new one with new parameters like priority. =09 I can sure that we can have a never-ending discussion about the "optimal"-set of parameters. =09 I think we agree in beggining the working group discussion that we should not specify any "bearer-service" because NSIS should be a modular architecture with more flexibillity than RSVP. Therefore, I am surprised that we are doing the same mistake as in RSVP: Integrating a bearer service definition into the NSIS-architecture. =09 If we go this track, the QoS-part of NSIS has much less use. RSVP is in this case significantly better in terms of performance and have the same functionality than NSIS. If have to choose I would select RSVP rather than a much more complex three layer protocol stack. =09 regards Lasse =09 Georgios Karagiannis wrote: =09 Hi Lars =09 Do you mean that the QSPEC template must not contain any mandatory (QSPEC-1) parameters? =09 =09 Best Regards, Georgios =09 =09 =09 On 10/16/2006, "Lars Westberg" wrote: =09 =20 Hi, The template seems not to be a template because the mandatory part is more or less the same as Intserv. The main idea with QoS-template was to make an modular solution that could allow flexibillity for different Qos-models =09 Therefore, I do not understand the scope of the specification. =09 I suggest that we move the major part of the parameters to a separate "Int.serv. over NSIS" specification. Int.serv. can be seen as a common bearer service. =09 regards Lasse =09 Ash, Gerald R (Jerry), ALABS wrote: =09 =20 Lars, =09 =20 You mention in the below e-mail that there are no open issues, while there is a huge discussion on the nsis mailing list regarding the QSPEC-1 parameters. =20 John can call a different consensus if he sees one (I've asked him a couple of times to do that). What I saw was =09 1. Many posts supported the QSPEC-1 concept, only one (or maybe two) I saw opposed. The opposing view was repeated *many* times (and is still being repeated) but it only counts as one opinion. 2. Many posts supported retaining the 4 QSPEC-1 parameters, only one I saw opposed. The opposing view was repeated many times. 3. There was only one opinion expressed to be able to ignore QSPEC-1 parameters. That one opinion has been repeated many times but it only counts as one opinion. =09 John asked a while ago for new opinions on these issues, that would be good if there are any *new* opinions. We don't need to hear opinions repeated that we've seen so many times. =09 I invite John once again to make a consensus call so we can move on here. I think it is time to make progress and stop repeating ourselves, we're not generating any new light in this rather endless discussion. =09 Thanks, Jerry =09 =20 =09 =20 ------_=_NextPart_001_01C6F1D2.9F12B93C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Lasse,
 
"specification of treatment of a flow" should = be done in=20 the QOSM Specs (e.g. RMD, CLS), it is not at an issue of the QSPEC. =
 
The job of the QSPEC draft is to define a set = of parameters=20 that QOSM specs can choose from to define this treatment. (Would you = agree this=20 is a reasonable approach?)
 
Could you more concretely point out where in = the QSPEC a=20 specific flow treatment is defined - beyond the=20 (necessary) description of  how a particular parameter should = be dealt=20 with?
 
Cornelia

Von: Lars Westberg=20 [mailto:Lars.westberg@ericsson.com]
Gesendet: Dienstag, 17. = Oktober=20 2006 10:56
An: Kappler, Cornelia
Cc: Georgios = Karagiannis;=20 gash@att.com; nsis@ietf.org
Betreff: Re: AW: [NSIS] I-D=20 ACTION:draft-ietf-nsis-qspec-12.txt

comments inline

Kappler, Cornelia wrote:
Hi Lars,
 
could you explain why the qspec draft = defines a new=20 bearer service?
 
let's define it = as=20 "Specification of the Controlled-Load Network Element = Service"
=3D>a=20 specifiaction of treatment of a "flow".
What is a bearer service? This concept = exists in 3GPP,=20 but it does not exist in IETF I dont think, and I dont think the = 3GPP=20 definition is transferrable to IETF. So what exactly are you=20 stating?
 
see above.
Cornelia

Von: Lars Westberg [mailto:Lars.westberg@ericsson.= com]=20
Gesendet: Dienstag, 17. Oktober 2006 = 08:46
An:=20 Georgios Karagiannis
Cc: gash@att.com; nsis@ietf.org
Betreff: = Re:=20 [NSIS] I-D = ACTION:draft-ietf-nsis-qspec-12.txt

yes.=20
the main problem is that IETF is not the only Standardization=20 organization that like to discuss "bearer services". Just as an = example=20 :
If we specify the those parameters, How can we use NSIS for = SLAs=20 specified by MEF????

How can we use it for 3GPP-Qos = definitiions=20 ?


In the draft I also see  that we the draft = specify a new=20 bearer service. It is not compliant to old Int.serv = architecture. =20 This is a completely new one with new parameters like = priority.

I=20 can sure that we can have a never-ending discussion about the=20 "optimal"-set of parameters.

I think we agree in beggining = the=20 working group discussion that we should not specify any = "bearer-service"=20 because NSIS should be a modular architecture with  more = flexibillity=20 than RSVP.  Therefore, I am surprised that we are doing the = same=20 mistake as in RSVP: Integrating a bearer service definition into = the=20 NSIS-architecture.

If we go this track, the QoS-part of = NSIS has=20 much less use. RSVP is in this case significantly better in terms = of=20 performance and have the same functionality than NSIS.
If have = to=20 choose I would select RSVP rather than a much more complex  = three=20 layer protocol stack.

regards Lasse

Georgios = Karagiannis=20 wrote:
Hi Lars

Do you mean that the QSPEC template must not contain any mandatory
(QSPEC-1) parameters?


Best Regards,
Georgios



On 10/16/2006, "Lars Westberg" <Lars.westberg@ericsson.com=
> wrote:

  
Hi,
The template seems not to be a template because the mandatory part  is
more or less the same as Intserv.
The main idea with QoS-template was to make an modular solution that
could allow flexibillity for different Qos-models

Therefore, I do not understand the scope of the specification.

I suggest that we move the major part of the parameters to a separate
"Int.serv. over NSIS" specification.
Int.serv. can be seen as a common bearer service.

regards Lasse

Ash, Gerald R (Jerry), ALABS wrote:

    
Lars,

      
You mention in the =
below e-mail that there are no open issues,
while there is a huge discussion on the nsis mailing list
regarding the QSPEC-1 parameters.
        
John can call a different =
consensus if he sees one (I've asked him a
couple of times to do that).  What I saw was

1. Many posts supported the QSPEC-1 concept, only one (or maybe two) I
saw opposed.  The opposing view was repeated *many* times (and is still
being repeated) but it only counts as one opinion.
2. Many posts supported retaining the 4 QSPEC-1 parameters, only one I
saw opposed.  The opposing view was repeated many times.
3. There was only one opinion expressed to be able to ignore QSPEC-1
parameters.  That one opinion has been repeated many times but it only
counts as one opinion.

John asked a while ago for new opinions on these issues, that would be
good if there are any *new* opinions.  We don't need to hear opinions
repeated that we've seen so many times.

I invite John once again to make a consensus call so we can move on
here.  I think it is time to make progress and stop repeating ourselves,
we're not generating any new light in this rather endless discussion.

Thanks,
Jerry

      

  =
------_=_NextPart_001_01C6F1D2.9F12B93C-- --===============0511717368== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0511717368==-- From nsis-bounces@ietf.org Tue Oct 17 06:01:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZlkp-0005bm-5y; Tue, 17 Oct 2006 06:00:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZlko-0005bh-EW for nsis@ietf.org; Tue, 17 Oct 2006 06:00:58 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZlkl-00014Q-Rk for nsis@ietf.org; Tue, 17 Oct 2006 06:00:58 -0400 Received: from mail1.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id k9HA0rSV012911; Tue, 17 Oct 2006 12:00:53 +0200 Received: from mchp7wta.ww002.siemens.net (mchp7wta.ww002.siemens.net [139.25.131.193]) by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id k9HA0oQw030546; Tue, 17 Oct 2006 12:00:52 +0200 Received: from blns00fa.ww002.siemens.net ([147.54.45.102]) by mchp7wta.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 12:00:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [NSIS] QSPEC-issue (GK-2) Date: Tue, 17 Oct 2006 12:00:49 +0200 Message-ID: In-Reply-To: <004801c6f1cf$4b60b0b0$4c0d5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QSPEC-issue (GK-2) Thread-Index: AcbtanD6fn22GI49QTOs4tcmcnPXswEXnjhgAABCSLAAAPaEgAAAPjkQAAD9scA= From: "Kappler, Cornelia" To: "Georgios Karagiannis" , "Hannes Tschofenig" X-OriginalArrivalTime: 17 Oct 2006 10:00:51.0585 (UTC) FILETIME=[20B64F10:01C6F1D3] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Georgios,=20 why do you think for example mapping Y.1541 Class 0 to PHB Expedited = Service (I think this is how its called) is useless? This is better than = having a Y.1541 Class 0 signaling arrive at a DiffSer domin and being = ignored!? Cornelia > -----Urspr=FCngliche Nachricht----- > Von: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 > Gesendet: Dienstag, 17. Oktober 2006 11:33 > An: Kappler, Cornelia; 'Hannes Tschofenig' > Cc: nsis@ietf.org > Betreff: RE: [NSIS] QSPEC-issue (GK-2) >=20 > Hi Cornelia >=20 > The reasonable maping can only be accomplished between: > Token Bucket (peak rate) =3D> Bandwidth > Higher (than normal) priority =3D> Normal priority > Lower (than normal) priority =3D> Normal priority >=20 > In my opinion other types of remappings (of other parameters)=20 > are either impossible or useless! >=20 > Best Regards, > Georgios >=20 > > -----Original Message----- > > From: Kappler, Cornelia [mailto:cornelia.kappler@siemens.com]=20 > > Sent: dinsdag 17 oktober 2006 11:29 > > To: Georgios Karagiannis; Hannes Tschofenig > > Cc: nsis@ietf.org > > Subject: AW: [NSIS] QSPEC-issue (GK-2) > >=20 > > Hi Georgios,=20 > >=20 > > it is a matter of interpreting what "reasonable mapping" means.=20 > >=20 > > For me, reasonable means that (i) the original idea of the=20 > > parameter value should be preserved as much as possible, but=20 > > on (ii) a QNE implementing a different set of paraemeters=20 > > (QOSM) should not be burdened with too much knowledge /=20 > > processing that is outside its own QOSM. > >=20 > > Regarding CLS I gave a possible answer balancing (i) and (ii)=20 > > which is deployable (in fact it is quite simple). > >=20 > > I cannot answer how to map PHB class into Y.1541 class since=20 > > I am not an expert in this. =20 > >=20 > > Cornelia=20 > >=20 > > > -----Urspr=FCngliche Nachricht----- > > > Von: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > Gesendet: Dienstag, 17. Oktober 2006 10:57 > > > An: Kappler, Cornelia; 'Hannes Tschofenig' > > > Cc: nsis@ietf.org > > > Betreff: RE: [NSIS] QSPEC-issue (GK-2) > > >=20 > > > Hi Cornelia > > >=20 > > > This is not possible! > > > How a QNE will know how to map a PHB class into a Y.1541 class? > > > It is impossible to come up with a reasonable mapping. > > >=20 > > > The only solution on this is to mandate that all QNEs implement=20 > > > Diffserv and MPLS and Y.1541. > > > In this way NSIS will never be used and deployed. > > >=20 > > > Best regards, > > > Georgios > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: Kappler, Cornelia [mailto:cornelia.kappler@siemens.com] > > > > Sent: dinsdag 17 oktober 2006 10:52 > > > > To: Hannes Tschofenig; Georgios Karagiannis > > > > Cc: nsis@ietf.org > > > > Subject: AW: [NSIS] QSPEC-issue (GK-2) > > > >=20 > > > > Hi Georgios and Hannes, > > > >=20 > > > > see my previous post regarding how to handle these > > > parameters in CL.=20 > > > >=20 > > > > The proposal for CL is that a CL QNE has an algorithm=20 > > that tells it=20 > > > > which QoS Class parameters are "high class" and whcih are "low=20 > > > > class". If they are high class, they will receive CL=20 > > treatment. If=20 > > > > they are low class, they receive best effort. > > > >=20 > > > > This way QSPECs based on "QoS Class" QOSMs get as reasonable a=20 > > > > treatment as one can expect, and at the same time I=20 > dont see a CL=20 > > > > QNE being overburdened by this task. > > > >=20 > > > > Cornelia > > > >=20 > > > > > -----Urspr=FCngliche Nachricht----- > > > > > Von: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > > > Gesendet: Mittwoch, 11. Oktober 2006 21:05 > > > > > An: Georgios Karagiannis > > > > > Cc: nsis@ietf.org > > > > > Betreff: Re: [NSIS] QSPEC-issue (GK-2) > > > > >=20 > > > > > I support Georgios. > > > > >=20 > > > > > I think it is unrealistic to assume that Y.1541 and DSTE > > > > behavior (as > > > > > required for strictly interpreting these parameters) is > > > > implemented in > > > > > every QNE. > > > > >=20 > > > > > Ciao > > > > > Hannes > > > > >=20 > > > > > Georgios Karagiannis schrieb: > > > > > > Description of issue > > > > > > Change to QSPEC-2 parameter > > > > > >=20 > > > > > >=20 > > > > > > Submitter name: Georgios Karagiannis Submitter=20 > email address:=20 > > > > > > karagian@cs.utwente.nl Date first > > > > > submitted: > > > > > > 11.10.2006 > > > > > > Reference: =20 > > > > > > Comment type: T > > > > > > Priority: 'S' > > > > > > Section: Various > > > > > > Rationale/Explanation of issue: > > > > > >=20 > > > > > > It is not realistic to assume that the QNI is able to > > > know which > > > > > > network technologies (Diffserv, MPLS, Y.1541) are > > > > supported on the > > > > > > end-to-end path. > > > > > > If the "QoS Class" parameter is considered to be a > > > > QSPEC-1 parameter > > > > > > then it will mean that all QNEs located on the end-to-end > > > > path must > > > > > > support the Diffserv and MPLS and > > > > > Y.1541 technologies.=20 > > > > > > This is unrealistic. > > > > > >=20 > > > > > > Requested change: > > > > > > The parameter must be a QSPEC-2 parameter. > > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > > _______________________________________________ > > > > > > nsis mailing list > > > > > > nsis@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > >=20 > > > > > >=20 > > > > >=20 > > > > >=20 > > > > > _______________________________________________ > > > > > nsis mailing list > > > > > nsis@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > nsis mailing list > > > > nsis@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > >=20 > > >=20 > > >=20 > > >=20 > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > >=20 > >=20 >=20 >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 17 06:36:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZmIO-0001Au-N8; Tue, 17 Oct 2006 06:35:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZmFW-0000LQ-A3 for nsis@ietf.org; Tue, 17 Oct 2006 06:32:42 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZmBR-0005FE-Bi for nsis@ietf.org; Tue, 17 Oct 2006 06:28:38 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E545079A; Tue, 17 Oct 2006 12:28:23 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 12:28:23 +0200 Received: from ericsson.com ([147.214.26.58]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 12:28:22 +0200 Message-ID: <4534B046.5040405@ericsson.com> Date: Tue, 17 Oct 2006 12:28:22 +0200 From: Lars Westberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roland Bless Subject: Re: [NSIS] messages content References: <0CDAE977A7172A40A2A3A1C20C12BD650488B0C6@esealmw106.eemea.ericsson.se> <4534A837.8010606@tm.uka.de> In-Reply-To: <4534A837.8010606@tm.uka.de> X-OriginalArrivalTime: 17 Oct 2006 10:28:22.0342 (UTC) FILETIME=[F8A3D660:01C6F1D6] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 4c358d334afcd91b425d436ca5722f22 Cc: nsis@ietf.org, "Hancock, Robert" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0933585898==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0933585898== Content-Type: multipart/alternative; boundary="------------000201030202050905080600" This is a multi-part message in MIME format. --------------000201030202050905080600 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit yes, thanks, that would be very nice. regards Lasse Roland Bless wrote: > Hi Lars, > > Lars Westberg (KI/EAB) wrote: > > comments inline > > dito > > >> It's somewhat complex, but implementable. A student of mine was able to > >> do a full implementation within 6 months. > > > > I do not have six-months to spend of it. I would rather prefer a > > fast-track solution. > > I guess you don't need 6 months to read and understand the spec, > I meant a full implementation including writing and testing the code. > > >> I am after examples of message structures and sequence diagram so I > >> can verify my assumptions. > >> I would be very happy if someone can help me with such information. > > > > Protocol state machines are in Chapter 6 (see p. 62 and 65) and message > > structures in Chapter 5. If this doesn't help you may ask your question > > on the list. > > > > I can't all questions on the list. I would rather appreciate an example > > implementation of it with message shown in text-format. Does the > > implementation showing the messages in text ?? > > Yep, e.g.: an incoming connection with query/response/confirm > (C-Mode setup) may look like this: > 2006-10-13 14:10:43.626-20911- EVENT /4: GIST Processing Received > message #5 (SigInd) from: Signaling, signaling peer: 193.136.212.219, PDU: > : NSLP ID: 1 > Message Routing Information : (0) > MRM-ID: > IP-Version: 4 > Flags: PAB > Source Address: 193.136.212.219 > Destination Address: 193.136.212.216 > Source Prefixlen: 27 > Destination Prefixlen: 27 > IP-Protocol: udp > Destination Port: 8080 > Source Port: 8080 > Direction: Downstream > > SessionID : 666f6f62-61727769-62626c65-00000000 > > NLI : (0) > > PI length: 4 > IP_TTL: 0 > IP_Version: 4 > RSV_Time: 150000 > PI: > IF_Address: 193.136.212.219 > > Query Cookie : <0x517565727920436f6f6b69652066726f6d20616631000000> > > StackProposal > Profiles: 1 > 1 MA fields: <1> > > StackConfigurationData > Profiles: 1 > MA-Hold Time: 10000 ms > Protocol: 1 Profile: 0 Configuration Data: > ---------------------------------------------------------------------------- > 2006-10-13 14:10:43.640-20911- DEBUG /4: GIST Signaling Sending: > : NSLP ID: 1 > Message Routing Information : (0) > MRM-ID: IP-Version: 4 > Flags: PABD > Source Address: 193.136.212.219 > Destination Address: 193.136.212.216 > Source Prefixlen: 27 > Destination Prefixlen: 27 > IP-Protocol: udp > Destination Port: 8080 > Source Port: 8080 > Direction: Upstream > > SessionID : 666f6f62-61727769-62626c65-00000000 > > NLI : (0) > > PI length: 16 > IP_TTL: 0 > IP_Version: 4 > RSV_Time: 60000 > PI: > IF_Address: 193.136.212.216 > > Query Cookie : <0x517565727920436f6f6b69652066726f6d20616631000000> > > Responder Cookie : <0x31850f42b79f123151eac346592934685ab8ef5772b0112f> > > StackProposal > Profiles: 2 > 1 MA fields: <1> > 2 MA fields: <2> <1> > > StackConfigurationData > Profiles: 2 > MA-Hold Time: 180000 ms > Protocol: 1 Profile: 1 Configuration Data: <75> <30> (30000) > Protocol: 1 Profile: 2 Configuration Data: <75> <31> (30001) > -------------------------------------------------------------------- > 2006-10-13 14:10:43.748-20911- EVENT /4: GIST Processing Received > message #12 (SigInd) from: Signaling, signaling peer: > ::ffff:193.136.212.219, PDU: > : > Message Routing Information : (0) > MRM-ID: IP-Version: 4 > Flags: PAB > Source Address: 193.136.212.219 > Destination Address: 193.136.212.216 > Source Prefixlen: 27 > Destination Prefixlen: 27 > IP-Protocol: udp > Destination Port: 8080 > Source Port: 8080 > Direction: Downstream > > SessionID : 666f6f62-61727769-62626c65-00000000 > > NLI : (0) > > PI length: 4 > IP_TTL: 0 > IP_Version: 4 > RSV_Time: 150000 > PI: > IF_Address: 193.136.212.219 > > Responder Cookie : <0x31850f42b79f123151eac346592934685ab8ef5772b0112f> > > StackProposal > Profiles: 2 > 1 MA fields: <1> > 2 MA fields: <2> <1> > > StackConfigurationData > Profiles: 0 > MA-Hold Time: 10000 ms > ----------------------------------------------------------------- > > > > If so, I am interested in it. Is it possible to get a copy ??? > > I can sent you a full copy of our log output from one of our > recent interop-tests if that helps. > > Regards, > Roland > --------------000201030202050905080600 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit yes, thanks, that would be very nice.

regards Lasse

Roland Bless wrote:
Re: [NSIS] messages content

Hi Lars,

Lars Westberg (KI/EAB) wrote:
>  comments inline

dito

>> It's somewhat complex, but implementable. A student of mine was able to
>> do a full implementation within 6 months.
>
> I do not have six-months to spend of it. I would rather prefer a
> fast-track solution.

I guess you don't need 6 months to read and understand the spec,
I meant a full implementation including writing and testing the code.

>> I am after examples of message structures and sequence diagram so I
>> can verify my assumptions.
>> I would be very happy if someone can help me with such information.
>
> Protocol state machines are in Chapter 6 (see p. 62 and 65) and message
> structures in Chapter 5. If this doesn't help you may ask your question
> on the list.
>
> I can't all questions on the list.  I would rather appreciate an example
> implementation of it with message shown in text-format. Does the
> implementation showing the messages in text ??

Yep, e.g.: an incoming connection with query/response/confirm
(C-Mode setup) may look like this:
2006-10-13 14:10:43.626-20911- EVENT /4: GIST Processing Received
message #5 (SigInd) from: Signaling, signaling peer: 193.136.212.219, PDU:
<query>:   NSLP ID: 1
Message Routing Information <mri_pathcoupled>: (0)
MRM-ID:
IP-Version:             4
Flags:                  PAB
Source Address:         193.136.212.219
Destination Address:    193.136.212.216
Source Prefixlen:       27
Destination Prefixlen:  27
IP-Protocol:               udp
Destination Port:       8080
Source Port:            8080
Direction: Downstream

   SessionID <sessionid>: 666f6f62-61727769-62626c65-00000000

NLI <nli>: (0)

PI length: 4
IP_TTL: 0
IP_Version: 4
RSV_Time: 150000
PI:
IF_Address: 193.136.212.219

   Query Cookie : <0x517565727920436f6f6b69652066726f6d20616631000000>

   StackProposal
Profiles: 1
1 MA fields: <1>

   StackConfigurationData
Profiles: 1
MA-Hold Time: 10000 ms
Protocol: 1 Profile: 0 Configuration Data:
----------------------------------------------------------------------------
2006-10-13 14:10:43.640-20911- DEBUG /4: GIST Signaling  Sending:
<response>:   NSLP ID: 1
Message Routing Information <mri_pathcoupled>: (0)
MRM-ID:                 IP-Version:             4
Flags:                  PABD
Source Address:         193.136.212.219
Destination Address:    193.136.212.216
Source Prefixlen:       27
Destination Prefixlen:  27
IP-Protocol:               udp
Destination Port:       8080
Source Port:            8080
Direction: Upstream

   SessionID <sessionid>: 666f6f62-61727769-62626c65-00000000

NLI <nli>: (0)

PI length: 16
IP_TTL: 0
IP_Version: 4
RSV_Time: 60000
PI:
IF_Address: 193.136.212.216

   Query Cookie : <0x517565727920436f6f6b69652066726f6d20616631000000>

   Responder Cookie : <0x31850f42b79f123151eac346592934685ab8ef5772b0112f>

   StackProposal
Profiles: 2
1 MA fields: <1>
2 MA fields: <2> <1>

   StackConfigurationData
Profiles: 2
MA-Hold Time: 180000 ms
Protocol: 1 Profile: 1 Configuration Data: <75> <30> (30000)
Protocol: 1 Profile: 2 Configuration Data: <75> <31> (30001)
--------------------------------------------------------------------
2006-10-13 14:10:43.748-20911- EVENT /4: GIST Processing Received
message #12 (SigInd) from: Signaling, signaling peer:
::ffff:193.136.212.219, PDU:
<confirm>:
Message Routing Information <mri_pathcoupled>: (0)
MRM-ID:                 IP-Version:             4
Flags:                  PAB
Source Address:         193.136.212.219
Destination Address:    193.136.212.216
Source Prefixlen:       27
Destination Prefixlen:  27
IP-Protocol:               udp
Destination Port:       8080
Source Port:            8080
Direction: Downstream

   SessionID <sessionid>: 666f6f62-61727769-62626c65-00000000

NLI <nli>: (0)

PI length: 4
IP_TTL: 0
IP_Version: 4
RSV_Time: 150000
PI:
IF_Address: 193.136.212.219

   Responder Cookie : <0x31850f42b79f123151eac346592934685ab8ef5772b0112f>

   StackProposal
Profiles: 2
1 MA fields: <1>
2 MA fields: <2> <1>

   StackConfigurationData
Profiles: 0
MA-Hold Time: 10000 ms
-----------------------------------------------------------------


> If so, I am interested in it. Is it possible to get a copy ???

I can sent you a full copy of our log output from one of our
recent interop-tests if that helps.

Regards,
 Roland

--------------000201030202050905080600-- --===============0933585898== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0933585898==-- From nsis-bounces@ietf.org Tue Oct 17 08:24:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZnzP-0001Mb-5a; Tue, 17 Oct 2006 08:24:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZnzN-0001Gy-PX for nsis@ietf.org; Tue, 17 Oct 2006 08:24:09 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZnzK-0006Fu-St for nsis@ietf.org; Tue, 17 Oct 2006 08:24:09 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k9HCNkVh008812; Tue, 17 Oct 2006 14:23:57 +0200 (MEST) From: "Georgios Karagiannis" To: "'Kappler, Cornelia'" , "'Lars Westberg'" Subject: RE: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Date: Tue, 17 Oct 2006 14:23:43 +0200 Message-ID: <005001c6f1e7$19bb9120$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Acbxymmrqi77gQSmQ4Ode5w+MSLtVgAB0MyAAAUSAkA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: -4.888 () ALL_TRUSTED, AWL, BAYES_00, FVGT_s_OBFU_Q1, HTML_50_60, HTML_MESSAGE, HTML_TITLE_EMPTY, J_CHICKENPOX_23, J_CHICKENPOX_34 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Tue, 17 Oct 2006 14:24:01 +0200 (MEST) X-Spam-Score: 0.1 (/) X-Scan-Signature: b4be0d55bab88df9d21005ced9551e26 Cc: gash@att.com, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0766632299==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0766632299== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0051_01C6F1F7.DD446120" This is a multi-part message in MIME format. ------=_NextPart_000_0051_01C6F1F7.DD446120 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Cornelia What Lars means is that when the QSPEC template defines that Traffic, QoS Class, Excess Treatment and Priority are mandatory sets of parameters then the QS{PEC template is also defining a bearer service. Meaning that all QNEs must support these parameters, thus they must support the bearer service that is dictated by the 4 sets of mandatory parameters, i.e., 13 mandatory parameters. It is very important to note that there are not 4 mandatory parameters but there are 4 sets of mandatory parmeters. The total number of mandatory parameters is 13. * Traffic parameter set has 2 mandatory parameters * QoS class set has 3 mandatory parameters * Priority has 4 mandatory parameters * Excess Treatment has 4 mandatory parameters Best Regards, Georgios _____ From: Kappler, Cornelia [mailto:cornelia.kappler@siemens.com] Sent: dinsdag 17 oktober 2006 11:57 To: Lars Westberg Cc: gash@att.com; Georgios Karagiannis; nsis@ietf.org Subject: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Hi Lasse, "specification of treatment of a flow" should be done in the QOSM Specs (e.g. RMD, CLS), it is not at an issue of the QSPEC. The job of the QSPEC draft is to define a set of parameters that QOSM specs can choose from to define this treatment. (Would you agree this is a reasonable approach?) Could you more concretely point out where in the QSPEC a specific flow treatment is defined - beyond the (necessary) description of how a particular parameter should be dealt with? Cornelia _____ Von: Lars Westberg [mailto:Lars.westberg@ericsson.com] Gesendet: Dienstag, 17. Oktober 2006 10:56 An: Kappler, Cornelia Cc: Georgios Karagiannis; gash@att.com; nsis@ietf.org Betreff: Re: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt comments inline Kappler, Cornelia wrote: Hi Lars, could you explain why the qspec draft defines a new bearer service? let's define it as "Specification of the Controlled-Load Network Element Service" =>a specifiaction of treatment of a "flow". What is a bearer service? This concept exists in 3GPP, but it does not exist in IETF I dont think, and I dont think the 3GPP definition is transferrable to IETF. So what exactly are you stating? see above. Cornelia _____ Von: Lars Westberg [mailto:Lars.westberg@ericsson.com] Gesendet: Dienstag, 17. Oktober 2006 08:46 An: Georgios Karagiannis Cc: gash@att.com; nsis@ietf.org Betreff: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt yes. the main problem is that IETF is not the only Standardization organization that like to discuss "bearer services". Just as an example : If we specify the those parameters, How can we use NSIS for SLAs specified by MEF???? How can we use it for 3GPP-Qos definitiions ? In the draft I also see that we the draft specify a new bearer service. It is not compliant to old Int.serv architecture. This is a completely new one with new parameters like priority. I can sure that we can have a never-ending discussion about the "optimal"-set of parameters. I think we agree in beggining the working group discussion that we should not specify any "bearer-service" because NSIS should be a modular architecture with more flexibillity than RSVP. Therefore, I am surprised that we are doing the same mistake as in RSVP: Integrating a bearer service definition into the NSIS-architecture. If we go this track, the QoS-part of NSIS has much less use. RSVP is in this case significantly better in terms of performance and have the same functionality than NSIS. If have to choose I would select RSVP rather than a much more complex three layer protocol stack. regards Lasse Georgios Karagiannis wrote: Hi Lars Do you mean that the QSPEC template must not contain any mandatory (QSPEC-1) parameters? Best Regards, Georgios On 10/16/2006, "Lars Westberg" wrote: Hi, The template seems not to be a template because the mandatory part is more or less the same as Intserv. The main idea with QoS-template was to make an modular solution that could allow flexibillity for different Qos-models Therefore, I do not understand the scope of the specification. I suggest that we move the major part of the parameters to a separate "Int.serv. over NSIS" specification. Int.serv. can be seen as a common bearer service. regards Lasse Ash, Gerald R (Jerry), ALABS wrote: Lars, You mention in the below e-mail that there are no open issues, while there is a huge discussion on the nsis mailing list regarding the QSPEC-1 parameters. John can call a different consensus if he sees one (I've asked him a couple of times to do that). What I saw was 1. Many posts supported the QSPEC-1 concept, only one (or maybe two) I saw opposed. The opposing view was repeated *many* times (and is still being repeated) but it only counts as one opinion. 2. Many posts supported retaining the 4 QSPEC-1 parameters, only one I saw opposed. The opposing view was repeated many times. 3. There was only one opinion expressed to be able to ignore QSPEC-1 parameters. That one opinion has been repeated many times but it only counts as one opinion. John asked a while ago for new opinions on these issues, that would be good if there are any *new* opinions. We don't need to hear opinions repeated that we've seen so many times. I invite John once again to make a consensus call so we can move on here. I think it is time to make progress and stop repeating ourselves, we're not generating any new light in this rather endless discussion. Thanks, Jerry ------=_NextPart_000_0051_01C6F1F7.DD446120 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Cornelia
 
What Lars means is that when the QSPEC template = defines=20 that
Traffic, QoS Class, Excess Treatment and = Priority are=20 mandatory sets of parameters
then the QS{PEC template is also defining a = bearer service.=20
Meaning that all QNEs must = support these parameters, thus they=20
must support the bearer service=20 that is dictated by the = 4 sets of=20 mandatory parameters, i.e., 13 mandatory=20 parameters.
 
It is very important to note that there are = not 4=20 mandatory parameters but there are 4 sets of mandatory=20 parmeters.
The total number of mandatory parameters is=20 13.
 
* Traffic parameter set has 2 mandatory=20 parameters
* QoS class set has 3 mandatory=20 parameters
* Priority has 4 mandatory=20 parameters
* Excess Treatment has 4 mandatory=20 parameters
 
 
Best = Regards,
Georgios

=
From: Kappler, Cornelia=20 [mailto:cornelia.kappler@siemens.com]
Sent: dinsdag 17 = oktober 2006=20 11:57
To: Lars Westberg
Cc: gash@att.com; Georgios = Karagiannis; nsis@ietf.org
Subject: AW: AW: [NSIS] I-D=20 ACTION:draft-ietf-nsis-qspec-12.txt

Hi Lasse,
 
"specification of treatment of a flow" should = be done in=20 the QOSM Specs (e.g. RMD, CLS), it is not at an issue of the = QSPEC.=20
 
The job of the QSPEC draft is to define a set = of=20 parameters that QOSM specs can choose from to define this treatment. = (Would=20 you agree this is a reasonable approach?)
 
Could you more concretely point out where in = the QSPEC a=20 specific flow treatment is defined - beyond the=20 (necessary) description of  how a particular parameter = should be=20 dealt with?
 
Cornelia

Von: Lars Westberg=20 [mailto:Lars.westberg@ericsson.com]
Gesendet: Dienstag, = 17.=20 Oktober 2006 10:56
An: Kappler, Cornelia
Cc: = Georgios=20 Karagiannis; gash@att.com; nsis@ietf.org
Betreff: Re: AW: = [NSIS]=20 I-D ACTION:draft-ietf-nsis-qspec-12.txt

comments inline

Kappler, Cornelia wrote:
Hi Lars,
 
could you explain why the qspec draft = defines a new=20 bearer service?
 
let's define = it as=20 "Specification of the Controlled-Load Network Element = Service"
=3D>a=20 specifiaction of treatment of a "flow".
What is a bearer service? This concept = exists in=20 3GPP, but it does not exist in IETF I dont think, and I dont think = the=20 3GPP definition is transferrable to IETF. So what exactly are you=20 stating?
 
see above. =
Cornelia

Von: Lars Westberg [mailto:Lars.westberg@ericsson.= com]=20
Gesendet: Dienstag, 17. Oktober 2006 = 08:46
An:=20 Georgios Karagiannis
Cc: gash@att.com; nsis@ietf.org
Betreff: Re:=20 [NSIS] I-D = ACTION:draft-ietf-nsis-qspec-12.txt

yes.=20
the main problem is that IETF is not the only = Standardization=20 organization that like to discuss "bearer services". Just as an = example=20 :
If we specify the those parameters, How can we use NSIS for = SLAs=20 specified by MEF????

How can we use it for 3GPP-Qos = definitiions=20 ?


In the draft I also see  that we the draft = specify a=20 new bearer service. It is not compliant to old Int.serv=20 architecture.  This is a completely new one with new = parameters=20 like priority.

I can sure that we can have a never-ending = discussion about the "optimal"-set of parameters.

I think = we=20 agree in beggining the working group discussion that we should = not=20 specify any "bearer-service" because NSIS should be a modular=20 architecture with  more flexibillity than RSVP.  = Therefore, I=20 am surprised that we are doing the same mistake as in RSVP: = Integrating=20 a bearer service definition into the = NSIS-architecture.

If we go=20 this track, the QoS-part of NSIS has much less use. RSVP is in = this case=20 significantly better in terms of performance and have the same=20 functionality than NSIS.
If have to choose I would select = RSVP rather=20 than a much more complex  three layer protocol=20 stack.

regards Lasse

Georgios Karagiannis = wrote:
Hi Lars

Do you mean that the QSPEC template must not contain any mandatory
(QSPEC-1) parameters?


Best Regards,
Georgios



On 10/16/2006, "Lars Westberg" <Lars.westberg@ericsson.com=
> wrote:

  
Hi,
The template seems not to be a template because the mandatory part  is
more or less the same as Intserv.
The main idea with QoS-template was to make an modular solution that
could allow flexibillity for different Qos-models

Therefore, I do not understand the scope of the specification.

I suggest that we move the major part of the parameters to a separate
"Int.serv. over NSIS" specification.
Int.serv. can be seen as a common bearer service.

regards Lasse

Ash, Gerald R (Jerry), ALABS wrote:

    
Lars,

      
You mention in =
the below e-mail that there are no open issues,
while there is a huge discussion on the nsis mailing list
regarding the QSPEC-1 parameters.
        
John can call a different =
consensus if he sees one (I've asked him a
couple of times to do that).  What I saw was

1. Many posts supported the QSPEC-1 concept, only one (or maybe two) I
saw opposed.  The opposing view was repeated *many* times (and is still
being repeated) but it only counts as one opinion.
2. Many posts supported retaining the 4 QSPEC-1 parameters, only one I
saw opposed.  The opposing view was repeated many times.
3. There was only one opinion expressed to be able to ignore QSPEC-1
parameters.  That one opinion has been repeated many times but it only
counts as one opinion.

John asked a while ago for new opinions on these issues, that would be
good if there are any *new* opinions.  We don't need to hear opinions
repeated that we've seen so many times.

I invite John once again to make a consensus call so we can move on
here.  I think it is time to make progress and stop repeating ourselves,
we're not generating any new light in this rather endless discussion.

Thanks,
Jerry

      

  =
------=_NextPart_000_0051_01C6F1F7.DD446120-- --===============0766632299== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0766632299==-- From nsis-bounces@ietf.org Tue Oct 17 08:28:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZo39-0005Mw-H7; Tue, 17 Oct 2006 08:28:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZo37-0005Mr-LL for nsis@ietf.org; Tue, 17 Oct 2006 08:28:01 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZo36-0007BO-7a for nsis@ietf.org; Tue, 17 Oct 2006 08:28:01 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k9HCRoEC009285; Tue, 17 Oct 2006 14:27:54 +0200 (MEST) From: "Georgios Karagiannis" To: "'Kappler, Cornelia'" , "'Hannes Tschofenig'" Subject: RE: [NSIS] QSPEC-issue (GK-2) Date: Tue, 17 Oct 2006 14:27:47 +0200 Message-ID: <005501c6f1e7$aa5d79f0$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcbtanD6fn22GI49QTOs4tcmcnPXswEXnjhgAAeTNOA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: -5.533 () ALL_TRUSTED,AWL,BAYES_00,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Tue, 17 Oct 2006 14:27:55 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Cornelia Sorry, but in this way you define two new parameters and that are high class and low class! In addition to the 13 mandatory parameters we will add other two.=20 Thus the QNEs will have to support 15 mandatory parameters. Sorry but it becomes more complicated, than when just=20 having 13 mandatory parameters. Best Regards, Georgios > -----Original Message----- > From: Kappler, Cornelia [mailto:cornelia.kappler@siemens.com]=20 > Sent: dinsdag 17 oktober 2006 10:52 > To: Hannes Tschofenig; Georgios Karagiannis > Cc: nsis@ietf.org > Subject: AW: [NSIS] QSPEC-issue (GK-2) >=20 > Hi Georgios and Hannes,=20 >=20 > see my previous post regarding how to handle these parameters in CL.=20 >=20 > The proposal for CL is that a CL QNE has an algorithm that=20 > tells it which QoS Class parameters are "high class" and=20 > whcih are "low class". If they are high class, they will=20 > receive CL treatment. If they are low class, they receive=20 > best effort.=20 >=20 > This way QSPECs based on "QoS Class" QOSMs get as reasonable=20 > a treatment as one can expect, and at the same time I dont=20 > see a CL QNE being overburdened by this task. >=20 > Cornelia=20 >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > Gesendet: Mittwoch, 11. Oktober 2006 21:05 > > An: Georgios Karagiannis > > Cc: nsis@ietf.org > > Betreff: Re: [NSIS] QSPEC-issue (GK-2) > >=20 > > I support Georgios. > >=20 > > I think it is unrealistic to assume that Y.1541 and DSTE=20 > behavior (as=20 > > required for strictly interpreting these parameters) is=20 > implemented in=20 > > every QNE. > >=20 > > Ciao > > Hannes > >=20 > > Georgios Karagiannis schrieb: > > > Description of issue > > > Change to QSPEC-2 parameter > > >=20 > > >=20 > > > Submitter name: Georgios Karagiannis Submitter email address:=20 > > > karagian@cs.utwente.nl Date first > > submitted: > > > 11.10.2006 > > > Reference: =20 > > > Comment type: T > > > Priority: 'S' > > > Section: Various > > > Rationale/Explanation of issue: > > >=20 > > > It is not realistic to assume that the QNI is able to know which=20 > > > network technologies (Diffserv, MPLS, Y.1541) are=20 > supported on the=20 > > > end-to-end path. > > > If the "QoS Class" parameter is considered to be a=20 > QSPEC-1 parameter=20 > > > then it will mean that all QNEs located on the end-to-end=20 > path must=20 > > > support the Diffserv and MPLS and > > Y.1541 technologies.=20 > > > This is unrealistic. > > >=20 > > > Requested change: > > > The parameter must be a QSPEC-2 parameter. > > >=20 > > >=20 > > >=20 > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > >=20 > > >=20 > >=20 > >=20 > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 17 08:33:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZo84-0008F4-Ft; Tue, 17 Oct 2006 08:33:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZo82-0008Ey-Pl for nsis@ietf.org; Tue, 17 Oct 2006 08:33:06 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZo7u-0008Mw-C8 for nsis@ietf.org; Tue, 17 Oct 2006 08:33:06 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5581410FF; Tue, 17 Oct 2006 14:32:47 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 14:32:46 +0200 Received: from ericsson.com ([147.214.26.58]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 14:32:46 +0200 Message-ID: <4534CD6E.1050507@ericsson.com> Date: Tue, 17 Oct 2006 14:32:46 +0200 From: Lars Westberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kappler, Cornelia" Subject: Re: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt References: In-Reply-To: X-OriginalArrivalTime: 17 Oct 2006 12:32:46.0761 (UTC) FILETIME=[59C7C990:01C6F1E8] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 6e8a3b85ef670172081194f0b0f68e6f Cc: gash@att.com, Georgios Karagiannis , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0626872399==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0626872399== Content-Type: multipart/alternative; boundary="------------080108070404010408030804" This is a multi-part message in MIME format. --------------080108070404010408030804 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit The specification of Qspec1 is mandatory and therefore as I can see can not be avoided and The parameter description in The Qspec-1 is more detalied than Int.serv. The reason for dividing NSIS in three layers was that Int.serv. was too tightly built-into RSVP. Now, I see that this benefit is gone and what's the gain with NSIS for QoS ? If one just read the specification, and compare it with Int.serv. oe can conclude the following: 1) More parameters than Intserv. (excess treatment, priority???) 2) More functionality required for implementation even if its never used. issues like : how to model MEF bearer service definition ????? ...more layers with more functionality in each layer stacked on each other. I do not know what to do..... regards Lasse Kappler, Cornelia wrote: > Hi Lasse, > > "specification of treatment of a flow" should be done in the QOSM > Specs (e.g. RMD, CLS), it is not at an issue of the QSPEC. > > The job of the QSPEC draft is to define a set of parameters that QOSM > specs can choose from to define this treatment. (Would you agree this > is a reasonable approach?) > if the collection of paramters does not limit the applicabillity of QoS-models that may be ok. > Could you more concretely point out where in the QSPEC a specific flow > treatment is defined - beyond the (necessary) description of how a > particular parameter should be dealt with? I have sent out pointer to Metro-Ethernet forum specification. > > Cornelia > > ------------------------------------------------------------------------ > Von: Lars Westberg [mailto:Lars.westberg@ericsson.com] > Gesendet: Dienstag, 17. Oktober 2006 10:56 > An: Kappler, Cornelia > Cc: Georgios Karagiannis; gash@att.com; nsis@ietf.org > Betreff: Re: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt > > comments inline > > Kappler, Cornelia wrote: > >> Hi Lars, >> >> could you explain why the qspec draft defines a new bearer service? >> > > let's define it as "Specification of the Controlled-Load Network > Element Service" > =>a specifiaction of treatment of a "flow". > >> What is a bearer service? This concept exists in 3GPP, but it >> does not exist in IETF I dont think, and I dont think the 3GPP >> definition is transferrable to IETF. So what exactly are you stating? >> > > see above. > >> Cornelia >> >> ------------------------------------------------------------------------ >> Von: Lars Westberg [mailto:Lars.westberg@ericsson.com] >> Gesendet: Dienstag, 17. Oktober 2006 08:46 >> An: Georgios Karagiannis >> Cc: gash@att.com; nsis@ietf.org >> Betreff: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt >> >> yes. >> the main problem is that IETF is not the only Standardization >> organization that like to discuss "bearer services". Just as >> an example : >> If we specify the those parameters, How can we use NSIS for >> SLAs specified by MEF???? >> >> How can we use it for 3GPP-Qos definitiions ? >> >> >> In the draft I also see that we the draft specify a new >> bearer service. It is not compliant to old Int.serv >> architecture. This is a completely new one with new >> parameters like priority. >> >> I can sure that we can have a never-ending discussion about >> the "optimal"-set of parameters. >> >> I think we agree in beggining the working group discussion >> that we should not specify any "bearer-service" because NSIS >> should be a modular architecture with more flexibillity than >> RSVP. Therefore, I am surprised that we are doing the same >> mistake as in RSVP: Integrating a bearer service definition >> into the NSIS-architecture. >> >> If we go this track, the QoS-part of NSIS has much less use. >> RSVP is in this case significantly better in terms of >> performance and have the same functionality than NSIS. >> If have to choose I would select RSVP rather than a much more >> complex three layer protocol stack. >> >> regards Lasse >> >> Georgios Karagiannis wrote: >> >>>Hi Lars >>> >>>Do you mean that the QSPEC template must not contain any mandatory >>>(QSPEC-1) parameters? >>> >>> >>>Best Regards, >>>Georgios >>> >>> >>> >>>On 10/16/2006, "Lars Westberg" wrote: >>> >>> >>> >>>>Hi, >>>>The template seems not to be a template because the mandatory part is >>>>more or less the same as Intserv. >>>>The main idea with QoS-template was to make an modular solution that >>>>could allow flexibillity for different Qos-models >>>> >>>>Therefore, I do not understand the scope of the specification. >>>> >>>>I suggest that we move the major part of the parameters to a separate >>>>"Int.serv. over NSIS" specification. >>>>Int.serv. can be seen as a common bearer service. >>>> >>>>regards Lasse >>>> >>>>Ash, Gerald R (Jerry), ALABS wrote: >>>> >>>> >>>> >>>>>Lars, >>>>> >>>>> >>>>> >>>>>>You mention in the below e-mail that there are no open issues, >>>>>>while there is a huge discussion on the nsis mailing list >>>>>>regarding the QSPEC-1 parameters. >>>>>> >>>>>> >>>>>John can call a different consensus if he sees one (I've asked him a >>>>>couple of times to do that). What I saw was >>>>> >>>>>1. Many posts supported the QSPEC-1 concept, only one (or maybe two) I >>>>>saw opposed. The opposing view was repeated *many* times (and is still >>>>>being repeated) but it only counts as one opinion. >>>>>2. Many posts supported retaining the 4 QSPEC-1 parameters, only one I >>>>>saw opposed. The opposing view was repeated many times. >>>>>3. There was only one opinion expressed to be able to ignore QSPEC-1 >>>>>parameters. That one opinion has been repeated many times but it only >>>>>counts as one opinion. >>>>> >>>>>John asked a while ago for new opinions on these issues, that would be >>>>>good if there are any *new* opinions. We don't need to hear opinions >>>>>repeated that we've seen so many times. >>>>> >>>>>I invite John once again to make a consensus call so we can move on >>>>>here. I think it is time to make progress and stop repeating ourselves, >>>>>we're not generating any new light in this rather endless discussion. >>>>> >>>>>Thanks, >>>>>Jerry >>>>> >>>>> >>>>> >>> >>> >>> --------------080108070404010408030804 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
The specification of Qspec1 is mandatory and therefore as I can see can not be avoided and
The parameter description in The Qspec-1 is more detalied than  Int.serv.
The reason for dividing NSIS in three layers was that Int.serv.  was too tightly built-into RSVP.
Now, I see that this benefit is gone and what's the gain with NSIS for QoS ?

If one just read the specification, and compare it with Int.serv. oe can conclude the following:
1) More parameters than Intserv. (excess treatment, priority???)
2) More functionality required for implementation even if its never used.

issues like :
how to model MEF bearer service definition ?????

...more layers with more functionality in each layer stacked on each other. I do not know what to do.....

regards Lasse



Kappler, Cornelia wrote:
Hi Lasse,
 
"specification of treatment of a flow" should be done in the QOSM Specs (e.g. RMD, CLS), it is not at an issue of the QSPEC.
 
The job of the QSPEC draft is to define a set of parameters that QOSM specs can choose from to define this treatment. (Would you agree this is a reasonable approach?)
 
if the collection of paramters does not limit the applicabillity of QoS-models that may be ok.

Could you more concretely point out where in the QSPEC a specific flow treatment is defined - beyond the (necessary) description of  how a particular parameter should be dealt with?
I have sent out pointer to Metro-Ethernet forum specification.
 
Cornelia

Von: Lars Westberg [mailto:Lars.westberg@ericsson.com]
Gesendet: Dienstag, 17. Oktober 2006 10:56
An: Kappler, Cornelia
Cc: Georgios Karagiannis; gash@att.com; nsis@ietf.org
Betreff: Re: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

comments inline

Kappler, Cornelia wrote:
Hi Lars,
 
could you explain why the qspec draft defines a new bearer service?
 
let's define it as "Specification of the Controlled-Load Network Element Service"
=>a specifiaction of treatment of a "flow".
What is a bearer service? This concept exists in 3GPP, but it does not exist in IETF I dont think, and I dont think the 3GPP definition is transferrable to IETF. So what exactly are you stating?
 
see above.
Cornelia

Von: Lars Westberg [mailto:Lars.westberg@ericsson.com]
Gesendet: Dienstag, 17. Oktober 2006 08:46
An: Georgios Karagiannis
Cc: gash@att.com; nsis@ietf.org
Betreff: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

yes.
the main problem is that IETF is not the only Standardization organization that like to discuss "bearer services". Just as an example :
If we specify the those parameters, How can we use NSIS for SLAs specified by MEF????

How can we use it for 3GPP-Qos definitiions ?


In the draft I also see  that we the draft specify a new bearer service. It is not compliant to old Int.serv architecture.  This is a completely new one with new parameters like priority.

I can sure that we can have a never-ending discussion about the "optimal"-set of parameters.

I think we agree in beggining the working group discussion that we should not specify any "bearer-service" because NSIS should be a modular architecture with  more flexibillity than RSVP.  Therefore, I am surprised that we are doing the same mistake as in RSVP: Integrating a bearer service definition into the NSIS-architecture.

If we go this track, the QoS-part of NSIS has much less use. RSVP is in this case significantly better in terms of performance and have the same functionality than NSIS.
If have to choose I would select RSVP rather than a much more complex  three layer protocol stack.

regards Lasse

Georgios Karagiannis wrote:
Hi Lars

Do you mean that the QSPEC template must not contain any mandatory
(QSPEC-1) parameters?


Best Regards,
Georgios



On 10/16/2006, "Lars Westberg" <Lars.westberg@ericsson.com> wrote:

  
Hi,
The template seems not to be a template because the mandatory part  is
more or less the same as Intserv.
The main idea with QoS-template was to make an modular solution that
could allow flexibillity for different Qos-models

Therefore, I do not understand the scope of the specification.

I suggest that we move the major part of the parameters to a separate
"Int.serv. over NSIS" specification.
Int.serv. can be seen as a common bearer service.

regards Lasse

Ash, Gerald R (Jerry), ALABS wrote:

    
Lars,

      
You mention in the below e-mail that there are no open issues,
while there is a huge discussion on the nsis mailing list
regarding the QSPEC-1 parameters.
        
John can call a different consensus if he sees one (I've asked him a
couple of times to do that).  What I saw was

1. Many posts supported the QSPEC-1 concept, only one (or maybe two) I
saw opposed.  The opposing view was repeated *many* times (and is still
being repeated) but it only counts as one opinion.
2. Many posts supported retaining the 4 QSPEC-1 parameters, only one I
saw opposed.  The opposing view was repeated many times.
3. There was only one opinion expressed to be able to ignore QSPEC-1
parameters.  That one opinion has been repeated many times but it only
counts as one opinion.

John asked a while ago for new opinions on these issues, that would be
good if there are any *new* opinions.  We don't need to hear opinions
repeated that we've seen so many times.

I invite John once again to make a consensus call so we can move on
here.  I think it is time to make progress and stop repeating ourselves,
we're not generating any new light in this rather endless discussion.

Thanks,
Jerry
--------------080108070404010408030804-- --===============0626872399== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0626872399==-- From nsis-bounces@ietf.org Tue Oct 17 09:03:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZobF-0004HU-RE; Tue, 17 Oct 2006 09:03:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZobE-0004Cc-0I for nsis@ietf.org; Tue, 17 Oct 2006 09:03:16 -0400 Received: from mclmx2.mail.saic.com ([149.8.64.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZobC-0005NH-Oy for nsis@ietf.org; Tue, 17 Oct 2006 09:03:15 -0400 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com; Tue, 17 Oct 2006 09:03:01 -0400 Received: from 0015-ITS-EXBH01.us.saic.com ([10.43.229.18]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006101709025912235 ; Tue, 17 Oct 2006 09:03:00 -0400 Received: from 0591-ITS-EXMP02.us.saic.com ([10.42.81.248]) by 0015-ITS-EXBH01.us.saic.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 09:02:58 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] QSPEC-issue (GK-2) Date: Tue, 17 Oct 2006 09:02:57 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426230EC5@0591-ITS-EXMP02.us.saic.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QSPEC-issue (GK-2) Thread-Index: AcbtanD6fn22GI49QTOs4tcmcnPXswEXnjhgAABCSLAAAPaEgAAAPjkQAAD9scAABe4EEA== From: "Roy, Radhika R." To: "Kappler, Cornelia" , "Georgios Karagiannis" , "Hannes Tschofenig" X-OriginalArrivalTime: 17 Oct 2006 13:02:58.0650 (UTC) FILETIME=[91C01BA0:01C6F1EC] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Folks: As we talked a million times before, so-called Y.1541 QOS classes are = based "values" like 50-ms, 100-ms, etc. while DiffSeve PHBs are based on = "characteristics" of services that are not dependent on any specific = "values." How can one map between "apples" and "oranges?" We cannot "generalize" all those "arbitrary" things in one single draft = as it stands on this QSPEC draft. Kindly see the "QSPEC Issue RRR-1." The only way to solve this problem is to write separate drafts for = specific implementations for Y.1541 and DSTE QOS classes separately. = Unlike RSVP QOS classes, these two QOS classes depend on some = "arbitrarily" defined some specific "values" decoupling from the = applications' needs with one-to-one mapping. Here the confusions some: = Mixing between "apples" and "oranges." As Georgios and others explained, there is no light at the end of this = tunnel unless deals with the suggestion provided in "QSPEC Issue RRR-1." Otherwise, as Georgios and others pointed out, more you dig-in = technically for proper interworking for implementations, more mud will = be split all around. Best regards, Radhika -----Original Message----- From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On Behalf Of = Kappler, Cornelia Sent: Tuesday, October 17, 2006 6:01 AM To: Georgios Karagiannis; Hannes Tschofenig Cc: nsis@ietf.org Subject: AW: [NSIS] QSPEC-issue (GK-2) Hi Georgios,=20 why do you think for example mapping Y.1541 Class 0 to PHB Expedited = Service (I think this is how its called) is useless? This is better than = having a Y.1541 Class 0 signaling arrive at a DiffSer domin and being = ignored!? Cornelia > -----Urspr=FCngliche Nachricht----- > Von: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 > Gesendet: Dienstag, 17. Oktober 2006 11:33 > An: Kappler, Cornelia; 'Hannes Tschofenig' > Cc: nsis@ietf.org > Betreff: RE: [NSIS] QSPEC-issue (GK-2) >=20 > Hi Cornelia >=20 > The reasonable maping can only be accomplished between: > Token Bucket (peak rate) =3D> Bandwidth > Higher (than normal) priority =3D> Normal priority > Lower (than normal) priority =3D> Normal priority >=20 > In my opinion other types of remappings (of other parameters)=20 > are either impossible or useless! >=20 > Best Regards, > Georgios >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 17 10:01:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZpUu-0000Sg-GT; Tue, 17 Oct 2006 10:00:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZpUr-0000RB-GV for nsis@ietf.org; Tue, 17 Oct 2006 10:00:45 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZpGc-0001oS-Ct for nsis@ietf.org; Tue, 17 Oct 2006 09:46:08 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k9HDilax017511; Tue, 17 Oct 2006 15:45:01 +0200 (MEST) From: "Georgios Karagiannis" To: "'Lars Westberg'" , "'Kappler, Cornelia'" Date: Tue, 17 Oct 2006 15:44:44 +0200 Message-ID: <007601c6f1f2$6fdf4280$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4534CD6E.1050507@ericsson.com> Thread-Index: Acbx6Fu2ZO3jQza1RUeK1cdAVLHJiAACSg7Q X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: -4.887 () ALL_TRUSTED, AWL, BAYES_00, FVGT_s_OBFU_Q1, HTML_50_60, HTML_MESSAGE, HTML_TITLE_EMPTY, J_CHICKENPOX_34, J_CHICKENPOX_41 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Tue, 17 Oct 2006 15:45:07 +0200 (MEST) X-Spam-Score: 0.1 (/) X-Scan-Signature: bc751b94b9e719c152b6b70b67620ccf Cc: gash@att.com, nsis@ietf.org Subject: [NSIS] remove QSPEC-1 (mandatory) parameters from QSPEC template draft X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0705918085==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0705918085== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0077_01C6F203.33681280" This is a multi-part message in MIME format. ------=_NextPart_000_0077_01C6F203.33681280 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Lars So, what you actually say is that it would be quite impossible to deploy NSIS based QoS solutions in e.g., 3GPP or MEF (Metro-Ethernet Forum), if the QSEPC template draft specifies the use of any mandatory (QSPEC-1) parameters. Best Regards, Georgios _____ From: Lars Westberg [mailto:Lars.westberg@ericsson.com] Sent: dinsdag 17 oktober 2006 14:33 To: Kappler, Cornelia Cc: Georgios Karagiannis; gash@att.com; nsis@ietf.org Subject: Re: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt The specification of Qspec1 is mandatory and therefore as I can see can not be avoided and The parameter description in The Qspec-1 is more detalied than Int.serv. The reason for dividing NSIS in three layers was that Int.serv. was too tightly built-into RSVP. Now, I see that this benefit is gone and what's the gain with NSIS for QoS ? If one just read the specification, and compare it with Int.serv. oe can conclude the following: 1) More parameters than Intserv. (excess treatment, priority???) 2) More functionality required for implementation even if its never used. issues like : how to model MEF bearer service definition ????? ...more layers with more functionality in each layer stacked on each other. I do not know what to do..... regards Lasse Kappler, Cornelia wrote: Hi Lasse, "specification of treatment of a flow" should be done in the QOSM Specs (e.g. RMD, CLS), it is not at an issue of the QSPEC. The job of the QSPEC draft is to define a set of parameters that QOSM specs can choose from to define this treatment. (Would you agree this is a reasonable approach?) if the collection of paramters does not limit the applicabillity of QoS-models that may be ok. Could you more concretely point out where in the QSPEC a specific flow treatment is defined - beyond the (necessary) description of how a particular parameter should be dealt with? I have sent out pointer to Metro-Ethernet forum specification. Cornelia _____ Von: Lars Westberg [mailto:Lars.westberg@ericsson.com] Gesendet: Dienstag, 17. Oktober 2006 10:56 An: Kappler, Cornelia Cc: Georgios Karagiannis; gash@att.com; nsis@ietf.org Betreff: Re: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt comments inline Kappler, Cornelia wrote: Hi Lars, could you explain why the qspec draft defines a new bearer service? let's define it as "Specification of the Controlled-Load Network Element Service" =>a specifiaction of treatment of a "flow". What is a bearer service? This concept exists in 3GPP, but it does not exist in IETF I dont think, and I dont think the 3GPP definition is transferrable to IETF. So what exactly are you stating? see above. Cornelia _____ Von: Lars Westberg [mailto:Lars.westberg@ericsson.com] Gesendet: Dienstag, 17. Oktober 2006 08:46 An: Georgios Karagiannis Cc: gash@att.com; nsis@ietf.org Betreff: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt yes. the main problem is that IETF is not the only Standardization organization that like to discuss "bearer services". Just as an example : If we specify the those parameters, How can we use NSIS for SLAs specified by MEF???? How can we use it for 3GPP-Qos definitiions ? In the draft I also see that we the draft specify a new bearer service. It is not compliant to old Int.serv architecture. This is a completely new one with new parameters like priority. I can sure that we can have a never-ending discussion about the "optimal"-set of parameters. I think we agree in beggining the working group discussion that we should not specify any "bearer-service" because NSIS should be a modular architecture with more flexibillity than RSVP. Therefore, I am surprised that we are doing the same mistake as in RSVP: Integrating a bearer service definition into the NSIS-architecture. If we go this track, the QoS-part of NSIS has much less use. RSVP is in this case significantly better in terms of performance and have the same functionality than NSIS. If have to choose I would select RSVP rather than a much more complex three layer protocol stack. regards Lasse Georgios Karagiannis wrote: Hi Lars Do you mean that the QSPEC template must not contain any mandatory (QSPEC-1) parameters? Best Regards, Georgios On 10/16/2006, "Lars Westberg" wrote: Hi, The template seems not to be a template because the mandatory part is more or less the same as Intserv. The main idea with QoS-template was to make an modular solution that could allow flexibillity for different Qos-models Therefore, I do not understand the scope of the specification. I suggest that we move the major part of the parameters to a separate "Int.serv. over NSIS" specification. Int.serv. can be seen as a common bearer service. regards Lasse Ash, Gerald R (Jerry), ALABS wrote: Lars, You mention in the below e-mail that there are no open issues, while there is a huge discussion on the nsis mailing list regarding the QSPEC-1 parameters. John can call a different consensus if he sees one (I've asked him a couple of times to do that). What I saw was 1. Many posts supported the QSPEC-1 concept, only one (or maybe two) I saw opposed. The opposing view was repeated *many* times (and is still being repeated) but it only counts as one opinion. 2. Many posts supported retaining the 4 QSPEC-1 parameters, only one I saw opposed. The opposing view was repeated many times. 3. There was only one opinion expressed to be able to ignore QSPEC-1 parameters. That one opinion has been repeated many times but it only counts as one opinion. John asked a while ago for new opinions on these issues, that would be good if there are any *new* opinions. We don't need to hear opinions repeated that we've seen so many times. I invite John once again to make a consensus call so we can move on here. I think it is time to make progress and stop repeating ourselves, we're not generating any new light in this rather endless discussion. Thanks, Jerry ------=_NextPart_000_0077_01C6F203.33681280 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Lars
 
So, what you actually say is that it would be = quite=20 impossible to
deploy NSIS based QoS  solutions in e.g., = 3GPP or MEF=20 (Metro-Ethernet Forum), if
the QSEPC=20 template draft specifies the use of
any mandatory (QSPEC-1) = parameters.
 
Best Regards,
Georgios
 
 
 
 
 
 

From: Lars Westberg=20 [mailto:Lars.westberg@ericsson.com]
Sent: dinsdag 17 = oktober 2006=20 14:33
To: Kappler, Cornelia
Cc: Georgios = Karagiannis;=20 gash@att.com; nsis@ietf.org
Subject: Re: AW: AW: [NSIS] I-D=20 ACTION:draft-ietf-nsis-qspec-12.txt


The specification of Qspec1 is mandatory and therefore = as I can=20 see can not be avoided and
The parameter description in The Qspec-1 = is more=20 detalied than  Int.serv.
The reason for dividing NSIS in three = layers=20 was that Int.serv.  was too tightly built-into RSVP.
Now, I = see that=20 this benefit is gone and what's the gain with NSIS for QoS ?

If = one=20 just read the specification, and compare it with Int.serv. oe can = conclude the=20 following:
1) More parameters than Intserv. (excess treatment,=20 priority???)
2) More functionality required for implementation even = if its=20 never used.

issues like :
how to model MEF bearer service = definition=20 ?????

...more layers with more functionality in each layer = stacked on=20 each other. I do not know what to do.....

regards=20 Lasse



Kappler, Cornelia wrote:
Hi Lasse,
 
"specification of treatment of a flow" = should be done=20 in the QOSM Specs (e.g. RMD, CLS), it is not at an issue of the = QSPEC.=20
 
The job of the QSPEC draft is to define a = set of=20 parameters that QOSM specs can choose from to define this treatment. = (Would=20 you agree this is a reasonable approach?)
 
if the = collection of=20 paramters does not limit the applicabillity of QoS-models that may be = ok.=20

Could you more concretely point out where = in the QSPEC=20 a specific flow treatment is defined - beyond the=20 (necessary) description of  how a particular parameter = should be=20 dealt with?
I have sent out pointer = to=20 Metro-Ethernet forum specification.
 
Cornelia

Von: Lars Westberg [mailto:Lars.westberg@ericsson.= com]=20
Gesendet: Dienstag, 17. Oktober 2006 = 10:56
An:=20 Kappler, Cornelia
Cc: Georgios Karagiannis; gash@att.com; nsis@ietf.org
Betreff: = Re: AW:=20 [NSIS] I-D=20 ACTION:draft-ietf-nsis-qspec-12.txt

comments=20 inline

Kappler, Cornelia wrote:
Hi Lars,
 
could you explain why the qspec draft = defines a new=20 bearer service?
 
let's = define it as=20 "Specification of the Controlled-Load Network Element=20 Service"
=3D>a specifiaction of treatment of a "flow". =
What is a bearer service? This concept = exists in=20 3GPP, but it does not exist in IETF I dont think, and I dont = think the=20 3GPP definition is transferrable to IETF. So what exactly are = you=20 stating?
 
see above. =
Cornelia

Von: Lars Westberg [mailto:Lars.westberg@ericsson.= com]=20
Gesendet: Dienstag, 17. Oktober 2006 = 08:46
An:=20 Georgios Karagiannis
Cc: gash@att.com; nsis@ietf.org
Betreff: Re:=20 [NSIS] I-D=20 ACTION:draft-ietf-nsis-qspec-12.txt

yes. =
the=20 main problem is that IETF is not the only Standardization = organization=20 that like to discuss "bearer services". Just as an example = :
If we=20 specify the those parameters, How can we use NSIS for SLAs = specified=20 by MEF????

How can we use it for 3GPP-Qos definitiions=20 ?


In the draft I also see  that we the draft = specify a=20 new bearer service. It is not compliant to old Int.serv=20 architecture.  This is a completely new one with new = parameters=20 like priority.

I can sure that we can have a = never-ending=20 discussion about the "optimal"-set of parameters.

I = think we=20 agree in beggining the working group discussion that we should = not=20 specify any "bearer-service" because NSIS should be a modular=20 architecture with  more flexibillity than RSVP.  = Therefore,=20 I am surprised that we are doing the same mistake as in RSVP:=20 Integrating a bearer service definition into the=20 NSIS-architecture.

If we go this track, the QoS-part of = NSIS=20 has much less use. RSVP is in this case significantly better = in terms=20 of performance and have the same functionality than = NSIS.
If have=20 to choose I would select RSVP rather than a much more = complex =20 three layer protocol stack.

regards = Lasse

Georgios=20 Karagiannis wrote:
Hi Lars

Do you mean that the QSPEC template must not contain any mandatory
(QSPEC-1) parameters?


Best Regards,
Georgios



On 10/16/2006, "Lars Westberg" <Lars.westberg@ericsson.com=
> wrote:

  
Hi,
The template seems not to be a template because the mandatory part  is
more or less the same as Intserv.
The main idea with QoS-template was to make an modular solution that
could allow flexibillity for different Qos-models

Therefore, I do not understand the scope of the specification.

I suggest that we move the major part of the parameters to a separate
"Int.serv. over NSIS" specification.
Int.serv. can be seen as a common bearer service.

regards Lasse

Ash, Gerald R (Jerry), ALABS wrote:

    
Lars,

      
You mention in =
the below e-mail that there are no open issues,
while there is a huge discussion on the nsis mailing list
regarding the QSPEC-1 parameters.
        
John can call a different =
consensus if he sees one (I've asked him a
couple of times to do that).  What I saw was

1. Many posts supported the QSPEC-1 concept, only one (or maybe two) I
saw opposed.  The opposing view was repeated *many* times (and is still
being repeated) but it only counts as one opinion.
2. Many posts supported retaining the 4 QSPEC-1 parameters, only one I
saw opposed.  The opposing view was repeated many times.
3. There was only one opinion expressed to be able to ignore QSPEC-1
parameters.  That one opinion has been repeated many times but it only
counts as one opinion.

John asked a while ago for new opinions on these issues, that would be
good if there are any *new* opinions.  We don't need to hear opinions
repeated that we've seen so many times.

I invite John once again to make a consensus call so we can move on
here.  I think it is time to make progress and stop repeating ourselves,
we're not generating any new light in this rather endless discussion.

Thanks,
Jerry

      

  =
------=_NextPart_000_0077_01C6F203.33681280-- --===============0705918085== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0705918085==-- From nsis-bounces@ietf.org Tue Oct 17 10:01:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZpVF-0000gc-Jx; Tue, 17 Oct 2006 10:01:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZpVD-0000fu-VQ for nsis@ietf.org; Tue, 17 Oct 2006 10:01:07 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZpV1-0003iK-AV for nsis@ietf.org; Tue, 17 Oct 2006 10:01:07 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k9HE0Rxk027374 for ; Tue, 17 Oct 2006 15:00:27 +0100 Received: from victor ([193.118.192.66]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 15:00:26 +0100 From: "Robert Hancock" To: Date: Tue, 17 Oct 2006 16:00:44 +0200 Message-ID: <008b01c6f1f4$a44ecde0$946b0a0a@comm.ad.roke.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <62D92A9A02BCC845B202323D49A48426230EC5@0591-ITS-EXMP02.us.saic.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-OriginalArrivalTime: 17 Oct 2006 14:00:26.0893 (UTC) FILETIME=[99103BD0:01C6F1F4] X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Subject: [NSIS] a comment on type-1/type-2 QSPEC parameters X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Dear all, Without wanting to get too hung up on exactly which parameters should be 'globally supported/mandatory/[insert your favourite terminology here]' = and which should not, I'd like to re-iterate what I believe is the benefit = of the Type-1 parameter concept in the first place. In several external reviews of NSIS (within the IETF but partly outside = the working group), it's my impression that there was a real worry about how = the flexibility that the original QoS-NSLP/QSPEC concepts allowed would harm interoperability - in other words, that it would be commonplace for = people to issue reservations which were completely not understood by downstream domains. (Just look at the early review minutes from Korea, for = example.)=20 The Type-1 parameter concept is an attempt (IMHO a good one) to address = that problem, by providing a minimal parameter set which everyone = understands. We can argue about which parameters should be Type-1, but I think that if = the concept itself is dropped and we just allow a free-for-all in QSPEC parameters, then it will be a major barrier to getting this work through = the forthcoming review stages. For the sake of argument, I'd be interested to know if there are people = who really can argue that the token bucket (or bandwidth, which is just a degenerate token bucket really) cannot be handled correctly as a Type-1 parameter. If they cannot, I think that this would at least validate the conceptual structure of the QSPEC - we could still discuss the other parameters. Lars - I'm a bit confused about your references to MEF7. MEF7 is about an information model for network management; I wouldn't really expect the = QSPEC to be relevant here. Surely the appropriate comparison is with MEF10 ("Ethernet Services Attributes"). Not entirely surprisingly, MEF10 = expresses its bandwidth profiles in terms of token bucket parameters. Doesn't that rather prove the point? cheers, Robert H. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 17 10:01:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZpUt-0000Sb-T8; Tue, 17 Oct 2006 10:00:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZpUr-0000Nn-0x for nsis@ietf.org; Tue, 17 Oct 2006 10:00:45 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZpGh-0001ow-0R for nsis@ietf.org; Tue, 17 Oct 2006 09:46:16 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9HDjM1i008594; Tue, 17 Oct 2006 16:45:23 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 16:45:22 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 16:45:22 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Date: Tue, 17 Oct 2006 16:45:21 +0300 Message-ID: In-Reply-To: <45347C10.6090602@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Thread-Index: AcbxuHtQ92fBk4GyRnaw38rAcCkjiQAOXHnQ From: To: , X-OriginalArrivalTime: 17 Oct 2006 13:45:22.0779 (UTC) FILETIME=[7E2B62B0:01C6F1F2] X-Spam-Score: 0.3 (/) X-Scan-Signature: 6b519fb0ef66258f34533f52ff46aedf Cc: gash@att.com, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0413853606==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0413853606== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F1F2.7D8C799B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F1F2.7D8C799B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There was a proposal for a QoS model on 3GPP QoS model, by the way. http://www.watersprings.org/pub/id/draft-jeong-nsis-3gpp-qosm-02.txt =20 However, I think that we are going circular. The QSPEC defines a general model for being able to support different QoS Models. We were asked to look at how to support different models, including Y1541, by our AD at the time and by ITU-T liasons. =20 If you feel that things are too complicated, I would suggest you send a list of what you consider to be mandatory and what is optional (or in otherwords, what is essential and what is not). It could be that we have created something that is more complicated than what is generally needed, but then we need a counter proposal. =20 thanks, John =20 ________________________________ From: ext Lars Westberg [mailto:Lars.westberg@ericsson.com]=20 Sent: 16 October, 2006 23:46 To: Georgios Karagiannis Cc: gash@att.com; nsis@ietf.org Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt =09 =09 yes.=20 the main problem is that IETF is not the only Standardization organization that like to discuss "bearer services". Just as an example : If we specify the those parameters, How can we use NSIS for SLAs specified by MEF???? =09 How can we use it for 3GPP-Qos definitiions ? =09 =09 In the draft I also see that we the draft specify a new bearer service. It is not compliant to old Int.serv architecture. This is a completely new one with new parameters like priority. =09 I can sure that we can have a never-ending discussion about the "optimal"-set of parameters. =09 I think we agree in beggining the working group discussion that we should not specify any "bearer-service" because NSIS should be a modular architecture with more flexibillity than RSVP. Therefore, I am surprised that we are doing the same mistake as in RSVP: Integrating a bearer service definition into the NSIS-architecture. =09 If we go this track, the QoS-part of NSIS has much less use. RSVP is in this case significantly better in terms of performance and have the same functionality than NSIS. If have to choose I would select RSVP rather than a much more complex three layer protocol stack. =09 regards Lasse =09 Georgios Karagiannis wrote: =09 Hi Lars =09 Do you mean that the QSPEC template must not contain any mandatory (QSPEC-1) parameters? =09 =09 Best Regards, Georgios =09 =09 =09 On 10/16/2006, "Lars Westberg" wrote: =09 =20 Hi, The template seems not to be a template because the mandatory part is more or less the same as Intserv. The main idea with QoS-template was to make an modular solution that could allow flexibillity for different Qos-models =09 Therefore, I do not understand the scope of the specification. =09 I suggest that we move the major part of the parameters to a separate "Int.serv. over NSIS" specification. Int.serv. can be seen as a common bearer service. =09 regards Lasse =09 Ash, Gerald R (Jerry), ALABS wrote: =09 =20 Lars, =09 =20 You mention in the below e-mail that there are no open issues, while there is a huge discussion on the nsis mailing list regarding the QSPEC-1 parameters. =20 John can call a different consensus if he sees one (I've asked him a couple of times to do that). What I saw was =09 1. Many posts supported the QSPEC-1 concept, only one (or maybe two) I saw opposed. The opposing view was repeated *many* times (and is still being repeated) but it only counts as one opinion. 2. Many posts supported retaining the 4 QSPEC-1 parameters, only one I saw opposed. The opposing view was repeated many times. 3. There was only one opinion expressed to be able to ignore QSPEC-1 parameters. That one opinion has been repeated many times but it only counts as one opinion. =09 John asked a while ago for new opinions on these issues, that would be good if there are any *new* opinions. We don't need to hear opinions repeated that we've seen so many times. =09 I invite John once again to make a consensus call so we can move on here. I think it is time to make progress and stop repeating ourselves, we're not generating any new light in this rather endless discussion. =09 Thanks, Jerry =09 =20 =09 =20 ------_=_NextPart_001_01C6F1F2.7D8C799B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
There was a proposal for a QoS model on 3GPP = QoS model, by=20 the way.
http://www.watersprings.org/pub/id/draft-jeong-nsis-3gpp-qosm-02.txt=
 
However, I think that we are going = circular.  The=20 QSPEC defines a general model for being able to support different QoS=20 Models.  We were asked to look at how to support different models,=20 including Y1541, by our AD at the time and by ITU-T = liasons.
 
If you feel that things are too complicated, I = would=20 suggest you send a list of what you consider to be mandatory and what is = optional (or in otherwords, what is essential and what is not).  It = could=20 be that we have created something that is more complicated than what is=20 generally needed, but then we need a counter = proposal.
 
thanks,
John
 

From: ext Lars Westberg=20 [mailto:Lars.westberg@ericsson.com]
Sent: 16 October, 2006=20 23:46
To: Georgios Karagiannis
Cc: gash@att.com;=20 nsis@ietf.org
Subject: Re: [NSIS] I-D=20 ACTION:draft-ietf-nsis-qspec-12.txt

yes.
the main problem is that IETF is not the only=20 Standardization organization that like to discuss "bearer services". = Just as=20 an example :
If we specify the those parameters, How can we use = NSIS for=20 SLAs specified by MEF????

How can we use it for 3GPP-Qos = definitiions=20 ?


In the draft I also see  that we the draft specify a = new=20 bearer service. It is not compliant to old Int.serv = architecture.  This=20 is a completely new one with new parameters like priority.

I = can sure=20 that we can have a never-ending discussion about the "optimal"-set of=20 parameters.

I think we agree in beggining the working group = discussion=20 that we should not specify any "bearer-service" because NSIS should be = a=20 modular architecture with  more flexibillity than RSVP.  = Therefore,=20 I am surprised that we are doing the same mistake as in RSVP: = Integrating a=20 bearer service definition into the NSIS-architecture.

If we go = this=20 track, the QoS-part of NSIS has much less use. RSVP is in this case=20 significantly better in terms of performance and have the same = functionality=20 than NSIS.
If have to choose I would select RSVP rather than a much = more=20 complex  three layer protocol stack.

regards = Lasse

Georgios=20 Karagiannis wrote:
Hi Lars

Do you mean that the QSPEC template must not contain any mandatory
(QSPEC-1) parameters?


Best Regards,
Georgios



On 10/16/2006, "Lars Westberg" <Lars.westberg@ericsson.com=
> wrote:

  
Hi,
The template seems not to be a template because the mandatory part  is
more or less the same as Intserv.
The main idea with QoS-template was to make an modular solution that
could allow flexibillity for different Qos-models

Therefore, I do not understand the scope of the specification.

I suggest that we move the major part of the parameters to a separate
"Int.serv. over NSIS" specification.
Int.serv. can be seen as a common bearer service.

regards Lasse

Ash, Gerald R (Jerry), ALABS wrote:

    
Lars,

      
You mention in the =
below e-mail that there are no open issues,
while there is a huge discussion on the nsis mailing list
regarding the QSPEC-1 parameters.
        
John can call a different =
consensus if he sees one (I've asked him a
couple of times to do that).  What I saw was

1. Many posts supported the QSPEC-1 concept, only one (or maybe two) I
saw opposed.  The opposing view was repeated *many* times (and is still
being repeated) but it only counts as one opinion.
2. Many posts supported retaining the 4 QSPEC-1 parameters, only one I
saw opposed.  The opposing view was repeated many times.
3. There was only one opinion expressed to be able to ignore QSPEC-1
parameters.  That one opinion has been repeated many times but it only
counts as one opinion.

John asked a while ago for new opinions on these issues, that would be
good if there are any *new* opinions.  We don't need to hear opinions
repeated that we've seen so many times.

I invite John once again to make a consensus call so we can move on
here.  I think it is time to make progress and stop repeating ourselves,
we're not generating any new light in this rather endless discussion.

Thanks,
Jerry
------_=_NextPart_001_01C6F1F2.7D8C799B-- --===============0413853606== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0413853606==-- From nsis-bounces@ietf.org Tue Oct 17 10:01:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZpVF-0000gc-Jx; Tue, 17 Oct 2006 10:01:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZpVD-0000fu-VQ for nsis@ietf.org; Tue, 17 Oct 2006 10:01:07 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZpV1-0003iK-AV for nsis@ietf.org; Tue, 17 Oct 2006 10:01:07 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k9HE0Rxk027374 for ; Tue, 17 Oct 2006 15:00:27 +0100 Received: from victor ([193.118.192.66]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 15:00:26 +0100 From: "Robert Hancock" To: Date: Tue, 17 Oct 2006 16:00:44 +0200 Message-ID: <008b01c6f1f4$a44ecde0$946b0a0a@comm.ad.roke.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <62D92A9A02BCC845B202323D49A48426230EC5@0591-ITS-EXMP02.us.saic.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-OriginalArrivalTime: 17 Oct 2006 14:00:26.0893 (UTC) FILETIME=[99103BD0:01C6F1F4] X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Subject: [NSIS] a comment on type-1/type-2 QSPEC parameters X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Dear all, Without wanting to get too hung up on exactly which parameters should be 'globally supported/mandatory/[insert your favourite terminology here]' = and which should not, I'd like to re-iterate what I believe is the benefit = of the Type-1 parameter concept in the first place. In several external reviews of NSIS (within the IETF but partly outside = the working group), it's my impression that there was a real worry about how = the flexibility that the original QoS-NSLP/QSPEC concepts allowed would harm interoperability - in other words, that it would be commonplace for = people to issue reservations which were completely not understood by downstream domains. (Just look at the early review minutes from Korea, for = example.)=20 The Type-1 parameter concept is an attempt (IMHO a good one) to address = that problem, by providing a minimal parameter set which everyone = understands. We can argue about which parameters should be Type-1, but I think that if = the concept itself is dropped and we just allow a free-for-all in QSPEC parameters, then it will be a major barrier to getting this work through = the forthcoming review stages. For the sake of argument, I'd be interested to know if there are people = who really can argue that the token bucket (or bandwidth, which is just a degenerate token bucket really) cannot be handled correctly as a Type-1 parameter. If they cannot, I think that this would at least validate the conceptual structure of the QSPEC - we could still discuss the other parameters. Lars - I'm a bit confused about your references to MEF7. MEF7 is about an information model for network management; I wouldn't really expect the = QSPEC to be relevant here. Surely the appropriate comparison is with MEF10 ("Ethernet Services Attributes"). Not entirely surprisingly, MEF10 = expresses its bandwidth profiles in terms of token bucket parameters. Doesn't that rather prove the point? cheers, Robert H. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 17 10:01:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZpUt-0000Sb-T8; Tue, 17 Oct 2006 10:00:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZpUr-0000Nn-0x for nsis@ietf.org; Tue, 17 Oct 2006 10:00:45 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZpGh-0001ow-0R for nsis@ietf.org; Tue, 17 Oct 2006 09:46:16 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9HDjM1i008594; Tue, 17 Oct 2006 16:45:23 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 16:45:22 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 16:45:22 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Date: Tue, 17 Oct 2006 16:45:21 +0300 Message-ID: In-Reply-To: <45347C10.6090602@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Thread-Index: AcbxuHtQ92fBk4GyRnaw38rAcCkjiQAOXHnQ From: To: , X-OriginalArrivalTime: 17 Oct 2006 13:45:22.0779 (UTC) FILETIME=[7E2B62B0:01C6F1F2] X-Spam-Score: 0.3 (/) X-Scan-Signature: 6b519fb0ef66258f34533f52ff46aedf Cc: gash@att.com, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0413853606==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0413853606== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F1F2.7D8C799B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F1F2.7D8C799B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There was a proposal for a QoS model on 3GPP QoS model, by the way. http://www.watersprings.org/pub/id/draft-jeong-nsis-3gpp-qosm-02.txt =20 However, I think that we are going circular. The QSPEC defines a general model for being able to support different QoS Models. We were asked to look at how to support different models, including Y1541, by our AD at the time and by ITU-T liasons. =20 If you feel that things are too complicated, I would suggest you send a list of what you consider to be mandatory and what is optional (or in otherwords, what is essential and what is not). It could be that we have created something that is more complicated than what is generally needed, but then we need a counter proposal. =20 thanks, John =20 ________________________________ From: ext Lars Westberg [mailto:Lars.westberg@ericsson.com]=20 Sent: 16 October, 2006 23:46 To: Georgios Karagiannis Cc: gash@att.com; nsis@ietf.org Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt =09 =09 yes.=20 the main problem is that IETF is not the only Standardization organization that like to discuss "bearer services". Just as an example : If we specify the those parameters, How can we use NSIS for SLAs specified by MEF???? =09 How can we use it for 3GPP-Qos definitiions ? =09 =09 In the draft I also see that we the draft specify a new bearer service. It is not compliant to old Int.serv architecture. This is a completely new one with new parameters like priority. =09 I can sure that we can have a never-ending discussion about the "optimal"-set of parameters. =09 I think we agree in beggining the working group discussion that we should not specify any "bearer-service" because NSIS should be a modular architecture with more flexibillity than RSVP. Therefore, I am surprised that we are doing the same mistake as in RSVP: Integrating a bearer service definition into the NSIS-architecture. =09 If we go this track, the QoS-part of NSIS has much less use. RSVP is in this case significantly better in terms of performance and have the same functionality than NSIS. If have to choose I would select RSVP rather than a much more complex three layer protocol stack. =09 regards Lasse =09 Georgios Karagiannis wrote: =09 Hi Lars =09 Do you mean that the QSPEC template must not contain any mandatory (QSPEC-1) parameters? =09 =09 Best Regards, Georgios =09 =09 =09 On 10/16/2006, "Lars Westberg" wrote: =09 =20 Hi, The template seems not to be a template because the mandatory part is more or less the same as Intserv. The main idea with QoS-template was to make an modular solution that could allow flexibillity for different Qos-models =09 Therefore, I do not understand the scope of the specification. =09 I suggest that we move the major part of the parameters to a separate "Int.serv. over NSIS" specification. Int.serv. can be seen as a common bearer service. =09 regards Lasse =09 Ash, Gerald R (Jerry), ALABS wrote: =09 =20 Lars, =09 =20 You mention in the below e-mail that there are no open issues, while there is a huge discussion on the nsis mailing list regarding the QSPEC-1 parameters. =20 John can call a different consensus if he sees one (I've asked him a couple of times to do that). What I saw was =09 1. Many posts supported the QSPEC-1 concept, only one (or maybe two) I saw opposed. The opposing view was repeated *many* times (and is still being repeated) but it only counts as one opinion. 2. Many posts supported retaining the 4 QSPEC-1 parameters, only one I saw opposed. The opposing view was repeated many times. 3. There was only one opinion expressed to be able to ignore QSPEC-1 parameters. That one opinion has been repeated many times but it only counts as one opinion. =09 John asked a while ago for new opinions on these issues, that would be good if there are any *new* opinions. We don't need to hear opinions repeated that we've seen so many times. =09 I invite John once again to make a consensus call so we can move on here. I think it is time to make progress and stop repeating ourselves, we're not generating any new light in this rather endless discussion. =09 Thanks, Jerry =09 =20 =09 =20 ------_=_NextPart_001_01C6F1F2.7D8C799B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
There was a proposal for a QoS model on 3GPP = QoS model, by=20 the way.
http://www.watersprings.org/pub/id/draft-jeong-nsis-3gpp-qosm-02.txt=
 
However, I think that we are going = circular.  The=20 QSPEC defines a general model for being able to support different QoS=20 Models.  We were asked to look at how to support different models,=20 including Y1541, by our AD at the time and by ITU-T = liasons.
 
If you feel that things are too complicated, I = would=20 suggest you send a list of what you consider to be mandatory and what is = optional (or in otherwords, what is essential and what is not).  It = could=20 be that we have created something that is more complicated than what is=20 generally needed, but then we need a counter = proposal.
 
thanks,
John
 

From: ext Lars Westberg=20 [mailto:Lars.westberg@ericsson.com]
Sent: 16 October, 2006=20 23:46
To: Georgios Karagiannis
Cc: gash@att.com;=20 nsis@ietf.org
Subject: Re: [NSIS] I-D=20 ACTION:draft-ietf-nsis-qspec-12.txt

yes.
the main problem is that IETF is not the only=20 Standardization organization that like to discuss "bearer services". = Just as=20 an example :
If we specify the those parameters, How can we use = NSIS for=20 SLAs specified by MEF????

How can we use it for 3GPP-Qos = definitiions=20 ?


In the draft I also see  that we the draft specify a = new=20 bearer service. It is not compliant to old Int.serv = architecture.  This=20 is a completely new one with new parameters like priority.

I = can sure=20 that we can have a never-ending discussion about the "optimal"-set of=20 parameters.

I think we agree in beggining the working group = discussion=20 that we should not specify any "bearer-service" because NSIS should be = a=20 modular architecture with  more flexibillity than RSVP.  = Therefore,=20 I am surprised that we are doing the same mistake as in RSVP: = Integrating a=20 bearer service definition into the NSIS-architecture.

If we go = this=20 track, the QoS-part of NSIS has much less use. RSVP is in this case=20 significantly better in terms of performance and have the same = functionality=20 than NSIS.
If have to choose I would select RSVP rather than a much = more=20 complex  three layer protocol stack.

regards = Lasse

Georgios=20 Karagiannis wrote:
Hi Lars

Do you mean that the QSPEC template must not contain any mandatory
(QSPEC-1) parameters?


Best Regards,
Georgios



On 10/16/2006, "Lars Westberg" <Lars.westberg@ericsson.com=
> wrote:

  
Hi,
The template seems not to be a template because the mandatory part  is
more or less the same as Intserv.
The main idea with QoS-template was to make an modular solution that
could allow flexibillity for different Qos-models

Therefore, I do not understand the scope of the specification.

I suggest that we move the major part of the parameters to a separate
"Int.serv. over NSIS" specification.
Int.serv. can be seen as a common bearer service.

regards Lasse

Ash, Gerald R (Jerry), ALABS wrote:

    
Lars,

      
You mention in the =
below e-mail that there are no open issues,
while there is a huge discussion on the nsis mailing list
regarding the QSPEC-1 parameters.
        
John can call a different =
consensus if he sees one (I've asked him a
couple of times to do that).  What I saw was

1. Many posts supported the QSPEC-1 concept, only one (or maybe two) I
saw opposed.  The opposing view was repeated *many* times (and is still
being repeated) but it only counts as one opinion.
2. Many posts supported retaining the 4 QSPEC-1 parameters, only one I
saw opposed.  The opposing view was repeated many times.
3. There was only one opinion expressed to be able to ignore QSPEC-1
parameters.  That one opinion has been repeated many times but it only
counts as one opinion.

John asked a while ago for new opinions on these issues, that would be
good if there are any *new* opinions.  We don't need to hear opinions
repeated that we've seen so many times.

I invite John once again to make a consensus call so we can move on
here.  I think it is time to make progress and stop repeating ourselves,
we're not generating any new light in this rather endless discussion.

Thanks,
Jerry
------_=_NextPart_001_01C6F1F2.7D8C799B-- --===============0413853606== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0413853606==-- From nsis-bounces@ietf.org Tue Oct 17 10:03:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZpX2-0001pC-7E; Tue, 17 Oct 2006 10:03:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZpX0-0001p2-7T for nsis@ietf.org; Tue, 17 Oct 2006 10:02:58 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZpWu-0003to-JL for nsis@ietf.org; Tue, 17 Oct 2006 10:02:58 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9HE2mCo032051; Tue, 17 Oct 2006 17:02:48 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 17:02:49 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 17:02:49 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] QSPEC-issue (GK-2) Date: Tue, 17 Oct 2006 17:02:47 +0300 Message-ID: In-Reply-To: <005501c6f1e7$aa5d79f0$4c0d5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QSPEC-issue (GK-2) Thread-Index: AcbtanD6fn22GI49QTOs4tcmcnPXswEXnjhgAAeTNOAAA2Hx8A== From: To: , , X-OriginalArrivalTime: 17 Oct 2006 14:02:49.0058 (UTC) FILETIME=[EDCCE420:01C6F1F4] X-Spam-Score: 0.2 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Georgios, Cornelia explained how she thought it would work with CL. I agree with her that I think that should be a sufficient solutions. Is your objection based upon the total number of Mandatory Parameters? Too many parameters in general? John=20 >-----Original Message----- >From: ext Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 >Sent: 17 October, 2006 05:28 >To: 'Kappler, Cornelia'; 'Hannes Tschofenig' >Cc: nsis@ietf.org >Subject: RE: [NSIS] QSPEC-issue (GK-2) > >Hi Cornelia > >Sorry, but in this way you define two new parameters and that=20 >are high class and low class! >In addition to the 13 mandatory parameters we will add other two.=20 >Thus the QNEs will have to support 15 mandatory parameters. >Sorry but it becomes more complicated, than when just having=20 >13 mandatory parameters. > > >Best Regards, >Georgios > > >> -----Original Message----- >> From: Kappler, Cornelia [mailto:cornelia.kappler@siemens.com]=20 >> Sent: dinsdag 17 oktober 2006 10:52 >> To: Hannes Tschofenig; Georgios Karagiannis >> Cc: nsis@ietf.org >> Subject: AW: [NSIS] QSPEC-issue (GK-2) >>=20 >> Hi Georgios and Hannes,=20 >>=20 >> see my previous post regarding how to handle these parameters in CL.=20 >>=20 >> The proposal for CL is that a CL QNE has an algorithm that=20 >> tells it which QoS Class parameters are "high class" and=20 >> whcih are "low class". If they are high class, they will=20 >> receive CL treatment. If they are low class, they receive=20 >> best effort.=20 >>=20 >> This way QSPECs based on "QoS Class" QOSMs get as reasonable=20 >> a treatment as one can expect, and at the same time I dont=20 >> see a CL QNE being overburdened by this task. >>=20 >> Cornelia=20 >>=20 >> > -----Urspr=FCngliche Nachricht----- >> > Von: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> > Gesendet: Mittwoch, 11. Oktober 2006 21:05 >> > An: Georgios Karagiannis >> > Cc: nsis@ietf.org >> > Betreff: Re: [NSIS] QSPEC-issue (GK-2) >> >=20 >> > I support Georgios. >> >=20 >> > I think it is unrealistic to assume that Y.1541 and DSTE=20 >> behavior (as=20 >> > required for strictly interpreting these parameters) is=20 >> implemented in=20 >> > every QNE. >> >=20 >> > Ciao >> > Hannes >> >=20 >> > Georgios Karagiannis schrieb: >> > > Description of issue >> > > Change to QSPEC-2 parameter >> > >=20 >> > >=20 >> > > Submitter name: Georgios Karagiannis Submitter email address:=20 >> > > karagian@cs.utwente.nl Date first >> > submitted: >> > > 11.10.2006 >> > > Reference: =20 >> > > Comment type: T >> > > Priority: 'S' >> > > Section: Various >> > > Rationale/Explanation of issue: >> > >=20 >> > > It is not realistic to assume that the QNI is able to know which=20 >> > > network technologies (Diffserv, MPLS, Y.1541) are=20 >> supported on the=20 >> > > end-to-end path. >> > > If the "QoS Class" parameter is considered to be a=20 >> QSPEC-1 parameter=20 >> > > then it will mean that all QNEs located on the end-to-end=20 >> path must=20 >> > > support the Diffserv and MPLS and >> > Y.1541 technologies.=20 >> > > This is unrealistic. >> > >=20 >> > > Requested change: >> > > The parameter must be a QSPEC-2 parameter. >> > >=20 >> > >=20 >> > >=20 >> > > _______________________________________________ >> > > nsis mailing list >> > > nsis@ietf.org >> > > https://www1.ietf.org/mailman/listinfo/nsis >> > >=20 >> > >=20 >> >=20 >> >=20 >> > _______________________________________________ >> > nsis mailing list >> > nsis@ietf.org >> > https://www1.ietf.org/mailman/listinfo/nsis >> >=20 >>=20 > > > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 17 10:23:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZpqE-0007tT-LF; Tue, 17 Oct 2006 10:22:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZpqC-0007t1-DF for nsis@ietf.org; Tue, 17 Oct 2006 10:22:48 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZpow-00055m-Lg for nsis@ietf.org; Tue, 17 Oct 2006 10:21:31 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9HEKcZ4003017; Tue, 17 Oct 2006 17:20:38 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 17:20:38 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 17:20:37 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Date: Tue, 17 Oct 2006 17:20:37 +0300 Message-ID: In-Reply-To: <001301c6f1c7$de6d2a80$4c0d5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Thread-Index: Acbxt9rfPVXjqLj+T5uusDQMgUBvPwADy3pQAAwEd6A= From: To: , X-OriginalArrivalTime: 17 Oct 2006 14:20:37.0900 (UTC) FILETIME=[6AE13CC0:01C6F1F7] X-Spam-Score: 0.3 (/) X-Scan-Signature: 00134749b78ab2213964fc53d03de937 Cc: gash@att.com, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0061812431==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0061812431== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F1F7.6A80C4D3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F1F7.6A80C4D3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Georgios, =20 About having the QoS Models specifying manditory parameters - could you explain how we would get interoperability between two different QoS models that have different sets of manditory parameters? =20 I think we need to have a baseline QSPEC with manditory parameters to ensure interoperability - we should have the lowest common denominator between the QoS models to ensure some way of being able to signal across multiple QoS model deployments. =20 John ________________________________ From: ext Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 Sent: 17 October, 2006 01:40 To: 'Lars Westberg' Cc: gash@att.com; nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt =09 =09 Hi Lars =20 I think that I agree with you! =20 However, we may just need one QSPEC parameter, say Traffic (Tocken Bucket and Bandwidth)=20 that can be mandatory. In this way we will provide the required interoperability between the=20 QoS models. Actually this was also the conclusion that Xiaoming deduced after studying a couple of examples. =20 Furthermore, we could however provide the ability to QoS models to specify which=20 QSPEC parameters should be mandatory or not. What do you think? =20 Best regards, Georgios =20 =20 ________________________________ From: Lars Westberg [mailto:Lars.westberg@ericsson.com]=20 Sent: dinsdag 17 oktober 2006 8:46 To: Georgios Karagiannis Cc: gash@att.com; nsis@ietf.org Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt =09 =09 yes.=20 the main problem is that IETF is not the only Standardization organization that like to discuss "bearer services". Just as an example : If we specify the those parameters, How can we use NSIS for SLAs specified by MEF???? =09 How can we use it for 3GPP-Qos definitiions ? =09 =09 In the draft I also see that we the draft specify a new bearer service. It is not compliant to old Int.serv architecture. This is a completely new one with new parameters like priority. =09 I can sure that we can have a never-ending discussion about the "optimal"-set of parameters. =09 I think we agree in beggining the working group discussion that we should not specify any "bearer-service" because NSIS should be a modular architecture with more flexibillity than RSVP. Therefore, I am surprised that we are doing the same mistake as in RSVP: Integrating a bearer service definition into the NSIS-architecture. =09 If we go this track, the QoS-part of NSIS has much less use. RSVP is in this case significantly better in terms of performance and have the same functionality than NSIS. If have to choose I would select RSVP rather than a much more complex three layer protocol stack. =09 regards Lasse =09 Georgios Karagiannis wrote: =09 Hi Lars =09 Do you mean that the QSPEC template must not contain any mandatory (QSPEC-1) parameters? =09 =09 Best Regards, Georgios =09 =09 =09 On 10/16/2006, "Lars Westberg" wrote: =09 =20 Hi, The template seems not to be a template because the mandatory part is more or less the same as Intserv. The main idea with QoS-template was to make an modular solution that could allow flexibillity for different Qos-models =09 Therefore, I do not understand the scope of the specification. =09 I suggest that we move the major part of the parameters to a separate "Int.serv. over NSIS" specification. Int.serv. can be seen as a common bearer service. =09 regards Lasse =09 Ash, Gerald R (Jerry), ALABS wrote: =09 =20 Lars, =09 =20 You mention in the below e-mail that there are no open issues, while there is a huge discussion on the nsis mailing list regarding the QSPEC-1 parameters. =20 John can call a different consensus if he sees one (I've asked him a couple of times to do that). What I saw was =09 1. Many posts supported the QSPEC-1 concept, only one (or maybe two) I saw opposed. The opposing view was repeated *many* times (and is still being repeated) but it only counts as one opinion. 2. Many posts supported retaining the 4 QSPEC-1 parameters, only one I saw opposed. The opposing view was repeated many times. 3. There was only one opinion expressed to be able to ignore QSPEC-1 parameters. That one opinion has been repeated many times but it only counts as one opinion. =09 John asked a while ago for new opinions on these issues, that would be good if there are any *new* opinions. We don't need to hear opinions repeated that we've seen so many times. =09 I invite John once again to make a consensus call so we can move on here. I think it is time to make progress and stop repeating ourselves, we're not generating any new light in this rather endless discussion. =09 Thanks, Jerry =09 =20 =09 =20 ------_=_NextPart_001_01C6F1F7.6A80C4D3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Georgios,
 
About having the QoS Models specifying = manditory parameters=20 - could you explain how we would get interoperability between two = different QoS=20 models that have different sets of manditory = parameters?
 
I think we need to have a baseline QSPEC with = manditory=20 parameters to ensure interoperability - we should have the lowest common = denominator between the QoS models to ensure some way of being able to = signal=20 across multiple QoS model deployments.
 
John

From: ext Georgios Karagiannis=20 [mailto:karagian@cs.utwente.nl]
Sent: 17 October, 2006=20 01:40
To: 'Lars Westberg'
Cc: gash@att.com;=20 nsis@ietf.org
Subject: RE: [NSIS] I-D=20 ACTION:draft-ietf-nsis-qspec-12.txt

Hi Lars
 
I think that I agree with = you!
 
However, we may=20 just need one QSPEC parameter, say Traffic (Tocken Bucket and = Bandwidth)=20
that can be=20 mandatory. In this way we will provide the required interoperability = between=20 the
QoS=20 models.
Actually this=20 was also the conclusion that Xiaoming deduced after studying a couple = of=20 examples.
 
Furthermore, we could however provide the = ability to QoS=20 models to specify which
QSPEC parameters should be mandatory or=20 not.
What do you think?
 
Best regards,
Georgios
 
 

From: Lars Westberg=20 [mailto:Lars.westberg@ericsson.com]
Sent: dinsdag 17 = oktober 2006=20 8:46
To: Georgios Karagiannis
Cc: gash@att.com;=20 nsis@ietf.org
Subject: Re: [NSIS] I-D=20 ACTION:draft-ietf-nsis-qspec-12.txt

yes.
the main problem is that IETF is not the only=20 Standardization organization that like to discuss "bearer services". = Just as=20 an example :
If we specify the those parameters, How can we use = NSIS for=20 SLAs specified by MEF????

How can we use it for 3GPP-Qos = definitiions=20 ?


In the draft I also see  that we the draft specify = a new=20 bearer service. It is not compliant to old Int.serv = architecture.  This=20 is a completely new one with new parameters like priority.

I = can sure=20 that we can have a never-ending discussion about the "optimal"-set = of=20 parameters.

I think we agree in beggining the working group=20 discussion that we should not specify any "bearer-service" because = NSIS=20 should be a modular architecture with  more flexibillity than=20 RSVP.  Therefore, I am surprised that we are doing the same = mistake as=20 in RSVP: Integrating a bearer service definition into the=20 NSIS-architecture.

If we go this track, the QoS-part of NSIS = has much=20 less use. RSVP is in this case significantly better in terms of = performance=20 and have the same functionality than NSIS.
If have to choose I = would=20 select RSVP rather than a much more complex  three layer = protocol=20 stack.

regards Lasse

Georgios Karagiannis wrote:
Hi Lars

Do you mean that the QSPEC template must not contain any mandatory
(QSPEC-1) parameters?


Best Regards,
Georgios



On 10/16/2006, "Lars Westberg" <Lars.westberg@ericsson.com=
> wrote:

  
Hi,
The template seems not to be a template because the mandatory part  is
more or less the same as Intserv.
The main idea with QoS-template was to make an modular solution that
could allow flexibillity for different Qos-models

Therefore, I do not understand the scope of the specification.

I suggest that we move the major part of the parameters to a separate
"Int.serv. over NSIS" specification.
Int.serv. can be seen as a common bearer service.

regards Lasse

Ash, Gerald R (Jerry), ALABS wrote:

    
Lars,

      
You mention in the =
below e-mail that there are no open issues,
while there is a huge discussion on the nsis mailing list
regarding the QSPEC-1 parameters.
        
John can call a different =
consensus if he sees one (I've asked him a
couple of times to do that).  What I saw was

1. Many posts supported the QSPEC-1 concept, only one (or maybe two) I
saw opposed.  The opposing view was repeated *many* times (and is still
being repeated) but it only counts as one opinion.
2. Many posts supported retaining the 4 QSPEC-1 parameters, only one I
saw opposed.  The opposing view was repeated many times.
3. There was only one opinion expressed to be able to ignore QSPEC-1
parameters.  That one opinion has been repeated many times but it only
counts as one opinion.

John asked a while ago for new opinions on these issues, that would be
good if there are any *new* opinions.  We don't need to hear opinions
repeated that we've seen so many times.

I invite John once again to make a consensus call so we can move on
here.  I think it is time to make progress and stop repeating ourselves,
we're not generating any new light in this rather endless discussion.

Thanks,
Jerry
------_=_NextPart_001_01C6F1F7.6A80C4D3-- --===============0061812431== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0061812431==-- From nsis-bounces@ietf.org Tue Oct 17 10:23:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZpqH-0007vk-VW; Tue, 17 Oct 2006 10:22:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZpqF-0007u2-AD for nsis@ietf.org; Tue, 17 Oct 2006 10:22:51 -0400 Received: from sbcsmtp3.sbc.com ([144.160.112.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZpnm-00052I-RK for nsis@ietf.org; Tue, 17 Oct 2006 10:20:22 -0400 Received: from enaf.dadc.sbc.com (localhost.localdomain [127.0.0.1]) by sbcsmtp3.sbc.com (8.13.7/8.13.7) with ESMTP id k9HEKIwI021447; Tue, 17 Oct 2006 09:20:18 -0500 Received: from clph005.sldc.sbc.com (clph005.sldc.sbc.com [132.201.23.33]) by tlph033.enaf.dadc.sbc.com (8.13.7/8.13.7) with ESMTP id k9HEKHZO021439; Tue, 17 Oct 2006 09:20:17 -0500 Received: from sldc.sbc.com (localhost.localdomain [127.0.0.1]) by clph005.sldc.sbc.com (8.13.7/8.13.7) with ESMTP id k9HEKGhk021870; Tue, 17 Oct 2006 09:20:17 -0500 Received: from kcclust06evs1.ugd.att.com (kcst11.ugd.att.com [135.38.164.88]) by clph005.sldc.sbc.com (8.13.7/8.13.7) with ESMTP id k9HEKDIk021853; Tue, 17 Oct 2006 09:20:14 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Date: Tue, 17 Oct 2006 09:20:06 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7E59@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC7E58@KCCLUST06EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Thread-Index: AcbxuHtQ92fBk4GyRnaw38rAcCkjiQAOXHnQAACnLaAAAAbXcA== From: "Ash, Gerald R \(Jerry\), ALABS" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: "Ash, Gerald R \(Jerry\), ALABS" , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org > There was a proposal for a QoS model on 3GPP QoS model, by the way. > http://www.watersprings.org/pub/id/draft-jeong-nsis-3gpp-qosm-02.txt Note the co-authors -- it would be good IMO to restart this 3GPP-QOSM work. Note also that this draft defines mappings between TS 23.107 and Y.1541 QoS classes and between TS 23.107 and DiffServ QoS classes (see Section 4.1). Mappings between Y.1541 and DiffServ QoS classes can be equally well defined if need be by a particular QOSM. > However, I think that we are going circular. The QSPEC=20 > defines a general model for being able to support different=20 > QoS Models. We were asked to look at how to support=20 > different models, including Y1541, by our AD at the time and=20 > by ITU-T liaisons. Right. =20 Most people on the list seem to support retaining the QSPEC-1 concept to afford interoperability between QOSMs. The original charge to design the QSPEC template was to at least include DiffServ and IntServ/RSVP QSPEC-1 parameters in NSIS QoS. This approach was based on the premise that these are the 'legacy' IETF QoS models and must be supported by NSIS. Note that the combination of RSVP and DiffServ *do* support most or all of the QSPEC-1 parameters. I believe they are 'mandatory' parameters in the sense that DiffServ and RSVP implementations do support most or all of these capabilities since various service providers collectively require support for these various features. OTOH if we only define QSPEC parameters as QSPEC-2 (optional) parameters, and eliminate the concept of QSPEC-1 (mandatory) parameters, then various QOSMs may support mostly disjoint sets of parameters, and interoperability isn't helped. That is, RMD-QOSMs only interwork with other RMD-QOSMs, CL-QOSMs only interwork with CL-QOSMs, etc. because there is little or no commonality in the parameters they support. On balance I think Ruediger's post at http://www1.ietf.org/mail-archive/web/nsis/current/msg06748.html has it about right on this debate. Thanks, Jerry =20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 17 10:23:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZpqQ-00084Y-F9; Tue, 17 Oct 2006 10:23:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZpqP-00080G-Bg for nsis@ietf.org; Tue, 17 Oct 2006 10:23:01 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZpi2-0004dn-3w for nsis@ietf.org; Tue, 17 Oct 2006 10:14:28 -0400 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1GZphr-0005Qr-8b; Tue, 17 Oct 2006 16:14:16 +0200 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1GZphq-0000IQ-V6; Tue, 17 Oct 2006 16:14:11 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 7F75FB59D; Tue, 17 Oct 2006 16:14:10 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1GZphq-00057k-14; Tue, 17 Oct 2006 16:14:10 +0200 Message-ID: <4534E531.2050907@tm.uka.de> Date: Tue, 17 Oct 2006 16:14:09 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: "Hancock, Robert" Subject: Re: [NSIS] GIST issue on MA-Hold-Time References: <4533A86A.4010404@tm.uka.de> In-Reply-To: <4533A86A.4010404@tm.uka.de> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.1 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.3 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert and all, an important addition that I missed: repeating the MA-Hold-Time is only required when C-Mode is used. Sorry for that. Roland Bless wrote: > Furthermore, the specification in 5.1 of the Confirm message > is confusing in this respect and should be clarified. > Confirm = Common-Header > Message-Routing-Information > Session-Identification > Network-Layer-Information > [ Responder-Cookie > [ Stack-Proposal > [ Stack-Configuration-Data ] ] ] > [ NSLP-Data ] > While the example in fig.4 sheds more lighty on how it is > intended, one would think that Stack-Proposal _and_ SCD > of the Responder are repeated in the Confirm (so I guess > nesting with brackets must be fixed). Therefore, > clarification is needed that only the R-Node SP is repeated > (w/o R-Node SCD) > and the Q-Node SCD with MA-Hold-Time is mandatory in the > very first Confirm. Thus, also the MAY on top of p. 30 > (sec 4.4.1) should be a MUST. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 17 10:25:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZpqb-0008Cp-Uo; Tue, 17 Oct 2006 10:23:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZpqV-00083T-2K for nsis@ietf.org; Tue, 17 Oct 2006 10:23:07 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZpfO-0004WQ-7o for nsis@ietf.org; Tue, 17 Oct 2006 10:11:39 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k9HEBQtH020774; Tue, 17 Oct 2006 16:11:30 +0200 (MEST) From: "Georgios Karagiannis" To: , , Subject: RE: [NSIS] QSPEC-issue (GK-2) Date: Tue, 17 Oct 2006 16:11:22 +0200 Message-ID: <008a01c6f1f6$2396ebe0$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcbtanD6fn22GI49QTOs4tcmcnPXswEXnjhgAAeTNOAAA2Hx8AAAOZSw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: -5.532 () ALL_TRUSTED,AWL,BAYES_00,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Tue, 17 Oct 2006 16:11:32 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi John I realy do not understand how this will solve the QoS class=20 remapping problems. What is "high class" for "DSTE QoS class" and for "PHB QoS class" and = for "Y.1541 class" and the same for "low class"? Best regards, Georgios > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 > Sent: dinsdag 17 oktober 2006 16:03 > To: karagian@cs.utwente.nl; cornelia.kappler@siemens.com;=20 > Hannes.Tschofenig@gmx.net > Cc: nsis@ietf.org > Subject: RE: [NSIS] QSPEC-issue (GK-2) >=20 > Georgios, >=20 > Cornelia explained how she thought it would work with CL. I=20 > agree with her that I think that should be a sufficient solutions. >=20 > Is your objection based upon the total number of Mandatory Parameters? > Too many parameters in general? >=20 > John=20 >=20 > >-----Original Message----- > >From: ext Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > >Sent: 17 October, 2006 05:28 > >To: 'Kappler, Cornelia'; 'Hannes Tschofenig' > >Cc: nsis@ietf.org > >Subject: RE: [NSIS] QSPEC-issue (GK-2) > > > >Hi Cornelia > > > >Sorry, but in this way you define two new parameters and=20 > that are high=20 > >class and low class! > >In addition to the 13 mandatory parameters we will add other two.=20 > >Thus the QNEs will have to support 15 mandatory parameters. > >Sorry but it becomes more complicated, than when just having > >13 mandatory parameters. > > > > > >Best Regards, > >Georgios > > > > > >> -----Original Message----- > >> From: Kappler, Cornelia [mailto:cornelia.kappler@siemens.com] > >> Sent: dinsdag 17 oktober 2006 10:52 > >> To: Hannes Tschofenig; Georgios Karagiannis > >> Cc: nsis@ietf.org > >> Subject: AW: [NSIS] QSPEC-issue (GK-2) > >>=20 > >> Hi Georgios and Hannes, > >>=20 > >> see my previous post regarding how to handle these=20 > parameters in CL.=20 > >>=20 > >> The proposal for CL is that a CL QNE has an algorithm that=20 > tells it=20 > >> which QoS Class parameters are "high class" and whcih are "low=20 > >> class". If they are high class, they will receive CL treatment. If=20 > >> they are low class, they receive best effort. > >>=20 > >> This way QSPECs based on "QoS Class" QOSMs get as reasonable a=20 > >> treatment as one can expect, and at the same time I dont=20 > see a CL QNE=20 > >> being overburdened by this task. > >>=20 > >> Cornelia > >>=20 > >> > -----Urspr=FCngliche Nachricht----- > >> > Von: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >> > Gesendet: Mittwoch, 11. Oktober 2006 21:05 > >> > An: Georgios Karagiannis > >> > Cc: nsis@ietf.org > >> > Betreff: Re: [NSIS] QSPEC-issue (GK-2) > >> >=20 > >> > I support Georgios. > >> >=20 > >> > I think it is unrealistic to assume that Y.1541 and DSTE > >> behavior (as > >> > required for strictly interpreting these parameters) is > >> implemented in > >> > every QNE. > >> >=20 > >> > Ciao > >> > Hannes > >> >=20 > >> > Georgios Karagiannis schrieb: > >> > > Description of issue > >> > > Change to QSPEC-2 parameter > >> > >=20 > >> > >=20 > >> > > Submitter name: Georgios Karagiannis Submitter email address:=20 > >> > > karagian@cs.utwente.nl Date first > >> > submitted: > >> > > 11.10.2006 > >> > > Reference: =20 > >> > > Comment type: T > >> > > Priority: 'S' > >> > > Section: Various > >> > > Rationale/Explanation of issue: > >> > >=20 > >> > > It is not realistic to assume that the QNI is able to=20 > know which=20 > >> > > network technologies (Diffserv, MPLS, Y.1541) are > >> supported on the > >> > > end-to-end path. > >> > > If the "QoS Class" parameter is considered to be a > >> QSPEC-1 parameter > >> > > then it will mean that all QNEs located on the end-to-end > >> path must > >> > > support the Diffserv and MPLS and > >> > Y.1541 technologies.=20 > >> > > This is unrealistic. > >> > >=20 > >> > > Requested change: > >> > > The parameter must be a QSPEC-2 parameter. > >> > >=20 > >> > >=20 > >> > >=20 > >> > > _______________________________________________ > >> > > nsis mailing list > >> > > nsis@ietf.org > >> > > https://www1.ietf.org/mailman/listinfo/nsis > >> > >=20 > >> > >=20 > >> >=20 > >> >=20 > >> > _______________________________________________ > >> > nsis mailing list > >> > nsis@ietf.org > >> > https://www1.ietf.org/mailman/listinfo/nsis > >> >=20 > >>=20 > > > > > > > >_______________________________________________ > >nsis mailing list > >nsis@ietf.org > >https://www1.ietf.org/mailman/listinfo/nsis > > >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 17 10:30:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZpqb-0008CP-L0; Tue, 17 Oct 2006 10:23:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZpqU-00083T-Pd for nsis@ietf.org; Tue, 17 Oct 2006 10:23:06 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZpfQ-0004WV-QR for nsis@ietf.org; Tue, 17 Oct 2006 10:11:45 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9HEBZ1W030244; Tue, 17 Oct 2006 17:11:40 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 17:11:37 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 17:11:37 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] a comment on type-1/type-2 QSPEC parameters Date: Tue, 17 Oct 2006 17:11:36 +0300 Message-ID: In-Reply-To: <008b01c6f1f4$a44ecde0$946b0a0a@comm.ad.roke.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] a comment on type-1/type-2 QSPEC parameters Thread-Index: Acbx9QEcbnGiBbEWRCCM8tHbeOazsQAAEH6w From: To: , X-OriginalArrivalTime: 17 Oct 2006 14:11:37.0822 (UTC) FILETIME=[28F7DFE0:01C6F1F6] X-Spam-Score: 0.2 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Robert, I think this is a good summary. I agree with it. I haven't taken a strong stance on which are the mandatory, however we need to resolve that issue as well. John=20 >-----Original Message----- >From: ext Robert Hancock [mailto:robert.hancock@roke.co.uk]=20 >Sent: 17 October, 2006 07:01 >To: nsis@ietf.org >Subject: [NSIS] a comment on type-1/type-2 QSPEC parameters > >Dear all, > >Without wanting to get too hung up on exactly which parameters=20 >should be 'globally supported/mandatory/[insert your favourite=20 >terminology here]' and which should not, I'd like to=20 >re-iterate what I believe is the benefit of the Type-1=20 >parameter concept in the first place. > >In several external reviews of NSIS (within the IETF but=20 >partly outside the working group), it's my impression that=20 >there was a real worry about how the flexibility that the=20 >original QoS-NSLP/QSPEC concepts allowed would harm=20 >interoperability - in other words, that it would be=20 >commonplace for people to issue reservations which were=20 >completely not understood by downstream domains. (Just look at=20 >the early review minutes from Korea, for example.)=20 > >The Type-1 parameter concept is an attempt (IMHO a good one)=20 >to address that problem, by providing a minimal parameter set=20 >which everyone understands. We can argue about which=20 >parameters should be Type-1, but I think that if the concept=20 >itself is dropped and we just allow a free-for-all in QSPEC=20 >parameters, then it will be a major barrier to getting this=20 >work through the forthcoming review stages. > >For the sake of argument, I'd be interested to know if there=20 >are people who really can argue that the token bucket (or=20 >bandwidth, which is just a degenerate token bucket really)=20 >cannot be handled correctly as a Type-1 parameter. If they=20 >cannot, I think that this would at least validate the=20 >conceptual structure of the QSPEC - we could still discuss the=20 >other parameters. > >Lars - > >I'm a bit confused about your references to MEF7. MEF7 is=20 >about an information model for network management; I wouldn't=20 >really expect the QSPEC to be relevant here. Surely the=20 >appropriate comparison is with MEF10 ("Ethernet Services=20 >Attributes"). Not entirely surprisingly, MEF10 expresses its=20 >bandwidth profiles in terms of token bucket parameters.=20 >Doesn't that rather prove the point? > >cheers, > >Robert H. > > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 17 10:33:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZpzj-000390-PQ; Tue, 17 Oct 2006 10:32:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZpqK-0007uU-6E for nsis@ietf.org; Tue, 17 Oct 2006 10:22:56 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZplO-0004pb-Sp for nsis@ietf.org; Tue, 17 Oct 2006 10:17:51 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9HEHVh3008628; Tue, 17 Oct 2006 17:17:35 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 17:17:33 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 17:17:34 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] QSPEC-issue (GK-2) Date: Tue, 17 Oct 2006 17:17:33 +0300 Message-ID: In-Reply-To: <008a01c6f1f6$2396ebe0$4c0d5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QSPEC-issue (GK-2) Thread-Index: AcbtanD6fn22GI49QTOs4tcmcnPXswEXnjhgAAeTNOAAA2Hx8AAAOZSwAAAyB+A= From: To: , , X-OriginalArrivalTime: 17 Oct 2006 14:17:34.0280 (UTC) FILETIME=[FD6F0C80:01C6F1F6] X-Spam-Score: 0.2 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org OK, so I think your point on the manditory parameters could be = classified as something like this. If we have manditory parameters, how to map from one QoS model to another, especially when the QoS models are=20 using relative values - meaning no absolute values. If all QoS Models had 3 traffic classes - roughly high, medium and low - then it would be very simple to handle. However, different QoS models might have trouble to map from one model to another. Is that roughly want you are saying? John >-----Original Message----- >From: ext Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 >Sent: 17 October, 2006 07:11 >To: Loughney John (Nokia-NRC/Helsinki);=20 >cornelia.kappler@siemens.com; Hannes.Tschofenig@gmx.net >Cc: nsis@ietf.org >Subject: RE: [NSIS] QSPEC-issue (GK-2) > >Hi John > >I realy do not understand how this will solve the QoS class=20 >remapping problems. >What is "high class" for "DSTE QoS class" and for "PHB QoS=20 >class" and for >"Y.1541 class" >and the same for "low class"? > >Best regards, >Georgios > >> -----Original Message----- >> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] >> Sent: dinsdag 17 oktober 2006 16:03 >> To: karagian@cs.utwente.nl; cornelia.kappler@siemens.com;=20 >> Hannes.Tschofenig@gmx.net >> Cc: nsis@ietf.org >> Subject: RE: [NSIS] QSPEC-issue (GK-2) >>=20 >> Georgios, >>=20 >> Cornelia explained how she thought it would work with CL. I agree=20 >> with her that I think that should be a sufficient solutions. >>=20 >> Is your objection based upon the total number of Mandatory=20 >Parameters? >> Too many parameters in general? >>=20 >> John >>=20 >> >-----Original Message----- >> >From: ext Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >> >Sent: 17 October, 2006 05:28 >> >To: 'Kappler, Cornelia'; 'Hannes Tschofenig' >> >Cc: nsis@ietf.org >> >Subject: RE: [NSIS] QSPEC-issue (GK-2) >> > >> >Hi Cornelia >> > >> >Sorry, but in this way you define two new parameters and >> that are high >> >class and low class! >> >In addition to the 13 mandatory parameters we will add other two.=20 >> >Thus the QNEs will have to support 15 mandatory parameters. >> >Sorry but it becomes more complicated, than when just having >> >13 mandatory parameters. >> > >> > >> >Best Regards, >> >Georgios >> > >> > >> >> -----Original Message----- >> >> From: Kappler, Cornelia [mailto:cornelia.kappler@siemens.com] >> >> Sent: dinsdag 17 oktober 2006 10:52 >> >> To: Hannes Tschofenig; Georgios Karagiannis >> >> Cc: nsis@ietf.org >> >> Subject: AW: [NSIS] QSPEC-issue (GK-2) >> >>=20 >> >> Hi Georgios and Hannes, >> >>=20 >> >> see my previous post regarding how to handle these >> parameters in CL.=20 >> >>=20 >> >> The proposal for CL is that a CL QNE has an algorithm that >> tells it >> >> which QoS Class parameters are "high class" and whcih are "low=20 >> >> class". If they are high class, they will receive CL=20 >treatment. If=20 >> >> they are low class, they receive best effort. >> >>=20 >> >> This way QSPECs based on "QoS Class" QOSMs get as reasonable a=20 >> >> treatment as one can expect, and at the same time I dont >> see a CL QNE >> >> being overburdened by this task. >> >>=20 >> >> Cornelia >> >>=20 >> >> > -----Urspr=FCngliche Nachricht----- >> >> > Von: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> >> > Gesendet: Mittwoch, 11. Oktober 2006 21:05 >> >> > An: Georgios Karagiannis >> >> > Cc: nsis@ietf.org >> >> > Betreff: Re: [NSIS] QSPEC-issue (GK-2) >> >> >=20 >> >> > I support Georgios. >> >> >=20 >> >> > I think it is unrealistic to assume that Y.1541 and DSTE >> >> behavior (as >> >> > required for strictly interpreting these parameters) is >> >> implemented in >> >> > every QNE. >> >> >=20 >> >> > Ciao >> >> > Hannes >> >> >=20 >> >> > Georgios Karagiannis schrieb: >> >> > > Description of issue >> >> > > Change to QSPEC-2 parameter >> >> > >=20 >> >> > >=20 >> >> > > Submitter name: Georgios Karagiannis Submitter email address:=20 >> >> > > karagian@cs.utwente.nl Date first >> >> > submitted: >> >> > > 11.10.2006 >> >> > > Reference: =20 >> >> > > Comment type: T >> >> > > Priority: 'S' >> >> > > Section: Various >> >> > > Rationale/Explanation of issue: >> >> > >=20 >> >> > > It is not realistic to assume that the QNI is able to >> know which >> >> > > network technologies (Diffserv, MPLS, Y.1541) are >> >> supported on the >> >> > > end-to-end path. >> >> > > If the "QoS Class" parameter is considered to be a >> >> QSPEC-1 parameter >> >> > > then it will mean that all QNEs located on the end-to-end >> >> path must >> >> > > support the Diffserv and MPLS and >> >> > Y.1541 technologies.=20 >> >> > > This is unrealistic. >> >> > >=20 >> >> > > Requested change: >> >> > > The parameter must be a QSPEC-2 parameter. >> >> > >=20 >> >> > >=20 >> >> > >=20 >> >> > > _______________________________________________ >> >> > > nsis mailing list >> >> > > nsis@ietf.org >> >> > > https://www1.ietf.org/mailman/listinfo/nsis >> >> > >=20 >> >> > >=20 >> >> >=20 >> >> >=20 >> >> > _______________________________________________ >> >> > nsis mailing list >> >> > nsis@ietf.org >> >> > https://www1.ietf.org/mailman/listinfo/nsis >> >> >=20 >> >>=20 >> > >> > >> > >> >_______________________________________________ >> >nsis mailing list >> >nsis@ietf.org >> >https://www1.ietf.org/mailman/listinfo/nsis >> > >>=20 >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis >>=20 > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 17 10:34:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZq0d-0003pI-Qa; Tue, 17 Oct 2006 10:33:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZq0d-0003pD-3X for nsis@ietf.org; Tue, 17 Oct 2006 10:33:35 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZq0Z-00078m-I4 for nsis@ietf.org; Tue, 17 Oct 2006 10:33:35 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k9HEXK1e023076; Tue, 17 Oct 2006 16:33:24 +0200 (MEST) From: "Georgios Karagiannis" To: , , Subject: RE: [NSIS] QSPEC-issue (GK-2) Date: Tue, 17 Oct 2006 16:33:17 +0200 Message-ID: <009801c6f1f9$32ad80a0$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcbtanD6fn22GI49QTOs4tcmcnPXswEXnjhgAAeTNOAAA2Hx8AAAOZSwAAAyB+AAAC0zgA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: -5.532 () ALL_TRUSTED,AWL,BAYES_00,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Tue, 17 Oct 2006 16:33:27 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi John=20 Okay, but this is something different then what we are curreently = discussing in this thread! Cornelia actually proposes two additional parameters that are different=20 then the 3 mandatory QOS classes defined already. Please consider the following: According to the QSPEC template a QNI can include a Y.1541 class = parameter.=20 Now a QNE that receives this parameter MUST interpret it, since this parameter is mandatory. Consider now that the QNE can support only Diffserv.=20 How this Diffserv QNE could interpret the Y.1541 class parameter? Best Regards, Georgios > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 > Sent: dinsdag 17 oktober 2006 16:18 > To: karagian@cs.utwente.nl; cornelia.kappler@siemens.com;=20 > Hannes.Tschofenig@gmx.net > Cc: nsis@ietf.org > Subject: RE: [NSIS] QSPEC-issue (GK-2) >=20 > OK, so I think your point on the manditory parameters could=20 > be classified as something like this. If we have manditory=20 > parameters, how to map from one QoS model to another,=20 > especially when the QoS models are using relative values -=20 > meaning no absolute values. If all QoS Models had 3 traffic=20 > classes - roughly high, medium and low - then it would be=20 > very simple to handle. However, different QoS models might=20 > have trouble to map from one model to another. >=20 > Is that roughly want you are saying? >=20 > John >=20 > >-----Original Message----- > >From: ext Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > >Sent: 17 October, 2006 07:11 > >To: Loughney John (Nokia-NRC/Helsinki);=20 > cornelia.kappler@siemens.com;=20 > >Hannes.Tschofenig@gmx.net > >Cc: nsis@ietf.org > >Subject: RE: [NSIS] QSPEC-issue (GK-2) > > > >Hi John > > > >I realy do not understand how this will solve the QoS class=20 > remapping=20 > >problems. > >What is "high class" for "DSTE QoS class" and for "PHB QoS=20 > class" and=20 > >for > >"Y.1541 class" > >and the same for "low class"? > > > >Best regards, > >Georgios > > > >> -----Original Message----- > >> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > >> Sent: dinsdag 17 oktober 2006 16:03 > >> To: karagian@cs.utwente.nl; cornelia.kappler@siemens.com;=20 > >> Hannes.Tschofenig@gmx.net > >> Cc: nsis@ietf.org > >> Subject: RE: [NSIS] QSPEC-issue (GK-2) > >>=20 > >> Georgios, > >>=20 > >> Cornelia explained how she thought it would work with CL. I agree=20 > >> with her that I think that should be a sufficient solutions. > >>=20 > >> Is your objection based upon the total number of Mandatory > >Parameters? > >> Too many parameters in general? > >>=20 > >> John > >>=20 > >> >-----Original Message----- > >> >From: ext Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > >> >Sent: 17 October, 2006 05:28 > >> >To: 'Kappler, Cornelia'; 'Hannes Tschofenig' > >> >Cc: nsis@ietf.org > >> >Subject: RE: [NSIS] QSPEC-issue (GK-2) > >> > > >> >Hi Cornelia > >> > > >> >Sorry, but in this way you define two new parameters and > >> that are high > >> >class and low class! > >> >In addition to the 13 mandatory parameters we will add other two.=20 > >> >Thus the QNEs will have to support 15 mandatory parameters. > >> >Sorry but it becomes more complicated, than when just having > >> >13 mandatory parameters. > >> > > >> > > >> >Best Regards, > >> >Georgios > >> > > >> > > >> >> -----Original Message----- > >> >> From: Kappler, Cornelia [mailto:cornelia.kappler@siemens.com] > >> >> Sent: dinsdag 17 oktober 2006 10:52 > >> >> To: Hannes Tschofenig; Georgios Karagiannis > >> >> Cc: nsis@ietf.org > >> >> Subject: AW: [NSIS] QSPEC-issue (GK-2) > >> >>=20 > >> >> Hi Georgios and Hannes, > >> >>=20 > >> >> see my previous post regarding how to handle these > >> parameters in CL.=20 > >> >>=20 > >> >> The proposal for CL is that a CL QNE has an algorithm that > >> tells it > >> >> which QoS Class parameters are "high class" and whcih are "low=20 > >> >> class". If they are high class, they will receive CL > >treatment. If > >> >> they are low class, they receive best effort. > >> >>=20 > >> >> This way QSPECs based on "QoS Class" QOSMs get as reasonable a=20 > >> >> treatment as one can expect, and at the same time I dont > >> see a CL QNE > >> >> being overburdened by this task. > >> >>=20 > >> >> Cornelia > >> >>=20 > >> >> > -----Urspr=FCngliche Nachricht----- > >> >> > Von: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >> >> > Gesendet: Mittwoch, 11. Oktober 2006 21:05 > >> >> > An: Georgios Karagiannis > >> >> > Cc: nsis@ietf.org > >> >> > Betreff: Re: [NSIS] QSPEC-issue (GK-2) > >> >> >=20 > >> >> > I support Georgios. > >> >> >=20 > >> >> > I think it is unrealistic to assume that Y.1541 and DSTE > >> >> behavior (as > >> >> > required for strictly interpreting these parameters) is > >> >> implemented in > >> >> > every QNE. > >> >> >=20 > >> >> > Ciao > >> >> > Hannes > >> >> >=20 > >> >> > Georgios Karagiannis schrieb: > >> >> > > Description of issue > >> >> > > Change to QSPEC-2 parameter > >> >> > >=20 > >> >> > >=20 > >> >> > > Submitter name: Georgios Karagiannis Submitter=20 > email address:=20 > >> >> > > karagian@cs.utwente.nl Date first > >> >> > submitted: > >> >> > > 11.10.2006 > >> >> > > Reference: =20 > >> >> > > Comment type: T > >> >> > > Priority: 'S' > >> >> > > Section: Various > >> >> > > Rationale/Explanation of issue: > >> >> > >=20 > >> >> > > It is not realistic to assume that the QNI is able to > >> know which > >> >> > > network technologies (Diffserv, MPLS, Y.1541) are > >> >> supported on the > >> >> > > end-to-end path. > >> >> > > If the "QoS Class" parameter is considered to be a > >> >> QSPEC-1 parameter > >> >> > > then it will mean that all QNEs located on the end-to-end > >> >> path must > >> >> > > support the Diffserv and MPLS and > >> >> > Y.1541 technologies.=20 > >> >> > > This is unrealistic. > >> >> > >=20 > >> >> > > Requested change: > >> >> > > The parameter must be a QSPEC-2 parameter. > >> >> > >=20 > >> >> > >=20 > >> >> > >=20 > >> >> > > _______________________________________________ > >> >> > > nsis mailing list > >> >> > > nsis@ietf.org > >> >> > > https://www1.ietf.org/mailman/listinfo/nsis > >> >> > >=20 > >> >> > >=20 > >> >> >=20 > >> >> >=20 > >> >> > _______________________________________________ > >> >> > nsis mailing list > >> >> > nsis@ietf.org > >> >> > https://www1.ietf.org/mailman/listinfo/nsis > >> >> >=20 > >> >>=20 > >> > > >> > > >> > > >> >_______________________________________________ > >> >nsis mailing list > >> >nsis@ietf.org > >> >https://www1.ietf.org/mailman/listinfo/nsis > >> > > >>=20 > >> _______________________________________________ > >> nsis mailing list > >> nsis@ietf.org > >> https://www1.ietf.org/mailman/listinfo/nsis > >>=20 > > > > > > >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 17 10:46:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZqC8-0008U9-Ff; Tue, 17 Oct 2006 10:45:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZqC6-0008U3-QD for nsis@ietf.org; Tue, 17 Oct 2006 10:45:26 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZqBx-00009G-Ji for nsis@ietf.org; Tue, 17 Oct 2006 10:45:26 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E8E25186; Tue, 17 Oct 2006 16:45:16 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 16:45:16 +0200 Received: from ericsson.com ([147.214.26.58]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 16:45:16 +0200 Message-ID: <4534EC7C.1040101@ericsson.com> Date: Tue, 17 Oct 2006 16:45:16 +0200 From: Lars Westberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt References: In-Reply-To: X-OriginalArrivalTime: 17 Oct 2006 14:45:16.0062 (UTC) FILETIME=[DBEEDBE0:01C6F1FA] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 5b943e80df8c8cad631fd60298783617 Cc: gash@att.com, karagian@cs.utwente.nl, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1127284162==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============1127284162== Content-Type: multipart/alternative; boundary="------------030802020800060900040902" This is a multi-part message in MIME format. --------------030802020800060900040902 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit comments inline john.loughney@nokia.com wrote: > There was a proposal for a QoS model on 3GPP QoS model, by the way. > http://www.watersprings.org/pub/id/draft-jeong-nsis-3gpp-qosm-02.txt > > However, I think that we are going circular. The QSPEC defines a > general model for being able to support different QoS Models. We were > asked to look at how to support different models, including Y1541, by > our AD at the time and by ITU-T liasons. The QSPEC-template at that time, defined an generic format for Qspec. The problem is that the draft contain a mandatory model that make it impossible to use the flexibillity i.e. MEF-definitions. Don't you remeber the discussion of the three layer model ?????????? The major reason was to get a more open and modular architecture. We have now developped the same architectue again but have specified in such away only controlled load can be used. It is even worse, we can not support GQS in our model, so the flexibillity is more limited than RSVP ??????????????????????????? I am still very confused............... regards Lasse > > If you feel that things are too complicated, I would suggest you send > a list of what you consider to be mandatory and what is optional (or > in otherwords, what is essential and what is not). It could be that > we have created something that is more complicated than what is > generally needed, but then we need a counter proposal. I do already. The > > thanks, > John > > > ------------------------------------------------------------------------ > From: ext Lars Westberg [mailto:Lars.westberg@ericsson.com] > Sent: 16 October, 2006 23:46 > To: Georgios Karagiannis > Cc: gash@att.com; nsis@ietf.org > Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt > > yes. > the main problem is that IETF is not the only Standardization > organization that like to discuss "bearer services". Just as an > example : > If we specify the those parameters, How can we use NSIS for SLAs > specified by MEF???? > > How can we use it for 3GPP-Qos definitiions ? > > > In the draft I also see that we the draft specify a new bearer > service. It is not compliant to old Int.serv architecture. This > is a completely new one with new parameters like priority. > > I can sure that we can have a never-ending discussion about the > "optimal"-set of parameters. > > I think we agree in beggining the working group discussion that we > should not specify any "bearer-service" because NSIS should be a > modular architecture with more flexibillity than RSVP. > Therefore, I am surprised that we are doing the same mistake as in > RSVP: Integrating a bearer service definition into the > NSIS-architecture. > > If we go this track, the QoS-part of NSIS has much less use. RSVP > is in this case significantly better in terms of performance and > have the same functionality than NSIS. > If have to choose I would select RSVP rather than a much more > complex three layer protocol stack. > > regards Lasse > > Georgios Karagiannis wrote: > >>Hi Lars >> >>Do you mean that the QSPEC template must not contain any mandatory >>(QSPEC-1) parameters? >> >> >>Best Regards, >>Georgios >> >> >> >>On 10/16/2006, "Lars Westberg" wrote: >> >> >> >>>Hi, >>>The template seems not to be a template because the mandatory part is >>>more or less the same as Intserv. >>>The main idea with QoS-template was to make an modular solution that >>>could allow flexibillity for different Qos-models >>> >>>Therefore, I do not understand the scope of the specification. >>> >>>I suggest that we move the major part of the parameters to a separate >>>"Int.serv. over NSIS" specification. >>>Int.serv. can be seen as a common bearer service. >>> >>>regards Lasse >>> >>>Ash, Gerald R (Jerry), ALABS wrote: >>> >>> >>> >>>>Lars, >>>> >>>> >>>> >>>>>You mention in the below e-mail that there are no open issues, >>>>>while there is a huge discussion on the nsis mailing list >>>>>regarding the QSPEC-1 parameters. >>>>> >>>>> >>>>John can call a different consensus if he sees one (I've asked him a >>>>couple of times to do that). What I saw was >>>> >>>>1. Many posts supported the QSPEC-1 concept, only one (or maybe two) I >>>>saw opposed. The opposing view was repeated *many* times (and is still >>>>being repeated) but it only counts as one opinion. >>>>2. Many posts supported retaining the 4 QSPEC-1 parameters, only one I >>>>saw opposed. The opposing view was repeated many times. >>>>3. There was only one opinion expressed to be able to ignore QSPEC-1 >>>>parameters. That one opinion has been repeated many times but it only >>>>counts as one opinion. >>>> >>>>John asked a while ago for new opinions on these issues, that would be >>>>good if there are any *new* opinions. We don't need to hear opinions >>>>repeated that we've seen so many times. >>>> >>>>I invite John once again to make a consensus call so we can move on >>>>here. I think it is time to make progress and stop repeating ourselves, >>>>we're not generating any new light in this rather endless discussion. >>>> >>>>Thanks, >>>>Jerry >>>> >>>> >>>> >> >> >> --------------030802020800060900040902 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit comments inline

john.loughney@nokia.com wrote:
There was a proposal for a QoS model on 3GPP QoS model, by the way.
 
However, I think that we are going circular.  The QSPEC defines a general model for being able to support different QoS Models.  We were asked to look at how to support different models, including Y1541, by our AD at the time and by ITU-T liasons.
The QSPEC-template at that time, defined an generic format for Qspec. The problem is that the draft contain a mandatory model that make it impossible to use the flexibillity i.e. MEF-definitions.

Don't you remeber the discussion of the three layer model ??????????
The major reason was to get a more open and modular architecture.

We have now developped the same architectue again but have specified in such away only controlled load can be used.  It is even worse, we can not support GQS in our model, so the flexibillity is more limited than RSVP ???????????????????????????

I am still very confused...............

regards Lasse
 
If you feel that things are too complicated, I would suggest you send a list of what you consider to be mandatory and what is optional (or in otherwords, what is essential and what is not).  It could be that we have created something that is more complicated than what is generally needed, but then we need a counter proposal.

I do already.

The
 
thanks,
John
 

From: ext Lars Westberg [mailto:Lars.westberg@ericsson.com]
Sent: 16 October, 2006 23:46
To: Georgios Karagiannis
Cc: gash@att.com; nsis@ietf.org
Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

yes.
the main problem is that IETF is not the only Standardization organization that like to discuss "bearer services". Just as an example :
If we specify the those parameters, How can we use NSIS for SLAs specified by MEF????

How can we use it for 3GPP-Qos definitiions ?


In the draft I also see  that we the draft specify a new bearer service. It is not compliant to old Int.serv architecture.  This is a completely new one with new parameters like priority.

I can sure that we can have a never-ending discussion about the "optimal"-set of parameters.

I think we agree in beggining the working group discussion that we should not specify any "bearer-service" because NSIS should be a modular architecture with  more flexibillity than RSVP.  Therefore, I am surprised that we are doing the same mistake as in RSVP: Integrating a bearer service definition into the NSIS-architecture.

If we go this track, the QoS-part of NSIS has much less use. RSVP is in this case significantly better in terms of performance and have the same functionality than NSIS.
If have to choose I would select RSVP rather than a much more complex  three layer protocol stack.

regards Lasse

Georgios Karagiannis wrote:
Hi Lars

Do you mean that the QSPEC template must not contain any mandatory
(QSPEC-1) parameters?


Best Regards,
Georgios



On 10/16/2006, "Lars Westberg" <Lars.westberg@ericsson.com> wrote:

  
Hi,
The template seems not to be a template because the mandatory part  is
more or less the same as Intserv.
The main idea with QoS-template was to make an modular solution that
could allow flexibillity for different Qos-models

Therefore, I do not understand the scope of the specification.

I suggest that we move the major part of the parameters to a separate
"Int.serv. over NSIS" specification.
Int.serv. can be seen as a common bearer service.

regards Lasse

Ash, Gerald R (Jerry), ALABS wrote:

    
Lars,

      
You mention in the below e-mail that there are no open issues,
while there is a huge discussion on the nsis mailing list
regarding the QSPEC-1 parameters.
        
John can call a different consensus if he sees one (I've asked him a
couple of times to do that).  What I saw was

1. Many posts supported the QSPEC-1 concept, only one (or maybe two) I
saw opposed.  The opposing view was repeated *many* times (and is still
being repeated) but it only counts as one opinion.
2. Many posts supported retaining the 4 QSPEC-1 parameters, only one I
saw opposed.  The opposing view was repeated many times.
3. There was only one opinion expressed to be able to ignore QSPEC-1
parameters.  That one opinion has been repeated many times but it only
counts as one opinion.

John asked a while ago for new opinions on these issues, that would be
good if there are any *new* opinions.  We don't need to hear opinions
repeated that we've seen so many times.

I invite John once again to make a consensus call so we can move on
here.  I think it is time to make progress and stop repeating ourselves,
we're not generating any new light in this rather endless discussion.

Thanks,
Jerry
--------------030802020800060900040902-- --===============1127284162== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============1127284162==-- From nsis-bounces@ietf.org Tue Oct 17 10:49:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZqFn-0001JY-UT; Tue, 17 Oct 2006 10:49:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZqFn-0001JS-0D for nsis@ietf.org; Tue, 17 Oct 2006 10:49:15 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZqFi-0000Va-MF for nsis@ietf.org; Tue, 17 Oct 2006 10:49:14 -0400 Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Tue, 17 Oct 2006 17:49:03 +0300 id 000AFD6B.4534ED5F.00004A33 Date: Tue, 17 Oct 2006 17:49:03 +0300 (EEST) From: Jukka MJ Manner To: nsis@ietf.org Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [NSIS] Proposal to move the QSPEC work forward X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org 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 nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 17 10:52:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZqId-00022k-VU; Tue, 17 Oct 2006 10:52:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZqId-00022f-2t for nsis@ietf.org; Tue, 17 Oct 2006 10:52:11 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZqIc-0000qk-7E for nsis@ietf.org; Tue, 17 Oct 2006 10:52:11 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k9HEp3Ea024940; Tue, 17 Oct 2006 16:51:08 +0200 (MEST) From: "Georgios Karagiannis" To: , Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Date: Tue, 17 Oct 2006 16:51:00 +0200 Message-ID: <00a501c6f1fb$acb0a1a0$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Acbxt9rfPVXjqLj+T5uusDQMgUBvPwADy3pQAAwEd6AAAKI3AA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: -5.185 () ALL_TRUSTED, AWL, BAYES_00, FVGT_s_OBFU_Q1, HTML_50_60, HTML_MESSAGE, HTML_TITLE_EMPTY, J_CHICKENPOX_34 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Tue, 17 Oct 2006 16:51:11 +0200 (MEST) X-Spam-Score: 0.1 (/) X-Scan-Signature: 94375f06b91351a23b2e62bbf6b5a18c Cc: gash@att.com, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0942054710==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0942054710== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A6_01C6F20C.703971A0" This is a multi-part message in MIME format. ------=_NextPart_000_00A6_01C6F20C.703971A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi John A solution of this can be as follows. First of all: the QSPEC template does not specify mandatory parameters. However, an end-to-end QoS model may mandate the use of a QSPEC parameter. Any QNE that suopports this end-to-end QoS model then it will have to interpret (strictly or remap) this parameter. The remapping is then specified in the end -to-end QOSM draft. Another local QoS model that needs to interoperate with the end-to-end QoS model it will either have to strictly interpret the parameter specified by the end -to- end QoS model, or to remap it. The remapping is also specified in the local QOSM draft. However, if a QNE does not support the end-to-end QoS model then it will just set the NON-QOSM Hop flag. In this way we achieve both modularity and interoperability. Best Regards, Georgios _____ From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: dinsdag 17 oktober 2006 16:21 To: karagian@cs.utwente.nl; Lars.westberg@ericsson.com Cc: gash@att.com; nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Georgios, About having the QoS Models specifying manditory parameters - could you explain how we would get interoperability between two different QoS models that have different sets of manditory parameters? I think we need to have a baseline QSPEC with manditory parameters to ensure interoperability - we should have the lowest common denominator between the QoS models to ensure some way of being able to signal across multiple QoS model deployments. John _____ From: ext Georgios Karagiannis [mailto:karagian@cs.utwente.nl] Sent: 17 October, 2006 01:40 To: 'Lars Westberg' Cc: gash@att.com; nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Hi Lars I think that I agree with you! However, we may just need one QSPEC parameter, say Traffic (Tocken Bucket and Bandwidth) that can be mandatory. In this way we will provide the required interoperability between the QoS models. Actually this was also the conclusion that Xiaoming deduced after studying a couple of examples. Furthermore, we could however provide the ability to QoS models to specify which QSPEC parameters should be mandatory or not. What do you think? Best regards, Georgios _____ From: Lars Westberg [mailto:Lars.westberg@ericsson.com] Sent: dinsdag 17 oktober 2006 8:46 To: Georgios Karagiannis Cc: gash@att.com; nsis@ietf.org Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt yes. the main problem is that IETF is not the only Standardization organization that like to discuss "bearer services". Just as an example : If we specify the those parameters, How can we use NSIS for SLAs specified by MEF???? How can we use it for 3GPP-Qos definitiions ? In the draft I also see that we the draft specify a new bearer service. It is not compliant to old Int.serv architecture. This is a completely new one with new parameters like priority. I can sure that we can have a never-ending discussion about the "optimal"-set of parameters. I think we agree in beggining the working group discussion that we should not specify any "bearer-service" because NSIS should be a modular architecture with more flexibillity than RSVP. Therefore, I am surprised that we are doing the same mistake as in RSVP: Integrating a bearer service definition into the NSIS-architecture. If we go this track, the QoS-part of NSIS has much less use. RSVP is in this case significantly better in terms of performance and have the same functionality than NSIS. If have to choose I would select RSVP rather than a much more complex three layer protocol stack. regards Lasse Georgios Karagiannis wrote: Hi Lars Do you mean that the QSPEC template must not contain any mandatory (QSPEC-1) parameters? Best Regards, Georgios On 10/16/2006, "Lars Westberg" wrote: Hi, The template seems not to be a template because the mandatory part is more or less the same as Intserv. The main idea with QoS-template was to make an modular solution that could allow flexibillity for different Qos-models Therefore, I do not understand the scope of the specification. I suggest that we move the major part of the parameters to a separate "Int.serv. over NSIS" specification. Int.serv. can be seen as a common bearer service. regards Lasse Ash, Gerald R (Jerry), ALABS wrote: Lars, You mention in the below e-mail that there are no open issues, while there is a huge discussion on the nsis mailing list regarding the QSPEC-1 parameters. John can call a different consensus if he sees one (I've asked him a couple of times to do that). What I saw was 1. Many posts supported the QSPEC-1 concept, only one (or maybe two) I saw opposed. The opposing view was repeated *many* times (and is still being repeated) but it only counts as one opinion. 2. Many posts supported retaining the 4 QSPEC-1 parameters, only one I saw opposed. The opposing view was repeated many times. 3. There was only one opinion expressed to be able to ignore QSPEC-1 parameters. That one opinion has been repeated many times but it only counts as one opinion. John asked a while ago for new opinions on these issues, that would be good if there are any *new* opinions. We don't need to hear opinions repeated that we've seen so many times. I invite John once again to make a consensus call so we can move on here. I think it is time to make progress and stop repeating ourselves, we're not generating any new light in this rather endless discussion. Thanks, Jerry ------=_NextPart_000_00A6_01C6F20C.703971A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi John
 
A solution of this can be as = follows.
 
First of all: the QSPEC template does = not specify=20  mandatory parameters.
 
However, an end-to-end QoS model may mandate = the use of a=20 QSPEC parameter.
Any QNE that suopports this end-to-end QoS = model then it=20 will have to interpret
(strictly or remap) this parameter. The = remapping is then=20 specified in the end -to-end QOSM draft.
 
Another local QoS model that needs to = interoperate with the=20 end-to-end QoS model it will either
have to strictly interpret the parameter = specified=20 by the end -to- end QoS model, or to remap = it. 
The remapping is also specified in the local = QOSM=20 draft.
 
However, if a QNE does not support the = end-to-end QoS model=20 then it will just set the
NON-QOSM Hop=20 flag.
In this way we achieve both modularity and=20 interoperability.
 
Best Regards,
Georgios
 
 
 

From: john.loughney@nokia.com=20 [mailto:john.loughney@nokia.com]
Sent: dinsdag 17 oktober = 2006=20 16:21
To: karagian@cs.utwente.nl;=20 Lars.westberg@ericsson.com
Cc: gash@att.com;=20 nsis@ietf.org
Subject: RE: [NSIS] I-D=20 ACTION:draft-ietf-nsis-qspec-12.txt

Georgios,
 
About having the QoS Models specifying = manditory=20 parameters - could you explain how we would get interoperability = between two=20 different QoS models that have different sets of manditory=20 parameters?
 
I think we need to have a baseline QSPEC with = manditory=20 parameters to ensure interoperability - we should have the lowest = common=20 denominator between the QoS models to ensure some way of being able to = signal=20 across multiple QoS model deployments.
 
John

From: ext Georgios Karagiannis=20 [mailto:karagian@cs.utwente.nl]
Sent: 17 October, 2006=20 01:40
To: 'Lars Westberg'
Cc: gash@att.com;=20 nsis@ietf.org
Subject: RE: [NSIS] I-D=20 ACTION:draft-ietf-nsis-qspec-12.txt

Hi Lars
 
I think that I agree with = you!
 
However, we=20 may just need one QSPEC parameter, say Traffic (Tocken Bucket and = Bandwidth)=20
that can be=20 mandatory. In this way we will provide the required interoperability = between=20 the
QoS=20 models.
Actually this=20 was also the conclusion that Xiaoming deduced after studying a = couple of=20 examples.
 
Furthermore, we could however provide the = ability to=20 QoS models to specify which
QSPEC parameters should be mandatory or=20 not.
What do you think?
 
Best regards,
Georgios
 
 

From: Lars Westberg=20 [mailto:Lars.westberg@ericsson.com]
Sent: dinsdag 17 = oktober=20 2006 8:46
To: Georgios Karagiannis
Cc: = gash@att.com;=20 nsis@ietf.org
Subject: Re: [NSIS] I-D=20 ACTION:draft-ietf-nsis-qspec-12.txt

yes.
the main problem is that IETF is not the only=20 Standardization organization that like to discuss "bearer = services". Just=20 as an example :
If we specify the those parameters, How can we = use NSIS=20 for SLAs specified by MEF????

How can we use it for = 3GPP-Qos=20 definitiions ?


In the draft I also see  that we = the draft=20 specify a new bearer service. It is not compliant to old Int.serv=20 architecture.  This is a completely new one with new = parameters like=20 priority.

I can sure that we can have a never-ending = discussion=20 about the "optimal"-set of parameters.

I think we agree in=20 beggining the working group discussion that we should not specify = any=20 "bearer-service" because NSIS should be a modular architecture = with =20 more flexibillity than RSVP.  Therefore, I am surprised that = we are=20 doing the same mistake as in RSVP: Integrating a bearer service = definition=20 into the NSIS-architecture.

If we go this track, the = QoS-part of=20 NSIS has much less use. RSVP is in this case significantly better = in terms=20 of performance and have the same functionality than NSIS.
If = have to=20 choose I would select RSVP rather than a much more complex  = three=20 layer protocol stack.

regards Lasse

Georgios = Karagiannis=20 wrote:
Hi Lars

Do you mean that the QSPEC template must not contain any mandatory
(QSPEC-1) parameters?


Best Regards,
Georgios



On 10/16/2006, "Lars Westberg" <Lars.westberg@ericsson.com=
> wrote:

  
Hi,
The template seems not to be a template because the mandatory part  is
more or less the same as Intserv.
The main idea with QoS-template was to make an modular solution that
could allow flexibillity for different Qos-models

Therefore, I do not understand the scope of the specification.

I suggest that we move the major part of the parameters to a separate
"Int.serv. over NSIS" specification.
Int.serv. can be seen as a common bearer service.

regards Lasse

Ash, Gerald R (Jerry), ALABS wrote:

    
Lars,

      
You mention in the =
below e-mail that there are no open issues,
while there is a huge discussion on the nsis mailing list
regarding the QSPEC-1 parameters.
        
John can call a different =
consensus if he sees one (I've asked him a
couple of times to do that).  What I saw was

1. Many posts supported the QSPEC-1 concept, only one (or maybe two) I
saw opposed.  The opposing view was repeated *many* times (and is still
being repeated) but it only counts as one opinion.
2. Many posts supported retaining the 4 QSPEC-1 parameters, only one I
saw opposed.  The opposing view was repeated many times.
3. There was only one opinion expressed to be able to ignore QSPEC-1
parameters.  That one opinion has been repeated many times but it only
counts as one opinion.

John asked a while ago for new opinions on these issues, that would be
good if there are any *new* opinions.  We don't need to hear opinions
repeated that we've seen so many times.

I invite John once again to make a consensus call so we can move on
here.  I think it is time to make progress and stop repeating ourselves,
we're not generating any new light in this rather endless discussion.

Thanks,
Jerry

      

  =
------=_NextPart_000_00A6_01C6F20C.703971A0-- --===============0942054710== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0942054710==-- From nsis-bounces@ietf.org Tue Oct 17 10:53:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZqJB-0002HO-P8; Tue, 17 Oct 2006 10:52:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZqJB-0002HD-67 for nsis@ietf.org; Tue, 17 Oct 2006 10:52:45 -0400 Received: from difra-computer.de ([81.169.157.103] helo=www.difra-computer.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZqJ7-0000sQ-Eh for nsis@ietf.org; Tue, 17 Oct 2006 10:52:45 -0400 Received: from win2003.dickmann2003.home (p548A7D96.dip.t-dialin.net [84.138.125.150]) by www.difra-computer.de (Postfix) with ESMTP id 44BB03E4011 for ; Tue, 17 Oct 2006 16:52:03 +0200 (CEST) Received: from [127.0.0.1] ([192.168.28.2]) by win2003.dickmann2003.home with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 16:40:45 +0200 Message-ID: <4534EDCF.40101@christian-dickmann.de> Date: Tue, 17 Oct 2006 10:50:55 -0400 From: Christian Dickmann User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Lars Westberg (KI/EAB)" Subject: Re: [NSIS] messages content References: <0CDAE977A7172A40A2A3A1C20C12BD650488B0C6@esealmw106.eemea.ericsson.se> In-Reply-To: <0CDAE977A7172A40A2A3A1C20C12BD650488B0C6@esealmw106.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Oct 2006 14:40:45.0799 (UTC) FILETIME=[3AD7FF70:01C6F1FA] X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, I am the main developer of the GIST implementation of the University of Goettingen. To me, the draft explains how messages look like pretty well and I have no clue how the draft could be more precise (from the structure point of view). > I can't all questions on the list. I would rather appreciate an example > implementation of it with message shown in text-format. Does the > implementation showing the messages in text ?? > > If so, I am interested in it. Is it possible to get a copy ??? > We implemented an dissector, which is able to display GIST (and QoS, NATFW, etc.) messages in the popular network protocol analyzer Ethereal (now known as Wireshark). In addition, we got several captures of NSIS sessions (some of them captured at the recent Interop event) that we can provide. So with this, you can look at every message, look at every detail you want and see how GIST works in real life. Please have a look at http://user.informatik.uni-goettingen.de/~nsis/ethereal.html Christian Dickmann _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 17 10:53:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZqJE-0002K3-17; Tue, 17 Oct 2006 10:52:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZqJD-0002Jb-4U for nsis@ietf.org; Tue, 17 Oct 2006 10:52:47 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZqJ8-0000vI-I1 for nsis@ietf.org; Tue, 17 Oct 2006 10:52:47 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DA1765E3; Tue, 17 Oct 2006 16:52:41 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 16:52:41 +0200 Received: from ericsson.com ([147.214.26.58]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 16:52:40 +0200 Message-ID: <4534EE39.60703@ericsson.com> Date: Tue, 17 Oct 2006 16:52:41 +0200 From: Lars Westberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt References: In-Reply-To: X-OriginalArrivalTime: 17 Oct 2006 14:52:40.0843 (UTC) FILETIME=[E50B0DB0:01C6F1FB] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 9e1884bf469cda400682762c3e8d96c9 Cc: gash@att.com, karagian@cs.utwente.nl, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2108465015==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============2108465015== Content-Type: multipart/alternative; boundary="------------040101030909020406090807" This is a multi-part message in MIME format. --------------040101030909020406090807 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Once again, you are making the same statement. A service defintion can not be future proof. there are no such definitions. We seen during 15 years of experience from ATM,FR, Int.serv. and MEF and 3GPP-Qos that different definition has come and go. john.loughney@nokia.com wrote: > Georgios, > > About having the QoS Models specifying manditory parameters - could > you explain how we would get interoperability between two different > QoS models that have different sets of manditory parameters? > > I think we need to have a baseline QSPEC with manditory parameters to > ensure interoperability - we should have the lowest common denominator > between the QoS models to ensure some way of being able to signal > across multiple QoS model deployments. > Why should we have NSIS when we have RSVP ? RSVP specifies two service types and we hard-coded only one service type in the basic-specification of NSIS ????????? The bearer service definition was separately specified in a separate working group. In NSIS we integrate everything in one spec. I get more and more confused.... > John > > ------------------------------------------------------------------------ > From: ext Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > Sent: 17 October, 2006 01:40 > To: 'Lars Westberg' > Cc: gash@att.com; nsis@ietf.org > Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt > > Hi Lars > > I think that I agree with you! > > However, we may just need one QSPEC parameter, say Traffic (Tocken > Bucket and Bandwidth) > that can be mandatory. In this way we will provide the required > interoperability between the > QoS models. > Actually this was also the conclusion that Xiaoming deduced after > studying a couple of examples. > > Furthermore, we could however provide the ability to QoS models to > specify which > QSPEC parameters should be mandatory or not. > What do you think? > > Best regards, > Georgios > > > > ------------------------------------------------------------------------ > From: Lars Westberg [mailto:Lars.westberg@ericsson.com] > Sent: dinsdag 17 oktober 2006 8:46 > To: Georgios Karagiannis > Cc: gash@att.com; nsis@ietf.org > Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt > > yes. > the main problem is that IETF is not the only Standardization > organization that like to discuss "bearer services". Just as > an example : > If we specify the those parameters, How can we use NSIS for > SLAs specified by MEF???? > > How can we use it for 3GPP-Qos definitiions ? > > > In the draft I also see that we the draft specify a new > bearer service. It is not compliant to old Int.serv > architecture. This is a completely new one with new > parameters like priority. > > I can sure that we can have a never-ending discussion about > the "optimal"-set of parameters. > > I think we agree in beggining the working group discussion > that we should not specify any "bearer-service" because NSIS > should be a modular architecture with more flexibillity than > RSVP. Therefore, I am surprised that we are doing the same > mistake as in RSVP: Integrating a bearer service definition > into the NSIS-architecture. > > If we go this track, the QoS-part of NSIS has much less use. > RSVP is in this case significantly better in terms of > performance and have the same functionality than NSIS. > If have to choose I would select RSVP rather than a much more > complex three layer protocol stack. > > regards Lasse > > Georgios Karagiannis wrote: > >>Hi Lars >> >>Do you mean that the QSPEC template must not contain any mandatory >>(QSPEC-1) parameters? >> >> >>Best Regards, >>Georgios >> >> >> >>On 10/16/2006, "Lars Westberg" wrote: >> >> >> >>>Hi, >>>The template seems not to be a template because the mandatory part is >>>more or less the same as Intserv. >>>The main idea with QoS-template was to make an modular solution that >>>could allow flexibillity for different Qos-models >>> >>>Therefore, I do not understand the scope of the specification. >>> >>>I suggest that we move the major part of the parameters to a separate >>>"Int.serv. over NSIS" specification. >>>Int.serv. can be seen as a common bearer service. >>> >>>regards Lasse >>> >>>Ash, Gerald R (Jerry), ALABS wrote: >>> >>> >>> >>>>Lars, >>>> >>>> >>>> >>>>>You mention in the below e-mail that there are no open issues, >>>>>while there is a huge discussion on the nsis mailing list >>>>>regarding the QSPEC-1 parameters. >>>>> >>>>> >>>>John can call a different consensus if he sees one (I've asked him a >>>>couple of times to do that). What I saw was >>>> >>>>1. Many posts supported the QSPEC-1 concept, only one (or maybe two) I >>>>saw opposed. The opposing view was repeated *many* times (and is still >>>>being repeated) but it only counts as one opinion. >>>>2. Many posts supported retaining the 4 QSPEC-1 parameters, only one I >>>>saw opposed. The opposing view was repeated many times. >>>>3. There was only one opinion expressed to be able to ignore QSPEC-1 >>>>parameters. That one opinion has been repeated many times but it only >>>>counts as one opinion. >>>> >>>>John asked a while ago for new opinions on these issues, that would be >>>>good if there are any *new* opinions. We don't need to hear opinions >>>>repeated that we've seen so many times. >>>> >>>>I invite John once again to make a consensus call so we can move on >>>>here. I think it is time to make progress and stop repeating ourselves, >>>>we're not generating any new light in this rather endless discussion. >>>> >>>>Thanks, >>>>Jerry >>>> >>>> >>>> >> >> >> --------------040101030909020406090807 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit ; Tue, 17 Oct 2006 16:52:03 +0200 (CEST) Received: from [127.0.0.1] ([192.168.28.2]) by win2003.dickmann2003.home with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 16:40:45 +0200 Message-ID: <4534EDCF.40101@christian-dickmann.de> Date: Tue, 17 Oct 2006 10:50:55 -0400 From: Christian Dickmann User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Lars Westberg (KI/EAB)" Subject: Re: [NSIS] messages content References: <0CDAE977A7172A40A2A3A1C20C12BD650488B0C6@esealmw106.eemea.ericsson.se> In-Reply-To: <0CDAE977A7172A40A2A3A1C20C12BD650488B0C6@esealmw106.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Oct 2006 14:40:45.0799 (UTC) FILETIME=[3AD7FF70:01C6F1FA] X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, I am the main developer of the GIST implementation of the University of Goettingen. To me, the draft explains how messages look like pretty well and I have no clue how the draft could be more precise (from the structure point of view). > I can't all questions on the list. I would rather appreciate an example > implementation of it with message shown in text-format. Does the > implementation showing the messages in text ?? > > If so, I am interested in it. Is it possible to get a copy ??? > We implemented an dissector, which is able to display GIST (and QoS, NATFW, etc.) messages in the popular network protocol analyzer Ethereal (now known as Wireshark). In addition, we got several captures of NSIS sessions (some of them captured at the recent Interop event) that we can provide. So with this, you can look at every message, look at every detail you want and see how GIST works in real life. Please have a look at http://user.informatik.uni-goettingen.de/~nsis/ethereal.html Christian Dickmann _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 17 10:53:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZqJE-0002K3-17; Tue, 17 Oct 2006 10:52:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZqJD-0002Jb-4U for nsis@ietf.org; Tue, 17 Oct 2006 10:52:47 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZqJ8-0000vI-I1 for nsis@ietf.org; Tue, 17 Oct 2006 10:52:47 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DA1765E3; Tue, 17 Oct 2006 16:52:41 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.17> Once again, you are making the same statement. A service defintion can not be future proof. there are no such definitions.
We seen during 15 years of experience from ATM,FR, Int.serv. and MEF and 3GPP-Qos that different definition has come and go.



john.loughney@nokia.com wrote:
Georgios,
 
About having the QoS Models specifying manditory parameters - could you explain how we would get interoperability between two different QoS models that have different sets of manditory parameters?
 
I think we need to have a baseline QSPEC with manditory parameters to ensure interoperability - we should have the lowest common denominator between the QoS models to ensure some way of being able to signal across multiple QoS model deployments.
 
Why should we have NSIS when we have RSVP ?
RSVP specifies two service types and we hard-coded only one service type in the basic-specification of NSIS ?????????
The bearer service definition was separately specified in a separate working group.
In NSIS we integrate everything in one spec.

I get more and more confused....


John

From: ext Georgios Karagiannis [mailto:karagian@cs.utwente.nl]
Sent: 17 October, 2006 01:40
To: 'Lars Westberg'
Cc: gash@att.com; nsis@ietf.org
Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

Hi Lars
 
I think that I agree with you!
 
However, we may just need one QSPEC parameter, say Traffic (Tocken Bucket and Bandwidth)
that can be mandatory. In this way we will provide the required interoperability between the
Georgios, > > About having the QoS Models specifying manditory parameters - could > you explain how we would get interoperability between two different > QoS models that have different sets of manditory parameters? > > I think we need to have a baseline QSPEC with manditory parameters to > ensure interoperability - we should have the lowest common denominator > between the QoS models to ensure some way of being able to signal > across multiple QoS model deployments. > Why should we have NSIS when we have RSVP ? RSVP specifies two service types and we hard-coded only one service type in the basic-specification of NSIS ????????? The bearer service definition was separately specified in a separate working group. In NSIS we integrate everything in one spec. I get more and more confused.... > John > > ------------------------------------------------------------------------ > From: ext Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > Sent: 17 October, 2006 01:40 > To: 'Lars Westberg' > Cc: gash@att.com; nsis@ietf.org > Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt > > Hi Lars > > I think that I agree with you! > > However, we may just need one QSPEC parameter, say Traffic (Tocken > Bucket and Bandwidth) > that can be mandatory. In this way we will provide the required > interoperability between the > QoS models. > Actually this was also the conclusion that Xiaoming deduced after > studying a couple of examples. > > Furthermore, we could however provide the ability to QoS models to > specify which > QSPEC parameters should be mandatory or not. > What do you think? > > Best regards, > Georgios > > > > ------------------------------------------------------------------------ > From: Lars Westberg [mailto:Lars.006">QoS models.
Actually this was also the conclusion that Xiaoming deduced after studying a couple of examples.
 
Furthermore, we could however provide the ability to QoS models to specify which
QSPEC parameters should be mandatory or not.
What do you think?
 
Best regards,
Georgios
 
 

From: Lars Westberg [mailto:Lars.westberg@ericsson.com]
Sent: dinsdag 17 oktober 2006 8:46
To: Georgios Karagiannis
Cc: gash@att.com; nsis@ietf.org
Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

yes.
the main problem is that IETF is not the only Standardization organization that like to discuss "bearer services". Just as an example :
If we specify the those parameters, How can we use NSIS for SLAs specified by MEF????

How can we use it for 3GPP-Qos definitiions ?


In the draft I also see  that we the draft specify a new bearer service. It is not compliant to old Int.serv architecture.  This is a completely new one with new parameters like priority.

I can sure that we can have a never-ending discussion about the "optimal"-set of parameters.

I think we agree in beggining the working group discussion that we should not specify any "bearer-service" because NSIS should be a modular architecture with  more flexibillity than RSVP.  Therefore, I am surprised that we are doing the same mistake as in RSVP: Integrating a bearer service definition into the NSIS-architecture.

If we go this track, the QoS-part of NSIS has much less use. RSVP is in this case significantly better in terms of performance and have the same functionality than NSIS.
If have to choose I would select RSVP rather than a much more complex  three layer protocol stack.

regards Lasse

Georgios Karagiannis wrote:
Hi Lars

Do you mean that the QSPEC template must not contain any mandatory
(QSPEC-1) parameters?


Best Regards,
Georgios



On 10/16/2006, "Lars Westberg" <Lars.westberg@ericsson.com> wrote:

  
Hi,
The template seems not to be a template because the mandatory part  is
more or less the same as Intserv.
The main idea wiwestberg@ericsson.com]
>         Sent: dinsdag 17 oktober 2006 8:46
>         To: Georgios Karagiannis
>         Cc: gash@att.com; nsis@ietf.org
>         Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt
>
>         yes.
>         the main problem is that IETF is not the only Standardization
>         organization that like to discuss "bearer services". Just as
>         an example :
>         If we specify the those parameters, How can we use NSIS for
>         SLAs specified by MEF????
>
>         How can we use it for 3GPP-Qos definitiions ?
>
>
>         In the draft I also see  that we the draft specify a new
>         bearer service. It is not compliant to old Int.serv
>         architecture.  This is a completely new one with new
>         parameters like priority.
>
>         I can sure that we can have a never-ending discussion about
>         the "optimal"-set of parameters.
>
>         I think we agree in beggining the working group discussion
>         that we should not specify any "bearer-service" because NSIS
>         should be a modular architecture with  more flexibillity than
>         RSVP.  Therefore, I am surprised that we are doing the same
>         mistake as in RSVP: Integrating a bearer service definition
>         into the NSIS-architecture.
>
>         If we go this track, the QoS-part of NSIS has much less use.
>         RSVP is in this case significantly better in terms of
>         performance and have the same functionality than NSIS.
>         If have to choose I would select RSVP rather than a much more
>         complex  three layer protocol stack.
>
>         regards Lasse
>
>         Georgios Karagiannis wrote:
>
>>Hi Lars
>>
>>Do you mean that the QSPEC template must not contain any mandatory
>>(QSPEC-1) parameters?
>>
>>
>>Best Regards,
>>Georgios
>>
>>
>>
>>On 10/16/2006, "Lars Westberg"  wrote:
>>
>>  
>>
>>>Hi,
>>>The template seems not to be a template because the mandatory part  is
>>>more or less the same as Intserv.
>>>The main idea with QoS-template was to make an modular solution that
>>>could allow flexibillity for different Qos-models
>>>
>>>Therefore, I do not understand the scope of the specification.
>>>
>>>I suggest that we move the major part of the parameters to a separate
>>>"Int.serv. over NSIS" specification.
>>>Int.serv. can be seen as a common bearer service.
>>>
>>>regards Lasse
>>>
>>>Ash, Gerald R (Jerry), ALABS wrote:
>>>
>>>    
>>>
>>>>Lars,
>>>>
>>>>      
>>>>
>>>>>You mention in the below e-mail that there are no open issues,
>>>>>while there is a huge discussion on the nsis mailing list
>>>>>regarding the QSPEC-1 parameters.
>>>>>        
>>>>>
>>>>John can call a different consensus if he sees one (I've asked him a
>>>>couple of times to do that).  What I saw was
>>>>
>>>>1. Many posts supported the QSPEC-1 concept, only one (or maybe two) I
>>>>saw opposed.  The opposing view was repeated *many* times (and is still
>>>>being repeated) but it only counts as one opinion.
>>>>2. Many posts supported retaining the 4 QSPEC-1 parameters, only one I
>>>>saw opposed.  The opposing view was repeated many times.
>>>>3. There was only one opinion expressed to be able to ignore QSPEC-1
>>>>parameters.  That one opinion has been repeated many times but it only
>>>>counts as one opinion.
>>>>
>>>>John asked a while ago for new opinions on these issues, that would be
>>>>good if there are any *new* opinions.  We don't need to hear opinions
>>>>repeated that we've seen so many times.
>>>>
>>>>I invite John once again to make a consensus call so we can move on
>>>>here.  I think it is time to make progress and stop repeating ourselves,
>>>>we're not generating any new light in this rather endless discussion.
>>>>
>>>>Thanks,
>>>>Jerry
>>>>
>>>>      
>>>>
>>
>>  
>>

--------------040101030909020406090807
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit




  
          

            
Lars,

      

            

              
You mention in the below e-mail that there are no open issues,
while there is a huge discussion on the nsis mailing list
regarding the QSPEC-1 parameters.
        

            

            
John can call a different consensus if he sees one (I've asked him a
couple of times to do that).  What I saw was

1. Many posts supported the QSPEC-1 concept, only one (or maybe two) I
saw opposed.  The opposing view was repeated *many* times (and is still
being repeated) but it only counts as one opinion.
2. Many posts supported retaining the 4 QSPEC-1 parameters, only one I
saw opposed.  The opposing view was repeated many times.
3. There was only one opinion expressed to be able to ignore QSPEC-1
parameters.  That one opinion has been repeated many times but it only
counts as one opinion.

John asked a while ago for new opinions on these issues, that would be
good if there are any *new* opinions.  We don't need to hear opinions
repeated that we've seen so many times.

I invite John once again to make a consensus call so we can move on
here.  I think it is time to make progress and stop repeating ourselves,
we're not generating any new light in this rather endless discussion.

Thanks,
Jerry
--------------040101030909020406090807-- --===============2108465015== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============2108465015==-- > Once again, you are making the same statement. A service defintion can not be future proof. there are no such definitions.
We seen during 15 years of experience from ATM,FR, Int.serv. and MEF and 3GPP-Qos that different definition has come and go.



john.loughney@nokia.com wrote:
Georgios,
 
About having the QoS Models specifying manditory parameters - could you explain how we would get interoperability between two different QoS models that have different sets of manditory parameters?
 
I think we need to have a baseline QSPEC with manditory parameters to ensure interoperability - we should have the lowest common denominator between the QoS models to ensure some way of being able to signal across multiple QoS model deployments.
 
Why should we have NSIS when we have RSVP ?
RSVP specifies two service types and we hard-coded only one service type in the basic-specification of NSIS ?????????
The bearer service definition was separately specified in a separate working group.
In NSIS we integrate everything in one spec.

I get more and more confused....


John

From: ext Georgios Karagiannis [mailto:karagian@cs.utwente.nl]
Sent: 17 October, 2006 01:40
To: 'Lars Westberg'
Cc: gash@att.com; nsis@ietf.org
Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

Hi Lars
 
I think that I agree with you!
 
However, we may just need one QSPEC parameter, say Traffic (Tocken Bucket and Bandwidth)
that can be mandatory. In this way we will provide the required interoperability between the
QoS models.
Actually this was also the conclusion that Xiaoming deduced after studying a couple of examples.
 
Furthermore, we could however provide the ability to QoS models to specify which
QSPEC parameters should be mandatory or not.
What do you think?
 
Best regards,
Georgios
 
 

From: Lars Westberg [mailto:Lars.westberg@ericsson.com]
Sent: dinsdag 17 oktober 2006 8:46
To: Georgios Karagiannis
Cc: gash@att.com; nsis@ietf.org
Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

yes.
the main problem is that IETF is not the only Standardization organization that like to discuss "bearer services". Just as an example :
If we specify the those parameters, How can we use NSIS for SLAs specified by MEF????

How can we use it for 3GPP-Qos definitiions ?


In the draft I also see  that we the draft specify a new bearer service. It is not compliant to old Int.serv architecture.  This is a completely new one with new parameters like priority.

I can sure that we can have a never-ending discussion about the "optimal"-set of parameters.

I think we agree in beggining the working group discussion that we should not specify any "bearer-service" because NSIS should be a modular architecture with  more flexibillity than RSVP.  Therefore, I am surprised that we are doing the same mistake as in RSVP: Integrating a bearer service definition into the NSIS-architecture.

If we go this track, the QoS-part of NSIS has much less use. RSVP is in this case significantly better in terms of performance and have the same functionality than NSIS.
If have to choose I would select RSVP rather than a much more complex  three layer protocol stack.

regards Lasse

Georgios Karagiannis wrote:
Hi Lars

Do you mean that the QSPEC template must not contain any mandatory
(QSPEC-1) parameters?


Best Regards,
Georgios



On 10/16/2006, "Lars Westberg" <Lars.westberg@ericsson.com> wrote:

  
Hi,
The template seems not to be a template because the mandatory part  is
more or less the same as Intserv.
The main idea with QoS-template was to make an modular solution that
could allow flexibillity for different Qos-models

Therefore, I do not understand the scope of the specification.

I suggest that we move the major part of the parameters to a separate
"Int.serv. over NSIS" specification.
Int.serv. can be seen as a common bearer service.

regards Lasse

Ash, Gerald R (Jerry), ALABS wrote:

    
Lars,

      
You mention in the below e-mail that there are no open issues,
while there is a huge discussion on the nsis mailing list
regarding the QSPEC-1 parameters.
        
John can call a different consensus if he sees one (I've asked him a
couple of times to do that).  What I saw was

1. Many posts supported the QSPEC-1 concept, only one (or maybe two) I
saw opposed.  The opposing view was repeated *many* times (and is still
being repeated) but it only counts as one opinion.
2. Many posts supported retaining the 4 QSPEC-1 parameters, only one I
saw opposed.  The opposing view was repeated many times.
3. There was only one opinion expressed to be able to ignore QSPEC-1
parameters.  That one opinion has been repeated many times but it only
counts as one opinion.

John asked a while ago for new opinions on these issues, that would be
good if there are any *new* opinions.  We don't need to hear opinions
repeated that we've seen so many times.

I invite John once again to make a consensus call so we can move on
here.  I think it is time to make progress and stop repeating ourselves,
we're not generating any new light in this rather endless discussion.

Thanks,
Jerry
--------------040101030909020406090807-- --===============2108465015== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============2108465015==-- From nsis-bounces@ietf.org Tue Oct 17 10:55:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZqLd-0003lX-9A; Tue, 17 Oct 2006 10:55:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZqLc-0003lS-2g for nsis@ietf.org; Tue, 17 Oct 2006 10:55:16 -0400 Received: from mclmx2.mail.saic.com ([149.8.64.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZqLY-0001FV-4m for nsis@ietf.org; Tue, 17 Oct 2006 10:55:16 -0400 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com; Tue, 17 Oct 2006 10:54:55 -0400 Received: from 0015-ITS-EXBH01.us.saic.com ([10.43.229.18]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006101710545505962 ; Tue, 17 Oct 2006 10:54:55 -0400 Received: from 0591-ITS-EXMP02.us.saic.com ([10.42.81.248]) by 0015-ITS-EXBH01.us.saic.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 10:54:54 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Date: Tue, 17 Oct 2006 10:54:53 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426230EC6@0591-ITS-EXMP02.us.saic.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Thread-Index: AcbxuHtQ92fBk4GyRnaw38rAcCkjiQAOXHnQAAEtkJA= From: "Roy, Radhika R." To: , , X-OriginalArrivalTime: 17 Oct 2006 14:54:54.0428 (UTC) FILETIME=[34AA81C0:01C6F1FC] X-Spam-Score: 0.0 (/) X-Scan-Signature: d3dffd2aefc0f55425d5c0046903fc08 Cc: gash@att.com, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0494416870==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0494416870== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F1FC.344447A2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F1FC.344447A2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable John: =20 You also need to understand that there are apples and oranges when we compare different QOS models. =20 If you do not dig-in one layer down, you will miss the basic point. Let me explain as follows: =20 1. If you think at the first layer of statement like "QOS Model," you will find that all are the same: DiffServ, RSVP, IntServ, Y.1541, and DSTE. This is providing the illusion as it they are the same. 2. If you think that what has been the basis for QOS models, you will get different answers: Type I - Based on characteristics of Services with non-defined specific values (DiffServ, RSVP, and IntServ) and Type II: QOS models depend on "specific" arbitrary values (Y.1541, and DSTE). 3. Like NSIS QOS signaling protocol that is general enough not to be tied based on specific values that are the usual characteristics for a set of given implementations, only Type I (DiffServ, RSVP, and IntServ) QOS models will be compatible. All Type I (DiffServ, RSVP, and IntServ) QOS models are compatible among themselves. That is, DiffServ, RSVP, and IntServ QOS models can interwork with proper mapping among themselves as they have been defined with some specific application service features/parameters (NOT based on some arbitrary values). 4. Unlike NSIS QOS signaling protocol that is generalized to be used under any specific implementations, Type II (Y.1541, and DSTE) QOS Models are incompatible in all respects. That is, they are incompatible for interworking between Y.1541 and DSTE as well as they are incompatible between Type I and Type II QOS model. 5. NSIS QOS signaling protocol is facing problems when QSPEC templates contain all the QOS parameters mixing with Type I and Type II QOS parameters. Here are the problems of mixing between "apples" and "oranges" as explained above. 6. Georgios, Lasse and others have come to the same conclusion of incompatibility of interworking because of the above (e.g., one deals with "bandwidth" while other deals with 50-ms. How do you make interworking between these two, etc. etc.?). =20 So, it is NOT too complicated. It is the problem of generalizing two incompatible QOS models as if mixing between water and oil. =20 AD will be better advised not to generalize ITU-T's Y.1541 QOS model with IETF's DiffServ/RSVP. In this way, problems can be isolated, and QOS issues will take its own turn. =20 Let Y.1541 QOS model stand on its own foot writing a stand-alone showing how to use NSIS QOS signaling protocol for this specific implementation. We have seen that any mandate that allows the Y.1541/DSTE QOS model to be generalized for interworking with DIffServ/RSVP while using NSIS QOS signaling protocol is NOT going to happen because of the incompatibility problems. =20 Recently, some technical twist has been seen to quantify so-called QOS classes of Y.1541 like high, medium, and low, as if, Y1541 QOS models, are also on the same basis like that of Type I QOS model based on non-specific "values." This technical twist will NOT help as it is distorting the technical fact more. =20 Best regards, Radhika =20 =20 ________________________________ From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On Behalf Of john.loughney@nokia.com Sent: Tuesday, October 17, 2006 9:45 AM To: Lars.westberg@ericsson.com; karagian@cs.utwente.nl Cc: gash@att.com; nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt =20 There was a proposal for a QoS model on 3GPP QoS model, by the way. http://www.watersprings.org/pub/id/draft-jeong-nsis-3gpp-qosm-02.txt =20 However, I think that we are going circular. The QSPEC defines a general model for being able to support different QoS Models. We were asked to look at how to support different models, including Y1541, by our AD at the time and by ITU-T liasons. =20 If you feel that things are too complicated, I would suggest you send a list of what you consider to be mandatory and what is optional (or in otherwords, what is essential and what is not). It could be that we have created something that is more complicated than what is generally needed, but then we need a counter proposal. =20 thanks, John =20 =20 =09 ________________________________ From: ext Lars Westberg [mailto:Lars.westberg@ericsson.com]=20 Sent: 16 October, 2006 23:46 To: Georgios Karagiannis Cc: gash@att.com; nsis@ietf.org Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt yes.=20 the main problem is that IETF is not the only Standardization organization that like to discuss "bearer services". Just as an example : If we specify the those parameters, How can we use NSIS for SLAs specified by MEF???? =09 How can we use it for 3GPP-Qos definitiions ? =09 =09 In the draft I also see that we the draft specify a new bearer service. It is not compliant to old Int.serv architecture. This is a completely new one with new parameters like priority. =09 I can sure that we can have a never-ending discussion about the "optimal"-set of parameters. =09 I think we agree in beggining the working group discussion that we should not specify any "bearer-service" because NSIS should be a modular architecture with more flexibillity than RSVP. Therefore, I am surprised that we are doing the same mistake as in RSVP: Integrating a bearer service definition into the NSIS-architecture. =09 If we go this track, the QoS-part of NSIS has much less use. RSVP is in this case significantly better in terms of performance and have the same functionality than NSIS. If have to choose I would select RSVP rather than a much more complex three layer protocol stack. =09 regards Lasse =09 Georgios Karagiannis wrote: =09 =09 Hi Lars =20 Do you mean that the QSPEC template must not contain any mandatory (QSPEC-1) parameters? =20 =20 Best Regards, Georgios =20 =20 =20 On 10/16/2006, "Lars Westberg" wrote: =20 =20 Hi, The template seems not to be a template because the mandatory part is more or less the same as Intserv. The main idea with QoS-template was to make an modular solution that could allow flexibillity for different Qos-models =20 Therefore, I do not understand the scope of the specification. =20 I suggest that we move the major part of the parameters to a separate "Int.serv. over NSIS" specification. Int.serv. can be seen as a common bearer service. =20 regards Lasse =20 Ash, Gerald R (Jerry), ALABS wrote: =20 =20 Lars, =20 =20 You mention in the below e-mail that there are no open issues, while there is a huge discussion on the nsis mailing list regarding the QSPEC-1 parameters. =20 John can call a different consensus if he sees one (I've asked him a couple of times to do that). What I saw was =20 1. Many posts supported the QSPEC-1 concept, only one (or maybe two) I saw opposed. The opposing view was repeated *many* times (and is still being repeated) but it only counts as one opinion. 2. Many posts supported retaining the 4 QSPEC-1 parameters, only one I saw opposed. The opposing view was repeated many times. 3. There was only one opinion expressed to be able to ignore QSPEC-1 parameters. That one opinion has been repeated many times but it only counts as one opinion. =20 John asked a while ago for new opinions on these issues, that would be good if there are any *new* opinions. We don't need to hear opinions repeated that we've seen so many times. =20 I invite John once again to make a consensus call so we can move on here. I think it is time to make progress and stop repeating ourselves, we're not generating any new light in this rather endless discussion. =20 Thanks, Jerry =20 =20 =20 =20 ------_=_NextPart_001_01C6F1FC.344447A2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

John:

 

You also need to understand that = there are apples and oranges when we compare different QOS = models.

 

If you do not dig-in one layer = down, you will miss the basic point. Let me explain as = follows:

 

1.       = If you think at the first layer of statement like “QOS = Model,” you will find that all are the same: DiffServ, RSVP, IntServ, Y.1541, = and DSTE. This is providing the illusion as it they are the = same.

2.       = If you think that what has been the basis for QOS models, = you will get different answers: Type I – Based on characteristics of = Services with non-defined specific values (DiffServ, RSVP, and IntServ) and Type II: = QOS models depend on “specific” arbitrary values (Y.1541, and = DSTE).

3.       = Like NSIS QOS signaling protocol that is general enough not = to be tied based on specific values that are the usual characteristics for a set of = given implementations, only Type I (DiffServ, RSVP, and IntServ) QOS models = will be compatible. All Type I (DiffServ, RSVP, and IntServ) QOS models are = compatible among themselves. That is, DiffServ, RSVP, and IntServ QOS models can = interwork with proper mapping among themselves as they have been defined with some specific application service features/parameters (NOT based on some = arbitrary values).

4.       = Unlike NSIS QOS signaling protocol that is generalized to be = used under any specific implementations, Type II (Y.1541, and DSTE) QOS = Models are incompatible in all respects. That is, they are incompatible for interworking between = Y.1541 and DSTE as well as they are incompatible between Type I and Type II QOS = model.

5.       = NSIS QOS signaling protocol is facing problems when QSPEC = templates contain all the QOS parameters mixing with Type I and Type II QOS = parameters. Here are the problems of mixing between “apples” and = “oranges” as explained above.

6.       = Georgios, Lasse and others have come to the same conclusion = of incompatibility of interworking because of the above (e.g., one deals = with “bandwidth” while other deals with 50-ms. How do you make interworking between these = two, etc. etc.?).

 

So, it is NOT too complicated. It = is the problem of generalizing two incompatible QOS models as if mixing between = water and oil.

 

AD will be better advised not to generalize ITU-T’s Y.1541 QOS model with IETF’s = DiffServ/RSVP. In this way, problems can be isolated, and QOS issues will take its own = turn.

 

Let Y.1541 QOS model stand on its = own foot writing a stand-alone showing how to use NSIS QOS signaling protocol for = this specific implementation. We have seen that any mandate that allows the = Y.1541/DSTE QOS model to be generalized for interworking with DIffServ/RSVP while = using NSIS QOS signaling protocol is NOT going to happen because of the incompatibility problems.

 

Recently, some technical twist has = been seen to quantify so-called QOS classes of Y.1541 like high, medium, and = low, as if, Y1541 QOS models, are also on the same basis like that of Type I QOS = model based on non-specific “values.”  This technical twist = will NOT help as it is distorting the technical fact = more.

 

Best = regards,

Radhika

=

 

 

From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] = On Behalf Of = john.loughney@nokia.com
Sent: Tuesday, October = 17, 2006 9:45 AM
To: = Lars.westberg@ericsson.com; karagian@cs.utwente.nl
Cc: gash@att.com; = nsis@ietf.org
Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

 

There was a proposal for a QoS = model on 3GPP QoS model, by the way.

http://www.watersprings.org/pub/id/draft-jeong-nsis-3gpp-qosm-02.txt=

 

However, I think that we are going circular.  The QSPEC defines a general model for being able to = support different QoS Models.  We were asked to look at how to support = different models, including Y1541, by our AD at the time and by ITU-T = liasons.

 

If you feel that things are too complicated, I would suggest you send a list of what you consider to be mandatory and what is optional (or in otherwords, what is essential and = what is not).  It could be that we have created something that is more = complicated than what is generally needed, but then we need a counter = proposal.

 

thanks,

=

John

 

 

From: ext Lars Westberg [mailto:Lars.westberg@ericsson.com]
Sent: 16 October, 2006 = 23:46
To: Georgios = Karagiannis
Cc: gash@att.com; = nsis@ietf.org
Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

yes.
the main problem is that IETF is not the only Standardization = organization that like to discuss "bearer services". Just as an example :
If we specify the those parameters, How can we use NSIS for SLAs = specified by MEF????

How can we use it for 3GPP-Qos definitiions ?


In the draft I also see  that we the draft specify a new bearer = service. It is not compliant to old Int.serv architecture.  This is a = completely new one with new parameters like priority.

I can sure that we can have a never-ending discussion about the "optimal"-set of parameters.

I think we agree in beggining the working group discussion that we = should not specify any "bearer-service" because NSIS should be a modular architecture with  more flexibillity than RSVP.  Therefore, I = am surprised that we are doing the same mistake as in RSVP: Integrating a = bearer service definition into the NSIS-architecture.

If we go this track, the QoS-part of NSIS has much less use. RSVP is in = this case significantly better in terms of performance and have the same functionality than NSIS.
If have to choose I would select RSVP rather than a much more = complex  three layer protocol stack.

regards Lasse

Georgios Karagiannis wrote:

Hi =
Lars
 
Do you mean that the QSPEC template must not =
contain any mandatory
(QSPEC-1) =
parameters?
 
 
Best =
Regards,
Georgios
 
 
 
On 10/16/2006, "Lars Westberg" <Lars.westberg@ericsson.com=
> wrote:
 
  
Hi,
The template seems not to be a template =
because the mandatory part  =
is
more or less the same as =
Intserv.
The main idea with QoS-template was to make =
an modular solution that
could allow flexibillity for different =
Qos-models
 
Therefore, I do not understand the scope of =
the specification.
 
I suggest that we move the major part of the =
parameters to a separate
"Int.serv. over NSIS" =
specification.
Int.serv. can be seen as a common bearer =
service.
 
regards =
Lasse
 
Ash, Gerald R (Jerry), ALABS =
wrote:
 
    =

Lars,
 
 =
     
You mention in the below e-mail that there =
are no open issues,
while there is a huge discussion on the nsis =
mailing list
regarding the QSPEC-1 =
parameters.
        =

John can call a different consensus if he =
sees one (I've asked him a
couple of times to do that).  What I saw =
was
 
1. Many posts supported the QSPEC-1 concept, =
only one (or maybe two) I
saw opposed.  The opposing view was =
repeated *many* times (and is =
still
being repeated) but it only counts as one =
opinion.
2. Many posts supported retaining the 4 =
QSPEC-1 parameters, only one I
saw opposed.  The opposing view was =
repeated many times.
3. There was only one opinion expressed to be =
able to ignore QSPEC-1
parameters.  That one opinion has been =
repeated many times but it only
counts as one =
opinion.
 
John asked a while ago for new opinions on =
these issues, that would be
good if there are any *new* opinions.  =
We don't need to hear opinions
repeated that we've seen so many =
times.
 
I invite John once again to make a consensus =
call so we can move on
here.  I think it is time to make =
progress and stop repeating =
ourselves,
we're not generating any new light in this =
rather endless discussion.
 
Thanks,
Jerry
 
      =

 
  =
------_=_NextPart_001_01C6F1FC.344447A2-- --===============0494416870== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0494416870==-- From nsis-bounces@ietf.org Tue Oct 17 10:59:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZqP2-0006ks-HT; Tue, 17 Oct 2006 10:58:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZqP2-0006kn-3s for nsis@ietf.org; Tue, 17 Oct 2006 10:58:48 -0400 Received: from mclmx2.mail.saic.com ([149.8.64.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZqP1-0001YT-8j for nsis@ietf.org; Tue, 17 Oct 2006 10:58:48 -0400 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com; Tue, 17 Oct 2006 10:58:17 -0400 Received: from 0015-ITS-EXBH01.us.saic.com ([10.43.229.18]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006101710581606887 ; Tue, 17 Oct 2006 10:58:17 -0400 Received: from 0591-ITS-EXMP02.us.saic.com ([10.42.81.248]) by 0015-ITS-EXBH01.us.saic.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 10:58:15 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Date: Tue, 17 Oct 2006 10:58:14 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426230EC7@0591-ITS-EXMP02.us.saic.com> In-Reply-To: <00a501c6f1fb$acb0a1a0$4c0d5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Thread-Index: Acbxt9rfPVXjqLj+T5uusDQMgUBvPwADy3pQAAwEd6AAAKI3AAAApwXg From: "Roy, Radhika R." To: "Georgios Karagiannis" , , X-OriginalArrivalTime: 17 Oct 2006 14:58:15.0340 (UTC) FILETIME=[AC6B3EC0:01C6F1FC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2b63490cb59a51fc369510b56a725cec Cc: gash@att.com, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0368896292==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0368896292== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F1FC.AC09B1AA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F1FC.AC09B1AA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Georgios: =20 I fear that it will also not solve the basic problem of incompatibility. Please see my email. It is just too much to solve as these are still subjective interpretations and too complex to implement for clear interworking. =20 Best regards, Radhika =20 ________________________________ From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On Behalf Of Georgios Karagiannis Sent: Tuesday, October 17, 2006 10:51 AM To: john.loughney@nokia.com; Lars.westberg@ericsson.com Cc: gash@att.com; nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt =20 Hi John =20 A solution of this can be as follows. =20 First of all: the QSPEC template does not specify mandatory parameters. =20 However, an end-to-end QoS model may mandate the use of a QSPEC parameter.=20 Any QNE that suopports this end-to-end QoS model then it will have to interpret=20 (strictly or remap) this parameter. The remapping is then specified in the end -to-end QOSM draft. =20 Another local QoS model that needs to interoperate with the end-to-end QoS model it will either=20 have to strictly interpret the parameter specified by the end -to- end QoS model, or to remap it.=20 The remapping is also specified in the local QOSM draft. =20 However, if a QNE does not support the end-to-end QoS model then it will just set the=20 NON-QOSM Hop flag.=20 In this way we achieve both modularity and interoperability. =20 Best Regards, Georgios =20 =20 =20 =20 =09 ________________________________ From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 Sent: dinsdag 17 oktober 2006 16:21 To: karagian@cs.utwente.nl; Lars.westberg@ericsson.com Cc: gash@att.com; nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Georgios, =20 About having the QoS Models specifying manditory parameters - could you explain how we would get interoperability between two different QoS models that have different sets of manditory parameters? =20 I think we need to have a baseline QSPEC with manditory parameters to ensure interoperability - we should have the lowest common denominator between the QoS models to ensure some way of being able to signal across multiple QoS model deployments. =20 John =20 =09 ________________________________ From: ext Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 Sent: 17 October, 2006 01:40 To: 'Lars Westberg' Cc: gash@att.com; nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Hi Lars =20 I think that I agree with you! =20 However, we may just need one QSPEC parameter, say Traffic (Tocken Bucket and Bandwidth)=20 that can be mandatory. In this way we will provide the required interoperability between the=20 QoS models. Actually this was also the conclusion that Xiaoming deduced after studying a couple of examples. =20 Furthermore, we could however provide the ability to QoS models to specify which=20 QSPEC parameters should be mandatory or not. What do you think? =20 Best regards, Georgios =20 =20 =20 =09 ________________________________ From: Lars Westberg [mailto:Lars.westberg@ericsson.com]=20 Sent: dinsdag 17 oktober 2006 8:46 To: Georgios Karagiannis Cc: gash@att.com; nsis@ietf.org Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt yes.=20 the main problem is that IETF is not the only Standardization organization that like to discuss "bearer services". Just as an example : If we specify the those parameters, How can we use NSIS for SLAs specified by MEF???? =09 How can we use it for 3GPP-Qos definitiions ? =09 =09 In the draft I also see that we the draft specify a new bearer service. It is not compliant to old Int.serv architecture. This is a completely new one with new parameters like priority. =09 I can sure that we can have a never-ending discussion about the "optimal"-set of parameters. =09 I think we agree in beggining the working group discussion that we should not specify any "bearer-service" because NSIS should be a modular architecture with more flexibillity than RSVP. Therefore, I am surprised that we are doing the same mistake as in RSVP: Integrating a bearer service definition into the NSIS-architecture. =09 If we go this track, the QoS-part of NSIS has much less use. RSVP is in this case significantly better in terms of performance and have the same functionality than NSIS. If have to choose I would select RSVP rather than a much more complex three layer protocol stack. =09 regards Lasse =09 Georgios Karagiannis wrote: =09 =09 Hi Lars =20 Do you mean that the QSPEC template must not contain any mandatory (QSPEC-1) parameters? =20 =20 Best Regards, Georgios =20 =20 =20 On 10/16/2006, "Lars Westberg" wrote: =20 =20 Hi, The template seems not to be a template because the mandatory part is more or less the same as Intserv. The main idea with QoS-template was to make an modular solution that could allow flexibillity for different Qos-models =20 Therefore, I do not understand the scope of the specification. =20 I suggest that we move the major part of the parameters to a separate "Int.serv. over NSIS" specification. Int.serv. can be seen as a common bearer service. =20 regards Lasse =20 Ash, Gerald R (Jerry), ALABS wrote: =20 =20 Lars, =20 =20 You mention in the below e-mail that there are no open issues, while there is a huge discussion on the nsis mailing list regarding the QSPEC-1 parameters. =20 John can call a different consensus if he sees one (I've asked him a couple of times to do that). What I saw was =20 1. Many posts supported the QSPEC-1 concept, only one (or maybe two) I saw opposed. The opposing view was repeated *many* times (and is still being repeated) but it only counts as one opinion. 2. Many posts supported retaining the 4 QSPEC-1 parameters, only one I saw opposed. The opposing view was repeated many times. 3. There was only one opinion expressed to be able to ignore QSPEC-1 parameters. That one opinion has been repeated many times but it only counts as one opinion. =20 John asked a while ago for new opinions on these issues, that would be good if there are any *new* opinions. We don't need to hear opinions repeated that we've seen so many times. =20 I invite John once again to make a consensus call so we can move on here. I think it is time to make progress and stop repeating ourselves, we're not generating any new light in this rather endless discussion. =20 Thanks, Jerry =20 =20 =20 =20 ------_=_NextPart_001_01C6F1FC.AC09B1AA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Georgios:

 

I fear that it will also not solve = the basic problem of incompatibility. Please see my email. It is just too = much to solve as these are still subjective interpretations and too complex to implement for clear interworking.

 

Best = regards,

Radhika

=

 

From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] = On Behalf Of Georgios = Karagiannis
Sent: Tuesday, October = 17, 2006 10:51 AM
To: = john.loughney@nokia.com; Lars.westberg@ericsson.com
Cc: gash@att.com; = nsis@ietf.org
Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

 

Hi = John

 

A solution of this can be as = follows.

 

First of all: the QSPEC template = does not specify  mandatory = parameters.

 

However, an end-to-end QoS model = may mandate the use of a QSPEC parameter.

Any QNE that suopports this = end-to-end QoS model then it will have to interpret

(strictly or remap) this parameter. = The remapping is then specified in the end -to-end QOSM = draft.

 

Another local QoS model that needs = to interoperate with the end-to-end QoS model it will either =

have to strictly interpret the = parameter specified by the end -to- end QoS model, or to remap = it. 

The remapping is also specified in = the local QOSM draft.

 

However, if a QNE does not support = the end-to-end QoS model then it will just set the =

NON-QOSM Hop flag. =

In this way we achieve both = modularity and interoperability.

 

Best = Regards,

Georgios

 

 

 

 

From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
Sent: dinsdag 17 oktober = 2006 16:21
To: = karagian@cs.utwente.nl; Lars.westberg@ericsson.com
Cc: gash@att.com; = nsis@ietf.org
Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

Georgios,

 

About having the QoS Models = specifying manditory parameters - could you explain how we would get = interoperability between two different QoS models that have different sets of manditory parameters?

 

I think we need to have a baseline = QSPEC with manditory parameters to ensure interoperability - we should have = the lowest common denominator between the QoS models to ensure some way of = being able to signal across multiple QoS model = deployments.

 

John

 

From: ext Georgios Karagiannis [mailto:karagian@cs.utwente.nl]
Sent: 17 October, 2006 = 01:40
To: 'Lars Westberg'
Cc: gash@att.com; = nsis@ietf.org
Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

Hi = Lars

 

I think that I agree with = you!

 

However, we may just need one QSPEC parameter, say Traffic (Tocken Bucket and Bandwidth) =

that can be mandatory. In this way = we will provide the required interoperability between the =

QoS = models.

Actually this was also the = conclusion that Xiaoming deduced after studying a couple of = examples.

 

Furthermore, we could however = provide the ability to QoS models to specify which

QSPEC parameters should be = mandatory or not.

What do you = think?

 

Best = regards,

Georgios

 

 

 

From: Lars Westberg [mailto:Lars.westberg@ericsson.com]
Sent: dinsdag 17 oktober = 2006 8:46
To: Georgios = Karagiannis
Cc: gash@att.com; = nsis@ietf.org
Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

yes.
the main problem is that IETF is not the only Standardization = organization that like to discuss "bearer services". Just as an example :
If we specify the those parameters, How can we use NSIS for SLAs = specified by MEF????

How can we use it for 3GPP-Qos definitiions ?


In the draft I also see  that we the draft specify a new bearer = service. It is not compliant to old Int.serv architecture.  This is a = completely new one with new parameters like priority.

I can sure that we can have a never-ending discussion about the "optimal"-set of parameters.

I think we agree in beggining the working group discussion that we = should not specify any "bearer-service" because NSIS should be a modular architecture with  more flexibillity than RSVP.  Therefore, I = am surprised that we are doing the same mistake as in RSVP: Integrating a = bearer service definition into the NSIS-architecture.

If we go this track, the QoS-part of NSIS has much less use. RSVP is in = this case significantly better in terms of performance and have the same functionality than NSIS.
If have to choose I would select RSVP rather than a much more = complex  three layer protocol stack.

regards Lasse

Georgios Karagiannis wrote:

Hi =
Lars
 
Do you mean that the QSPEC template must not =
contain any mandatory
(QSPEC-1) =
parameters?
 
 
Best =
Regards,
Georgios
 
 
 
On 10/16/2006, "Lars Westberg" <Lars.westberg@ericsson.com=
> wrote:
 
  
Hi,
The template seems not to be a template =
because the mandatory part  =
is
more or less the same as =
Intserv.
The main idea with QoS-template was to make =
an modular solution that
could allow flexibillity for different =
Qos-models
 
Therefore, I do not understand the scope of =
the specification.
 
I suggest that we move the major part of the =
parameters to a separate
"Int.serv. over NSIS" =
specification.
Int.serv. can be seen as a common bearer =
service.
 
regards =
Lasse
 
Ash, Gerald R (Jerry), ALABS =
wrote:
 
    =

Lars,
 
      =

You mention in the below e-mail that there =
are no open issues,
while there is a huge discussion on the nsis =
mailing list
regarding the QSPEC-1 =
parameters.
        =

John can call a different consensus if he =
sees one (I've asked him a
couple of times to do that).  What I saw =
was
 
1. Many posts supported the QSPEC-1 concept, =
only one (or maybe two) I
saw opposed.  The opposing view was =
repeated *many* times (and is =
still
being repeated) but it only counts as one =
opinion.
2. Many posts supported retaining the 4 =
QSPEC-1 parameters, only one I
saw opposed.  The opposing view was =
repeated many times.
3. There was only one opinion expressed to be =
able to ignore QSPEC-1
parameters.  That one opinion has been =
repeated many times but it only
counts as one =
opinion.
 
John asked a while ago for new opinions on =
these issues, that would be
good if there are any *new* opinions.  =
We don't need to hear opinions
repeated that we've seen so many =
times.
 
I invite John once again to make a consensus =
call so we can move on
here.  I think it is time to make =
progress and stop repeating =
ourselves,
we're not generating any new light in this =
rather endless discussion.
 
Thanks,
Jerry
 
      =

 
  =
------_=_NextPart_001_01C6F1FC.AC09B1AA-- --===============0368896292== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0368896292==-- From nsis-bounces@ietf.org Tue Oct 17 11:03:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZqSm-0005NN-Th; Tue, 17 Oct 2006 11:02:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZqSl-0005Dl-1P for nsis@ietf.org; Tue, 17 Oct 2006 11:02:39 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZqSj-0001qC-Jn for nsis@ietf.org; Tue, 17 Oct 2006 11:02:39 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k9HF2KWg026050; Tue, 17 Oct 2006 17:02:24 +0200 (MEST) From: "Georgios Karagiannis" To: "'Jukka MJ Manner'" , Subject: RE: [NSIS] Proposal to move the QSPEC work forward Date: Tue, 17 Oct 2006 17:02:17 +0200 Message-ID: <00b301c6f1fd$3fbcb730$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Acbx+3R7YPr1VwsVSRSiFG8Wz8S+lAAAF27Q X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: -5.53 () ALL_TRUSTED,AWL,BAYES_00,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Tue, 17 Oct 2006 17:02:29 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jukka This is a very good proposal! I agree with it! Best regards, Georgios > -----Original Message----- > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] > Sent: dinsdag 17 oktober 2006 16:49 > To: nsis@ietf.org > 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 > > 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 > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 17 11:11:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZqag-0002Gi-0K; Tue, 17 Oct 2006 11:10:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZqae-0002GT-NV for nsis@ietf.org; Tue, 17 Oct 2006 11:10:48 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZqac-0002en-DN for nsis@ietf.org; Tue, 17 Oct 2006 11:10:48 -0400 Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Tue, 17 Oct 2006 18:10:34 +0300 id 000AFD65.4534F26A.000003FE Date: Tue, 17 Oct 2006 18:10:34 +0300 (EEST) From: Jukka MJ Manner To: nsis@ietf.org Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [NSIS] QoS NSLP v.12 going out X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, At the address below you can find the current QoS NSLP, and a diff to -11. I'll wait until Friday for any feedback, then submit the draft during the weekend. http://www.cs.helsinki.fi/u/jmanner/qos-nslp/ Jukka ps. I currently have a serious problem with nroff and the TOC. My Linux system got updated by our admins, and now with new sed/awk/groff tools, I can't get a TOC anymore. I'll try to get over it before the weekend. :( _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 17 11:12:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZqbT-0002b2-Gi; Tue, 17 Oct 2006 11:11:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZqbS-0002as-4Z for nsis@ietf.org; Tue, 17 Oct 2006 11:11:38 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZqbP-0002i7-5k for nsis@ietf.org; Tue, 17 Oct 2006 11:11:38 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k9HFAwJN026843; Tue, 17 Oct 2006 17:11:03 +0200 (MEST) From: "Georgios Karagiannis" To: , , Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Date: Tue, 17 Oct 2006 17:10:55 +0200 Message-ID: <00c001c6f1fe$74be8cf0$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <62D92A9A02BCC845B202323D49A48426230EC7@0591-ITS-EXMP02.us.saic.com> Thread-Index: Acbxt9rfPVXjqLj+T5uusDQMgUBvPwADy3pQAAwEd6AAAKI3AAAApwXgAACA/yA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: -5.229 () ALL_TRUSTED, AWL, BAYES_00, FVGT_s_OBFU_Q1, HTML_MESSAGE, J_CHICKENPOX_34 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Tue, 17 Oct 2006 17:11:07 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0516e2ddc924b4e52f6253f239963708 Cc: gash@att.com, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0324121735==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0324121735== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C1_01C6F20F.38475CF0" This is a multi-part message in MIME format. ------=_NextPart_000_00C1_01C6F20F.38475CF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Radhika I think that Jukka just suggested a very good solution to this problem! Best Regards, Georgios _____ From: RADHIKA.R.ROY@saic.com [mailto:RADHIKA.R.ROY@saic.com] Sent: dinsdag 17 oktober 2006 16:58 To: Georgios Karagiannis; john.loughney@nokia.com; Lars.westberg@ericsson.com Cc: gash@att.com; nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Georgios: I fear that it will also not solve the basic problem of incompatibility. Please see my email. It is just too much to solve as these are still subjective interpretations and too complex to implement for clear interworking. Best regards, Radhika _____ From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On Behalf Of Georgios Karagiannis Sent: Tuesday, October 17, 2006 10:51 AM To: john.loughney@nokia.com; Lars.westberg@ericsson.com Cc: gash@att.com; nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Hi John A solution of this can be as follows. First of all: the QSPEC template does not specify mandatory parameters. However, an end-to-end QoS model may mandate the use of a QSPEC parameter. Any QNE that suopports this end-to-end QoS model then it will have to interpret (strictly or remap) this parameter. The remapping is then specified in the end -to-end QOSM draft. Another local QoS model that needs to interoperate with the end-to-end QoS model it will either have to strictly interpret the parameter specified by the end -to- end QoS model, or to remap it. The remapping is also specified in the local QOSM draft. However, if a QNE does not support the end-to-end QoS model then it will just set the NON-QOSM Hop flag. In this way we achieve both modularity and interoperability. Best Regards, Georgios _____ From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: dinsdag 17 oktober 2006 16:21 To: karagian@cs.utwente.nl; Lars.westberg@ericsson.com Cc: gash@att.com; nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Georgios, About having the QoS Models specifying manditory parameters - could you explain how we would get interoperability between two different QoS models that have different sets of manditory parameters? I think we need to have a baseline QSPEC with manditory parameters to ensure interoperability - we should have the lowest common denominator between the QoS models to ensure some way of being able to signal across multiple QoS model deployments. John _____ From: ext Georgios Karagiannis [mailto:karagian@cs.utwente.nl] Sent: 17 October, 2006 01:40 To: 'Lars Westberg' Cc: gash@att.com; nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Hi Lars I think that I agree with you! However, we may just need one QSPEC parameter, say Traffic (Tocken Bucket and Bandwidth) that can be mandatory. In this way we will provide the required interoperability between the QoS models. Actually this was also the conclusion that Xiaoming deduced after studying a couple of examples. Furthermore, we could however provide the ability to QoS models to specify which QSPEC parameters should be mandatory or not. What do you think? Best regards, Georgios _____ From: Lars Westberg [mailto:Lars.westberg@ericsson.com] Sent: dinsdag 17 oktober 2006 8:46 To: Georgios Karagiannis Cc: gash@att.com; nsis@ietf.org Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt yes. the main problem is that IETF is not the only Standardization organization that like to discuss "bearer services". Just as an example : If we specify the those parameters, How can we use NSIS for SLAs specified by MEF???? How can we use it for 3GPP-Qos definitiions ? In the draft I also see that we the draft specify a new bearer service. It is not compliant to old Int.serv architecture. This is a completely new one with new parameters like priority. I can sure that we can have a never-ending discussion about the "optimal"-set of parameters. I think we agree in beggining the working group discussion that we should not specify any "bearer-service" because NSIS should be a modular architecture with more flexibillity than RSVP. Therefore, I am surprised that we are doing the same mistake as in RSVP: Integrating a bearer service definition into the NSIS-architecture. If we go this track, the QoS-part of NSIS has much less use. RSVP is in this case significantly better in terms of performance and have the same functionality than NSIS. If have to choose I would select RSVP rather than a much more complex three layer protocol stack. regards Lasse Georgios Karagiannis wrote: Hi Lars Do you mean that the QSPEC template must not contain any mandatory (QSPEC-1) parameters? Best Regards, Georgios On 10/16/2006, "Lars Westberg" wrote: Hi, The template seems not to be a template because the mandatory part is more or less the same as Intserv. The main idea with QoS-template was to make an modular solution that could allow flexibillity for different Qos-models Therefore, I do not understand the scope of the specification. I suggest that we move the major part of the parameters to a separate "Int.serv. over NSIS" specification. Int.serv. can be seen as a common bearer service. regards Lasse Ash, Gerald R (Jerry), ALABS wrote: Lars, You mention in the below e-mail that there are no open issues, while there is a huge discussion on the nsis mailing list regarding the QSPEC-1 parameters. John can call a different consensus if he sees one (I've asked him a couple of times to do that). What I saw was 1. Many posts supported the QSPEC-1 concept, only one (or maybe two) I saw opposed. The opposing view was repeated *many* times (and is still being repeated) but it only counts as one opinion. 2. Many posts supported retaining the 4 QSPEC-1 parameters, only one I saw opposed. The opposing view was repeated many times. 3. There was only one opinion expressed to be able to ignore QSPEC-1 parameters. That one opinion has been repeated many times but it only counts as one opinion. John asked a while ago for new opinions on these issues, that would be good if there are any *new* opinions. We don't need to hear opinions repeated that we've seen so many times. I invite John once again to make a consensus call so we can move on here. I think it is time to make progress and stop repeating ourselves, we're not generating any new light in this rather endless discussion. Thanks, Jerry ------=_NextPart_000_00C1_01C6F20F.38475CF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Radhika
 
I think that Jukka just suggested a very good = solution to=20 this problem!
 
Best Regards,
Georgios
 
 

From: RADHIKA.R.ROY@saic.com=20 [mailto:RADHIKA.R.ROY@saic.com]
Sent: dinsdag 17 oktober = 2006=20 16:58
To: Georgios Karagiannis; john.loughney@nokia.com;=20 Lars.westberg@ericsson.com
Cc: gash@att.com;=20 nsis@ietf.org
Subject: RE: [NSIS] I-D=20 ACTION:draft-ietf-nsis-qspec-12.txt

Georgios:

 

I fear that = it will=20 also not solve the basic problem of incompatibility. Please see my = email. It=20 is just too much to solve as these are still subjective = interpretations and=20 too complex to implement for clear = interworking.

 

Best=20 regards,

Radhika

 

From:=20 nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On Behalf Of Georgios=20 Karagiannis
Sent: = Tuesday,=20 October 17, 2006 10:51 AM
To:=20 john.loughney@nokia.com; Lars.westberg@ericsson.com
Cc: gash@att.com;=20 nsis@ietf.org
Subject: RE:=20 [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

 

Hi=20 John

 

A solution = of this=20 can be as follows.

 

First of = all: the=20 QSPEC template does not specify  mandatory=20 parameters.

 

However, an = end-to-end QoS model may mandate the use of a QSPEC parameter.=20

Any QNE = that=20 suopports this end-to-end QoS model then it will have to interpret=20

(strictly = or remap)=20 this parameter. The remapping is then specified in the end -to-end = QOSM=20 draft.

 

Another = local QoS=20 model that needs to interoperate with the end-to-end QoS model it will = either=20

have to = strictly=20 interpret the parameter specified by the end -to- end QoS model, or to = remap=20 it. 

The = remapping is also=20 specified in the local QOSM draft.

 

However, if = a QNE=20 does not support the end-to-end QoS model then it will just set the=20

NON-QOSM = Hop flag.=20

In this way = we=20 achieve both modularity and = interoperability.

 

Best=20 Regards,

Georgios

 

 

 

 

From:=20 john.loughney@nokia.com [mailto:john.loughney@nokia.com] =
Sent: dinsdag 17 oktober 2006 = 16:21
To:=20 karagian@cs.utwente.nl; Lars.westberg@ericsson.com
Cc: gash@att.com;=20 nsis@ietf.org
Subject: RE:=20 [NSIS] I-D = ACTION:draft-ietf-nsis-qspec-12.txt

Georgios,

 

About = having the=20 QoS Models specifying manditory parameters - could you explain how = we would=20 get interoperability between two different QoS models that have = different=20 sets of manditory parameters?

 

I think = we need to=20 have a baseline QSPEC with manditory parameters to ensure = interoperability -=20 we should have the lowest common denominator between the QoS models = to=20 ensure some way of being able to signal across multiple QoS model=20 deployments.

 

John

 

From: ext=20 Georgios Karagiannis [mailto:karagian@cs.utwente.nl]
Sent: 17 October, 2006=20 01:40
To: 'Lars = Westberg'
Cc:=20 gash@att.com; nsis@ietf.org
Subject: RE: [NSIS] I-D=20 ACTION:draft-ietf-nsis-qspec-12.txt

Hi=20 Lars

 

I think = that I=20 agree with you!

 

However, we may=20 just need one QSPEC parameter, say Traffic (Tocken Bucket and = Bandwidth)=20

that = can be=20 mandatory. In this way we will provide the required = interoperability=20 between the

QoS=20 models.

Actually this was=20 also the conclusion that Xiaoming deduced after studying a couple = of=20 examples.

 

Furthermore, we=20 could however provide the ability to QoS models to specify which=20

QSPEC = parameters=20 should be mandatory or not.

What do = you=20 think?

 

Best=20 regards,

Georgios

 

 

 

From:=20 Lars Westberg [mailto:Lars.westberg@ericsson.com]
Sent: dinsdag 17 oktober = 2006=20 8:46
To: = Georgios=20 Karagiannis
Cc:=20 gash@att.com; nsis@ietf.org
Subject: Re: [NSIS] I-D=20 ACTION:draft-ietf-nsis-qspec-12.txt

yes.
the main problem is that IETF = is not=20 the only Standardization organization that like to discuss = "bearer=20 services". Just as an example :
If we specify the those = parameters,=20 How can we use NSIS for SLAs specified by MEF????

How can = we use=20 it for 3GPP-Qos definitiions ?


In the draft I also = see =20 that we the draft specify a new bearer service. It is not = compliant to=20 old Int.serv architecture.  This is a completely new one = with new=20 parameters like priority.

I can sure that we can have a=20 never-ending discussion about the "optimal"-set of = parameters.

I=20 think we agree in beggining the working group discussion that we = should=20 not specify any "bearer-service" because NSIS should be a = modular=20 architecture with  more flexibillity than RSVP.  = Therefore, I=20 am surprised that we are doing the same mistake as in RSVP: = Integrating=20 a bearer service definition into the = NSIS-architecture.

If we go=20 this track, the QoS-part of NSIS has much less use. RSVP is in = this case=20 significantly better in terms of performance and have the same=20 functionality than NSIS.
If have to choose I would select = RSVP rather=20 than a much more complex  three layer protocol=20 stack.

regards Lasse

Georgios Karagiannis=20 wrote:

Hi Lars
 
Do you mean =
that the QSPEC template must not contain any =
mandatory
(QSPEC-1) =
parameters?
 
 
Best =
Regards,
Georgios
 
 
 
On =
10/16/2006, "Lars Westberg" <Lars.westberg@ericsson.com=
> wrote:
 
  =

Hi,
The template =
seems not to be a template because the mandatory part  =
is
more or less the =
same as Intserv.
The main idea with QoS-template was to make an modular solution =
that
could allow =
flexibillity for different =
Qos-models
 
Therefore, I =
do not understand the scope of the =
specification.
 
I suggest =
that we move the major part of the parameters to a =
separate
"Int.serv. over =
NSIS" specification.
Int.serv. can be seen as a common bearer =
service.
 
regards =
Lasse
 
Ash, Gerald =
R (Jerry), ALABS wrote:
 
    
Lars,
 
      
You mention in the below e-mail =
that there are no open issues,
while there is a huge discussion on the nsis mailing =
list
regarding the =
QSPEC-1 parameters.
        =

John can call a different consensus if he sees one (I've asked him =
a
couple of times =
to do that).  What I saw =
was
 
1. Many =
posts supported the QSPEC-1 concept, only one (or maybe two) =
I
saw =
opposed.  The opposing view was repeated *many* times (and is =
still
being repeated) =
but it only counts as one =
opinion.
2. Many posts =
supported retaining the 4 QSPEC-1 parameters, only one =
I
saw =
opposed.  The opposing view was repeated many =
times.
3. There was only =
one opinion expressed to be able to ignore =
QSPEC-1
parameters.  =
That one opinion has been repeated many times but it =
only
counts as one =
opinion.
 
John asked a =
while ago for new opinions on these issues, that would =
be
good if there are =
any *new* opinions.  We don't need to hear =
opinions
repeated that =
we've seen so many times.
 
I invite =
John once again to make a consensus call so we can move =
on
here.  I =
think it is time to make progress and stop repeating =
ourselves,
we're not =
generating any new light in this rather endless =
discussion.
 
Thanks,
Jerry
 
      =

 
  =
------=_NextPart_000_00C1_01C6F20F.38475CF0-- --===============0324121735== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0324121735==-- From nsis-bounces@ietf.org Tue Oct 17 11:35:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZqxq-0000d2-F8; Tue, 17 Oct 2006 11:34:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZqxp-0000ah-Nc for nsis@ietf.org; Tue, 17 Oct 2006 11:34:45 -0400 Received: from amer-mta08.csc.com ([20.137.52.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZqxm-0004xy-EF for nsis@ietf.org; Tue, 17 Oct 2006 11:34:45 -0400 Received: from amer-gw09.csc.com (amer-gw09.csc.com [20.6.39.245]) by amer-mta08.csc.com (Switch-3.1.6/Switch-3.1.0) with ESMTP id k9HFXw2f005980; Tue, 17 Oct 2006 11:33:59 -0400 (EDT) In-Reply-To: <004801c6f1cf$4b60b0b0$4c0d5982@dynamic.ewi.utwente.nl> Subject: RE: [NSIS] QSPEC-issue (GK-2) To: "Georgios Karagiannis" X-Mailer: Lotus Notes 652HF83 November 04, 2004 Message-ID: From: Janet P Gunn Date: Tue, 17 Oct 2006 11:34:31 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 6.5.3|September 14, 2004) at 10/17/2006 11:32:54 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: nsis@ietf.org, "'Kappler, Cornelia'" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Even that is problematic. I think that the mapping between "token bucket (peak rate)" and "bandwidth" can generally be accomplished. But a mapping to "Normal Priority" requires a definition of "Normal Priority". Is "Normal Priority" defined by [] [] or by [] []? There is a"Normal" value for [], but there is no "Normal" for [] [], nor for []. The most benign mapping you can make with Preemption/Defending is to set the [] to the lowest legal value (so it can't preempt anything) and the [] to the highest legal value (so nothing can preempt it). But my understanding is that the organizations that USE preemption are more likely to want to define "Normal" as [] to the lowest legal value (so it can't preempt anything) and the [] to the lowest legal value (so EVERYTHING ELSE can preempt it). But this is equivalent to mapping it to "low priority" in most senses of the word. Either way, I can see all sorts of unintended consequences for a call that crosses multiple domains (and thus go through multiple mappings) with different (or no) priority schemes What should happen in a domain which supports neither form of priority? In most other protocols, the general rule for dealing with unknown priority structures is "if you don't understand/support it, don't mess with it". In other words, "ignore it". This is true for the Precedence parameter (as well as specialized use of the CPC parameter) in SS7, and the RPH in SIP. I still don't understand why "ignore it" is forbidden for Priority in QSPEC. Don't forget that unauthorized use of "Priority" has the potential for abuse. Janet "Georgios Karagiannis" wrote on 10/17/2006 05:33:20 AM: > Hi Cornelia > > The reasonable maping can only be accomplished between: > Token Bucket (peak rate) => Bandwidth > Higher (than normal) priority => Normal priority > Lower (than normal) priority => Normal priority > > In my opinion other types of remappings (of other parameters) > are either impossible or useless! > > Best Regards, > Georgios > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 17 11:44:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZr6Q-0002A7-1Y; Tue, 17 Oct 2006 11:43:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZr6P-00029t-0u for nsis@ietf.org; Tue, 17 Oct 2006 11:43:37 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZr66-0005wZ-Nn for nsis@ietf.org; Tue, 17 Oct 2006 11:43:37 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k9HFgcFL029964; Tue, 17 Oct 2006 17:42:42 +0200 (MEST) From: "Georgios Karagiannis" To: "'Janet P Gunn'" Subject: RE: [NSIS] QSPEC-issue (GK-2) Date: Tue, 17 Oct 2006 17:42:35 +0200 Message-ID: <00ce01c6f202$e114c910$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcbyAeLDoxA/cfyrQAuAq03tFBRrfAAANo3g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: -5.329 () ALL_TRUSTED, AWL, BAYES_00, FVGT_m_MULTI_ODD, FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Tue, 17 Oct 2006 17:42:43 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: nsis@ietf.org, "'Kappler, Cornelia'" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Janet I think that I agree with your observations. Please also note that Jukka proposed a good solution to this problem! Best regards, Georgios > -----Original Message----- > From: Janet P Gunn [mailto:jgunn6@csc.com] > Sent: dinsdag 17 oktober 2006 17:35 > To: Georgios Karagiannis > Cc: nsis@ietf.org; 'Kappler, Cornelia' > Subject: RE: [NSIS] QSPEC-issue (GK-2) > > > > > > Even that is problematic. > > I think that the mapping between "token bucket (peak rate)" > and "bandwidth" > can generally be accomplished. > > But a mapping to "Normal Priority" requires a definition of > "Normal Priority". > > Is "Normal Priority" defined by > [] [] or by > [] []? > > There is a"Normal" value for [], but > there is no "Normal" for [] [ Priority>], nor for [ Priority>]. > > The most benign mapping you can make with > Preemption/Defending is to set the [] to > the lowest legal value (so it can't preempt > anything) and the [] to the highest legal > value (so nothing can preempt it). > > But my understanding is that the organizations that USE > preemption are more likely to want to define "Normal" as > [] to the lowest legal value (so it > can't preempt anything) and the [] to the > lowest legal value (so EVERYTHING ELSE can preempt it). But > this is equivalent to mapping it to "low priority" in most > senses of the word. > > Either way, I can see all sorts of unintended consequences > for a call that crosses multiple domains (and thus go through > multiple mappings) with different (or no) priority schemes > > What should happen in a domain which supports neither form of > priority? > > In most other protocols, the general rule for dealing with > unknown priority structures is "if you don't > understand/support it, don't mess with it". In other words, > "ignore it". > > This is true for the Precedence parameter (as well as > specialized use of the CPC parameter) in SS7, and the RPH in SIP. > > I still don't understand why "ignore it" is forbidden for > Priority in QSPEC. > > Don't forget that unauthorized use of "Priority" has the > potential for abuse. > > Janet > > "Georgios Karagiannis" wrote on > 10/17/2006 05:33:20 AM: > > > Hi Cornelia > > > > The reasonable maping can only be accomplished between: > > Token Bucket (peak rate) => Bandwidth > > Higher (than normal) priority => Normal priority Lower > (than normal) > > priority => Normal priority > > > > In my opinion other types of remappings (of other parameters) are > > either impossible or useless! > > > > Best Regards, > > Georgios > > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 17 12:39:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZrxd-0000SW-WB; Tue, 17 Oct 2006 12:38:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZrxc-0000SQ-Gu for nsis@ietf.org; Tue, 17 Oct 2006 12:38:36 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZrxY-0004uP-04 for nsis@ietf.org; Tue, 17 Oct 2006 12:38:36 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9HGcQgL001697; Tue, 17 Oct 2006 19:38:28 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 19:38:27 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 19:38:26 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] messages content Date: Tue, 17 Oct 2006 19:38:25 +0300 Message-ID: In-Reply-To: <4534EDCF.40101@christian-dickmann.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] messages content Thread-Index: Acbx/BgKw1L7fyCjSU6a/+uBHGe8NQADk/CQ From: To: , X-OriginalArrivalTime: 17 Oct 2006 16:38:26.0515 (UTC) FILETIME=[AB5BC230:01C6F20A] X-Spam-Score: 0.2 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Thanks for the note Christian. Running code is a very important things to consider here. I think that this seems like very good information. As this is more of a discussion=20 (if needed) to carry on the NSIS Implementor's list, if people want to get discuss support in Wireshark or packet logs. thanks, John >-----Original Message----- >From: ext Christian Dickmann [mailto:mail@christian-dickmann.de]=20 >Sent: 17 October, 2006 07:51 >To: Lars Westberg (KI/EAB) >Cc: nsis@ietf.org >Subject: Re: [NSIS] messages content > >Hi, > >I am the main developer of the GIST implementation of the=20 >University of Goettingen. >To me, the draft explains how messages look like pretty well=20 >and I have no clue how the draft could be more precise (from=20 >the structure point of view). > >> I can't all questions on the list. I would rather appreciate an=20 >> example implementation of it with message shown in text-format. Does=20 >> the implementation showing the messages in text ?? >> >> If so, I am interested in it. Is it possible to get a copy ??? >> =20 > >We implemented an dissector, which is able to display GIST=20 >(and QoS, NATFW, etc.) messages in the popular network=20 >protocol analyzer Ethereal (now known as Wireshark). >In addition, we got several captures of NSIS sessions (some of=20 >them captured at the recent Interop event) that we can provide. >So with this, you can look at every message, look at every=20 >detail you want and see how GIST works in real life. > >Please have a look at >http://user.informatik.uni-goettingen.de/~nsis/ethereal.html > >Christian Dickmann > > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 17 12:41:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZs0D-0001MC-MF; Tue, 17 Oct 2006 12:41:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZs0B-0001M6-QB for nsis@ietf.org; Tue, 17 Oct 2006 12:41:15 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZs0A-00059V-BK for nsis@ietf.org; Tue, 17 Oct 2006 12:41:15 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9HGemhr005752; Tue, 17 Oct 2006 19:40:48 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 19:40:48 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 19:40:48 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] QSPEC-issue (GK-2) Date: Tue, 17 Oct 2006 19:40:47 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QSPEC-issue (GK-2) Thread-Index: AcbyAhfWQyoDYhPnQGyKl7YX9pky0QACLMgA From: To: , X-OriginalArrivalTime: 17 Oct 2006 16:40:48.0327 (UTC) FILETIME=[FFE28D70:01C6F20A] X-Spam-Score: 0.2 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: nsis@ietf.org, cornelia.kappler@siemens.com X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Janet, >Even that is problematic. > >I think that the mapping between "token bucket (peak rate)" and "bandwidth" >can generally be accomplished. I agree, so I think we could carry this forward. > >But a mapping to "Normal Priority" requires a definition of=20 >"Normal Priority". > >Is "Normal Priority" defined by >[] [] or by=20 >[] []? > >There is a"Normal" value for [], but there=20 >is no "Normal" for [] [Priority>], nor for [Priority>]. > >The most benign mapping you can make with Preemption/Defending=20 >is to set the [] to the lowest legal=20 >value (so it can't preempt >anything) and the [] to the highest legal=20 >value (so nothing can preempt it). > >But my understanding is that the organizations that USE=20 >preemption are more likely to want to define "Normal" as=20 >[] to the lowest legal value (so it can't=20 >preempt anything) and the [] to the lowest=20 >legal value (so EVERYTHING ELSE can preempt it). But this is=20 >equivalent to mapping it to "low priority" in most senses of the word. > >Either way, I can see all sorts of unintended consequences for=20 >a call that crosses multiple domains (and thus go through=20 >multiple mappings) with different (or no) priority schemes > >What should happen in a domain which supports neither form of priority? > >In most other protocols, the general rule for dealing with=20 >unknown priority structures is "if you don't=20 >understand/support it, don't mess with it". In other words,=20 >"ignore it". > >This is true for the Precedence parameter (as well as=20 >specialized use of the CPC parameter) in SS7, and the RPH in SIP. > >I still don't understand why "ignore it" is forbidden for=20 >Priority in QSPEC. > >Don't forget that unauthorized use of "Priority" has the=20 >potential for abuse. So, for the priority bit, should we have a general rule to silently pass if not understood? How do people feel about this? John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 17 13:23:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZseQ-0007a7-6I; Tue, 17 Oct 2006 13:22:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZseO-0007Wo-GI for nsis@ietf.org; Tue, 17 Oct 2006 13:22:48 -0400 Received: from sbcsmtp3.sbc.com ([144.160.112.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZseL-0002ta-65 for nsis@ietf.org; Tue, 17 Oct 2006 13:22:48 -0400 Received: from enaf.dadc.sbc.com (localhost.localdomain [127.0.0.1]) by sbcsmtp3.sbc.com (8.13.7/8.13.7) with ESMTP id k9HHMiMR020158; Tue, 17 Oct 2006 12:22:44 -0500 Received: from flph023.ffdc.sbc.com (flph023.ffdc.sbc.com [150.234.117.36]) by tlph033.enaf.dadc.sbc.com (8.13.7/8.13.7) with ESMTP id k9HHMfVX020143; Tue, 17 Oct 2006 12:22:42 -0500 Received: from ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flph023.ffdc.sbc.com (8.13.7/8.13.7) with ESMTP id k9HHMflZ031086; Tue, 17 Oct 2006 10:22:41 -0700 Received: from kcclust06evs1.ugd.att.com (kcst11.ugd.att.com [135.38.164.88]) by flph023.ffdc.sbc.com (8.13.7/8.13.7) with ESMTP id k9HHMQUd030911; Tue, 17 Oct 2006 10:22:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] QSPEC-issue (GK-2) Date: Tue, 17 Oct 2006 12:22:28 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7E5A@KCCLUST06EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QSPEC-issue (GK-2) Thread-Index: AcbyAhfWQyoDYhPnQGyKl7YX9pky0QACLMgAAAC6mPA= From: "Ash, Gerald R \(Jerry\), ALABS" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: "Ash, Gerald R \(Jerry\), ALABS" , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org > >But my understanding is that the organizations that USE=20 > >preemption are more likely to want to define "Normal" as=20 > >[] to the lowest legal value (so it can't=20 > >preempt anything) and the [] to the lowest=20 > >legal value (so EVERYTHING ELSE can preempt it). But this is=20 > >equivalent to mapping it to "low priority" in most senses of=20 > the word. > > > >Either way, I can see all sorts of unintended consequences for=20 > >a call that crosses multiple domains (and thus go through=20 > >multiple mappings) with different (or no) priority schemes > > > >What should happen in a domain which supports neither form=20 > >of priority? > > > >In most other protocols, the general rule for dealing with=20 > >unknown priority structures is "if you don't=20 > >understand/support it, don't mess with it". In other words,=20 > >"ignore it". If a QNI populates priority (either preemption, admission, RPH, etc.) for its QOSM then the QNI/QOSM requirement for the reservation is that QNEs will implement priority as populated (i.e., 'strictly interpret' the parameter as defined in the QSPEC draft). All sorts of meaningless 'remappings' from one priority space to another is *not* the norm or the intent, and are not allowed. A meaningful remapping of a priority parameter can be defined by a QOSM specification=20 > >I still don't understand why "ignore it" is forbidden for=20 > >Priority in QSPEC. > So, for the priority bit, should we have a general rule to silently > pass if not understood? How do people feel about this? This would be equivalent to making priority a qspec-2 parameter. Since preemption and other priority parameters are specified by referenced RFCs and standards documents (and supported in most cases already by implementations), I don't see the problem with strictly interpreting priority as the default, i.e., leaving it as a qspec-1 parameter. Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 17 15:29:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZucd-00041a-FH; Tue, 17 Oct 2006 15:29:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZucb-0003zl-TO for nsis@ietf.org; Tue, 17 Oct 2006 15:29:05 -0400 Received: from amer-mta08.csc.com ([20.137.52.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZucY-0001DR-J3 for nsis@ietf.org; Tue, 17 Oct 2006 15:29:05 -0400 Received: from amer-gw09.csc.com (amer-gw09.csc.com [20.6.39.245]) by amer-mta08.csc.com (Switch-3.1.6/Switch-3.1.0) with ESMTP id k9HJT086003205 for ; Tue, 17 Oct 2006 15:29:00 -0400 (EDT) In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC7E5A@KCCLUST06EVS1.ugd.att.com> Subject: RE: [NSIS] QSPEC-issue (GK-2) To: "Ash, Gerald R \(Jerry\), ALABS" X-Mailer: Lotus Notes 652HF83 November 04, 2004 Message-ID: From: Janet P Gunn Date: Tue, 17 Oct 2006 15:29:32 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 6.5.3|September 14, 2004) at 10/17/2006 03:27:55 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: john.loughney@nokia.com, "Ash, Gerald R \(Jerry\), ALABS" , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org I am clearly missing something, because I still don't get it. "Ash, Gerald R \(Jerry\), ALABS" wrote on 10/17/2006 01:22:28 PM: > > > > If a QNI populates priority (either preemption, admission, RPH, etc.) > for its QOSM then the QNI/QOSM requirement for the reservation is that > QNEs will implement priority as populated (i.e., 'strictly interpret' > the parameter as defined in the QSPEC draft). All sorts of meaningless > 'remappings' from one priority space to another is *not* the norm or the > intent, and are not allowed. A meaningful remapping of a priority > parameter can be defined by a QOSM specification > Suppose a call originates in a US DoD network that supports preemption, then crosses networks which do not support preemption, before terminating in a British MoD network that also supports preemption. (Hypothetically) The call path takes it from the US DoD network to a US based Telephony Service Provider (e.g., the IP core of an FCC regulated "carrier") to a UK based Telephony Service Provider (e.g., the IP core of a UK government regulated "carrier") to a UK MoD network which supports preemption Suppose the US DoD network supports preemption using RFCs 4411, 4412, and 4542. Then the QNI and "its" QOSM implement priority "as populated" (aka "strictly interpret"), using RPH with the dsn namespace. Suppose the US based Telephony provider supports Admission Priority (as in draft-lefaucheur-emergency-rsvp)and supports RFC 4412 (using RPH with the ets namespace for authorized users) but does not support 4411, 4542, or the dsn namespace in RPH? Suppose the UK based Telephony provider supports neither 4411, 4412, 4542, nor draft-lefaucheur-emergency-rsvp. Suppose the UK MoD network also supports 4411, 4412, and 4542 (but it supports preemption using the Q735 namespace, not the dsn namespace). What is the meaningful mapping at each NNI? I am NOT trying to be difficult, I am trying to understand. > > This would be equivalent to making priority a qspec-2 parameter. Since > preemption and other priority parameters are specified by referenced > RFCs and standards documents (and supported in most cases already by > implementations), I don't see the problem with strictly interpreting > priority as the default, i.e., leaving it as a qspec-1 parameter. > I am not sure that I agree that RFCs 4411, 4412 and 4542 are already implemented and commonly deployed. > Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 17 16:43:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZvlT-0002W3-PD; Tue, 17 Oct 2006 16:42:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZvlS-0002Vh-V1 for nsis@ietf.org; Tue, 17 Oct 2006 16:42:18 -0400 Received: from mail-red.research.att.com ([192.20.225.110]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZvlQ-000702-KL for nsis@ietf.org; Tue, 17 Oct 2006 16:42:18 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Date: Tue, 17 Oct 2006 16:42:00 -0400 Message-ID: In-Reply-To: <62D92A9A02BCC845B202323D49A48426230EC6@0591-ITS-EXMP02.us.saic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt thread-index: AcbxuHtQ92fBk4GyRnaw38rAcCkjiQAOXHnQAAEtkJAADLQI4A== From: To: X-Spam-Score: 0.2 (/) X-Scan-Signature: a4cdc653ecdd96665f2aa1c1af034c9e Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1466661517==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============1466661517== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F22C.B21B1E47" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F22C.B21B1E47 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Radhika =20 I have not been in the middle of this much, but I do want to make a point to you that may be helpful in deflecting your "anti Y.1541" theme in NSIS. =20 Your big complaint seems to be about trying to satisfy the *numerical* objectives of Y.1541. As I see it, the point for NSIS has never been to focus on those numerical objectives, but rather that the global community supports Y.1541 classes as a way to describe (and signal!!!) e2e IP QoS. =20 The idea is to enable an implementation capable of addressing the *parameters* in Y.1541 (which come from Y.1540) and the fact that Y.1541 classes involve a specific combination of parameters-whatever their numerical values. Thus NSIS should have a way of addressing the global agreement to describe IP QoS in terms of Y.1541 classes (and thus the combination of parameters) whether in practice any of the numerical values of a given class are satisfied, or not. =20 In other words, whether or not a specific class is numerically satisfied is not an issue for NSIS, but rather NSIS methods should allow one to address the need to signal any Y.1541 classes requested. =20 Regards =20 Chuck Dvorak AT&T Labs =20 ------_=_NextPart_001_01C6F22C.B21B1E47 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Radhika

 

I have not been in the middle of this much, but I do = want to make a point to you that may be helpful in deflecting your “anti Y.1541” theme in NSIS.

 

Your big complaint seems to be about trying to satisfy = the *numerical* objectives of Y.1541. As I see it, the point for NSIS has never been to = focus on those numerical objectives, but rather that the global community = supports Y.1541 classes as a way to describe (and signal!!!) e2e IP = QoS.

 

The idea is to enable an implementation capable of = addressing the *parameters* in Y.1541 (which come from Y.1540) and the fact that = Y.1541 classes involve a specific combination of parameters—whatever = their numerical values. Thus NSIS should have a way of addressing the global agreement = to describe IP QoS in terms of Y.1541 classes (and thus the combination of parameters) whether in practice any of the numerical values of a given = class are satisfied, or not.

      =

In other words, whether or not a specific class is = numerically satisfied is not an issue for NSIS, but rather NSIS methods should allow = one to address the need to signal any Y.1541 classes = requested.

 

Regards

 

Chuck Dvorak

AT&T Labs

 

------_=_NextPart_001_01C6F22C.B21B1E47-- --===============1466661517== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============1466661517==-- From nsis-bounces@ietf.org Tue Oct 17 20:31:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZzKa-0008Rw-US; Tue, 17 Oct 2006 20:30:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZzKa-0008Rr-8y for nsis@ietf.org; Tue, 17 Oct 2006 20:30:48 -0400 Received: from sbcsmtp3.sbc.com ([144.160.112.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZzKX-00052o-Ug for nsis@ietf.org; Tue, 17 Oct 2006 20:30:48 -0400 Received: from enaf.dadc.sbc.com (localhost.localdomain [127.0.0.1]) by sbcsmtp3.sbc.com (8.13.7/8.13.7) with ESMTP id k9I0UhHM017979 for ; Tue, 17 Oct 2006 19:30:43 -0500 Received: from flph023.ffdc.sbc.com (flph023.ffdc.sbc.com [150.234.117.36]) by tlph033.enaf.dadc.sbc.com (8.13.7/8.13.7) with ESMTP id k9I0UeM3017963 for ; Tue, 17 Oct 2006 19:30:40 -0500 Received: from ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flph023.ffdc.sbc.com (8.13.7/8.13.7) with ESMTP id k9I0UeRY001436; Tue, 17 Oct 2006 17:30:40 -0700 Received: from kcclust06evs1.ugd.att.com (kcst11.ugd.att.com [135.38.164.88]) by flph023.ffdc.sbc.com (8.13.7/8.13.7) with ESMTP id k9I0UZLm001377; Tue, 17 Oct 2006 17:30:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] QSPEC-issue (GK-2) Date: Tue, 17 Oct 2006 19:30:34 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7E69@KCCLUST06EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QSPEC-issue (GK-2) Thread-Index: AcbyIvcV39J4iVdoRlKsuDk5Ozc/JQAJMywA From: "Ash, Gerald R \(Jerry\), ALABS" To: "Janet P Gunn" X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: "Ash, Gerald R \(Jerry\), ALABS" , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Janet, > Suppose a call originates in a US DoD network that supports=20 > preemption, > then crosses networks which do not support preemption, before=20 > terminating > in a British MoD network that also supports preemption. >=20 > (Hypothetically) The call path takes it > from the US DoD network > to a US based Telephony Service Provider (e.g., the IP core of an FCC > regulated "carrier") > to a UK based Telephony Service Provider (e.g., the IP core of a UK > government regulated "carrier") > to a UK MoD network which supports preemption >=20 > Suppose the US DoD network supports preemption using RFCs=20 > 4411, 4412, and > 4542. Then the QNI and "its" QOSM implement priority "as=20 > populated" (aka > "strictly interpret"), using RPH with the dsn namespace. >=20 > Suppose the US based Telephony provider supports Admission=20 > Priority (as in > draft-lefaucheur-emergency-rsvp)and supports RFC 4412 (using=20 > RPH with the > ets namespace for authorized users) but does not support=20 > 4411, 4542, or the > dsn namespace in RPH? >=20 > Suppose the UK based Telephony provider supports neither=20 > 4411, 4412, 4542, > nor draft-lefaucheur-emergency-rsvp. >=20 > Suppose the UK MoD network also supports 4411, 4412, and 4542 (but it > supports preemption using the Q735 namespace, not the dsn namespace). >=20 > What is the meaningful mapping at each NNI? > > I am NOT trying to be difficult, I am trying to understand. The premise of your example is that QNEs don't abide by the requirements set down in the QSPEC draft. That is, you seem to assume that certain qspec-1 parameters are not 'supported'. Since the QNI populates preemption priority (and RPH) parameters, the QSPEC draft requires that all downstream QNEs must either a) strictly interpret the parameters according to the reference RFCs/standards, or b) remap the parameters as specified by the QNE's QOSM specification. =20 There is *no* assumption that (b) can be done for any arbitrary remappings between any set of qspec-1 parameters. It has been often stated in this lengthy discussion that it is difficult/impossible to remap from qspec-1 parameter apple1 to qspec-1 parameter orange2 and therefore 'qspec-1 rules don't work'. In your example the QNEs do not follow the rules. You are right that it is not obvious that preemption priority logically maps to admission priority nor is there any implication in the qspec rules that this should be possible. They have different functions as stated in the reference RFCs/standards. The default assumption is that qspec-1 parameters will be strictly interpreted or that a logical/meaningful remapping is defined in the QOSM specification. Thanks, Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 18 01:35:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga44P-0006NX-Jo; Wed, 18 Oct 2006 01:34:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga44L-0006N1-Ip for nsis@ietf.org; Wed, 18 Oct 2006 01:34:21 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ga44H-0003iQ-1Z for nsis@ietf.org; Wed, 18 Oct 2006 01:34:21 -0400 Received: from zeus.cs.utwente.nl (zeus.ewi.utwente.nl [130.89.10.12]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k9I5YAj9006854; Wed, 18 Oct 2006 07:34:10 +0200 (MEST) Received: from janus.ewi.utwente.nl (janus [130.89.10.26]) by zeus.cs.utwente.nl (8.12.10/8.12.10) with ESMTP id k9I5YAL0021390; Wed, 18 Oct 2006 07:34:10 +0200 (MEST) Received: (from nobody@localhost) by janus.ewi.utwente.nl (8.11.7p1+Sun/8.10.2) id k9I5Y5E22205; Wed, 18 Oct 2006 07:34:05 +0200 (MEST) Date: Wed, 18 Oct 2006 07:34:05 +0200 (MEST) X-Authentication-Warning: janus.ewi.utwente.nl: nobody set sender to karagian@cs.utwente.nl using -f To: john.loughney@nokia.com Subject: Re: [NSIS] Proposal to move the QSPEC work forward Received: from 84.82.109.231 (auth. user karagian@imap2.cs.utwente.nl) by webmail.cs.utwente.nl with HTTP; Wed, 18 Oct 2006 05:34:04 +0000 X-IlohaMail-Blah: karagian@ewi.utwente.nl X-IlohaMail-Method: mail() [mem] X-IlohaMail-Dummy: moo X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -5.513 () ALL_TRUSTED,AWL,BAYES_00,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Wed, 18 Oct 2006 07:34:11 +0200 (MEST) X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Jukka MJ Manner , "nsis@ietf.org" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi John Do you agree with the proposal of Jukka? Please see below! Best Regards, Georgios On 10/17/2006, "Jukka MJ Manner" 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 >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 18 02:07:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga4ZE-0003pV-Pg; Wed, 18 Oct 2006 02:06:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga4ZD-0003pG-6a for nsis@ietf.org; Wed, 18 Oct 2006 02:06:15 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ga4Z3-0002Kz-EM for nsis@ietf.org; Wed, 18 Oct 2006 02:06:15 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5DC5C19B; Wed, 18 Oct 2006 08:05:48 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Oct 2006 08:05:48 +0200 Received: from ericsson.com ([147.214.26.58]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Oct 2006 08:05:47 +0200 Message-ID: <4535C43B.8050606@ericsson.com> Date: Wed, 18 Oct 2006 08:05:47 +0200 From: Lars Westberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt References: <00c001c6f1fe$74be8cf0$4c0d5982@dynamic.ewi.utwente.nl> In-Reply-To: <00c001c6f1fe$74be8cf0$4c0d5982@dynamic.ewi.utwente.nl> X-OriginalArrivalTime: 18 Oct 2006 06:05:47.0836 (UTC) FILETIME=[74A2BFC0:01C6F27B] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 407b2b2f241d630837da70082e911e77 Cc: gash@att.com, Georgios Karagiannis , RADHIKA.R.ROY@saic.com, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1783068149==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============1783068149== Content-Type: multipart/alternative; boundary="------------050208010607010000060603" This is a multi-part message in MIME format. --------------050208010607010000060603 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit let's try to breifly discuss the interoperabillity problem. history: From the history we have seen a lot of different QoS-models. Most of them has no commercial value today and the typical problem is that they have over-engineered the solution. The best outcome of the engineering has been weel educated PHD-students that have made a lof of interesting thesis. In general, the interoperabillity is very simple: Overprovisioning, in the same way Internet is provisioned today. Whatever QoS-requirement you have, enough spare capacity solves the problem. The only question is related to the requirement for utilization. In the backbones with low-cost per bit, Overprovisioning of the backbones seems today be the most commercially effective way to solve it. However, static provisioning or PCN is yet another way to solve the bandwidth managent in the backbone if a more bandwidth efficient solution is required. Therefore, the main need for signalled Qos is mainly in the access, not in the backbone. If someone need to signal QoS in the access one can easily solve it by peak-allocation. Not bandwidth efficient but it solves the interoperabillity. The same discussion as for ATM. A CBR can encapsulate a VBR-RT. Inter-operabillity solved by: 1) Overprovisioning in the core such as all QoS-requirments are solved. 2) Interoperabillity for different QoS-models =>Peak-allocation of bandwidth. The major problem is that Qspec-1 doesn't make the solution future proof considering different access types and scenarios. Just as an example the current specification does not cover the QoS-requirements for UDP-lite. UDP-lite was develop for partial checksum coverage for wireless access. The two part of the payload requires different QoS-treatments: one QoS that covered by the checksum and one for the part that can accept bit-errors. My suggestion is that the Template is changed so it's only contain optional parameters description. regards Lasse Georgios Karagiannis wrote: > Hi Radhika > > I think that Jukka just suggested a very good solution to this problem! > > Best Regards, > Georgios > > > > ------------------------------------------------------------------------ > From: RADHIKA.R.ROY@saic.com [mailto:RADHIKA.R.ROY@saic.com] > Sent: dinsdag 17 oktober 2006 16:58 > To: Georgios Karagiannis; john.loughney@nokia.com; > Lars.westberg@ericsson.com > Cc: gash@att.com; nsis@ietf.org > Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt > > Georgios: > > > > I fear that it will also not solve the basic problem of > incompatibility. Please see my email. It is just too much to solve > as these are still subjective interpretations and too complex to > implement for clear interworking. > > > > Best regards, > > Radhika > > > > ------------------------------------------------------------------------ > > From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On > Behalf Of Georgios Karagiannis > Sent: Tuesday, October 17, 2006 10:51 AM > To: john.loughney@nokia.com; Lars.westberg@ericsson.com > Cc: gash@att.com; nsis@ietf.org > Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt > > > > Hi John > > > > A solution of this can be as follows. > > > > First of all: the QSPEC template does not specify mandatory > parameters. > > > > However, an end-to-end QoS model may mandate the use of a QSPEC > parameter. > > Any QNE that suopports this end-to-end QoS model then it will have > to interpret > > (strictly or remap) this parameter. The remapping is then > specified in the end -to-end QOSM draft. > > > > Another local QoS model that needs to interoperate with the > end-to-end QoS model it will either > > have to strictly interpret the parameter specified by the end -to- > end QoS model, or to remap it. > > The remapping is also specified in the local QOSM draft. > > > > However, if a QNE does not support the end-to-end QoS model then > it will just set the > > NON-QOSM Hop flag. > > In this way we achieve both modularity and interoperability. > > > > Best Regards, > > Georgios > > > > > > > > > > ------------------------------------------------------------------------ > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: dinsdag 17 oktober 2006 16:21 > To: karagian@cs.utwente.nl; Lars.westberg@ericsson.com > Cc: gash@att.com; nsis@ietf.org > Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt > > Georgios, > > > > About having the QoS Models specifying manditory parameters - > could you explain how we would get interoperability between > two different QoS models that have different sets of manditory > parameters? > > > > I think we need to have a baseline QSPEC with manditory > parameters to ensure interoperability - we should have the > lowest common denominator between the QoS models to ensure > some way of being able to signal across multiple QoS model > deployments. > > > > John > > > > ------------------------------------------------------------------------ > > From: ext Georgios Karagiannis > [mailto:karagian@cs.utwente.nl] > Sent: 17 October, 2006 01:40 > To: 'Lars Westberg' > Cc: gash@att.com; nsis@ietf.org > Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt > > Hi Lars > > > > I think that I agree with you! > > > > However, we may just need one QSPEC parameter, say Traffic > (Tocken Bucket and Bandwidth) > > that can be mandatory. In this way we will provide the > required interoperability between the > > QoS models. > > Actually this was also the conclusion that Xiaoming > deduced after studying a couple of examples. > > > > Furthermore, we could however provide the ability to QoS > models to specify which > > QSPEC parameters should be mandatory or not. > > What do you think? > > > > Best regards, > > Georgios > > > > > > > > ------------------------------------------------------------------------ > > From: Lars Westberg [mailto:Lars.westberg@ericsson.com] > Sent: dinsdag 17 oktober 2006 8:46 > To: Georgios Karagiannis > Cc: gash@att.com; nsis@ietf.org > Subject: Re: [NSIS] I-D > ACTION:draft-ietf-nsis-qspec-12.txt > > yes. > the main problem is that IETF is not the only > Standardization organization that like to discuss > "bearer services". Just as an example : > If we specify the those parameters, How can we use > NSIS for SLAs specified by MEF???? > > How can we use it for 3GPP-Qos definitiions ? > > > In the draft I also see that we the draft specify a > new bearer service. It is not compliant to old > Int.serv architecture. This is a completely new one > with new parameters like priority. > > I can sure that we can have a never-ending discussion > about the "optimal"-set of parameters. > > I think we agree in beggining the working group > discussion that we should not specify any > "bearer-service" because NSIS should be a modular > architecture with more flexibillity than RSVP. > Therefore, I am surprised that we are doing the same > mistake as in RSVP: Integrating a bearer service > definition into the NSIS-architecture. > > If we go this track, the QoS-part of NSIS has much > less use. RSVP is in this case significantly better in > terms of performance and have the same functionality > than NSIS. > If have to choose I would select RSVP rather than a > much more complex three layer protocol stack. > > regards Lasse > > Georgios Karagiannis wrote: > >Hi Lars > > > >Do you mean that the QSPEC template must not contain any mandatory > >(QSPEC-1) parameters? > > > > > >Best Regards, > >Georgios > > > > > > > >On 10/16/2006, "Lars Westberg" wrote: > > > > > >>Hi, >> >>The template seems not to be a template because the mandatory part is >> >>more or less the same as Intserv. >> >>The main idea with QoS-template was to make an modular solution that >> >>could allow flexibillity for different Qos-models >> >> >> >>Therefore, I do not understand the scope of the specification. >> >> >> >>I suggest that we move the major part of the parameters to a separate >> >>"Int.serv. over NSIS" specification. >> >>Int.serv. can be seen as a common bearer service. >> >> >> >>regards Lasse >> >> >> >>Ash, Gerald R (Jerry), ALABS wrote: >> >> >> >> >> >>>Lars, >>> >>> >>> >>> >>> >>>>You mention in the below e-mail that there are no open issues, >>>> >>>>while there is a huge discussion on the nsis mailing list >>>> >>>>regarding the QSPEC-1 parameters. >>>> >>>> >>>> >>>John can call a different consensus if he sees one (I've asked him a >>> >>>couple of times to do that). What I saw was >>> >>> >>> >>>1. Many posts supported the QSPEC-1 concept, only one (or maybe two) I >>> >>>saw opposed. The opposing view was repeated *many* times (and is still >>> >>>being repeated) but it only counts as one opinion. >>> >>>2. Many posts supported retaining the 4 QSPEC-1 parameters, only one I >>> >>>saw opposed. The opposing view was repeated many times. >>> >>>3. There was only one opinion expressed to be able to ignore QSPEC-1 >>> >>>parameters. That one opinion has been repeated many times but it only >>> >>>counts as one opinion. >>> >>> >>> >>>John asked a while ago for new opinions on these issues, that would be >>> >>>good if there are any *new* opinions. We don't need to hear opinions >>> >>>repeated that we've seen so many times. >>> >>> >>> >>>I invite John once again to make a consensus call so we can move on >>> >>>here. I think it is time to make progress and stop repeating ourselves, >>> >>>we're not generating any new light in this rather endless discussion. >>> >>> >>> >>>Thanks, >>> >>>Jerry >>> >>> >>> >>> >>> > > > > --------------050208010607010000060603 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit let's try to breifly discuss the interoperabillity problem.
history:
>From the history we have seen a lot of different QoS-models. Most of them has no commercial value today and the typical problem is that they have over-engineered the solution. The best outcome of the engineering has been weel educated PHD-students that have made a lof of interesting thesis.

In general, the interoperabillity is very simple:
Overprovisioning, in the same way Internet is provisioned today. Whatever QoS-requirement you have, enough spare capacity solves the problem. The only question is related to the requirement for utilization.
In the backbones with low-cost per bit, Overprovisioning of the backbones seems today be the most commercially effective way to solve it. 
However, static provisioning or PCN is yet another way to solve the bandwidth managent in the backbone if a more bandwidth efficient solution is required.

Therefore, the main need for signalled Qos is mainly in the access, not in the backbone. If someone need to signal QoS in the access one can easily solve it by peak-allocation. Not bandwidth efficient but it solves the interoperabillity. The same discussion as for ATM. A CBR can encapsulate a VBR-RT.

Inter-operabillity solved by:
1) Overprovisioning in the core such as all QoS-requirments are solved.
2) Interoperabillity for different QoS-models =>Peak-allocation of bandwidth.

The major problem is that Qspec-1 doesn't make the solution future proof considering different access types and scenarios.

Just as an example the current specification does not cover the QoS-requirements for UDP-lite. UDP-lite was develop for partial checksum coverage for wireless access. The two part of the payload requires different QoS-treatments: one QoS that covered by the checksum and one for the part that can accept bit-errors.

My suggestion is that the Template is changed so it's only contain optional parameters description.

regards Lasse




Georgios Karagiannis wrote:
Hi Radhika
 
I think that Jukka just suggested a very good solution to this problem!
 
Best Regards,
Georgios
 
 

From: RADHIKA.R.ROY@saic.com [mailto:RADHIKA.R.ROY@saic.com]
Sent: dinsdag 17 oktober 2006 16:58
To: Georgios Karagiannis; john.loughney@nokia.com; Lars.westberg@ericsson.com
Cc: gash@att.com; nsis@ietf.org
Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

Georgios:

 

I fear that it will also not solve the basic problem of incompatibility. Please see my email. It is just too much to solve as these are still subjective interpretations and too complex to implement for clear interworking.

 

Best regards,

Radhika

 

From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On Behalf Of Georgios Karagiannis
Sent: Tuesday, October 17, 2006 10:51 AM
To: john.loughney@nokia.com; Lars.westberg@ericsson.com
Cc: gash@att.com; nsis@ietf.org
Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

 

Hi John

 

A solution of this can be as follows.

 

First of all: the QSPEC template does not specify  mandatory parameters.

 

However, an end-to-end QoS model may mandate the use of a QSPEC parameter.

Any QNE that suopports this end-to-end QoS model then it will have to interpret

(strictly or remap) this parameter. The remapping is then specified in the end -to-end QOSM draft.

 

Another local QoS model that needs to interoperate with the end-to-end QoS model it will either

have to strictly interpret the parameter specified by the end -to- end QoS model, or to remap it. 

The remapping is also specified in the local QOSM draft.

 

However, if a QNE does not support the end-to-end QoS model then it will just set the

NON-QOSM Hop flag.

In this way we achieve both modularity and interoperability.

 

Best Regards,

Georgios

 

 

 

 

From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
Sent: dinsdag 17 oktober 2006 16:21
To: karagian@cs.utwente.nl; Lars.westberg@ericsson.com
Cc: gash@att.com; nsis@ietf.org
Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

Georgios,

 

About having the QoS Models specifying manditory parameters - could you explain how we would get interoperability between two different QoS models that have different sets of manditory parameters?

 

I think we need to have a baseline QSPEC with manditory parameters to ensure interoperability - we should have the lowest common denominator between the QoS models to ensure some way of being able to signal across multiple QoS model deployments.

 

John

 

From: ext Georgios Karagiannis [mailto:karagian@cs.utwente.nl]
Sent: 17 October, 2006 01:40
To: 'Lars Westberg'
Cc: gash@att.com; nsis@ietf.org
Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

Hi Lars

 

I think that I agree with you!

 

However, we may just need one QSPEC parameter, say Traffic (Tocken Bucket and Bandwidth)

that can be mandatory. In this way we will provide the required interoperability between the

QoS models.

Actually this was also the conclusion that Xiaoming deduced after studying a couple of examples.

 

Furthermore, we could however provide the ability to QoS models to specify which

QSPEC parameters should be mandatory or not.

What do you think?

 

Best regards,

Georgios

 

 

 

From: Lars Westberg [mailto:Lars.westberg@ericsson.com]
Sent: dinsdag 17 oktober 2006 8:46
To: Georgios Karagiannis
Cc: gash@att.com; nsis@ietf.org
Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

yes.
the main problem is that IETF is not the only Standardization organization that like to discuss "bearer services". Just as an example :
If we specify the those parameters, How can we use NSIS for SLAs specified by MEF????

How can we use it for 3GPP-Qos definitiions ?


In the draft I also see  that we the draft specify a new bearer service. It is not compliant to old Int.serv architecture.  This is a completely new one with new parameters like priority.

I can sure that we can have a never-ending discussion about the "optimal"-set of parameters.

I think we agree in beggining the working group discussion that we should not specify any "bearer-service" because NSIS should be a modular architecture with  more flexibillity than RSVP.  Therefore, I am surprised that we are doing the same mistake as in RSVP: Integrating a bearer service definition into the NSIS-architecture.

If we go this track, the QoS-part of NSIS has much less use. RSVP is in this case significantly better in terms of performance and have the same functionality than NSIS.
If have to choose I would select RSVP rather than a much more complex  three layer protocol stack.

regards Lasse

Georgios Karagiannis wrote:

Hi Lars
 
Do you mean that the QSPEC template must not contain any mandatory
(QSPEC-1) parameters?
 
 
Best Regards,
Georgios
 
 
 
On 10/16/2006, "Lars Westberg" <Lars.westberg@ericsson.com> wrote:
 
  
Hi,
The template seems not to be a template because the mandatory part  is
more or less the same as Intserv.
The main idea with QoS-template was to make an modular solution that
could allow flexibillity for different Qos-models
 
Therefore, I do not understand the scope of the specification.
 
I suggest that we move the major part of the parameters to a separate
"Int.serv. over NSIS" specification.
Int.serv. can be seen as a common bearer service.
 
regards Lasse
 
Ash, Gerald R (Jerry), ALABS wrote:
 
    
Lars,
 
      
You mention in the below e-mail that there are no open issues,
while there is a huge discussion on the nsis mailing list
regarding the QSPEC-1 parameters.
        
John can call a different consensus if he sees one (I've asked him a
couple of times to do that).  What I saw was
 
1. Many posts supported the QSPEC-1 concept, only one (or maybe two) I
saw opposed.  The opposing view was repeated *many* times (and is still
being repeated) but it only counts as one opinion.
2. Many posts supported retaining the 4 QSPEC-1 parameters, only one I
saw opposed.  The opposing view was repeated many times.
3. There was only one opinion expressed to be able to ignore QSPEC-1
parameters.  That one opinion has been repeated many times but it only
counts as one opinion.
 
John asked a while ago for new opinions on these issues, that would be
good if there are any *new* opinions.  We don't need to hear opinions
repeated that we've seen so many times.
 
I invite John once again to make a consensus call so we can move on
here.  I think it is time to make progress and stop repeating ourselves,
we're not generating any new light in this rather endless discussion.
 
Thanks,
Jerry
 
      
 
 
--------------050208010607010000060603-- --===============1783068149== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============1783068149==-- From nsis-bounces@ietf.org Wed Oct 18 02:49:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga5Eg-0005tz-Ts; Wed, 18 Oct 2006 02:49:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga5Ef-0005tu-Gp for nsis@ietf.org; Wed, 18 Oct 2006 02:49:05 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ga5Ed-0002yM-U4 for nsis@ietf.org; Wed, 18 Oct 2006 02:49:05 -0400 Received: from S4DE8PSAAGT.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Wed, 18 Oct 2006 08:48:59 +0200 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by S4DE8PSAAGT.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Oct 2006 08:48:58 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] QSPEC-issue (GK-2) X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 18 Oct 2006 08:48:57 +0200 Message-Id: <6439282641581441A36F7F6F83ED2ED2CBF8E5@S4DE8PSAAFQ.mitte.t-com.de> in-reply-to: <9473683187ADC049A855ED2DA739ABCA0DDC7E5A@KCCLUST06EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QSPEC-issue (GK-2) Thread-Index: AcbyEP/OYEPgb32cR5KJnsvG374d7AAb8V9A From: "Geib, Ruediger" To: X-OriginalArrivalTime: 18 Oct 2006 06:48:58.0598 (UTC) FILETIME=[7CD9A860:01C6F281] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Jerry, so your recommendation for providers not interested in priority=20 or those in countries where it is prohibited by laws would be=20 not deploy QoS NSLP or to prevent roaming support for visiting=20 customers of any provider supporting priority? Regards, Rudiger |> >In most other protocols, the general rule for dealing with=20 |> >unknown priority structures is "if you don't=20 |> >understand/support it, don't mess with it". In other words,=20 |> >"ignore it". | |If a QNI populates priority (either preemption, admission, RPH, etc.) |for its QOSM then the QNI/QOSM requirement for the reservation is that |QNEs will implement priority as populated (i.e., 'strictly interpret' |the parameter as defined in the QSPEC draft). All sorts of meaningless |'remappings' from one priority space to another is *not* the=20 |norm or the |intent, and are not allowed. A meaningful remapping of a priority |parameter can be defined by a QOSM specification=20 | |> >I still don't understand why "ignore it" is forbidden for=20 |> >Priority in QSPEC. | |> So, for the priority bit, should we have a general rule to silently |> pass if not understood? How do people feel about this? | |This would be equivalent to making priority a qspec-2 parameter. Since |preemption and other priority parameters are specified by referenced |RFCs and standards documents (and supported in most cases already by |implementations), I don't see the problem with strictly interpreting |priority as the default, i.e., leaving it as a qspec-1 parameter. | |Jerry | |_______________________________________________ |nsis mailing list |nsis@ietf.org |https://www1.ietf.org/mailman/listinfo/nsis | _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 18 03:50:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga6B2-0005h7-IR; Wed, 18 Oct 2006 03:49:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga6B1-0005h2-HD for nsis@ietf.org; Wed, 18 Oct 2006 03:49:23 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ga6Au-0001kl-VR for nsis@ietf.org; Wed, 18 Oct 2006 03:49:23 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k9I7mson008226; Wed, 18 Oct 2006 08:48:54 +0100 Received: from victor ([193.118.192.66]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Oct 2006 08:48:53 +0100 From: "Robert Hancock" To: "'Georgios Karagiannis'" , Subject: RE: [NSIS] Proposal to move the QSPEC work forward Date: Wed, 18 Oct 2006 09:49:12 +0200 Message-ID: <011401c6f289$e7885230$946b0a0a@comm.ad.roke.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Importance: Normal X-OriginalArrivalTime: 18 Oct 2006 07:48:54.0123 (UTC) FILETIME=[DBF33BB0:01C6F289] X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: 'Jukka MJ Manner' , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org 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:karagian@cs.utwente.nl] > Sent: 18 October 2006 07:34 > To: john.loughney@nokia.com > Cc: Jukka MJ Manner; nsis@ietf.org > 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" 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 > >nsis@ietf.org > >https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 18 04:08:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga6Sv-0001ci-En; Wed, 18 Oct 2006 04:07:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga6Su-0001cd-HC for nsis@ietf.org; Wed, 18 Oct 2006 04:07:52 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ga6Ss-0003bW-JH for nsis@ietf.org; Wed, 18 Oct 2006 04:07:52 -0400 Received: from S4DE8PSAAGT.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Wed, 18 Oct 2006 10:07:34 +0200 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by S4DE8PSAAGT.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Oct 2006 10:07:31 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 18 Oct 2006 10:07:30 +0200 Message-Id: <6439282641581441A36F7F6F83ED2ED2CBF8E6@S4DE8PSAAFQ.mitte.t-com.de> in-reply-to: <4535C43B.8050606@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Thread-Index: Acbye8pVo4AFu41/SsaCLand2cDlQAACKMJA From: "Geib, Ruediger" To: X-OriginalArrivalTime: 18 Oct 2006 08:07:31.0459 (UTC) FILETIME=[75EF2D30:01C6F28C] X-Spam-Score: 0.0 (/) X-Scan-Signature: a2010529d86d8cb33607793afc74e283 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1523609758==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============1523609758== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F28C.753F8140" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F28C.753F8140 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Lasse, =20 I fully support your view. *Peak Bandwidth* is sufficient as a mandatory parameter. I too expect QoS by resource reservations to be limited to the access. As soon as multiplexing effects can be exploited, PCN, RMD or the like seem to be more effective than per flow reservations. So if admission control based on resource reservations is applied, peak bandwidth is the parameter you look for. =20 The QOSM should carry information on the DSCP(s) to be used. =20 Regards, =20 Rudiger =20 .... Inter-operabillity solved by:=20 1) Overprovisioning in the core such as all QoS-requirments are solved. 2) Interoperabillity for different QoS-models =3D>Peak-allocation of bandwidth. ......=20 My suggestion is that the Template is changed so it's only contain optional parameters description. regards Lasse Georgios Karagiannis wrote: Hi Radhika =20 I think that Jukka just suggested a very good solution to this problem! =20 Best Regards, Georgios =20 =20 _____ =20 From: RADHIKA.R.ROY@saic.com [ mailto:RADHIKA.R.ROY@saic.com]=20 Sent: dinsdag 17 oktober 2006 16:58 To: Georgios Karagiannis; john.loughney@nokia.com; Lars.westberg@ericsson.com Cc: gash@att.com; nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Georgios: I fear that it will also not solve the basic problem of incompatibility. Please see my email. It is just too much to solve as these are still subjective interpretations and too complex to implement for clear interworking. Best regards, Radhika _____ =20 From: nsis-bounces@ietf.org [ mailto:nsis-bounces@ietf.org] On Behalf Of Georgios Karagiannis Sent: Tuesday, October 17, 2006 10:51 AM To: john.loughney@nokia.com; Lars.westberg@ericsson.com Cc: gash@att.com; nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Hi John A solution of this can be as follows. First of all: the QSPEC template does not specify mandatory parameters. However, an end-to-end QoS model may mandate the use of a QSPEC parameter.=20 Any QNE that suopports this end-to-end QoS model then it will have to interpret=20 (strictly or remap) this parameter. The remapping is then specified in the end -to-end QOSM draft. Another local QoS model that needs to interoperate with the end-to-end QoS model it will either=20 have to strictly interpret the parameter specified by the end -to- end QoS model, or to remap it.=20 The remapping is also specified in the local QOSM draft. However, if a QNE does not support the end-to-end QoS model then it will just set the=20 NON-QOSM Hop flag.=20 In this way we achieve both modularity and interoperability. Best Regards, Georgios _____ =20 From: john.loughney@nokia.com [ mailto:john.loughney@nokia.com]=20 Sent: dinsdag 17 oktober 2006 16:21 To: karagian@cs.utwente.nl; Lars.westberg@ericsson.com Cc: gash@att.com; nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Georgios, About having the QoS Models specifying manditory parameters - could you explain how we would get interoperability between two different QoS models that have different sets of manditory parameters? I think we need to have a baseline QSPEC with manditory parameters to ensure interoperability - we should have the lowest common denominator between the QoS models to ensure some way of being able to signal across multiple QoS model deployments. John _____ =20 From: ext Georgios Karagiannis [ mailto:karagian@cs.utwente.nl]=20 Sent: 17 October, 2006 01:40 To: 'Lars Westberg' Cc: gash@att.com; nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Hi Lars I think that I agree with you! However, we may just need one QSPEC parameter, say Traffic (Tocken Bucket and Bandwidth)=20 that can be mandatory. In this way we will provide the required interoperability between the=20 QoS models. Actually this was also the conclusion that Xiaoming deduced after studying a couple of examples. Furthermore, we could however provide the ability to QoS models to specify which=20 QSPEC parameters should be mandatory or not. What do you think? Best regards, Georgios _____ =20 From: Lars Westberg [ mailto:Lars.westberg@ericsson.com]=20 Sent: dinsdag 17 oktober 2006 8:46 To: Georgios Karagiannis Cc: gash@att.com; nsis@ietf.org Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt yes.=20 the main problem is that IETF is not the only Standardization organization that like to discuss "bearer services". Just as an example : If we specify the those parameters, How can we use NSIS for SLAs specified by MEF???? How can we use it for 3GPP-Qos definitiions ? In the draft I also see that we the draft specify a new bearer service. It is not compliant to old Int.serv architecture. This is a completely new one with new parameters like priority. I can sure that we can have a never-ending discussion about the "optimal"-set of parameters. I think we agree in beggining the working group discussion that we should not specify any "bearer-service" because NSIS should be a modular architecture with more flexibillity than RSVP. Therefore, I am surprised that we are doing the same mistake as in RSVP: Integrating a bearer service definition into the NSIS-architecture. If we go this track, the QoS-part of NSIS has much less use. RSVP is in this case significantly better in terms of performance and have the same functionality than NSIS. If have to choose I would select RSVP rather than a much more complex three layer protocol stack. regards Lasse Georgios Karagiannis wrote: Hi Lars =20 Do you mean that the QSPEC template must not contain any mandatory (QSPEC-1) parameters? =20 =20 Best Regards, Georgios =20 =20 =20 On 10/16/2006, "Lars Westberg" wrote: =20 =20 Hi, The template seems not to be a template because the mandatory part is more or less the same as Intserv. The main idea with QoS-template was to make an modular solution that could allow flexibillity for different Qos-models =20 Therefore, I do not understand the scope of the specification. =20 I suggest that we move the major part of the parameters to a separate "Int.serv. over NSIS" specification. Int.serv. can be seen as a common bearer service. =20 regards Lasse =20 Ash, Gerald R (Jerry), ALABS wrote: =20 =20 Lars, =20 =20 You mention in the below e-mail that there are no open issues, while there is a huge discussion on the nsis mailing list regarding the QSPEC-1 parameters. =20 John can call a different consensus if he sees one (I've asked him a couple of times to do that). What I saw was =20 1. Many posts supported the QSPEC-1 concept, only one (or maybe two) I saw opposed. The opposing view was repeated *many* times (and is still being repeated) but it only counts as one opinion. 2. Many posts supported retaining the 4 QSPEC-1 parameters, only one I saw opposed. The opposing view was repeated many times. 3. There was only one opinion expressed to be able to ignore QSPEC-1 parameters. That one opinion has been repeated many times but it only counts as one opinion. =20 John asked a while ago for new opinions on these issues, that would be good if there are any *new* opinions. We don't need to hear opinions repeated that we've seen so many times. =20 I invite John once again to make a consensus call so we can move on here. I think it is time to make progress and stop repeating ourselves, we're not generating any new light in this rather endless discussion. =20 Thanks, Jerry =20 =20 =20 =20 ------_=_NextPart_001_01C6F28C.753F8140 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Lasse,
 
I=20 fully support your view. *Peak Bandwidth* is sufficient as a = mandatory=20 parameter. I too expect QoS by resource reservations to be limited = to the=20 access. As soon as multiplexing effects can be exploited, = PCN, RMD or=20 the like seem to be more effective than per flow reservations. So if = admission=20 control based on resource reservations is applied, peak bandwidth is the = parameter you look for.
 
The QOSM should carry information on the = DSCP(s)=20 to be used.
 
Regards,
 
Rüdiger
 
 .... Inter-operabillity solved by: =
1)=20 Overprovisioning in the core such as all QoS-requirments are = solved.
2)=20 Interoperabillity for different QoS-models =3D>Peak-allocation of=20 bandwidth.

 ...... 
My = suggestion is that=20 the Template is changed so it's only contain optional parameters=20 description.

regards Lasse




Georgios = Karagiannis=20 wrote:
Hi Radhika
 
I think that Jukka just suggested a very = good solution=20 to this problem!
 
Best Regards,
Georgios
 
 

From: RADHIKA.R.ROY@saic.com = [mailto:RADHIKA.R.ROY@saic.com]= =20
Sent: dinsdag 17 oktober 2006 16:58
To: = Georgios=20 Karagiannis; john.loughney@nokia.com; Lars.westberg@ericsson.com=
Cc:=20 gash@att.com; nsis@ietf.org
Subject: = RE:=20 [NSIS] I-D = ACTION:draft-ietf-nsis-qspec-12.txt

Georgios:

I fear = that it=20 will also not solve the basic problem of incompatibility. Please = see my=20 email. It is just too much to solve as these are still subjective=20 interpretations and too complex to implement for clear=20 interworking.

Best=20 regards,

Radhika

From: = nsis-bounces@ietf.org = [mailto:nsis-bounces@ietf.org]=20 On Behalf Of = Georgios=20 Karagiannis
Sent:=20 Tuesday, October 17, 2006 10:51 AM
To: john.loughney@nokia.com; Lars.westberg@ericsson.com=
Cc: gash@att.com; nsis@ietf.org
Subject: RE: [NSIS] I-D=20 ACTION:draft-ietf-nsis-qspec-12.txt

Hi=20 John

A = solution of=20 this can be as follows.

First = of all: the=20 QSPEC template does not specify  mandatory=20 parameters.

However, an=20 end-to-end QoS model may mandate the use of a QSPEC parameter.=20

Any QNE = that=20 suopports this end-to-end QoS model then it will have to interpret =

(strictly or=20 remap) this parameter. The remapping is then specified in the end = -to-end=20 QOSM draft.

Another = local QoS=20 model that needs to interoperate with the end-to-end QoS model it = will=20 either

have to = strictly=20 interpret the parameter specified by the end -to- end QoS model, = or to=20 remap it. 

The = remapping is=20 also specified in the local QOSM = draft.

However, if a QNE=20 does not support the end-to-end QoS model then it will just set = the=20

NON-QOSM Hop=20 flag.

In this = way we=20 achieve both modularity and = interoperability.

Best=20 Regards,

Georgios

From:=20 john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20
Sent: = dinsdag 17=20 oktober 2006 16:21
To:=20 karagian@cs.utwente.nl; Lars.westberg@ericsson.com=
Cc: gash@att.com; nsis@ietf.org
Subject: RE: [NSIS] I-D=20 ACTION:draft-ietf-nsis-qspec-12.txt

Georgios,

About = having=20 the QoS Models specifying manditory parameters - could you = explain how=20 we would get interoperability between two different QoS models = that have=20 different sets of manditory = parameters?

I = think we need=20 to have a baseline QSPEC with manditory parameters to ensure=20 interoperability - we should have the lowest common denominator = between=20 the QoS models to ensure some way of being able to signal across = multiple QoS model deployments.

John

From:=20 ext Georgios Karagiannis [mailto:karagian@cs.utwente.nl]= =20
Sent: 17 = October,=20 2006 01:40
To: 'Lars=20 Westberg'
Cc: gash@att.com; nsis@ietf.org
Subject: RE: [NSIS] I-D = = ACTION:draft-ietf-nsis-qspec-12.txt

Hi=20 Lars

I = think that=20 I agree with you!

However, we=20 may just need one QSPEC parameter, say Traffic (Tocken Bucket = and=20 Bandwidth)

that can be=20 mandatory. In this way we will provide the required = interoperability=20 between the

QoS = models.

Actually this=20 was also the conclusion that Xiaoming deduced after studying a = couple=20 of examples.

Furthermore,=20 we could however provide the ability to QoS models to specify = which=20

QSPEC=20 parameters should be mandatory or = not.

What do you=20 think?

Best=20 regards,

Georgios

From: Lars = Westberg [mailto:Lars.westberg@ericsson.= com]=20
Sent: = dinsdag 17=20 oktober 2006 8:46
To: Georgios=20 Karagiannis
Cc: gash@att.com; nsis@ietf.org
Subject: Re: [NSIS] = I-D=20 = ACTION:draft-ietf-nsis-qspec-12.txt

yes.
the main = problem is=20 that IETF is not the only Standardization organization that = like to=20 discuss "bearer services". Just as an example :
If we = specify the=20 those parameters, How can we use NSIS for SLAs specified by=20 MEF????

How can we use it for 3GPP-Qos definitiions=20 ?


In the draft I also see  that we the draft = specify=20 a new bearer service. It is not compliant to old Int.serv=20 architecture.  This is a completely new one with new = parameters=20 like priority.

I can sure that we can have a = never-ending=20 discussion about the "optimal"-set of parameters.

I = think we=20 agree in beggining the working group discussion that we = should not=20 specify any "bearer-service" because NSIS should be a = modular=20 architecture with  more flexibillity than RSVP. =20 Therefore, I am surprised that we are doing the same mistake = as in=20 RSVP: Integrating a bearer service definition into the=20 NSIS-architecture.

If we go this track, the QoS-part = of NSIS=20 has much less use. RSVP is in this case significantly better = in=20 terms of performance and have the same functionality than=20 NSIS.
If have to choose I would select RSVP rather than a = much=20 more complex  three layer protocol = stack.

regards=20 Lasse

Georgios Karagiannis=20 wrote:

Hi =
Lars
 
Do you mean =
that the QSPEC template must not contain any =
mandatory
(QSPEC-1) =
parameters?
 
 
Best =
Regards,
Georgios
 
 
 
On =
10/16/2006, "Lars Westberg" <Lars.westberg@ericsson.com=
> wrote:
 
  =

Hi,
The template =
seems not to be a template because the mandatory part  =
is
more or less the =
same as Intserv.
The main idea with QoS-template was to make an modular solution =
that
could allow =
flexibillity for different =
Qos-models
 
Therefore, I =
do not understand the scope of the =
specification.
 
I suggest =
that we move the major part of the parameters to a =
separate
"Int.serv. over =
NSIS" specification.
Int.serv. can be seen as a common bearer =
service.
 
regards =
Lasse
 
Ash, Gerald =
R (Jerry), ALABS wrote:
 
    
Lars,
 
      
You mention in =
the below e-mail that there are no open =
issues,
while there is a =
huge discussion on the nsis mailing =
list
regarding the =
QSPEC-1 parameters.
        =

John can call a different consensus if he sees one (I've asked him =
a
couple of times =
to do that).  What I saw =
was
 
1. Many =
posts supported the QSPEC-1 concept, only one (or maybe two) =
I
saw =
opposed.  The opposing view was repeated *many* times (and is =
still
being repeated) =
but it only counts as one =
opinion.
2. Many posts =
supported retaining the 4 QSPEC-1 parameters, only one =
I
saw =
opposed.  The opposing view was repeated many =
times.
3. There was only =
one opinion expressed to be able to ignore =
QSPEC-1
parameters.  =
That one opinion has been repeated many times but it =
only
counts as one =
opinion.
 
John asked a =
while ago for new opinions on these issues, that would =
be
good if there are =
any *new* opinions.  We don't need to hear =
opinions
repeated that =
we've seen so many times.
 
I invite =
John once again to make a consensus call so we can move =
on
here.  I =
think it is time to make progress and stop repeating =
ourselves,
we're not =
generating any new light in this rather endless =
discussion.
 
Thanks,
Jerry
 
      =

 
  =
------_=_NextPart_001_01C6F28C.753F8140-- --===============1523609758== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============1523609758==-- From nsis-bounces@ietf.org Wed Oct 18 04:08:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga6TH-0001eZ-2E; Wed, 18 Oct 2006 04:08:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga6TG-0001eU-9u for nsis@ietf.org; Wed, 18 Oct 2006 04:08:14 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ga6TA-0003cz-O6 for nsis@ietf.org; Wed, 18 Oct 2006 04:08:14 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id EA12513DF; Wed, 18 Oct 2006 10:08:05 +0200 (CEST) Received: from esealmw116.eemea.ericsson.se ([153.88.200.7]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Oct 2006 10:08:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Proposal to move the QSPEC work forward Date: Wed, 18 Oct 2006 10:08:04 +0200 Message-ID: <05F34B6959F19F43BBD78FFCD4C15D055DFF8A@esealmw116.eemea.ericsson.se> In-Reply-To: <011401c6f289$e7885230$946b0a0a@comm.ad.roke.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Proposal to move the QSPEC work forward Thread-Index: Acbyijw5OYg4qEUsQlGSJ6If9YvVnAAAJVSA From: =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= To: "Robert Hancock" , "Georgios Karagiannis" , X-OriginalArrivalTime: 18 Oct 2006 08:08:05.0281 (UTC) FILETIME=[8A180110:01C6F28C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: Jukka MJ Manner , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi All,=20 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 >-----Original Message----- >From: Robert Hancock [mailto:robert.hancock@roke.co.uk]=20 >Sent: Wednesday, October 18, 2006 9:49 AM >To: 'Georgios Karagiannis'; john.loughney@nokia.com >Cc: 'Jukka MJ Manner'; nsis@ietf.org >Subject: RE: [NSIS] Proposal to move the QSPEC work forward > >hi, > >personally, i don't think this would be a good idea. without a=20 >decision on the type-1/type-2 question, the qspec is a bag of=20 >packet formats, and not much use in creating usable qos models=20 >since it just sidesteps the interoperability questions. > >(if the interoperability questions were easy and the packet=20 >formats were hard, then the situation might be different. but=20 >i don't see that deferring the interoperability discussion is=20 >going to make that discussion any easier - it will just=20 >present the illusion of progress.) > >i still have yet to see anyone in this debate give any=20 >counter-argument to my assertion that the type-1/type-2=20 >distinction is both useful and achievable for at least one=20 >parameter(*), which makes me think that the problem is=20 >actually not so hard as some people want to make it seem. > >robert h. > >(*) see=20 >http://www1.ietf.org/mail-archive/web/nsis/current/msg06908.html > >> -----Original Message----- >> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >> Sent: 18 October 2006 07:34 >> To: john.loughney@nokia.com >> Cc: Jukka MJ Manner; nsis@ietf.org >> Subject: Re: [NSIS] Proposal to move the QSPEC work forward >>=20 >>=20 >>=20 >> Hi John >>=20 >> Do you agree with the proposal of Jukka? >>=20 >> Please see below! >>=20 >> Best Regards, >> Georgios >>=20 >>=20 >> On 10/17/2006, "Jukka MJ Manner" wrote: >>=20 >> > >> >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=20 >> >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=20 >order to=20 >> >get people design new QoS Models. This latter draft will=20 >probably be=20 >> >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=20 >> >Informational. Once the latter draft is done, QoS Model authors may=20 >> >update their spec based on the interworking rules, and seek to move=20 >> >their QoS Models to Standards Track. >> > >> >Jukka >> > >> >_______________________________________________ >> >nsis mailing list >> >nsis@ietf.org >> >https://www1.ietf.org/mailman/listinfo/nsis >>=20 >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis >>=20 > > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 18 04:09:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga6U9-0001xk-23; Wed, 18 Oct 2006 04:09:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga6U8-0001wl-6k for nsis@ietf.org; Wed, 18 Oct 2006 04:09:08 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ga6U1-0003iR-Ds for nsis@ietf.org; Wed, 18 Oct 2006 04:09:08 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 97264122C; Wed, 18 Oct 2006 10:08:58 +0200 (CEST) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Oct 2006 10:08:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Date: Wed, 18 Oct 2006 10:08:57 +0200 Message-ID: <0CDAE977A7172A40A2A3A1C20C12BD65048B4A41@esealmw106.eemea.ericsson.se> In-Reply-To: <6439282641581441A36F7F6F83ED2ED2CBF8E6@S4DE8PSAAFQ.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Thread-Index: Acbye8pVo4AFu41/SsaCLand2cDlQAACKMJAAAINGUA= From: "Lars Westberg \(KI/EAB\)" To: "Geib, Ruediger" X-OriginalArrivalTime: 18 Oct 2006 08:08:58.0069 (UTC) FILETIME=[A98ED050:01C6F28C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 53b2663681a067d6bc137eb1242b2dac Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0849265698==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0849265698== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F28C.A972C7C4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F28C.A972C7C4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable sure, that's ok. ________________________________ From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]=20 Sent: den 18 oktober 2006 10:08 To: Lars Westberg (KI/EAB) Cc: nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Lasse, =20 I fully support your view. *Peak Bandwidth* is sufficient as a mandatory = parameter. I too expect QoS by resource reservations to be limited to = the access. As soon as multiplexing effects can be exploited, PCN, RMD = or the like seem to be more effective than per flow reservations. So if = admission control based on resource reservations is applied, peak = bandwidth is the parameter you look for. =20 The QOSM should carry information on the DSCP(s) to be used. =20 Regards, =20 R=FCdiger =20 .... Inter-operabillity solved by:=20 1) Overprovisioning in the core such as all QoS-requirments are solved. 2) Interoperabillity for different QoS-models =3D>Peak-allocation of = bandwidth. =09 ......=20 My suggestion is that the Template is changed so it's only contain = optional parameters description. =09 regards Lasse =09 =09 =09 =09 Georgios Karagiannis wrote: =09 Hi Radhika =20 I think that Jukka just suggested a very good solution to this = problem! =20 Best Regards, Georgios =20 =20 ________________________________ From: RADHIKA.R.ROY@saic.com [mailto:RADHIKA.R.ROY@saic.com]=20 Sent: dinsdag 17 oktober 2006 16:58 To: Georgios Karagiannis; john.loughney@nokia.com; = Lars.westberg@ericsson.com Cc: gash@att.com; nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt =09 =09 Georgios: =09 I fear that it will also not solve the basic problem of = incompatibility. Please see my email. It is just too much to solve as = these are still subjective interpretations and too complex to implement = for clear interworking. =09 Best regards, Radhika =09 =09 ________________________________ From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On Behalf = Of Georgios Karagiannis Sent: Tuesday, October 17, 2006 10:51 AM To: john.loughney@nokia.com; Lars.westberg@ericsson.com Cc: gash@att.com; nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt =09 Hi John =09 A solution of this can be as follows. =09 First of all: the QSPEC template does not specify mandatory = parameters. =09 However, an end-to-end QoS model may mandate the use of a QSPEC = parameter.=20 Any QNE that suopports this end-to-end QoS model then it will have to = interpret=20 (strictly or remap) this parameter. The remapping is then specified = in the end -to-end QOSM draft. =09 Another local QoS model that needs to interoperate with the = end-to-end QoS model it will either=20 have to strictly interpret the parameter specified by the end -to- = end QoS model, or to remap it.=20 The remapping is also specified in the local QOSM draft. =09 However, if a QNE does not support the end-to-end QoS model then it = will just set the=20 NON-QOSM Hop flag.=20 In this way we achieve both modularity and interoperability. =09 Best Regards, Georgios =09 =09 =09 =09 =09 ________________________________ From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 Sent: dinsdag 17 oktober 2006 16:21 To: karagian@cs.utwente.nl; Lars.westberg@ericsson.com Cc: gash@att.com; nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Georgios, =09 About having the QoS Models specifying manditory parameters - could = you explain how we would get interoperability between two different QoS = models that have different sets of manditory parameters? =09 I think we need to have a baseline QSPEC with manditory parameters = to ensure interoperability - we should have the lowest common = denominator between the QoS models to ensure some way of being able to = signal across multiple QoS model deployments. =09 John =09 =09 ________________________________ From: ext Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 Sent: 17 October, 2006 01:40 To: 'Lars Westberg' Cc: gash@att.com; nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Hi Lars =09 I think that I agree with you! =09 However, we may just need one QSPEC parameter, say Traffic (Tocken = Bucket and Bandwidth)=20 that can be mandatory. In this way we will provide the required = interoperability between the=20 QoS models. Actually this was also the conclusion that Xiaoming deduced after = studying a couple of examples. =09 Furthermore, we could however provide the ability to QoS models to = specify which=20 QSPEC parameters should be mandatory or not. What do you think? =09 Best regards, Georgios =09 =09 =09 =09 ________________________________ From: Lars Westberg [mailto:Lars.westberg@ericsson.com]=20 Sent: dinsdag 17 oktober 2006 8:46 To: Georgios Karagiannis Cc: gash@att.com; nsis@ietf.org Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt yes.=20 the main problem is that IETF is not the only Standardization = organization that like to discuss "bearer services". Just as an example = : If we specify the those parameters, How can we use NSIS for SLAs = specified by MEF???? =09 How can we use it for 3GPP-Qos definitiions ? =09 =09 In the draft I also see that we the draft specify a new bearer = service. It is not compliant to old Int.serv architecture. This is a = completely new one with new parameters like priority. =09 I can sure that we can have a never-ending discussion about the = "optimal"-set of parameters. =09 I think we agree in beggining the working group discussion that we = should not specify any "bearer-service" because NSIS should be a modular = architecture with more flexibillity than RSVP. Therefore, I am = surprised that we are doing the same mistake as in RSVP: Integrating a = bearer service definition into the NSIS-architecture. =09 If we go this track, the QoS-part of NSIS has much less use. RSVP = is in this case significantly better in terms of performance and have = the same functionality than NSIS. If have to choose I would select RSVP rather than a much more = complex three layer protocol stack. =09 regards Lasse =09 Georgios Karagiannis wrote: =09 =09 Hi Lars =20 Do you mean that the QSPEC template must not contain any mandatory (QSPEC-1) parameters? =20 =20 Best Regards, Georgios =20 =20 =20 On 10/16/2006, "Lars Westberg" = wrote: =20 =20 Hi, The template seems not to be a template because the mandatory part = is more or less the same as Intserv. The main idea with QoS-template was to make an modular solution = that could allow flexibillity for different Qos-models =20 Therefore, I do not understand the scope of the specification. =20 I suggest that we move the major part of the parameters to a = separate "Int.serv. over NSIS" specification. Int.serv. can be seen as a common bearer service. =20 regards Lasse =20 Ash, Gerald R (Jerry), ALABS wrote: =20 =20 Lars, =20 =20 You mention in the below e-mail that there are no open issues, while there is a huge discussion on the nsis mailing list regarding the QSPEC-1 parameters. =20 John can call a different consensus if he sees one (I've asked him = a couple of times to do that). What I saw was =20 1. Many posts supported the QSPEC-1 concept, only one (or maybe = two) I saw opposed. The opposing view was repeated *many* times (and is = still being repeated) but it only counts as one opinion. 2. Many posts supported retaining the 4 QSPEC-1 parameters, only = one I saw opposed. The opposing view was repeated many times. 3. There was only one opinion expressed to be able to ignore = QSPEC-1 parameters. That one opinion has been repeated many times but it = only counts as one opinion. =20 John asked a while ago for new opinions on these issues, that would = be good if there are any *new* opinions. We don't need to hear = opinions repeated that we've seen so many times. =20 I invite John once again to make a consensus call so we can move on here. I think it is time to make progress and stop repeating = ourselves, we're not generating any new light in this rather endless = discussion. =20 Thanks, Jerry =20 =20 =20 =20 ------_=_NextPart_001_01C6F28C.A972C7C4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
sure,=20 that's ok.

From: Geib, Ruediger=20 [mailto:Ruediger.Geib@t-systems.com]
Sent: den 18 oktober = 2006=20 10:08
To: Lars Westberg (KI/EAB)
Cc:=20 nsis@ietf.org
Subject: RE: [NSIS] I-D=20 ACTION:draft-ietf-nsis-qspec-12.txt

Lasse,
 
I=20 fully support your view. *Peak Bandwidth* is sufficient as a = mandatory=20 parameter. I too expect QoS by resource reservations to be limited = to the=20 access. As soon as multiplexing effects can be exploited, = PCN, RMD or=20 the like seem to be more effective than per flow reservations. So if = admission=20 control based on resource reservations is applied, peak bandwidth is the = parameter you look for.
 
The QOSM should carry information on the = DSCP(s)=20 to be used.
 
Regards,
 
R=FCdiger
 
 .... Inter-operabillity solved by: =
1)=20 Overprovisioning in the core such as all QoS-requirments are = solved.
2)=20 Interoperabillity for different QoS-models =3D>Peak-allocation of=20 bandwidth.

 ...... 
My = suggestion is that=20 the Template is changed so it's only contain optional parameters=20 description.

regards Lasse




Georgios = Karagiannis=20 wrote:
Hi Radhika
 
I think that Jukka just suggested a very = good solution=20 to this problem!
 
Best Regards,
Georgios
 
 

From: RADHIKA.R.ROY@saic.com = [mailto:RADHIKA.R.ROY@saic.com]= =20
Sent: dinsdag 17 oktober 2006 16:58
To: = Georgios=20 Karagiannis; john.loughney@nokia.com; Lars.westberg@ericsson.com=
Cc:=20 gash@att.com; nsis@ietf.org
Subject: = RE:=20 [NSIS] I-D = ACTION:draft-ietf-nsis-qspec-12.txt

Georgios:

I fear = that it=20 will also not solve the basic problem of incompatibility. Please = see my=20 email. It is just too much to solve as these are still subjective=20 interpretations and too complex to implement for clear=20 interworking.

Best=20 regards,

Radhika

From: = nsis-bounces@ietf.org = [mailto:nsis-bounces@ietf.org]=20 On Behalf Of = Georgios=20 Karagiannis
Sent:=20 Tuesday, October 17, 2006 10:51 AM
To: john.loughney@nokia.com; Lars.westberg@ericsson.com=
Cc: gash@att.com; nsis@ietf.org
Subject: RE: [NSIS] I-D=20 ACTION:draft-ietf-nsis-qspec-12.txt

Hi=20 John

A = solution of=20 this can be as follows.

First = of all: the=20 QSPEC template does not specify  mandatory=20 parameters.

However, an=20 end-to-end QoS model may mandate the use of a QSPEC parameter.=20

Any QNE = that=20 suopports this end-to-end QoS model then it will have to interpret =

(strictly or=20 remap) this parameter. The remapping is then specified in the end = -to-end=20 QOSM draft.

Another = local QoS=20 model that needs to interoperate with the end-to-end QoS model it = will=20 either

have to = strictly=20 interpret the parameter specified by the end -to- end QoS model, = or to=20 remap it. 

The = remapping is=20 also specified in the local QOSM = draft.

However, if a QNE=20 does not support the end-to-end QoS model then it will just set = the=20

NON-QOSM Hop=20 flag.

In this = way we=20 achieve both modularity and = interoperability.

Best=20 Regards,

Georgios

From:=20 john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20
Sent: = dinsdag 17=20 oktober 2006 16:21
To:=20 karagian@cs.utwente.nl; Lars.westberg@ericsson.com=
Cc: gash@att.com; nsis@ietf.org
Subject: RE: [NSIS] I-D=20 ACTION:draft-ietf-nsis-qspec-12.txt

Georgios,

About = having=20 the QoS Models specifying manditory parameters - could you = explain how=20 we would get interoperability between two different QoS models = that have=20 different sets of manditory = parameters?

I = think we need=20 to have a baseline QSPEC with manditory parameters to ensure=20 interoperability - we should have the lowest common denominator = between=20 the QoS models to ensure some way of being able to signal across = multiple QoS model deployments.

John

From:=20 ext Georgios Karagiannis [mailto:karagian@cs.utwente.nl]= =20
Sent: 17 = October,=20 2006 01:40
To: 'Lars=20 Westberg'
Cc: gash@att.com; nsis@ietf.org
Subject: RE: [NSIS] I-D = = ACTION:draft-ietf-nsis-qspec-12.txt

Hi=20 Lars

I = think that=20 I agree with you!

However, we=20 may just need one QSPEC parameter, say Traffic (Tocken Bucket = and=20 Bandwidth)

that can be=20 mandatory. In this way we will provide the required = interoperability=20 between the

QoS = models.

Actually this=20 was also the conclusion that Xiaoming deduced after studying a = couple=20 of examples.

Furthermore,=20 we could however provide the ability to QoS models to specify = which=20

QSPEC=20 parameters should be mandatory or = not.

What do you=20 think?

Best=20 regards,

Georgios

From: Lars = Westberg [mailto:Lars.westberg@ericsson.= com]=20
Sent: = dinsdag 17=20 oktober 2006 8:46
To: Georgios=20 Karagiannis
Cc: gash@att.com; nsis@ietf.org
Subject: Re: [NSIS] = I-D=20 = ACTION:draft-ietf-nsis-qspec-12.txt

yes.
the main = problem is=20 that IETF is not the only Standardization organization that = like to=20 discuss "bearer services". Just as an example :
If we = specify the=20 those parameters, How can we use NSIS for SLAs specified by=20 MEF????

How can we use it for 3GPP-Qos definitiions=20 ?


In the draft I also see  that we the draft = specify=20 a new bearer service. It is not compliant to old Int.serv=20 architecture.  This is a completely new one with new = parameters=20 like priority.

I can sure that we can have a = never-ending=20 discussion about the "optimal"-set of parameters.

I = think we=20 agree in beggining the working group discussion that we = should not=20 specify any "bearer-service" because NSIS should be a = modular=20 architecture with  more flexibillity than RSVP. =20 Therefore, I am surprised that we are doing the same mistake = as in=20 RSVP: Integrating a bearer service definition into the=20 NSIS-architecture.

If we go this track, the QoS-part = of NSIS=20 has much less use. RSVP is in this case significantly better = in=20 terms of performance and have the same functionality than=20 NSIS.
If have to choose I would select RSVP rather than a = much=20 more complex  three layer protocol = stack.

regards=20 Lasse

Georgios Karagiannis=20 wrote:

Hi =
Lars
 
Do you mean =
that the QSPEC template must not contain any =
mandatory
(QSPEC-1) =
parameters?
 
 
Best =
Regards,
Georgios
 
 
 
On =
10/16/2006, "Lars Westberg" <Lars.westberg@ericsson.com=
> wrote:
 
  =

Hi,
The template =
seems not to be a template because the mandatory part  =
is
more or less the =
same as Intserv.
The main idea with QoS-template was to make an modular solution =
that
could allow =
flexibillity for different =
Qos-models
 
Therefore, I =
do not understand the scope of the =
specification.
 
I suggest =
that we move the major part of the parameters to a =
separate
"Int.serv. over =
NSIS" specification.
Int.serv. can be seen as a common bearer =
service.
 
regards =
Lasse
 
Ash, Gerald =
R (Jerry), ALABS wrote:
 
    
Lars,
 
      
You mention in =
the below e-mail that there are no open =
issues,
while there is a =
huge discussion on the nsis mailing =
list
regarding the =
QSPEC-1 parameters.
        =

John can call a different consensus if he sees one (I've asked him =
a
couple of times =
to do that).  What I saw =
was
 
1. Many =
posts supported the QSPEC-1 concept, only one (or maybe two) =
I
saw =
opposed.  The opposing view was repeated *many* times (and is =
still
being repeated) =
but it only counts as one =
opinion.
2. Many posts =
supported retaining the 4 QSPEC-1 parameters, only one =
I
saw =
opposed.  The opposing view was repeated many =
times.
3. There was only =
one opinion expressed to be able to ignore =
QSPEC-1
parameters.  =
That one opinion has been repeated many times but it =
only
counts as one =
opinion.
 
John asked a =
while ago for new opinions on these issues, that would =
be
good if there are =
any *new* opinions.  We don't need to hear =
opinions
repeated that =
we've seen so many times.
 
I invite =
John once again to make a consensus call so we can move =
on
here.  I =
think it is time to make progress and stop repeating =
ourselves,
we're not =
generating any new light in this rather endless =
discussion.
 
Thanks,
Jerry
 
      =

 
  =
------_=_NextPart_001_01C6F28C.A972C7C4-- --===============0849265698== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0849265698==-- From nsis-bounces@ietf.org Wed Oct 18 04:20:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga6ea-0001Xf-P0; Wed, 18 Oct 2006 04:19:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga6eZ-0001Xa-CA for nsis@ietf.org; Wed, 18 Oct 2006 04:19:55 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ga6eW-0005Sy-R5 for nsis@ietf.org; Wed, 18 Oct 2006 04:19:55 -0400 Received: from sbz-30.cs.helsinki.fi (sbz-30.cs.helsinki.fi [128.214.9.98]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Wed, 18 Oct 2006 11:19:51 +0300 id 000AFD31.4535E3A7.000048C6 Date: Wed, 18 Oct 2006 11:19:51 +0300 (EEST) From: Jukka MJ Manner To: Robert Hancock Subject: RE: [NSIS] Proposal to move the QSPEC work forward In-Reply-To: <011401c6f289$e7885230$946b0a0a@comm.ad.roke.co.uk> Message-ID: References: <011401c6f289$e7885230$946b0a0a@comm.ad.roke.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org 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 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:karagian@cs.utwente.nl] > > Sent: 18 October 2006 07:34 > > To: john.loughney@nokia.com > > Cc: Jukka MJ Manner; nsis@ietf.org > > 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" 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 > > >nsis@ietf.org > > >https://www1.ietf.org/mailman/listinfo/nsis > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 18 04:41:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga6yf-0006hq-Lb; Wed, 18 Oct 2006 04:40:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga6ye-0006hi-74 for nsis@ietf.org; Wed, 18 Oct 2006 04:40:40 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ga6yc-0000EE-SA for nsis@ietf.org; Wed, 18 Oct 2006 04:40:40 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k9I8eKI8025744; Wed, 18 Oct 2006 10:40:30 +0200 (MEST) From: "Georgios Karagiannis" To: "'Geib, Ruediger'" , Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Date: Wed, 18 Oct 2006 10:40:21 +0200 Message-ID: <001201c6f291$110fddb0$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <6439282641581441A36F7F6F83ED2ED2CBF8E6@S4DE8PSAAFQ.mitte.t-com.de> x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: Acbye8pVo4AFu41/SsaCLand2cDlQAACKMJAAAMc6+A= X-Spam-Score: -5.225 () ALL_TRUSTED, AWL, BAYES_00, FVGT_s_OBFU_Q1, HTML_MESSAGE, HTML_TITLE_EMPTY, J_CHICKENPOX_34 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Wed, 18 Oct 2006 10:40:35 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: f6c43b73fe807ea58c7d540be5bd4d71 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1810514194==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============1810514194== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01C6F2A1.D498ADB0" This is a multi-part message in MIME format. ------=_NextPart_000_0013_01C6F2A1.D498ADB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all =20 I also support the point of view of Lars that peak bandwdith is the only parameter that can be used to provide interoperability. =20 Best regards, Georgios =20 _____ =20 From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]=20 Sent: woensdag 18 oktober 2006 10:08 To: Lars.westberg@ericsson.com Cc: nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Lasse, =20 I fully support your view. *Peak Bandwidth* is sufficient as a mandatory parameter. I too expect QoS by resource reservations to be limited to = the access. As soon as multiplexing effects can be exploited, PCN, RMD or = the like seem to be more effective than per flow reservations. So if = admission control based on resource reservations is applied, peak bandwidth is the parameter you look for. =20 The QOSM should carry information on the DSCP(s) to be used. =20 Regards, =20 R=FCdiger =20 .... Inter-operabillity solved by:=20 1) Overprovisioning in the core such as all QoS-requirments are solved. 2) Interoperabillity for different QoS-models =3D>Peak-allocation of bandwidth. ......=20 My suggestion is that the Template is changed so it's only contain = optional parameters description. regards Lasse Georgios Karagiannis wrote: Hi Radhika =20 I think that Jukka just suggested a very good solution to this problem! =20 Best Regards, Georgios =20 =20 _____ =20 From: RADHIKA.R.ROY@saic.com [mailto:RADHIKA.R.ROY@saic.com]=20 Sent: dinsdag 17 oktober 2006 16:58 To: Georgios Karagiannis; john.loughney@nokia.com; Lars.westberg@ericsson.com Cc: gash@att.com; nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Georgios: I fear that it will also not solve the basic problem of incompatibility. Please see my email. It is just too much to solve as these are still subjective interpretations and too complex to implement for clear interworking. Best regards, Radhika _____ =20 From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On Behalf Of Georgios Karagiannis Sent: Tuesday, October 17, 2006 10:51 AM To: john.loughney@nokia.com; Lars.westberg@ericsson.com Cc: gash@att.com; nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Hi John A solution of this can be as follows. First of all: the QSPEC template does not specify mandatory parameters. However, an end-to-end QoS model may mandate the use of a QSPEC = parameter.=20 Any QNE that suopports this end-to-end QoS model then it will have to interpret=20 (strictly or remap) this parameter. The remapping is then specified in = the end -to-end QOSM draft. Another local QoS model that needs to interoperate with the end-to-end = QoS model it will either=20 have to strictly interpret the parameter specified by the end -to- end = QoS model, or to remap it.=20 The remapping is also specified in the local QOSM draft. However, if a QNE does not support the end-to-end QoS model then it will just set the=20 NON-QOSM Hop flag.=20 In this way we achieve both modularity and interoperability. Best Regards, Georgios _____ =20 From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 Sent: dinsdag 17 oktober 2006 16:21 To: karagian@cs.utwente.nl; Lars.westberg@ericsson.com Cc: gash@att.com; nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Georgios, About having the QoS Models specifying manditory parameters - could you explain how we would get interoperability between two different QoS = models that have different sets of manditory parameters? I think we need to have a baseline QSPEC with manditory parameters to = ensure interoperability - we should have the lowest common denominator between = the QoS models to ensure some way of being able to signal across multiple = QoS model deployments. John _____ =20 From: ext Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 Sent: 17 October, 2006 01:40 To: 'Lars Westberg' Cc: gash@att.com; nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Hi Lars I think that I agree with you! However, we may just need one QSPEC parameter, say Traffic (Tocken = Bucket and Bandwidth)=20 that can be mandatory. In this way we will provide the required interoperability between the=20 QoS models. Actually this was also the conclusion that Xiaoming deduced after = studying a couple of examples. Furthermore, we could however provide the ability to QoS models to = specify which=20 QSPEC parameters should be mandatory or not. What do you think? Best regards, Georgios _____ =20 From: Lars Westberg [mailto:Lars.westberg@ericsson.com]=20 Sent: dinsdag 17 oktober 2006 8:46 To: Georgios Karagiannis Cc: gash@att.com; nsis@ietf.org Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt yes.=20 the main problem is that IETF is not the only Standardization = organization that like to discuss "bearer services". Just as an example : If we specify the those parameters, How can we use NSIS for SLAs = specified by MEF???? How can we use it for 3GPP-Qos definitiions ? In the draft I also see that we the draft specify a new bearer service. = It is not compliant to old Int.serv architecture. This is a completely new = one with new parameters like priority. I can sure that we can have a never-ending discussion about the "optimal"-set of parameters. I think we agree in beggining the working group discussion that we = should not specify any "bearer-service" because NSIS should be a modular architecture with more flexibillity than RSVP. Therefore, I am = surprised that we are doing the same mistake as in RSVP: Integrating a bearer = service definition into the NSIS-architecture. If we go this track, the QoS-part of NSIS has much less use. RSVP is in = this case significantly better in terms of performance and have the same functionality than NSIS. If have to choose I would select RSVP rather than a much more complex = three layer protocol stack. regards Lasse Georgios Karagiannis wrote: Hi Lars =20 Do you mean that the QSPEC template must not contain any mandatory (QSPEC-1) parameters? =20 =20 Best Regards, Georgios =20 =20 =20 On 10/16/2006, "Lars Westberg" wrote: =20 =20 Hi, The template seems not to be a template because the mandatory part is more or less the same as Intserv. The main idea with QoS-template was to make an modular solution that could allow flexibillity for different Qos-models =20 Therefore, I do not understand the scope of the specification. =20 I suggest that we move the major part of the parameters to a separate "Int.serv. over NSIS" specification. Int.serv. can be seen as a common bearer service. =20 regards Lasse =20 Ash, Gerald R (Jerry), ALABS wrote: =20 =20 Lars, =20 =20 You mention in the below e-mail that there are no open issues, while there is a huge discussion on the nsis mailing list regarding the QSPEC-1 parameters. =20 John can call a different consensus if he sees one (I've asked him a couple of times to do that). What I saw was =20 1. Many posts supported the QSPEC-1 concept, only one (or maybe two) I saw opposed. The opposing view was repeated *many* times (and is still being repeated) but it only counts as one opinion. 2. Many posts supported retaining the 4 QSPEC-1 parameters, only one I saw opposed. The opposing view was repeated many times. 3. There was only one opinion expressed to be able to ignore QSPEC-1 parameters. That one opinion has been repeated many times but it only counts as one opinion. =20 John asked a while ago for new opinions on these issues, that would be good if there are any *new* opinions. We don't need to hear opinions repeated that we've seen so many times. =20 I invite John once again to make a consensus call so we can move on here. I think it is time to make progress and stop repeating ourselves, we're not generating any new light in this rather endless discussion. =20 Thanks, Jerry =20 =20 =20 =20 ------=_NextPart_000_0013_01C6F2A1.D498ADB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all
 
I also support the point of view of Lars that = peak=20 bandwdith is the only parameter that can be used to provide=20 interoperability.
 
Best regards,
Georgios
 

From: Geib, Ruediger=20 [mailto:Ruediger.Geib@t-systems.com]
Sent: woensdag 18 = oktober 2006=20 10:08
To: Lars.westberg@ericsson.com
Cc:=20 nsis@ietf.org
Subject: RE: [NSIS] I-D=20 ACTION:draft-ietf-nsis-qspec-12.txt

Lasse,
 
I=20 fully support your view. *Peak Bandwidth* is sufficient as a = mandatory=20 parameter. I too expect QoS by resource reservations to be = limited to the=20 access. As soon as multiplexing effects can be exploited,=20 PCN, RMD or the like seem to be more effective than per flow = reservations. So if admission control based on resource reservations = is=20 applied, peak bandwidth is the parameter you look = for.
 
The = QOSM should=20 carry information on the DSCP(s) to be = used.
 
Regards,
 
R=FCdiger
 
 .... Inter-operabillity solved by: =
1)=20 Overprovisioning in the core such as all QoS-requirments are = solved.
2)=20 Interoperabillity for different QoS-models =3D>Peak-allocation of = bandwidth.

 ...... 
My = suggestion is=20 that the Template is changed so it's only contain optional = parameters=20 description.

regards Lasse




Georgios = Karagiannis=20 wrote:
Hi Radhika
 
I think that Jukka just suggested a very = good=20 solution to this problem!
 
Best Regards,
Georgios
 
 

From: RADHIKA.R.ROY@saic.com [mailto:RADHIKA.R.ROY@saic.com]= =20
Sent: dinsdag 17 oktober 2006 16:58
To: = Georgios=20 Karagiannis; john.loughney@nokia.com; Lars.westberg@ericsson.com=
Cc:=20 gash@att.com; nsis@ietf.org
Subject: RE:=20 [NSIS] I-D = ACTION:draft-ietf-nsis-qspec-12.txt

Georgios:

I = fear that it=20 will also not solve the basic problem of incompatibility. Please = see my=20 email. It is just too much to solve as these are still = subjective=20 interpretations and too complex to implement for clear=20 interworking.

Best=20 regards,

Radhika

From: nsis-bounces@ietf.org = [mailto:nsis-bounces@ietf.org]=20 On Behalf Of = Georgios=20 Karagiannis
Sent:=20 Tuesday, October 17, 2006 10:51 AM
To: john.loughney@nokia.com; Lars.westberg@ericsson.com=
Cc: gash@att.com; nsis@ietf.org
Subject: RE: [NSIS] I-D=20 ACTION:draft-ietf-nsis-qspec-12.txt

Hi=20 John

A = solution of=20 this can be as follows.

First = of all:=20 the QSPEC template does not specify  mandatory=20 parameters.

However, an=20 end-to-end QoS model may mandate the use of a QSPEC parameter.=20

Any = QNE that=20 suopports this end-to-end QoS model then it will have to = interpret=20

(strictly or=20 remap) this parameter. The remapping is then specified in the = end=20 -to-end QOSM draft.

Another local=20 QoS model that needs to interoperate with the end-to-end QoS = model it=20 will either

have = to=20 strictly interpret the parameter specified by the end -to- end = QoS=20 model, or to remap it. 

The = remapping=20 is also specified in the local QOSM = draft.

However, if a=20 QNE does not support the end-to-end QoS model then it will just = set the=20

NON-QOSM Hop=20 flag.

In = this way we=20 achieve both modularity and=20 interoperability.

Best=20 Regards,

Georgios

From:=20 john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20
Sent: = dinsdag 17=20 oktober 2006 16:21
To: karagian@cs.utwente.nl; Lars.westberg@ericsson.com=
Cc: gash@att.com; nsis@ietf.org
Subject: RE: [NSIS] I-D = = ACTION:draft-ietf-nsis-qspec-12.txt

Georgios,

About having=20 the QoS Models specifying manditory parameters - could you = explain how=20 we would get interoperability between two different QoS models = that=20 have different sets of manditory=20 parameters?

I = think we=20 need to have a baseline QSPEC with manditory parameters to = ensure=20 interoperability - we should have the lowest common = denominator=20 between the QoS models to ensure some way of being able to = signal=20 across multiple QoS model = deployments.

John

From: ext Georgios = Karagiannis [mailto:karagian@cs.utwente.nl]= =20
Sent: 17 = October,=20 2006 01:40
To:=20 'Lars Westberg'
Cc:=20 gash@att.com; nsis@ietf.org
Subject: RE: [NSIS] = I-D=20 = ACTION:draft-ietf-nsis-qspec-12.txt

Hi=20 Lars

I = think=20 that I agree with you!

However, we=20 may just need one QSPEC parameter, say Traffic (Tocken = Bucket and=20 Bandwidth)

that can be=20 mandatory. In this way we will provide the required = interoperability=20 between the

QoS=20 models.

Actually=20 this was also the conclusion that Xiaoming deduced after = studying a=20 couple of examples.

Furthermore,=20 we could however provide the ability to QoS models to = specify which=20

QSPEC=20 parameters should be mandatory or = not.

What do you=20 think?

Best=20 regards,

Georgios

From: Lars = Westberg [mailto:Lars.westberg@ericsson.= com]=20
Sent: = dinsdag 17=20 oktober 2006 8:46
To: Georgios=20 Karagiannis
Cc:=20 gash@att.com; nsis@ietf.org
Subject: Re: [NSIS] = I-D=20 = ACTION:draft-ietf-nsis-qspec-12.txt

yes.
the main = problem is=20 that IETF is not the only Standardization organization = that like=20 to discuss "bearer services". Just as an example :
If = we=20 specify the those parameters, How can we use NSIS for SLAs = specified by MEF????

How can we use it for 3GPP-Qos = definitiions ?


In the draft I also see  = that we=20 the draft specify a new bearer service. It is not = compliant to old=20 Int.serv architecture.  This is a completely new one = with new=20 parameters like priority.

I can sure that we can = have a=20 never-ending discussion about the "optimal"-set of=20 parameters.

I think we agree in beggining the = working group=20 discussion that we should not specify any "bearer-service" = because=20 NSIS should be a modular architecture with  more = flexibillity=20 than RSVP.  Therefore, I am surprised that we are = doing the=20 same mistake as in RSVP: Integrating a bearer service = definition=20 into the NSIS-architecture.

If we go this track, = the=20 QoS-part of NSIS has much less use. RSVP is in this case=20 significantly better in terms of performance and have the = same=20 functionality than NSIS.
If have to choose I would = select RSVP=20 rather than a much more complex  three layer protocol = stack.

regards Lasse

Georgios Karagiannis=20 wrote:

Hi =
Lars
 
Do you mean =
that the QSPEC template must not contain any =
mandatory
(QSPEC-1) =
parameters?
 
 
Best =
Regards,
Georgios
 
 
 
On =
10/16/2006, "Lars Westberg" <Lars.westberg@ericsson.com=
> wrote:
 
  =

Hi,
The template =
seems not to be a template because the mandatory part  =
is
more or less the =
same as Intserv.
The main idea with QoS-template was to make an modular solution =
that
could allow =
flexibillity for different =
Qos-models
 
Therefore, I =
do not understand the scope of the =
specification.
 
I suggest =
that we move the major part of the parameters to a =
separate
"Int.serv. over =
NSIS" specification.
Int.serv. can be seen as a common bearer =
service.
 
regards =
Lasse
 
Ash, Gerald =
R (Jerry), ALABS wrote:
 
    
Lars,
 
      
You mention =
in the below e-mail that there are no open =
issues,
while there is a =
huge discussion on the nsis mailing =
list
regarding the =
QSPEC-1 parameters.
        =

John can call a different consensus if he sees one (I've asked him =
a
couple of times =
to do that).  What I saw =
was
 
1. Many =
posts supported the QSPEC-1 concept, only one (or maybe two) =
I
saw =
opposed.  The opposing view was repeated *many* times (and is =
still
being repeated) =
but it only counts as one =
opinion.
2. Many posts =
supported retaining the 4 QSPEC-1 parameters, only one =
I
saw =
opposed.  The opposing view was repeated many =
times.
3. There was only =
one opinion expressed to be able to ignore =
QSPEC-1
parameters.  =
That one opinion has been repeated many times but it =
only
counts as one =
opinion.
 
John asked a =
while ago for new opinions on these issues, that would =
be
good if there are =
any *new* opinions.  We don't need to hear =
opinions
repeated that =
we've seen so many times.
 
I invite =
John once again to make a consensus call so we can move =
on
here.  I =
think it is time to make progress and stop repeating =
ourselves,
we're not =
generating any new light in this rather endless =
discussion.
 
Thanks,
Jerry
 
      =

 
  =
------=_NextPart_000_0013_01C6F2A1.D498ADB0-- --===============1810514194== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============1810514194==-- From nsis-bounces@ietf.org Wed Oct 18 08:41:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaAiT-00061t-JY; Wed, 18 Oct 2006 08:40:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaAiR-00061S-Uh for nsis@ietf.org; Wed, 18 Oct 2006 08:40:11 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaAiO-00074B-7L for nsis@ietf.org; Wed, 18 Oct 2006 08:40:11 -0400 Received: from mail2.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id k9ICe2NQ021404; Wed, 18 Oct 2006 14:40:02 +0200 Received: from mchp7wta.ww002.siemens.net (mchp7wta.ww002.siemens.net [139.25.131.193]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id k9ICe1Hg003550; Wed, 18 Oct 2006 14:40:02 +0200 Received: from blns00fa.ww002.siemens.net ([147.54.45.102]) by mchp7wta.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Oct 2006 14:39:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [NSIS] QSPEC-issue (GK-2) Date: Wed, 18 Oct 2006 14:39:23 +0200 Message-ID: In-Reply-To: <009801c6f1f9$32ad80a0$4c0d5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QSPEC-issue (GK-2) Thread-Index: AcbtanD6fn22GI49QTOs4tcmcnPXswEXnjhgAAeTNOAAA2Hx8AAAOZSwAAAyB+AAAC0zgAAuq9Tw From: "Kappler, Cornelia" To: "Georgios Karagiannis" , , X-OriginalArrivalTime: 18 Oct 2006 12:39:26.0026 (UTC) FILETIME=[722C8AA0:01C6F2B2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 162d87dc0b780d17da9b1934777fd451 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Georgios,=20 you are misinterpreting what I've been saying. It is incorrect that I = introduce additional parameters. For the _CL QOSM_ which, by its very nature, only can support two "QoS = classes", the only meaningful way to deal with all the different QoS = classes is to divide them in two (low / high). For another QOSM (Y.1548 = say), this may be a completely different story. In my view this is a very nice example of "providing both = interoperability and flexibility".=20 Cornelia > -----Urspr=FCngliche Nachricht----- > Von: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 > Gesendet: Dienstag, 17. Oktober 2006 16:33 > An: john.loughney@nokia.com; Kappler, Cornelia;=20 > Hannes.Tschofenig@gmx.net > Cc: nsis@ietf.org > Betreff: RE: [NSIS] QSPEC-issue (GK-2) >=20 > Hi John=20 >=20 > Okay, but this is something different then what we are=20 > curreently discussing > in this thread! > Cornelia actually proposes two additional parameters that are=20 > different=20 > then the 3 mandatory QOS classes defined already. >=20 > Please consider the following: > According to the QSPEC template a QNI can include a Y.1541=20 > class parameter.=20 > Now a QNE that receives this parameter MUST interpret it, since this > parameter is mandatory. > Consider now that the QNE can support only Diffserv.=20 > How this Diffserv QNE could interpret the Y.1541 class parameter? >=20 > Best Regards, > Georgios >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 > > Sent: dinsdag 17 oktober 2006 16:18 > > To: karagian@cs.utwente.nl; cornelia.kappler@siemens.com;=20 > > Hannes.Tschofenig@gmx.net > > Cc: nsis@ietf.org > > Subject: RE: [NSIS] QSPEC-issue (GK-2) > >=20 > > OK, so I think your point on the manditory parameters could=20 > > be classified as something like this. If we have manditory=20 > > parameters, how to map from one QoS model to another,=20 > > especially when the QoS models are using relative values -=20 > > meaning no absolute values. If all QoS Models had 3 traffic=20 > > classes - roughly high, medium and low - then it would be=20 > > very simple to handle. However, different QoS models might=20 > > have trouble to map from one model to another. > >=20 > > Is that roughly want you are saying? > >=20 > > John > >=20 > > >-----Original Message----- > > >From: ext Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > >Sent: 17 October, 2006 07:11 > > >To: Loughney John (Nokia-NRC/Helsinki);=20 > > cornelia.kappler@siemens.com;=20 > > >Hannes.Tschofenig@gmx.net > > >Cc: nsis@ietf.org > > >Subject: RE: [NSIS] QSPEC-issue (GK-2) > > > > > >Hi John > > > > > >I realy do not understand how this will solve the QoS class=20 > > remapping=20 > > >problems. > > >What is "high class" for "DSTE QoS class" and for "PHB QoS=20 > > class" and=20 > > >for > > >"Y.1541 class" > > >and the same for "low class"? > > > > > >Best regards, > > >Georgios > > > > > >> -----Original Message----- > > >> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > >> Sent: dinsdag 17 oktober 2006 16:03 > > >> To: karagian@cs.utwente.nl; cornelia.kappler@siemens.com;=20 > > >> Hannes.Tschofenig@gmx.net > > >> Cc: nsis@ietf.org > > >> Subject: RE: [NSIS] QSPEC-issue (GK-2) > > >>=20 > > >> Georgios, > > >>=20 > > >> Cornelia explained how she thought it would work with=20 > CL. I agree=20 > > >> with her that I think that should be a sufficient solutions. > > >>=20 > > >> Is your objection based upon the total number of Mandatory > > >Parameters? > > >> Too many parameters in general? > > >>=20 > > >> John > > >>=20 > > >> >-----Original Message----- > > >> >From: ext Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > >> >Sent: 17 October, 2006 05:28 > > >> >To: 'Kappler, Cornelia'; 'Hannes Tschofenig' > > >> >Cc: nsis@ietf.org > > >> >Subject: RE: [NSIS] QSPEC-issue (GK-2) > > >> > > > >> >Hi Cornelia > > >> > > > >> >Sorry, but in this way you define two new parameters and > > >> that are high > > >> >class and low class! > > >> >In addition to the 13 mandatory parameters we will add=20 > other two.=20 > > >> >Thus the QNEs will have to support 15 mandatory parameters. > > >> >Sorry but it becomes more complicated, than when just having > > >> >13 mandatory parameters. > > >> > > > >> > > > >> >Best Regards, > > >> >Georgios > > >> > > > >> > > > >> >> -----Original Message----- > > >> >> From: Kappler, Cornelia [mailto:cornelia.kappler@siemens.com] > > >> >> Sent: dinsdag 17 oktober 2006 10:52 > > >> >> To: Hannes Tschofenig; Georgios Karagiannis > > >> >> Cc: nsis@ietf.org > > >> >> Subject: AW: [NSIS] QSPEC-issue (GK-2) > > >> >>=20 > > >> >> Hi Georgios and Hannes, > > >> >>=20 > > >> >> see my previous post regarding how to handle these > > >> parameters in CL.=20 > > >> >>=20 > > >> >> The proposal for CL is that a CL QNE has an algorithm that > > >> tells it > > >> >> which QoS Class parameters are "high class" and whcih=20 > are "low=20 > > >> >> class". If they are high class, they will receive CL > > >treatment. If > > >> >> they are low class, they receive best effort. > > >> >>=20 > > >> >> This way QSPECs based on "QoS Class" QOSMs get as=20 > reasonable a=20 > > >> >> treatment as one can expect, and at the same time I dont > > >> see a CL QNE > > >> >> being overburdened by this task. > > >> >>=20 > > >> >> Cornelia > > >> >>=20 > > >> >> > -----Urspr=FCngliche Nachricht----- > > >> >> > Von: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > >> >> > Gesendet: Mittwoch, 11. Oktober 2006 21:05 > > >> >> > An: Georgios Karagiannis > > >> >> > Cc: nsis@ietf.org > > >> >> > Betreff: Re: [NSIS] QSPEC-issue (GK-2) > > >> >> >=20 > > >> >> > I support Georgios. > > >> >> >=20 > > >> >> > I think it is unrealistic to assume that Y.1541 and DSTE > > >> >> behavior (as > > >> >> > required for strictly interpreting these parameters) is > > >> >> implemented in > > >> >> > every QNE. > > >> >> >=20 > > >> >> > Ciao > > >> >> > Hannes > > >> >> >=20 > > >> >> > Georgios Karagiannis schrieb: > > >> >> > > Description of issue > > >> >> > > Change to QSPEC-2 parameter > > >> >> > >=20 > > >> >> > >=20 > > >> >> > > Submitter name: Georgios Karagiannis Submitter=20 > > email address:=20 > > >> >> > > karagian@cs.utwente.nl Date first > > >> >> > submitted: > > >> >> > > 11.10.2006 > > >> >> > > Reference: =20 > > >> >> > > Comment type: T > > >> >> > > Priority: 'S' > > >> >> > > Section: Various > > >> >> > > Rationale/Explanation of issue: > > >> >> > >=20 > > >> >> > > It is not realistic to assume that the QNI is able to > > >> know which > > >> >> > > network technologies (Diffserv, MPLS, Y.1541) are > > >> >> supported on the > > >> >> > > end-to-end path. > > >> >> > > If the "QoS Class" parameter is considered to be a > > >> >> QSPEC-1 parameter > > >> >> > > then it will mean that all QNEs located on the end-to-end > > >> >> path must > > >> >> > > support the Diffserv and MPLS and > > >> >> > Y.1541 technologies.=20 > > >> >> > > This is unrealistic. > > >> >> > >=20 > > >> >> > > Requested change: > > >> >> > > The parameter must be a QSPEC-2 parameter. > > >> >> > >=20 > > >> >> > >=20 > > >> >> > >=20 > > >> >> > > _______________________________________________ > > >> >> > > nsis mailing list > > >> >> > > nsis@ietf.org > > >> >> > > https://www1.ietf.org/mailman/listinfo/nsis > > >> >> > >=20 > > >> >> > >=20 > > >> >> >=20 > > >> >> >=20 > > >> >> > _______________________________________________ > > >> >> > nsis mailing list > > >> >> > nsis@ietf.org > > >> >> > https://www1.ietf.org/mailman/listinfo/nsis > > >> >> >=20 > > >> >>=20 > > >> > > > >> > > > >> > > > >> >_______________________________________________ > > >> >nsis mailing list > > >> >nsis@ietf.org > > >> >https://www1.ietf.org/mailman/listinfo/nsis > > >> > > > >>=20 > > >> _______________________________________________ > > >> nsis mailing list > > >> nsis@ietf.org > > >> https://www1.ietf.org/mailman/listinfo/nsis > > >>=20 > > > > > > > > > > >=20 >=20 >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 18 08:42:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaAjv-0006Ed-RR; Wed, 18 Oct 2006 08:41:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaAjv-0006EV-6k for nsis@ietf.org; Wed, 18 Oct 2006 08:41:43 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaAjt-0007IN-Kq for nsis@ietf.org; Wed, 18 Oct 2006 08:41:43 -0400 Received: from mail3.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id k9ICfdDE022515; Wed, 18 Oct 2006 14:41:39 +0200 Received: from mchp7wta.ww002.siemens.net (mchp7wta.ww002.siemens.net [139.25.131.193]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id k9ICfceF017143; Wed, 18 Oct 2006 14:41:38 +0200 Received: from blns00fa.ww002.siemens.net ([147.54.45.102]) by mchp7wta.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Oct 2006 14:41:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [NSIS] Proposal to move the QSPEC work forward Date: Wed, 18 Oct 2006 14:41:37 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Proposal to move the QSPEC work forward Thread-Index: AcbyjpkGcPqjTAUBQM682fq8rnFs0wAI+dVg From: "Kappler, Cornelia" To: "Jukka MJ Manner" , "Robert Hancock" X-OriginalArrivalTime: 18 Oct 2006 12:41:38.0465 (UTC) FILETIME=[C11D2110:01C6F2B2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jukka,=20 we've seen many emails _claiming_ that interworking through the qspec-1 = concept is not achievable. I have not seen a solid argument.=20 Cornelia=20 > -----Urspr=FCngliche Nachricht----- > Von: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI]=20 > Gesendet: Mittwoch, 18. Oktober 2006 10:20 > An: Robert Hancock > Cc: nsis@ietf.org > Betreff: RE: [NSIS] Proposal to move the QSPEC work forward >=20 >=20 > Hi Rob, >=20 > Having partipated and lately just reviewed the arguments for=20 > and against,=20 > I have not seen good examples and solutions that truly and=20 > clearly support=20 > the goal of interworking (except Georgios' comment about having only=20 > as QSPES-1). We have seen many emails that point out that=20 > interworking through the QSPEC-1 concept is _not_achievable,=20 > at least not=20 > currently - the Internet is just too broad in how ISPs and countries=20 > allow IP packets to be handled. >=20 > Thus, my proposal was to make all QOSMs at this stage (just)=20 > Informational. And once we have some common understanding of=20 > how different=20 > technologies can interwork, we can write a document about it,=20 > bringing=20 > back the concept of QSPEC-1 vs. -2, and QOSM authors, if they=20 > want to have=20 > their solution on the standards track, will need to revise=20 > their QOSMs. >=20 > IMO, this interworking debate should go to the IAB. This is a larger=20 > question that a WG can handle. The result affects the=20 > fundamentals of the=20 > Internet. >=20 > Jukka >=20 > On Wed, 18 Oct 2006, Robert Hancock wrote: >=20 > > hi, > >=20 > > 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. > >=20 > > (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.) > >=20 > > i still have yet to see anyone in this debate give any=20 > > 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. > >=20 > > robert h. > >=20 > > (*) see=20 > http://www1.ietf.org/mail-archive/web/nsis/current/msg06908.html > >=20 > > > -----Original Message----- > > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 > > > Sent: 18 October 2006 07:34 > > > To: john.loughney@nokia.com > > > Cc: Jukka MJ Manner; nsis@ietf.org > > > Subject: Re: [NSIS] Proposal to move the QSPEC work forward > > >=20 > > >=20 > > >=20 > > > Hi John > > >=20 > > > Do you agree with the proposal of Jukka? > > >=20 > > > Please see below! > > >=20 > > > Best Regards, > > > Georgios > > >=20 > > >=20 > > > On 10/17/2006, "Jukka MJ Manner" wrote: > > >=20 > > > > > > > >Hi all, > > > > > > > >If this QSPEC debate will not end soon with some kind of=20 > > > solution, in=20 > > > >order to get at least some of the QSPEC work forward, I=20 > propose to > > > > > > > >1. Make the QSPEC Template just define parameters and their=20 > > > encoding for > > > > QoS Model designers to be used. Loose the QSPEC-1 vs. QSPEC-2=20 > > > >concept. > > > > > > > >2. Move _all_ this interworking debate to another draft,=20 > > > which describes > > > > how to achieve interworking between domains implementing=20 > > > different QoS > > > > Models. > > > > > > > > > > > >We need the QSPEC Template and the object encoding rules=20 > in order to=20 > > > >get people design new QoS Models. This latter draft will=20 > probably be=20 > > > >difficult to achieve, but at least we would get the spec out=20 > > > for people=20 > > > >who are interested to design their own QoS Models. > > > > > > > >Before the latter draft is done, all QoS Model documents=20 > would be=20 > > > >Informational. Once the latter draft is done, QoS Model=20 > authors may=20 > > > >update their spec based on the interworking rules, and=20 > seek to move=20 > > > >their QoS Models to Standards Track. > > > > > > > >Jukka > > > > > > > >_______________________________________________ > > > >nsis mailing list > > > >nsis@ietf.org > > > >https://www1.ietf.org/mailman/listinfo/nsis > > >=20 > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > >=20 > >=20 > >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 18 08:59:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaB03-00021Z-U3; Wed, 18 Oct 2006 08:58:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaB03-0001xk-8N for nsis@ietf.org; Wed, 18 Oct 2006 08:58:23 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaAzz-0001rG-KU for nsis@ietf.org; Wed, 18 Oct 2006 08:58:23 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k9ICw5gn026456; Wed, 18 Oct 2006 14:58:11 +0200 (MEST) From: "Georgios Karagiannis" To: "'Kappler, Cornelia'" , , Subject: RE: [NSIS] QSPEC-issue (GK-2) Date: Wed, 18 Oct 2006 14:58:02 +0200 Message-ID: <003301c6f2b5$0f1dee60$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcbtanD6fn22GI49QTOs4tcmcnPXswEXnjhgAAeTNOAAA2Hx8AAAOZSwAAAyB+AAAC0zgAAuq9TwAACU9zA= X-Spam-Score: -5.527 () ALL_TRUSTED,AWL,BAYES_00,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Wed, 18 Oct 2006 14:58:15 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4515df9441674711565101d9d5c4f63f Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Cornelia >From what you say, I can deduce that the CL QOSM will use two=20 QoS classes that are different than the three ones (PHB Class, DSTE = class, Y.1548 Class) that are already defined in the QSPEC template and are mandatory.=20 My point is that even if the CL QOSM will not use the PHB Class, DSTE = Class, Y.1548 Class, a QNE will have to support the three classes: PHB Class, DSTE Class, = Y.1548 Class, anyway since they are mandatory. Now if the QNE would want to also support=20 the CL QOSM, in addition to the QSPEC template, then this QNE must also = be able to=20 support the two new QoS classes that will be (I suppose) defined in the = CL QOSM draft. Please inform me if my interpretation of the above is right? Best Regards, Georgios > -----Original Message----- > From: Kappler, Cornelia [mailto:cornelia.kappler@siemens.com]=20 > Sent: woensdag 18 oktober 2006 14:39 > To: Georgios Karagiannis; john.loughney@nokia.com;=20 > Hannes.Tschofenig@gmx.net > Cc: nsis@ietf.org > Subject: AW: [NSIS] QSPEC-issue (GK-2) >=20 > Georgios,=20 >=20 > you are misinterpreting what I've been saying. It is=20 > incorrect that I introduce additional parameters. >=20 > For the _CL QOSM_ which, by its very nature, only can support=20 > two "QoS classes", the only meaningful way to deal with all=20 > the different QoS classes is to divide them in two (low /=20 > high). For another QOSM (Y.1548 say), this may be a=20 > completely different story. >=20 > In my view this is a very nice example of "providing both=20 > interoperability and flexibility".=20 >=20 > Cornelia >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > Gesendet: Dienstag, 17. Oktober 2006 16:33 > > An: john.loughney@nokia.com; Kappler, Cornelia;=20 > > Hannes.Tschofenig@gmx.net > > Cc: nsis@ietf.org > > Betreff: RE: [NSIS] QSPEC-issue (GK-2) > >=20 > > Hi John > >=20 > > Okay, but this is something different then what we are curreently=20 > > discussing in this thread! > > Cornelia actually proposes two additional parameters that are=20 > > different then the 3 mandatory QOS classes defined already. > >=20 > > Please consider the following: > > According to the QSPEC template a QNI can include a Y.1541 class=20 > > parameter. > > Now a QNE that receives this parameter MUST interpret it,=20 > since this=20 > > parameter is mandatory. > > Consider now that the QNE can support only Diffserv.=20 > > How this Diffserv QNE could interpret the Y.1541 class parameter? > >=20 > > Best Regards, > > Georgios > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > > Sent: dinsdag 17 oktober 2006 16:18 > > > To: karagian@cs.utwente.nl; cornelia.kappler@siemens.com;=20 > > > Hannes.Tschofenig@gmx.net > > > Cc: nsis@ietf.org > > > Subject: RE: [NSIS] QSPEC-issue (GK-2) > > >=20 > > > OK, so I think your point on the manditory parameters could be=20 > > > classified as something like this. If we have manditory=20 > parameters,=20 > > > how to map from one QoS model to another, especially when the QoS=20 > > > models are using relative values - meaning no absolute=20 > values. If=20 > > > all QoS Models had 3 traffic classes - roughly high,=20 > medium and low=20 > > > - then it would be very simple to handle. However, different QoS=20 > > > models might have trouble to map from one model to another. > > >=20 > > > Is that roughly want you are saying? > > >=20 > > > John > > >=20 > > > >-----Original Message----- > > > >From: ext Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > >Sent: 17 October, 2006 07:11 > > > >To: Loughney John (Nokia-NRC/Helsinki); > > > cornelia.kappler@siemens.com; > > > >Hannes.Tschofenig@gmx.net > > > >Cc: nsis@ietf.org > > > >Subject: RE: [NSIS] QSPEC-issue (GK-2) > > > > > > > >Hi John > > > > > > > >I realy do not understand how this will solve the QoS class > > > remapping > > > >problems. > > > >What is "high class" for "DSTE QoS class" and for "PHB QoS > > > class" and > > > >for > > > >"Y.1541 class" > > > >and the same for "low class"? > > > > > > > >Best regards, > > > >Georgios > > > > > > > >> -----Original Message----- > > > >> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > > >> Sent: dinsdag 17 oktober 2006 16:03 > > > >> To: karagian@cs.utwente.nl; cornelia.kappler@siemens.com;=20 > > > >> Hannes.Tschofenig@gmx.net > > > >> Cc: nsis@ietf.org > > > >> Subject: RE: [NSIS] QSPEC-issue (GK-2) > > > >>=20 > > > >> Georgios, > > > >>=20 > > > >> Cornelia explained how she thought it would work with > > CL. I agree > > > >> with her that I think that should be a sufficient solutions. > > > >>=20 > > > >> Is your objection based upon the total number of Mandatory > > > >Parameters? > > > >> Too many parameters in general? > > > >>=20 > > > >> John > > > >>=20 > > > >> >-----Original Message----- > > > >> >From: ext Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > >> >Sent: 17 October, 2006 05:28 > > > >> >To: 'Kappler, Cornelia'; 'Hannes Tschofenig' > > > >> >Cc: nsis@ietf.org > > > >> >Subject: RE: [NSIS] QSPEC-issue (GK-2) > > > >> > > > > >> >Hi Cornelia > > > >> > > > > >> >Sorry, but in this way you define two new parameters and > > > >> that are high > > > >> >class and low class! > > > >> >In addition to the 13 mandatory parameters we will add > > other two.=20 > > > >> >Thus the QNEs will have to support 15 mandatory parameters. > > > >> >Sorry but it becomes more complicated, than when just having > > > >> >13 mandatory parameters. > > > >> > > > > >> > > > > >> >Best Regards, > > > >> >Georgios > > > >> > > > > >> > > > > >> >> -----Original Message----- > > > >> >> From: Kappler, Cornelia=20 > [mailto:cornelia.kappler@siemens.com] > > > >> >> Sent: dinsdag 17 oktober 2006 10:52 > > > >> >> To: Hannes Tschofenig; Georgios Karagiannis > > > >> >> Cc: nsis@ietf.org > > > >> >> Subject: AW: [NSIS] QSPEC-issue (GK-2) > > > >> >>=20 > > > >> >> Hi Georgios and Hannes, > > > >> >>=20 > > > >> >> see my previous post regarding how to handle these > > > >> parameters in CL.=20 > > > >> >>=20 > > > >> >> The proposal for CL is that a CL QNE has an algorithm that > > > >> tells it > > > >> >> which QoS Class parameters are "high class" and whcih > > are "low > > > >> >> class". If they are high class, they will receive CL > > > >treatment. If > > > >> >> they are low class, they receive best effort. > > > >> >>=20 > > > >> >> This way QSPECs based on "QoS Class" QOSMs get as > > reasonable a > > > >> >> treatment as one can expect, and at the same time I dont > > > >> see a CL QNE > > > >> >> being overburdened by this task. > > > >> >>=20 > > > >> >> Cornelia > > > >> >>=20 > > > >> >> > -----Urspr=FCngliche Nachricht----- > > > >> >> > Von: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > >> >> > Gesendet: Mittwoch, 11. Oktober 2006 21:05 > > > >> >> > An: Georgios Karagiannis > > > >> >> > Cc: nsis@ietf.org > > > >> >> > Betreff: Re: [NSIS] QSPEC-issue (GK-2) > > > >> >> >=20 > > > >> >> > I support Georgios. > > > >> >> >=20 > > > >> >> > I think it is unrealistic to assume that Y.1541 and DSTE > > > >> >> behavior (as > > > >> >> > required for strictly interpreting these parameters) is > > > >> >> implemented in > > > >> >> > every QNE. > > > >> >> >=20 > > > >> >> > Ciao > > > >> >> > Hannes > > > >> >> >=20 > > > >> >> > Georgios Karagiannis schrieb: > > > >> >> > > Description of issue > > > >> >> > > Change to QSPEC-2 parameter > > > >> >> > >=20 > > > >> >> > >=20 > > > >> >> > > Submitter name: Georgios Karagiannis Submitter > > > email address:=20 > > > >> >> > > karagian@cs.utwente.nl Date first > > > >> >> > submitted: > > > >> >> > > 11.10.2006 > > > >> >> > > Reference: =20 > > > >> >> > > Comment type: T > > > >> >> > > Priority: 'S' > > > >> >> > > Section: Various > > > >> >> > > Rationale/Explanation of issue: > > > >> >> > >=20 > > > >> >> > > It is not realistic to assume that the QNI is able to > > > >> know which > > > >> >> > > network technologies (Diffserv, MPLS, Y.1541) are > > > >> >> supported on the > > > >> >> > > end-to-end path. > > > >> >> > > If the "QoS Class" parameter is considered to be a > > > >> >> QSPEC-1 parameter > > > >> >> > > then it will mean that all QNEs located on the=20 > end-to-end > > > >> >> path must > > > >> >> > > support the Diffserv and MPLS and > > > >> >> > Y.1541 technologies.=20 > > > >> >> > > This is unrealistic. > > > >> >> > >=20 > > > >> >> > > Requested change: > > > >> >> > > The parameter must be a QSPEC-2 parameter. > > > >> >> > >=20 > > > >> >> > >=20 > > > >> >> > >=20 > > > >> >> > > _______________________________________________ > > > >> >> > > nsis mailing list > > > >> >> > > nsis@ietf.org > > > >> >> > > https://www1.ietf.org/mailman/listinfo/nsis > > > >> >> > >=20 > > > >> >> > >=20 > > > >> >> >=20 > > > >> >> >=20 > > > >> >> > _______________________________________________ > > > >> >> > nsis mailing list > > > >> >> > nsis@ietf.org > > > >> >> > https://www1.ietf.org/mailman/listinfo/nsis > > > >> >> >=20 > > > >> >>=20 > > > >> > > > > >> > > > > >> > > > > >> >_______________________________________________ > > > >> >nsis mailing list > > > >> >nsis@ietf.org > > > >> >https://www1.ietf.org/mailman/listinfo/nsis > > > >> > > > > >>=20 > > > >> _______________________________________________ > > > >> nsis mailing list > > > >> nsis@ietf.org > > > >> https://www1.ietf.org/mailman/listinfo/nsis > > > >>=20 > > > > > > > > > > > > > > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 18 09:31:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaBVV-0008AS-H6; Wed, 18 Oct 2006 09:30:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaBVU-0008AD-2l for nsis@ietf.org; Wed, 18 Oct 2006 09:30:52 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaBVQ-0007fl-FF for nsis@ietf.org; Wed, 18 Oct 2006 09:30:52 -0400 Received: from S4DE8PSAAGT.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Wed, 18 Oct 2006 15:30:35 +0200 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by S4DE8PSAAGT.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Oct 2006 15:30:35 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Proposal to move the QSPEC work forward X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 18 Oct 2006 15:30:34 +0200 Message-Id: <6439282641581441A36F7F6F83ED2ED2CBF8EE@S4DE8PSAAFQ.mitte.t-com.de> in-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Proposal to move the QSPEC work forward Thread-Index: AcbysumifCs/f1AyTWOrjH5xwwE/YgAAe9pg From: "Geib, Ruediger" To: X-OriginalArrivalTime: 18 Oct 2006 13:30:35.0491 (UTC) FILETIME=[97B7BB30:01C6F2B9] X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Cornelia, if I get the QOSPEC draft right, then the QOSM IDs must define=20 the "not strictly interpret" part of remapped QSPEC-1=20 parameters. In the case of eg. priority one domain may support=20 complete priority for a QOSM ID, while others don't at all=20 and a third may support preemption partially.=20 The QOSM ID would have to cover all possible cases of=20 QSPEC-1 parameter ID mappings. That sound like a lot of time=20 to be pushed into "what if" scenarios. What I feel to be worrying is that a box is expected to=20 touch parameters it doesn't care about. I know this behaviour as a backward compatibility support mechanism (an there it=20 is only used to indicate "don't understand"). Couldn't the=20 box just indicate what it does support/understand? I didn't read the draft completely, but if users with two=20 different QOSM's, none of which supports preemption, try=20 to set up a call between each other it will require=20 QSPEC-1 interpretation. Could you describe how they=20 indicate "no preemption" and successfully set up the call? Regards, R=FCdiger |-----Original Message----- |From: Kappler, Cornelia [mailto:cornelia.kappler@siemens.com] |Sent: Wednesday, October 18, 2006 2:42 PM |To: Jukka MJ Manner; Robert Hancock |Cc: nsis@ietf.org |Subject: AW: [NSIS] Proposal to move the QSPEC work forward | | |Hi Jukka,=20 | |we've seen many emails _claiming_ that interworking through=20 |the qspec-1 concept is not achievable. I have not seen a solid=20 |argument.=20 | |Cornelia=20 | |> -----Urspr=FCngliche Nachricht----- |> Von: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI]=20 |> Gesendet: Mittwoch, 18. Oktober 2006 10:20 |> An: Robert Hancock |> Cc: nsis@ietf.org |> Betreff: RE: [NSIS] Proposal to move the QSPEC work forward |>=20 |>=20 |> Hi Rob, |>=20 |> Having partipated and lately just reviewed the arguments for=20 |> and against,=20 |> I have not seen good examples and solutions that truly and=20 |> clearly support=20 |> the goal of interworking (except Georgios' comment about having only=20 |> as QSPES-1). We have seen many emails that point=20 |out that=20 |> interworking through the QSPEC-1 concept is _not_achievable,=20 |> at least not=20 |> currently - the Internet is just too broad in how ISPs and countries=20 |> allow IP packets to be handled. |>=20 |> Thus, my proposal was to make all QOSMs at this stage (just)=20 |> Informational. And once we have some common understanding of=20 |> how different=20 |> technologies can interwork, we can write a document about it,=20 |> bringing=20 |> back the concept of QSPEC-1 vs. -2, and QOSM authors, if they=20 |> want to have=20 |> their solution on the standards track, will need to revise=20 |> their QOSMs. |>=20 |> IMO, this interworking debate should go to the IAB. This is a larger=20 |> question that a WG can handle. The result affects the=20 |> fundamentals of the=20 |> Internet. |>=20 |> Jukka |>=20 |> On Wed, 18 Oct 2006, Robert Hancock wrote: |>=20 |> > hi, |> >=20 |> > 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. |> >=20 |> > (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.) |> >=20 |> > i still have yet to see anyone in this debate give any=20 |> > 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. |> >=20 |> > robert h. |> >=20 |> > (*) see=20 |> http://www1.ietf.org/mail-archive/web/nsis/current/msg06908.html |> >=20 |> > > -----Original Message----- |> > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 |> > > Sent: 18 October 2006 07:34 |> > > To: john.loughney@nokia.com |> > > Cc: Jukka MJ Manner; nsis@ietf.org |> > > Subject: Re: [NSIS] Proposal to move the QSPEC work forward |> > >=20 |> > >=20 |> > >=20 |> > > Hi John |> > >=20 |> > > Do you agree with the proposal of Jukka? |> > >=20 |> > > Please see below! |> > >=20 |> > > Best Regards, |> > > Georgios |> > >=20 |> > >=20 |> > > On 10/17/2006, "Jukka MJ Manner" wrote: |> > >=20 |> > > > |> > > >Hi all, |> > > > |> > > >If this QSPEC debate will not end soon with some kind of=20 |> > > solution, in=20 |> > > >order to get at least some of the QSPEC work forward, I=20 |> propose to |> > > > |> > > >1. Make the QSPEC Template just define parameters and their=20 |> > > encoding for |> > > > QoS Model designers to be used. Loose the QSPEC-1=20 |vs. QSPEC-2=20 |> > > >concept. |> > > > |> > > >2. Move _all_ this interworking debate to another draft,=20 |> > > which describes |> > > > how to achieve interworking between domains implementing=20 |> > > different QoS |> > > > Models. |> > > > |> > > > |> > > >We need the QSPEC Template and the object encoding rules=20 |> in order to=20 |> > > >get people design new QoS Models. This latter draft will=20 |> probably be=20 |> > > >difficult to achieve, but at least we would get the spec out=20 |> > > for people=20 |> > > >who are interested to design their own QoS Models. |> > > > |> > > >Before the latter draft is done, all QoS Model documents=20 |> would be=20 |> > > >Informational. Once the latter draft is done, QoS Model=20 |> authors may=20 |> > > >update their spec based on the interworking rules, and=20 |> seek to move=20 |> > > >their QoS Models to Standards Track. |> > > > |> > > >Jukka |> > > > |> > > >_______________________________________________ |> > > >nsis mailing list |> > > >nsis@ietf.org |> > > >https://www1.ietf.org/mailman/listinfo/nsis |> > >=20 |> > > _______________________________________________ |> > > nsis mailing list |> > > nsis@ietf.org |> > > https://www1.ietf.org/mailman/listinfo/nsis |> > >=20 |> >=20 |> >=20 |>=20 |> _______________________________________________ |> nsis mailing list |> nsis@ietf.org |> https://www1.ietf.org/mailman/listinfo/nsis |>=20 | |_______________________________________________ |nsis mailing list |nsis@ietf.org |https://www1.ietf.org/mailman/listinfo/nsis | _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 18 09:44:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaBhk-00012P-D1; Wed, 18 Oct 2006 09:43:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaBhi-0000xl-DJ for nsis@ietf.org; Wed, 18 Oct 2006 09:43:30 -0400 Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaBhd-0001Kk-Ry for nsis@ietf.org; Wed, 18 Oct 2006 09:43:30 -0400 Received: from 0015-its-ieg01.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx.mail.saic.com; Wed, 18 Oct 2006 09:43:17 -0400 Received: from 0015-ITS-EXBH01.us.saic.com ([10.43.229.18]) by 0015-its-ieg01.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006101809431718354 ; Wed, 18 Oct 2006 09:43:17 -0400 Received: from 0591-ITS-EXMP02.us.saic.com ([10.42.81.248]) by 0015-ITS-EXBH01.us.saic.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Oct 2006 09:43:17 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Date: Wed, 18 Oct 2006 09:43:16 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426230EC8@0591-ITS-EXMP02.us.saic.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Thread-Index: AcbxuHtQ92fBk4GyRnaw38rAcCkjiQAOXHnQAAEtkJAADLQI4AAjtwYg From: "Roy, Radhika R." To: X-OriginalArrivalTime: 18 Oct 2006 13:43:17.0459 (UTC) FILETIME=[5DE2D230:01C6F2BB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d38eb86565b1a4d8c3dba35af39014d Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2106703592==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============2106703592== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F2BB.5D97B4D6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F2BB.5D97B4D6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Chuck: =20 You will be better advised to reply with all technical points that I have provided in my all emails including John's. =20 I have no objections that Y.1541's grand QOS schemes should be addressed with all those so-called arbitrary value-based QOS classes all by itself, and we all will help it to make it happen as a stand-alone scheme. The whole world may accept what they want to use as they like in their specific values. It is nothing to do with DiffServ or RSVP.=20 =20 When it comes to interworking of Y.1541 with DiffServ, RSVP, and IntServ, it is a mixture of between water and oil. It is a simple common sense because of the fundamental properties: Implementation-specific value-based QOS parameters versus Non-Implementation-specific non-value-based QOS parameters. =20 No amount of words or twist in technical statements like high, low, or medium will be able to make it work for Interworking. =20 You will be better advised to call-off the QSPEC draft for Interworking between Y.1541, DiffServ, and DSTE parameters in the same QSPEC draft. Let Y1541 QSPEC draft be a stand-alone draft. No one will object to stand Y.1541 on its own feet using NSIS QOS signaling protocol. =20 Unless you address the root cause of all problems, nothing good will come out of it other than the messy technical debates that we are observing in this mailing list what I predicted almost 2 years ago. =20 It is a question of Interworking in standards. =20 Best regards, Radhika =20 ________________________________ From: cdvorak@research.att.com [mailto:cdvorak@research.att.com]=20 Sent: Tuesday, October 17, 2006 4:42 PM To: RADHIKA.R.ROY@saic.com Cc: nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt =20 Radhika =20 I have not been in the middle of this much, but I do want to make a point to you that may be helpful in deflecting your "anti Y.1541" theme in NSIS. =20 Your big complaint seems to be about trying to satisfy the *numerical* objectives of Y.1541. As I see it, the point for NSIS has never been to focus on those numerical objectives, but rather that the global community supports Y.1541 classes as a way to describe (and signal!!!) e2e IP QoS. =20 The idea is to enable an implementation capable of addressing the *parameters* in Y.1541 (which come from Y.1540) and the fact that Y.1541 classes involve a specific combination of parameters-whatever their numerical values. Thus NSIS should have a way of addressing the global agreement to describe IP QoS in terms of Y.1541 classes (and thus the combination of parameters) whether in practice any of the numerical values of a given class are satisfied, or not. =20 In other words, whether or not a specific class is numerically satisfied is not an issue for NSIS, but rather NSIS methods should allow one to address the need to signal any Y.1541 classes requested. =20 Regards =20 Chuck Dvorak AT&T Labs =20 ------_=_NextPart_001_01C6F2BB.5D97B4D6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Chuck:

 

You will be better advised to reply = with all technical points that I have provided in my all emails including = John’s.

 

I have no objections that = Y.1541’s grand QOS schemes should be addressed with all those so-called arbitrary = value-based QOS classes all by itself, and we all will help it to make it happen as = a stand-alone scheme. The whole world may accept what they want to use as = they like in their specific values. It is nothing to do with DiffServ or = RSVP.

 

When it comes to interworking of = Y.1541 with DiffServ, RSVP, and IntServ, it is a mixture of between water and oil. = It is a simple common sense because of the fundamental properties: Implementation-specific value-based QOS parameters versus Non-Implementation-specific non-value-based QOS = parameters.

 

No amount of words or twist in = technical statements like high, low, or medium will be able to make it work for = Interworking.

 

You will be better advised to = call-off the QSPEC draft for Interworking between Y.1541, DiffServ, and DSTE = parameters in the same QSPEC draft. Let Y1541 QSPEC draft be a stand-alone draft. No = one will object to stand Y.1541 on its own feet using NSIS QOS signaling = protocol.

 

Unless you address the root cause = of all problems, nothing good will come out of it other than the messy = technical debates that we are observing in this mailing list what I predicted = almost 2 years ago.

 

It is a question of Interworking in standards.

 

Best = regards,

Radhika

=

 

From: cdvorak@research.att.com = [mailto:cdvorak@research.att.com]
Sent: Tuesday, October = 17, 2006 4:42 PM
To: = RADHIKA.R.ROY@saic.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

 

Radhika

 

I have not been in the middle of this much, but I do = want to make a point to you that may be helpful in deflecting your “anti Y.1541” theme in NSIS.

 

Your big complaint seems to be about trying to satisfy = the *numerical* objectives of Y.1541. As I see it, the point for NSIS has = never been to focus on those numerical objectives, but rather that the global community supports Y.1541 classes as a way to describe (and signal!!!) = e2e IP QoS.

 

The idea is to enable an implementation capable of = addressing the *parameters* in Y.1541 (which come from Y.1540) and the fact that = Y.1541 classes involve a specific combination of parameters—whatever = their numerical values. Thus NSIS should have a way of addressing the global = agreement to describe IP QoS in terms of Y.1541 classes (and thus the combination = of parameters) whether in practice any of the numerical values of a given = class are satisfied, or not.

      =

In other words, whether or not a specific class is numerically satisfied is not an issue for NSIS, but rather NSIS methods = should allow one to address the need to signal any Y.1541 classes = requested.

 

Regards

 

Chuck Dvorak

AT&T Labs

 

------_=_NextPart_001_01C6F2BB.5D97B4D6-- --===============2106703592== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============2106703592==-- From nsis-bounces@ietf.org Wed Oct 18 09:46:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaBk4-0001tY-PY; Wed, 18 Oct 2006 09:45:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaBk3-0001pZ-N7 for nsis@ietf.org; Wed, 18 Oct 2006 09:45:55 -0400 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaBjz-0001di-PL for nsis@ietf.org; Wed, 18 Oct 2006 09:45:55 -0400 Received: from mail3.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id k9IDjiD4008913; Wed, 18 Oct 2006 15:45:44 +0200 Received: from mchp771a.ww002.siemens.net (mchp771a.ww002.siemens.net [139.25.131.189]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id k9IDjI3p032464; Wed, 18 Oct 2006 15:45:43 +0200 Received: from blns00fa.ww002.siemens.net ([147.54.45.102]) by mchp771a.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Oct 2006 15:45:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [NSIS] QSPEC-issue (GK-2) Date: Wed, 18 Oct 2006 15:45:17 +0200 Message-ID: In-Reply-To: <003301c6f2b5$0f1dee60$4c0d5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QSPEC-issue (GK-2) Thread-Index: AcbtanD6fn22GI49QTOs4tcmcnPXswEXnjhgAAeTNOAAA2Hx8AAAOZSwAAAyB+AAAC0zgAAuq9TwAACU9zAAAGyXoA== From: "Kappler, Cornelia" To: "Georgios Karagiannis" , , X-OriginalArrivalTime: 18 Oct 2006 13:45:20.0833 (UTC) FILETIME=[A76C3310:01C6F2BB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 73f7847c44628482de9d5f1018acf469 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Georgios,=20 thanks a lot for your mail! I would like to first step back and reconsider what we would like to = achieve ideally. Ideally, each domain implements its QOSM and no = additional mechanism beyond its QOSM (!). Also ideally, a domain = receives a reservation expressed in terms of a different QOSM, and = translates it into its own QOSM language. Now it is in a position to = just perform its normal QOSM procedures. At the same time the QNI is = happy because, while not getting exactly what it was requesting, it = receives as adequate a treatment as possible. Would you agree to this = goal? I also think the key to the matter is what does it mean to "support". = See inline. > -----Urspr=FCngliche Nachricht----- > Von: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 > Gesendet: Mittwoch, 18. Oktober 2006 14:58 > An: Kappler, Cornelia; john.loughney@nokia.com;=20 > Hannes.Tschofenig@gmx.net > Cc: nsis@ietf.org > Betreff: RE: [NSIS] QSPEC-issue (GK-2) >=20 > Hi Cornelia >=20 > From what you say, I can deduce that the CL QOSM will use two=20 > QoS classes that are different than the three ones (PHB=20 > Class, DSTE class, > Y.1548 Class) > that are already defined in the QSPEC template and are mandatory.=20 I would formulate it differently: The CL QOSM "by its nature" can only support two classes. Therefore it = _remaps_ the many QoS classes into the two it can support.=20 >=20 > My point is that even if the CL QOSM will not use the PHB=20 > Class, DSTE Class, > Y.1548 Class, > a QNE will have to support the three classes: PHB Class, DSTE=20 > Class, Y.1548 > Class, anyway > since they are mandatory. Now if the QNE would want to also support=20 > the CL QOSM, in addition to the QSPEC template, then this QNE=20 > must also be > able to=20 > support the two new QoS classes that will be (I suppose)=20 > defined in the CL > QOSM draft. >From my explanation above did it become clear, that the "support" in the = QNE for the three classes really consists in a remapping, and that the = "two new classes" are just the natural two classes provided by the CL = QOSM? So the overhead created for the QNE is minimal.=20 At the same time, from a QNI perspective, this is better than no = remapping. What do you think about this? Cornelia >=20 > Please inform me if my interpretation of the above is right? >=20 > Best Regards, > Georgios >=20 >=20 > > -----Original Message----- > > From: Kappler, Cornelia [mailto:cornelia.kappler@siemens.com]=20 > > Sent: woensdag 18 oktober 2006 14:39 > > To: Georgios Karagiannis; john.loughney@nokia.com;=20 > > Hannes.Tschofenig@gmx.net > > Cc: nsis@ietf.org > > Subject: AW: [NSIS] QSPEC-issue (GK-2) > >=20 > > Georgios,=20 > >=20 > > you are misinterpreting what I've been saying. It is=20 > > incorrect that I introduce additional parameters. > >=20 > > For the _CL QOSM_ which, by its very nature, only can support=20 > > two "QoS classes", the only meaningful way to deal with all=20 > > the different QoS classes is to divide them in two (low /=20 > > high). For another QOSM (Y.1548 say), this may be a=20 > > completely different story. > >=20 > > In my view this is a very nice example of "providing both=20 > > interoperability and flexibility".=20 > >=20 > > Cornelia > >=20 > > > -----Urspr=FCngliche Nachricht----- > > > Von: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > Gesendet: Dienstag, 17. Oktober 2006 16:33 > > > An: john.loughney@nokia.com; Kappler, Cornelia;=20 > > > Hannes.Tschofenig@gmx.net > > > Cc: nsis@ietf.org > > > Betreff: RE: [NSIS] QSPEC-issue (GK-2) > > >=20 > > > Hi John > > >=20 > > > Okay, but this is something different then what we are curreently=20 > > > discussing in this thread! > > > Cornelia actually proposes two additional parameters that are=20 > > > different then the 3 mandatory QOS classes defined already. > > >=20 > > > Please consider the following: > > > According to the QSPEC template a QNI can include a Y.1541 class=20 > > > parameter. > > > Now a QNE that receives this parameter MUST interpret it,=20 > > since this=20 > > > parameter is mandatory. > > > Consider now that the QNE can support only Diffserv.=20 > > > How this Diffserv QNE could interpret the Y.1541 class parameter? > > >=20 > > > Best Regards, > > > Georgios > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > > > Sent: dinsdag 17 oktober 2006 16:18 > > > > To: karagian@cs.utwente.nl; cornelia.kappler@siemens.com;=20 > > > > Hannes.Tschofenig@gmx.net > > > > Cc: nsis@ietf.org > > > > Subject: RE: [NSIS] QSPEC-issue (GK-2) > > > >=20 > > > > OK, so I think your point on the manditory parameters could be=20 > > > > classified as something like this. If we have manditory=20 > > parameters,=20 > > > > how to map from one QoS model to another, especially=20 > when the QoS=20 > > > > models are using relative values - meaning no absolute=20 > > values. If=20 > > > > all QoS Models had 3 traffic classes - roughly high,=20 > > medium and low=20 > > > > - then it would be very simple to handle. However,=20 > different QoS=20 > > > > models might have trouble to map from one model to another. > > > >=20 > > > > Is that roughly want you are saying? > > > >=20 > > > > John > > > >=20 > > > > >-----Original Message----- > > > > >From: ext Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > > >Sent: 17 October, 2006 07:11 > > > > >To: Loughney John (Nokia-NRC/Helsinki); > > > > cornelia.kappler@siemens.com; > > > > >Hannes.Tschofenig@gmx.net > > > > >Cc: nsis@ietf.org > > > > >Subject: RE: [NSIS] QSPEC-issue (GK-2) > > > > > > > > > >Hi John > > > > > > > > > >I realy do not understand how this will solve the QoS class > > > > remapping > > > > >problems. > > > > >What is "high class" for "DSTE QoS class" and for "PHB QoS > > > > class" and > > > > >for > > > > >"Y.1541 class" > > > > >and the same for "low class"? > > > > > > > > > >Best regards, > > > > >Georgios > > > > > > > > > >> -----Original Message----- > > > > >> From: john.loughney@nokia.com=20 > [mailto:john.loughney@nokia.com] > > > > >> Sent: dinsdag 17 oktober 2006 16:03 > > > > >> To: karagian@cs.utwente.nl; cornelia.kappler@siemens.com;=20 > > > > >> Hannes.Tschofenig@gmx.net > > > > >> Cc: nsis@ietf.org > > > > >> Subject: RE: [NSIS] QSPEC-issue (GK-2) > > > > >>=20 > > > > >> Georgios, > > > > >>=20 > > > > >> Cornelia explained how she thought it would work with > > > CL. I agree > > > > >> with her that I think that should be a sufficient solutions. > > > > >>=20 > > > > >> Is your objection based upon the total number of Mandatory > > > > >Parameters? > > > > >> Too many parameters in general? > > > > >>=20 > > > > >> John > > > > >>=20 > > > > >> >-----Original Message----- > > > > >> >From: ext Georgios Karagiannis=20 > [mailto:karagian@cs.utwente.nl] > > > > >> >Sent: 17 October, 2006 05:28 > > > > >> >To: 'Kappler, Cornelia'; 'Hannes Tschofenig' > > > > >> >Cc: nsis@ietf.org > > > > >> >Subject: RE: [NSIS] QSPEC-issue (GK-2) > > > > >> > > > > > >> >Hi Cornelia > > > > >> > > > > > >> >Sorry, but in this way you define two new parameters and > > > > >> that are high > > > > >> >class and low class! > > > > >> >In addition to the 13 mandatory parameters we will add > > > other two.=20 > > > > >> >Thus the QNEs will have to support 15 mandatory parameters. > > > > >> >Sorry but it becomes more complicated, than when just having > > > > >> >13 mandatory parameters. > > > > >> > > > > > >> > > > > > >> >Best Regards, > > > > >> >Georgios > > > > >> > > > > > >> > > > > > >> >> -----Original Message----- > > > > >> >> From: Kappler, Cornelia=20 > > [mailto:cornelia.kappler@siemens.com] > > > > >> >> Sent: dinsdag 17 oktober 2006 10:52 > > > > >> >> To: Hannes Tschofenig; Georgios Karagiannis > > > > >> >> Cc: nsis@ietf.org > > > > >> >> Subject: AW: [NSIS] QSPEC-issue (GK-2) > > > > >> >>=20 > > > > >> >> Hi Georgios and Hannes, > > > > >> >>=20 > > > > >> >> see my previous post regarding how to handle these > > > > >> parameters in CL.=20 > > > > >> >>=20 > > > > >> >> The proposal for CL is that a CL QNE has an algorithm that > > > > >> tells it > > > > >> >> which QoS Class parameters are "high class" and whcih > > > are "low > > > > >> >> class". If they are high class, they will receive CL > > > > >treatment. If > > > > >> >> they are low class, they receive best effort. > > > > >> >>=20 > > > > >> >> This way QSPECs based on "QoS Class" QOSMs get as > > > reasonable a > > > > >> >> treatment as one can expect, and at the same time I dont > > > > >> see a CL QNE > > > > >> >> being overburdened by this task. > > > > >> >>=20 > > > > >> >> Cornelia > > > > >> >>=20 > > > > >> >> > -----Urspr=FCngliche Nachricht----- > > > > >> >> > Von: Hannes Tschofenig=20 > [mailto:Hannes.Tschofenig@gmx.net] > > > > >> >> > Gesendet: Mittwoch, 11. Oktober 2006 21:05 > > > > >> >> > An: Georgios Karagiannis > > > > >> >> > Cc: nsis@ietf.org > > > > >> >> > Betreff: Re: [NSIS] QSPEC-issue (GK-2) > > > > >> >> >=20 > > > > >> >> > I support Georgios. > > > > >> >> >=20 > > > > >> >> > I think it is unrealistic to assume that Y.1541 and DSTE > > > > >> >> behavior (as > > > > >> >> > required for strictly interpreting these parameters) is > > > > >> >> implemented in > > > > >> >> > every QNE. > > > > >> >> >=20 > > > > >> >> > Ciao > > > > >> >> > Hannes > > > > >> >> >=20 > > > > >> >> > Georgios Karagiannis schrieb: > > > > >> >> > > Description of issue > > > > >> >> > > Change to QSPEC-2 parameter > > > > >> >> > >=20 > > > > >> >> > >=20 > > > > >> >> > > Submitter name: Georgios Karagiannis Submitter > > > > email address:=20 > > > > >> >> > > karagian@cs.utwente.nl Date first > > > > >> >> > submitted: > > > > >> >> > > 11.10.2006 > > > > >> >> > > Reference: =20 > > > > >> >> > > Comment type: T > > > > >> >> > > Priority: 'S' > > > > >> >> > > Section: Various > > > > >> >> > > Rationale/Explanation of issue: > > > > >> >> > >=20 > > > > >> >> > > It is not realistic to assume that the QNI is able to > > > > >> know which > > > > >> >> > > network technologies (Diffserv, MPLS, Y.1541) are > > > > >> >> supported on the > > > > >> >> > > end-to-end path. > > > > >> >> > > If the "QoS Class" parameter is considered to be a > > > > >> >> QSPEC-1 parameter > > > > >> >> > > then it will mean that all QNEs located on the=20 > > end-to-end > > > > >> >> path must > > > > >> >> > > support the Diffserv and MPLS and > > > > >> >> > Y.1541 technologies.=20 > > > > >> >> > > This is unrealistic. > > > > >> >> > >=20 > > > > >> >> > > Requested change: > > > > >> >> > > The parameter must be a QSPEC-2 parameter. > > > > >> >> > >=20 > > > > >> >> > >=20 > > > > >> >> > >=20 > > > > >> >> > > _______________________________________________ > > > > >> >> > > nsis mailing list > > > > >> >> > > nsis@ietf.org > > > > >> >> > > https://www1.ietf.org/mailman/listinfo/nsis > > > > >> >> > >=20 > > > > >> >> > >=20 > > > > >> >> >=20 > > > > >> >> >=20 > > > > >> >> > _______________________________________________ > > > > >> >> > nsis mailing list > > > > >> >> > nsis@ietf.org > > > > >> >> > https://www1.ietf.org/mailman/listinfo/nsis > > > > >> >> >=20 > > > > >> >>=20 > > > > >> > > > > > >> > > > > > >> > > > > > >> >_______________________________________________ > > > > >> >nsis mailing list > > > > >> >nsis@ietf.org > > > > >> >https://www1.ietf.org/mailman/listinfo/nsis > > > > >> > > > > > >>=20 > > > > >> _______________________________________________ > > > > >> nsis mailing list > > > > >> nsis@ietf.org > > > > >> https://www1.ietf.org/mailman/listinfo/nsis > > > > >>=20 > > > > > > > > > > > > > > > > > > >=20 > > >=20 > > >=20 > > >=20 > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > >=20 > >=20 >=20 >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 18 10:12:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaC93-00045m-3m; Wed, 18 Oct 2006 10:11:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaC91-000450-Ml for nsis@ietf.org; Wed, 18 Oct 2006 10:11:43 -0400 Received: from sbcsmtp3.sbc.com ([144.160.112.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaC8x-0005kq-BE for nsis@ietf.org; Wed, 18 Oct 2006 10:11:43 -0400 Received: from enaf.dadc.sbc.com (localhost.localdomain [127.0.0.1]) by sbcsmtp3.sbc.com (8.13.7/8.13.7) with ESMTP id k9IEBcdL001421; Wed, 18 Oct 2006 09:11:39 -0500 Received: from clph005.sldc.sbc.com (clph005.sldc.sbc.com [132.201.23.33]) by tlph033.enaf.dadc.sbc.com (8.13.7/8.13.7) with ESMTP id k9IEBasp001386; Wed, 18 Oct 2006 09:11:36 -0500 Received: from sldc.sbc.com (localhost.localdomain [127.0.0.1]) by clph005.sldc.sbc.com (8.13.7/8.13.7) with ESMTP id k9IEBaXB017191; Wed, 18 Oct 2006 09:11:36 -0500 Received: from kcclust06evs1.ugd.att.com (kcst11.ugd.att.com [135.38.164.88]) by clph005.sldc.sbc.com (8.13.7/8.13.7) with ESMTP id k9IEBTHB017134; Wed, 18 Oct 2006 09:11:30 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Proposal to move the QSPEC work forward Date: Wed, 18 Oct 2006 09:11:29 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7E6D@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <6439282641581441A36F7F6F83ED2ED2CBF8EE@S4DE8PSAAFQ.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Proposal to move the QSPEC work forward Thread-Index: AcbysumifCs/f1AyTWOrjH5xwwE/YgAAe9pgAAGnY0A= From: "Ash, Gerald R \(Jerry\), ALABS" To: "Geib, Ruediger" X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: "Ash, Gerald R \(Jerry\), ALABS" , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org > What I feel to be worrying is that a box is expected to=20 > touch parameters it doesn't care about. I know this behaviour > as a backward compatibility support mechanism (an there it=20 > is only used to indicate "don't understand"). Couldn't the=20 > box just indicate what it does support/understand? >=20 > I didn't read the draft completely, but if users with two=20 > different QOSM's, none of which supports preemption, try=20 > to set up a call between each other it will require=20 > QSPEC-1 interpretation. Could you describe how they=20 > 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 nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 18 10:37:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaCXr-0002pJ-Jg; Wed, 18 Oct 2006 10:37:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaCXq-0002ot-4M for nsis@ietf.org; Wed, 18 Oct 2006 10:37:22 -0400 Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaCXl-0001rA-Q3 for nsis@ietf.org; Wed, 18 Oct 2006 10:37:22 -0400 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx.mail.saic.com; Wed, 18 Oct 2006 10:36:57 -0400 Received: from 0015-ITS-EXBH01.us.saic.com ([10.43.229.18]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006101810365506575 ; Wed, 18 Oct 2006 10:36:55 -0400 Received: from 0591-ITS-EXMP02.us.saic.com ([10.42.81.248]) by 0015-ITS-EXBH01.us.saic.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Oct 2006 10:36:55 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Date: Wed, 18 Oct 2006 10:36:54 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426230EC9@0591-ITS-EXMP02.us.saic.com> In-Reply-To: <4535C43B.8050606@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Thread-Index: Acbye4IZ7vmeaP4vRWSoYWr8MvZn4AARbEXA From: "Roy, Radhika R." To: , X-OriginalArrivalTime: 18 Oct 2006 14:36:55.0030 (UTC) FILETIME=[DBB53160:01C6F2C2] X-Spam-Score: 0.0 (/) X-Scan-Signature: a67cdb0531fa0833bc39a420fca82ee6 Cc: gash@att.com, Georgios Karagiannis , RADHIKA.R.ROY@saic.com, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0269866602==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0269866602== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F2C2.DB6E3274" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F2C2.DB6E3274 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Lars: =20 You are right. That is why, the QOS model like DiffServ comes into picture. =20 There is another aspect of these QOS models so far the standardization is concerned. That is called interwoking between the different QOS modeling standards. For example, you have mentioned as follows: =20 Inter-operabillity solved by:=20 1) Overprovisioning in the core such as all QoS-requirments are solved. 2) Interoperabillity for different QoS-models =3D>Peak-allocation of bandwidth. =20 All the trends of QOS models have been basically like the above. =20 Recently, we also see some fertile brains have created some so-called "Implementation-specific QOS schemes" that are based on "values" of all QOS parameters. The fundamental problems are that they also called these as QOS models (instead of saying that these are some QOS "implementation" schemes, NOT QOS models). They have even convinced few folks here and there of different standard organizations that they need "interworking" between different QOS models. =20 Here the fundamental problems come. Who is kidding whom trying to mixing between water and oil?=20 =20 Best regards, Radhika ________________________________ From: lars.westberg@ericsson.com [mailto:lars.westberg@ericsson.com]=20 Sent: Wednesday, October 18, 2006 2:06 AM To: john.loughney@nokia.com Cc: Georgios Karagiannis; RADHIKA.R.ROY@saic.com; gash@att.com; nsis@ietf.org Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt =20 let's try to breifly discuss the interoperabillity problem. history:=20 >From the history we have seen a lot of different QoS-models. Most of them has no commercial value today and the typical problem is that they have over-engineered the solution. The best outcome of the engineering has been weel educated PHD-students that have made a lof of interesting thesis. In general, the interoperabillity is very simple:=20 Overprovisioning, in the same way Internet is provisioned today. Whatever QoS-requirement you have, enough spare capacity solves the problem. The only question is related to the requirement for utilization. In the backbones with low-cost per bit, Overprovisioning of the backbones seems today be the most commercially effective way to solve it. =20 However, static provisioning or PCN is yet another way to solve the bandwidth managent in the backbone if a more bandwidth efficient solution is required.=20 Therefore, the main need for signalled Qos is mainly in the access, not in the backbone. If someone need to signal QoS in the access one can easily solve it by peak-allocation. Not bandwidth efficient but it solves the interoperabillity. The same discussion as for ATM. A CBR can encapsulate a VBR-RT.=20 Inter-operabillity solved by:=20 1) Overprovisioning in the core such as all QoS-requirments are solved. 2) Interoperabillity for different QoS-models =3D>Peak-allocation of bandwidth. The major problem is that Qspec-1 doesn't make the solution future proof considering different access types and scenarios. Just as an example the current specification does not cover the QoS-requirements for UDP-lite. UDP-lite was develop for partial checksum coverage for wireless access. The two part of the payload requires different QoS-treatments: one QoS that covered by the checksum and one for the part that can accept bit-errors.=20 My suggestion is that the Template is changed so it's only contain optional parameters description. regards Lasse Georgios Karagiannis wrote: Hi Radhika =20 I think that Jukka just suggested a very good solution to this problem! =20 Best Regards, Georgios =20 =20 =20 =09 ________________________________ From: RADHIKA.R.ROY@saic.com [mailto:RADHIKA.R.ROY@saic.com]=20 Sent: dinsdag 17 oktober 2006 16:58 To: Georgios Karagiannis; john.loughney@nokia.com; Lars.westberg@ericsson.com Cc: gash@att.com; nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Georgios: =20 I fear that it will also not solve the basic problem of incompatibility. Please see my email. It is just too much to solve as these are still subjective interpretations and too complex to implement for clear interworking. =20 Best regards, Radhika =20 =09 ________________________________ From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On Behalf Of Georgios Karagiannis Sent: Tuesday, October 17, 2006 10:51 AM To: john.loughney@nokia.com; Lars.westberg@ericsson.com Cc: gash@att.com; nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt =20 Hi John =20 A solution of this can be as follows. =20 First of all: the QSPEC template does not specify mandatory parameters. =20 However, an end-to-end QoS model may mandate the use of a QSPEC parameter.=20 Any QNE that suopports this end-to-end QoS model then it will have to interpret=20 (strictly or remap) this parameter. The remapping is then specified in the end -to-end QOSM draft. =20 Another local QoS model that needs to interoperate with the end-to-end QoS model it will either=20 have to strictly interpret the parameter specified by the end -to- end QoS model, or to remap it.=20 The remapping is also specified in the local QOSM draft. =20 However, if a QNE does not support the end-to-end QoS model then it will just set the=20 NON-QOSM Hop flag.=20 In this way we achieve both modularity and interoperability. =20 Best Regards, Georgios =20 =20 =20 =20 =09 ________________________________ From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 Sent: dinsdag 17 oktober 2006 16:21 To: karagian@cs.utwente.nl; Lars.westberg@ericsson.com Cc: gash@att.com; nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Georgios, =20 About having the QoS Models specifying manditory parameters - could you explain how we would get interoperability between two different QoS models that have different sets of manditory parameters? =20 I think we need to have a baseline QSPEC with manditory parameters to ensure interoperability - we should have the lowest common denominator between the QoS models to ensure some way of being able to signal across multiple QoS model deployments. =20 John =20 =09 ________________________________ From: ext Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 Sent: 17 October, 2006 01:40 To: 'Lars Westberg' Cc: gash@att.com; nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Hi Lars =20 I think that I agree with you! =20 However, we may just need one QSPEC parameter, say Traffic (Tocken Bucket and Bandwidth)=20 that can be mandatory. In this way we will provide the required interoperability between the=20 QoS models. Actually this was also the conclusion that Xiaoming deduced after studying a couple of examples. =20 Furthermore, we could however provide the ability to QoS models to specify which=20 QSPEC parameters should be mandatory or not. What do you think? =20 Best regards, Georgios =20 =20 =20 =09 ________________________________ From: Lars Westberg [mailto:Lars.westberg@ericsson.com]=20 Sent: dinsdag 17 oktober 2006 8:46 To: Georgios Karagiannis Cc: gash@att.com; nsis@ietf.org Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt yes.=20 the main problem is that IETF is not the only Standardization organization that like to discuss "bearer services". Just as an example : If we specify the those parameters, How can we use NSIS for SLAs specified by MEF???? =09 How can we use it for 3GPP-Qos definitiions ? =09 =09 In the draft I also see that we the draft specify a new bearer service. It is not compliant to old Int.serv architecture. This is a completely new one with new parameters like priority. =09 I can sure that we can have a never-ending discussion about the "optimal"-set of parameters. =09 I think we agree in beggining the working group discussion that we should not specify any "bearer-service" because NSIS should be a modular architecture with more flexibillity than RSVP. Therefore, I am surprised that we are doing the same mistake as in RSVP: Integrating a bearer service definition into the NSIS-architecture. =09 If we go this track, the QoS-part of NSIS has much less use. RSVP is in this case significantly better in terms of performance and have the same functionality than NSIS. If have to choose I would select RSVP rather than a much more complex three layer protocol stack. =09 regards Lasse =09 Georgios Karagiannis wrote: =09 =09 =09 Hi Lars =20 Do you mean that the QSPEC template must not contain any mandatory (QSPEC-1) parameters? =20 =20 Best Regards, Georgios =20 =20 =20 On 10/16/2006, "Lars Westberg" wrote: =20 =20 Hi, The template seems not to be a template because the mandatory part is more or less the same as Intserv. The main idea with QoS-template was to make an modular solution that could allow flexibillity for different Qos-models =20 Therefore, I do not understand the scope of the specification. =20 I suggest that we move the major part of the parameters to a separate "Int.serv. over NSIS" specification. Int.serv. can be seen as a common bearer service. =20 regards Lasse =20 Ash, Gerald R (Jerry), ALABS wrote: =20 =20 Lars, =20 =20 You mention in the below e-mail that there are no open issues, while there is a huge discussion on the nsis mailing list regarding the QSPEC-1 parameters. =20 John can call a different consensus if he sees one (I've asked him a couple of times to do that). What I saw was =20 1. Many posts supported the QSPEC-1 concept, only one (or maybe two) I saw opposed. The opposing view was repeated *many* times (and is still being repeated) but it only counts as one opinion. 2. Many posts supported retaining the 4 QSPEC-1 parameters, only one I saw opposed. The opposing view was repeated many times. 3. There was only one opinion expressed to be able to ignore QSPEC-1 parameters. That one opinion has been repeated many times but it only counts as one opinion. =20 John asked a while ago for new opinions on these issues, that would be good if there are any *new* opinions. We don't need to hear opinions repeated that we've seen so many times. =20 I invite John once again to make a consensus call so we can move on here. I think it is time to make progress and stop repeating ourselves, we're not generating any new light in this rather endless discussion. =20 Thanks, Jerry =20 =20 =20 =20 ------_=_NextPart_001_01C6F2C2.DB6E3274 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Lars:

 

You are right. That is why, the QOS = model like DiffServ comes into picture.

 

There is another aspect of these = QOS models so far the standardization is concerned. That is called = interwoking between the different QOS modeling standards. For example, you have = mentioned as follows:

 

Inter-operabillity solved by:
1) Overprovisioning in the core such as all QoS-requirments are = solved.
2) Interoperabillity for different QoS-models =3D>Peak-allocation of bandwidth.

 

All the trends of QOS models have = been basically like the above.

 

Recently, we also see some fertile = brains have created some so-called “Implementation-specific QOS schemes” = that are based on “values” of all QOS parameters. The fundamental = problems are that they also called these as QOS models (instead of saying that = these are some QOS “implementation” schemes, NOT QOS models). They = have even convinced few folks here and there of different standard organizations = that they need “interworking” between different QOS = models.

 

Here the fundamental problems come. = Who is kidding whom trying to mixing between water and oil? =

 

Best = regards,

Radhika

=

From: lars.westberg@ericsson.com [mailto:lars.westberg@ericsson.com]
Sent: Wednesday, October = 18, 2006 2:06 AM
To: = john.loughney@nokia.com
Cc: Georgios Karagiannis; RADHIKA.R.ROY@saic.com; gash@att.com; nsis@ietf.org
Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

 

let's try to breifly discuss the = interoperabillity problem.
history:
>From the history we have seen a lot of different QoS-models. Most of = them has no commercial value today and the typical problem is that they have over-engineered the solution. The best outcome of the engineering has = been weel educated PHD-students that have made a lof of interesting thesis.

In general, the interoperabillity is very simple:
Overprovisioning, in the same way Internet is provisioned today. = Whatever QoS-requirement you have, enough spare capacity solves the problem. The = only question is related to the requirement for utilization.
In the backbones with low-cost per bit, Overprovisioning of the = backbones seems today be the most commercially effective way to solve it. 
However, static provisioning or PCN is yet another way to solve the = bandwidth managent in the backbone if a more bandwidth efficient solution is = required.

Therefore, the main need for signalled Qos is mainly in the access, not = in the backbone. If someone need to signal QoS in the access one can easily = solve it by peak-allocation. Not bandwidth efficient but it solves the interoperabillity. The same discussion as for ATM. A CBR can encapsulate = a VBR-RT.

Inter-operabillity solved by:
1) Overprovisioning in the core such as all QoS-requirments are = solved.
2) Interoperabillity for different QoS-models =3D>Peak-allocation of bandwidth.

The major problem is that Qspec-1 doesn't make the solution future proof considering different access types and scenarios.

Just as an example the current specification does not cover the QoS-requirements for UDP-lite. UDP-lite was develop for partial checksum coverage for wireless access. The two part of the payload requires = different QoS-treatments: one QoS that covered by the checksum and one for the = part that can accept bit-errors.

My suggestion is that the Template is changed so it's only contain = optional parameters description.

regards Lasse




Georgios Karagiannis wrote:

Hi Radhika

 

I think that Jukka just suggested a = very good solution to this problem!

 

Best = Regards,

Georgios

 

 

 

From: RADHIKA.R.ROY@saic.com [mailto:RADHIKA.R.ROY@saic.com]=
Sent: dinsdag 17 oktober = 2006 16:58
To: Georgios Karagiannis; = john.loughney@nokia.com; Lars.westberg@ericsson.com=
Cc: gash@att.com; nsis@ietf.org
Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

Georgios:=

 

I fear that it will also not solve = the basic problem of incompatibility. Please see my email. It is just too = much to solve as these are still subjective interpretations and too complex to implement for clear = interworking.

 

Best = regards,

Radhika

 

From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] = On Behalf Of Georgios = Karagiannis
Sent: Tuesday, October = 17, 2006 10:51 AM
To: john.loughney@nokia.com; Lars.westberg@ericsson.com=
Cc: gash@att.com; nsis@ietf.org
Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

 

Hi = John

 

A solution of this can be as = follows.

 

First of all: the QSPEC template = does not specify  mandatory = parameters.

 

However, an end-to-end QoS model = may mandate the use of a QSPEC parameter. =

Any QNE that suopports this = end-to-end QoS model then it will have to interpret =

(strictly or remap) this parameter. = The remapping is then specified in the end -to-end QOSM = draft.

 

Another local QoS model that needs = to interoperate with the end-to-end QoS model it will either =

have to strictly interpret the = parameter specified by the end -to- end QoS model, or to remap = it. 

The remapping is also specified in = the local QOSM draft.

 

However, if a QNE does not support = the end-to-end QoS model then it will just set the =

NON-QOSM Hop flag. =

In this way we achieve both = modularity and interoperability.

 

Best = Regards,

Georgios<= o:p>

 

 

 

 

From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
Sent: dinsdag 17 oktober = 2006 16:21
To: karagian@cs.utwente.nl; Lars.westberg@ericsson.com=
Cc: gash@att.com; nsis@ietf.org
Subject: RE: [NSIS] I-D = ACTION:draft-ietf-nsis-qspec-12.txt=

Georgios,=

 

About having the QoS Models = specifying manditory parameters - could you explain how we would get = interoperability between two different QoS models that have different sets of manditory parameters?

 

I think we need to have a baseline = QSPEC with manditory parameters to ensure interoperability - we should have = the lowest common denominator between the QoS models to ensure some way of = being able to signal across multiple QoS model = deployments.

 

John=

 

From: ext Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=
Sent: 17 October, 2006 = 01:40
To: 'Lars Westberg'
Cc: gash@att.com; nsis@ietf.org
Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt=

Hi = Lars

 

I think that I agree with = you!

 

However, we may just need one QSPEC parameter, say Traffic (Tocken Bucket and Bandwidth) =

that can be mandatory. In this way = we will provide the required interoperability between the =

QoS = models.

Actually this was also the = conclusion that Xiaoming deduced after studying a couple of = examples.

 

Furthermore, we could however = provide the ability to QoS models to specify which =

QSPEC parameters should be = mandatory or not.

What do you = think?

 

Best = regards,

Georgios<= o:p>

 

 

 

From: Lars Westberg [mailto:Lars.westberg@ericsson.= com]
Sent: dinsdag 17 oktober = 2006 8:46
To: Georgios = Karagiannis
Cc: gash@att.com; nsis@ietf.org
Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt=

yes.
the main problem is that IETF is not the only Standardization = organization that like to discuss "bearer services". Just as an example :
If we specify the those parameters, How can we use NSIS for SLAs = specified by MEF????

How can we use it for 3GPP-Qos definitiions ?


In the draft I also see  that we the draft specify a new bearer = service. It is not compliant to old Int.serv architecture.  This is a = completely new one with new parameters like priority.

I can sure that we can have a never-ending discussion about the "optimal"-set of parameters.

I think we agree in beggining the working group discussion that we = should not specify any "bearer-service" because NSIS should be a modular architecture with  more flexibillity than RSVP.  Therefore, I = am surprised that we are doing the same mistake as in RSVP: Integrating a = bearer service definition into the NSIS-architecture.

If we go this track, the QoS-part of NSIS has much less use. RSVP is in = this case significantly better in terms of performance and have the same functionality than NSIS.
If have to choose I would select RSVP rather than a much more = complex  three layer protocol stack.

regards Lasse

Georgios Karagiannis wrote:


Hi =
Lars
 
Do you mean that the QSPEC template must not =
contain any =
mandatory
(QSPEC-1) =
parameters?
 
 
Best =
Regards,
Georgios=

 
 
 
On 10/16/2006, "Lars Westberg" <Lars.westberg@ericsson.com=
> wrote:
 
  =




Hi,
The template seems not to be a template =
because the mandatory part  =
is
more or less the same as =
Intserv.
The main idea with QoS-template was to make =
an modular solution =
that
could allow flexibillity for different =
Qos-models
 
Therefore, I do not understand the scope of =
the specification.
 
I suggest that we move the major part of the =
parameters to a =
separate
"Int.serv. over NSIS" =
specification.
Int.serv. can be seen as a common bearer =
service.
 
regards =
Lasse
 
Ash, Gerald R (Jerry), ALABS =
wrote:
 
    =




Lars,
 
      =




You mention in the below e-mail that there =
are no open =
issues,
while there is a huge discussion on the nsis =
mailing list
regarding the QSPEC-1 =
parameters.
        =




John can call a different consensus if he =
sees one (I've asked him =
a
couple of times to do that).  What I saw =
was
 
1. Many posts supported the QSPEC-1 concept, =
only one (or maybe two) =
I
saw opposed.  The opposing view was =
repeated *many* times (and is =
still
being repeated) but it only counts as one =
opinion.
2. Many posts supported retaining the 4 =
QSPEC-1 parameters, only one =
I
saw opposed.  The opposing view was =
repeated many =
times.
3. There was only one opinion expressed to be =
able to ignore =
QSPEC-1
parameters.  That one opinion has been =
repeated many times but it =
only
counts as one =
opinion.
 
John asked a while ago for new opinions on =
these issues, that would =
be
good if there are any *new* opinions.  =
We don't need to hear =
opinions
repeated that we've seen so many =
times.
 
I invite John once again to make a consensus =
call so we can move =
on
here.  I think it is time to make =
progress and stop repeating =
ourselves,
we're not generating any new light in this =
rather endless =
discussion.
 
Thanks,<=
/pre>
Jerry
 
      =







 
  =
------_=_NextPart_001_01C6F2C2.DB6E3274-- --===============0269866602== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0269866602==-- From nsis-bounces@ietf.org Wed Oct 18 11:23:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaDFM-0007Iw-Ve; Wed, 18 Oct 2006 11:22:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaDFL-0007Ek-Ap for nsis@ietf.org; Wed, 18 Oct 2006 11:22:19 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaDFH-00037e-KK for nsis@ietf.org; Wed, 18 Oct 2006 11:22:19 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k9IFLwfg014880; Wed, 18 Oct 2006 17:22:07 +0200 (MEST) From: "Georgios Karagiannis" To: "'Kappler, Cornelia'" , , Subject: RE: [NSIS] QSPEC-issue (GK-2) Date: Wed, 18 Oct 2006 17:21:56 +0200 Message-ID: <003901c6f2c9$2b960c80$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcbtanD6fn22GI49QTOs4tcmcnPXswEXnjhgAAeTNOAAA2Hx8AAAOZSwAAAyB+AAAC0zgAAuq9TwAACU9zAAAGyXoAABnLgw X-Spam-Score: -5.526 () ALL_TRUSTED,AWL,BAYES_00,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Wed, 18 Oct 2006 17:22:11 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 819069d28e3cfe534e22b502261ce83f Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Cornelia Please consider the observation made by Lars.=20 At the moment the QSPEC template, defines a bearer which requires 13 mandatory parameters. This is independently of the QOSMs that=20 NSIS will have to support. This is much heavier than=20 what RSVP requires from a router that supports RSVP. Now coming back to your e-mail, I still do not understand what these two additional parameters are used for. You mention that they are = used for remapping, but for remapping of what? How a QNE can remap the to =20 by using these two CL-QOSM classes? This thread explains that the 3 QOS class mandatory parameters cannot be = implemented by all QNEs, because this will mean that all these QNEs=20 must support Diffserv and MPLS and Y.1541. What is your opinion on this? Best Regards, Georgios =20 > -----Original Message----- > From: Kappler, Cornelia [mailto:cornelia.kappler@siemens.com]=20 > Sent: woensdag 18 oktober 2006 15:45 > To: Georgios Karagiannis; john.loughney@nokia.com;=20 > Hannes.Tschofenig@gmx.net > Cc: nsis@ietf.org > Subject: AW: [NSIS] QSPEC-issue (GK-2) >=20 > Hi Georgios,=20 >=20 > thanks a lot for your mail! >=20 > I would like to first step back and reconsider what we would=20 > like to achieve ideally. Ideally, each domain implements its=20 > QOSM and no additional mechanism beyond its QOSM (!). Also=20 > ideally, a domain receives a reservation expressed in terms=20 > of a different QOSM, and translates it into its own QOSM=20 > language. Now it is in a position to just perform its normal=20 > QOSM procedures. At the same time the QNI is happy because,=20 > while not getting exactly what it was requesting, it receives=20 > as adequate a treatment as possible. Would you agree to this goal? >=20 > I also think the key to the matter is what does it mean to=20 > "support". See inline. >=20 >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > Gesendet: Mittwoch, 18. Oktober 2006 14:58 > > An: Kappler, Cornelia; john.loughney@nokia.com;=20 > > Hannes.Tschofenig@gmx.net > > Cc: nsis@ietf.org > > Betreff: RE: [NSIS] QSPEC-issue (GK-2) > >=20 > > Hi Cornelia > >=20 > > From what you say, I can deduce that the CL QOSM will use two QoS=20 > > classes that are different than the three ones (PHB Class,=20 > DSTE class, > > Y.1548 Class) > > that are already defined in the QSPEC template and are mandatory.=20 >=20 > I would formulate it differently: > The CL QOSM "by its nature" can only support two classes.=20 > Therefore it _remaps_ the many QoS classes into the two it=20 > can support.=20 >=20 > >=20 > > My point is that even if the CL QOSM will not use the PHB=20 > Class, DSTE=20 > > Class, > > Y.1548 Class, > > a QNE will have to support the three classes: PHB Class,=20 > DSTE Class,=20 > > Y.1548 Class, anyway since they are mandatory. Now if the QNE would=20 > > want to also support the CL QOSM, in addition to the QSPEC=20 > template,=20 > > then this QNE must also be able to support the two new QoS classes=20 > > that will be (I suppose) defined in the CL QOSM draft. >=20 > >From my explanation above did it become clear, that the=20 > "support" in the QNE for the three classes really consists in=20 > a remapping, and that the "two new classes" are just the=20 > natural two classes provided by the CL QOSM? So the overhead=20 > created for the QNE is minimal.=20 >=20 > At the same time, from a QNI perspective, this is better than=20 > no remapping. >=20 > What do you think about this? >=20 > Cornelia >=20 >=20 > >=20 > > Please inform me if my interpretation of the above is right? > >=20 > > Best Regards, > > Georgios > >=20 > >=20 > > > -----Original Message----- > > > From: Kappler, Cornelia [mailto:cornelia.kappler@siemens.com] > > > Sent: woensdag 18 oktober 2006 14:39 > > > To: Georgios Karagiannis; john.loughney@nokia.com;=20 > > > Hannes.Tschofenig@gmx.net > > > Cc: nsis@ietf.org > > > Subject: AW: [NSIS] QSPEC-issue (GK-2) > > >=20 > > > Georgios, > > >=20 > > > you are misinterpreting what I've been saying. It is=20 > incorrect that=20 > > > I introduce additional parameters. > > >=20 > > > For the _CL QOSM_ which, by its very nature, only can support two=20 > > > "QoS classes", the only meaningful way to deal with all the=20 > > > different QoS classes is to divide them in two (low / high). For=20 > > > another QOSM (Y.1548 say), this may be a completely=20 > different story. > > >=20 > > > In my view this is a very nice example of "providing both=20 > > > interoperability and flexibility". > > >=20 > > > Cornelia > > >=20 > > > > -----Urspr=FCngliche Nachricht----- > > > > Von: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > > Gesendet: Dienstag, 17. Oktober 2006 16:33 > > > > An: john.loughney@nokia.com; Kappler, Cornelia;=20 > > > > Hannes.Tschofenig@gmx.net > > > > Cc: nsis@ietf.org > > > > Betreff: RE: [NSIS] QSPEC-issue (GK-2) > > > >=20 > > > > Hi John > > > >=20 > > > > Okay, but this is something different then what we are=20 > curreently=20 > > > > discussing in this thread! > > > > Cornelia actually proposes two additional parameters that are=20 > > > > different then the 3 mandatory QOS classes defined already. > > > >=20 > > > > Please consider the following: > > > > According to the QSPEC template a QNI can include a=20 > Y.1541 class=20 > > > > parameter. > > > > Now a QNE that receives this parameter MUST interpret it, > > > since this > > > > parameter is mandatory. > > > > Consider now that the QNE can support only Diffserv.=20 > > > > How this Diffserv QNE could interpret the Y.1541 class=20 > parameter? > > > >=20 > > > > Best Regards, > > > > Georgios > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > > -----Original Message----- > > > > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > > > > Sent: dinsdag 17 oktober 2006 16:18 > > > > > To: karagian@cs.utwente.nl; cornelia.kappler@siemens.com;=20 > > > > > Hannes.Tschofenig@gmx.net > > > > > Cc: nsis@ietf.org > > > > > Subject: RE: [NSIS] QSPEC-issue (GK-2) > > > > >=20 > > > > > OK, so I think your point on the manditory parameters=20 > could be=20 > > > > > classified as something like this. If we have manditory > > > parameters, > > > > > how to map from one QoS model to another, especially > > when the QoS > > > > > models are using relative values - meaning no absolute > > > values. If > > > > > all QoS Models had 3 traffic classes - roughly high, > > > medium and low > > > > > - then it would be very simple to handle. However, > > different QoS > > > > > models might have trouble to map from one model to another. > > > > >=20 > > > > > Is that roughly want you are saying? > > > > >=20 > > > > > John > > > > >=20 > > > > > >-----Original Message----- > > > > > >From: ext Georgios Karagiannis=20 > [mailto:karagian@cs.utwente.nl] > > > > > >Sent: 17 October, 2006 07:11 > > > > > >To: Loughney John (Nokia-NRC/Helsinki); > > > > > cornelia.kappler@siemens.com; > > > > > >Hannes.Tschofenig@gmx.net > > > > > >Cc: nsis@ietf.org > > > > > >Subject: RE: [NSIS] QSPEC-issue (GK-2) > > > > > > > > > > > >Hi John > > > > > > > > > > > >I realy do not understand how this will solve the QoS class > > > > > remapping > > > > > >problems. > > > > > >What is "high class" for "DSTE QoS class" and for "PHB QoS > > > > > class" and > > > > > >for > > > > > >"Y.1541 class" > > > > > >and the same for "low class"? > > > > > > > > > > > >Best regards, > > > > > >Georgios > > > > > > > > > > > >> -----Original Message----- > > > > > >> From: john.loughney@nokia.com > > [mailto:john.loughney@nokia.com] > > > > > >> Sent: dinsdag 17 oktober 2006 16:03 > > > > > >> To: karagian@cs.utwente.nl; cornelia.kappler@siemens.com;=20 > > > > > >> Hannes.Tschofenig@gmx.net > > > > > >> Cc: nsis@ietf.org > > > > > >> Subject: RE: [NSIS] QSPEC-issue (GK-2) > > > > > >>=20 > > > > > >> Georgios, > > > > > >>=20 > > > > > >> Cornelia explained how she thought it would work with > > > > CL. I agree > > > > > >> with her that I think that should be a sufficient=20 > solutions. > > > > > >>=20 > > > > > >> Is your objection based upon the total number of Mandatory > > > > > >Parameters? > > > > > >> Too many parameters in general? > > > > > >>=20 > > > > > >> John > > > > > >>=20 > > > > > >> >-----Original Message----- > > > > > >> >From: ext Georgios Karagiannis > > [mailto:karagian@cs.utwente.nl] > > > > > >> >Sent: 17 October, 2006 05:28 > > > > > >> >To: 'Kappler, Cornelia'; 'Hannes Tschofenig' > > > > > >> >Cc: nsis@ietf.org > > > > > >> >Subject: RE: [NSIS] QSPEC-issue (GK-2) > > > > > >> > > > > > > >> >Hi Cornelia > > > > > >> > > > > > > >> >Sorry, but in this way you define two new parameters and > > > > > >> that are high > > > > > >> >class and low class! > > > > > >> >In addition to the 13 mandatory parameters we will add > > > > other two.=20 > > > > > >> >Thus the QNEs will have to support 15 mandatory=20 > parameters. > > > > > >> >Sorry but it becomes more complicated, than when=20 > just having > > > > > >> >13 mandatory parameters. > > > > > >> > > > > > > >> > > > > > > >> >Best Regards, > > > > > >> >Georgios > > > > > >> > > > > > > >> > > > > > > >> >> -----Original Message----- > > > > > >> >> From: Kappler, Cornelia > > > [mailto:cornelia.kappler@siemens.com] > > > > > >> >> Sent: dinsdag 17 oktober 2006 10:52 > > > > > >> >> To: Hannes Tschofenig; Georgios Karagiannis > > > > > >> >> Cc: nsis@ietf.org > > > > > >> >> Subject: AW: [NSIS] QSPEC-issue (GK-2) > > > > > >> >>=20 > > > > > >> >> Hi Georgios and Hannes, > > > > > >> >>=20 > > > > > >> >> see my previous post regarding how to handle these > > > > > >> parameters in CL.=20 > > > > > >> >>=20 > > > > > >> >> The proposal for CL is that a CL QNE has an=20 > algorithm that > > > > > >> tells it > > > > > >> >> which QoS Class parameters are "high class" and whcih > > > > are "low > > > > > >> >> class". If they are high class, they will receive CL > > > > > >treatment. If > > > > > >> >> they are low class, they receive best effort. > > > > > >> >>=20 > > > > > >> >> This way QSPECs based on "QoS Class" QOSMs get as > > > > reasonable a > > > > > >> >> treatment as one can expect, and at the same time I dont > > > > > >> see a CL QNE > > > > > >> >> being overburdened by this task. > > > > > >> >>=20 > > > > > >> >> Cornelia > > > > > >> >>=20 > > > > > >> >> > -----Urspr=FCngliche Nachricht----- > > > > > >> >> > Von: Hannes Tschofenig > > [mailto:Hannes.Tschofenig@gmx.net] > > > > > >> >> > Gesendet: Mittwoch, 11. Oktober 2006 21:05 > > > > > >> >> > An: Georgios Karagiannis > > > > > >> >> > Cc: nsis@ietf.org > > > > > >> >> > Betreff: Re: [NSIS] QSPEC-issue (GK-2) > > > > > >> >> >=20 > > > > > >> >> > I support Georgios. > > > > > >> >> >=20 > > > > > >> >> > I think it is unrealistic to assume that=20 > Y.1541 and DSTE > > > > > >> >> behavior (as > > > > > >> >> > required for strictly interpreting these=20 > parameters) is > > > > > >> >> implemented in > > > > > >> >> > every QNE. > > > > > >> >> >=20 > > > > > >> >> > Ciao > > > > > >> >> > Hannes > > > > > >> >> >=20 > > > > > >> >> > Georgios Karagiannis schrieb: > > > > > >> >> > > Description of issue > > > > > >> >> > > Change to QSPEC-2 parameter > > > > > >> >> > >=20 > > > > > >> >> > >=20 > > > > > >> >> > > Submitter name: Georgios Karagiannis Submitter > > > > > email address:=20 > > > > > >> >> > > karagian@cs.utwente.nl Date first > > > > > >> >> > submitted: > > > > > >> >> > > 11.10.2006 > > > > > >> >> > > Reference: =20 > > > > > >> >> > > Comment type: T > > > > > >> >> > > Priority: 'S' > > > > > >> >> > > Section: Various > > > > > >> >> > > Rationale/Explanation of issue: > > > > > >> >> > >=20 > > > > > >> >> > > It is not realistic to assume that the QNI=20 > is able to > > > > > >> know which > > > > > >> >> > > network technologies (Diffserv, MPLS, Y.1541) are > > > > > >> >> supported on the > > > > > >> >> > > end-to-end path. > > > > > >> >> > > If the "QoS Class" parameter is considered to be a > > > > > >> >> QSPEC-1 parameter > > > > > >> >> > > then it will mean that all QNEs located on the > > > end-to-end > > > > > >> >> path must > > > > > >> >> > > support the Diffserv and MPLS and > > > > > >> >> > Y.1541 technologies.=20 > > > > > >> >> > > This is unrealistic. > > > > > >> >> > >=20 > > > > > >> >> > > Requested change: > > > > > >> >> > > The parameter must be a QSPEC-2=20 > parameter. > > > > > >> >> > >=20 > > > > > >> >> > >=20 > > > > > >> >> > >=20 > > > > > >> >> > > _______________________________________________ > > > > > >> >> > > nsis mailing list > > > > > >> >> > > nsis@ietf.org > > > > > >> >> > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > >> >> > >=20 > > > > > >> >> > >=20 > > > > > >> >> >=20 > > > > > >> >> >=20 > > > > > >> >> > _______________________________________________ > > > > > >> >> > nsis mailing list > > > > > >> >> > nsis@ietf.org > > > > > >> >> > https://www1.ietf.org/mailman/listinfo/nsis > > > > > >> >> >=20 > > > > > >> >>=20 > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> >_______________________________________________ > > > > > >> >nsis mailing list > > > > > >> >nsis@ietf.org > > > > > >> >https://www1.ietf.org/mailman/listinfo/nsis > > > > > >> > > > > > > >>=20 > > > > > >> _______________________________________________ > > > > > >> nsis mailing list > > > > > >> nsis@ietf.org > > > > > >> https://www1.ietf.org/mailman/listinfo/nsis > > > > > >>=20 > > > > > > > > > > > > > > > > > > > > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > nsis mailing list > > > > nsis@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > >=20 > > >=20 > >=20 > >=20 > >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 18 11:24:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaDGp-0000Wi-IC; Wed, 18 Oct 2006 11:23:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaDGn-0000Vp-QV for nsis@ietf.org; Wed, 18 Oct 2006 11:23:49 -0400 Received: from moutng.kundenserver.de ([212.227.126.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaDGk-0003XM-Do for nsis@ietf.org; Wed, 18 Oct 2006 11:23:49 -0400 Received: from [84.163.50.13] (helo=alanis.mafr.de) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis), id 0MKwtQ-1GaDGc1m75-0003Tx; Wed, 18 Oct 2006 17:23:39 +0200 Received: by alanis.mafr.de (Postfix, from userid 1000) id 8C4D75E824B; Wed, 18 Oct 2006 17:23:28 +0200 (CEST) Date: Wed, 18 Oct 2006 17:23:28 +0200 From: Matthias Friedrich To: nsis@ietf.org Message-ID: <20061018152328.GA3034@mafr.de> Mail-Followup-To: nsis@ietf.org, jmanner@cs.Helsinki.FI MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 X-Provags-ID: kundenserver.de abuse@kundenserver.de login:b369618fd1a3462119ba5a921f6f235b X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: jmanner@cs.Helsinki.FI Subject: [NSIS] NATFW+AUTH_SESSION: Scenarios with multiple authorization tokens X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, I think one AUTH_SESSION object isn't enough. Consider the following scenario, for example: A trusted party inside the NR's domain ("receiver domain") issues an autorization token (in AUTH_SESSION syntax). It is passed to the NI which has to include it in CREATE messages. Otherwise the NFs inside the receiver domain won't let the message pass. Now suppose the sender domain also relies on AUTH_SESSION objects. Local NFs only accept messages if they contain authorization tokens issued by a trusted party from the sender domain. The usage of a token has the advantage that it can be granted on a user basis. In contrast, an NF querying a policy server based on a NATFW message has no user information available and can only make a decision based on addresses. So we have two tokens (and thus two AUTH_SESSION objects) but only one ID, according to draft-manner-nsis-nslp-auth-01, Section 7. To cover this use case, I think we either have to assign multiple IDs or extend AUTH_SESSION to carry multiple (authorizing entity, signature) pairs. Regards, Matthias _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 18 12:19:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaE7h-00045V-Kx; Wed, 18 Oct 2006 12:18:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaE7g-00045J-SS for nsis@ietf.org; Wed, 18 Oct 2006 12:18:28 -0400 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaE7c-00005N-Af for nsis@ietf.org; Wed, 18 Oct 2006 12:18:28 -0400 Received: from S4DE8PSAAGT.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Wed, 18 Oct 2006 17:09:55 +0200 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by S4DE8PSAAGT.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Oct 2006 17:09:00 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Proposal to move the QSPEC work forward X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 18 Oct 2006 17:08:59 +0200 Message-Id: <6439282641581441A36F7F6F83ED2ED2CBF8F0@S4DE8PSAAFQ.mitte.t-com.de> in-reply-to: <9473683187ADC049A855ED2DA739ABCA0DDC7E6D@KCCLUST06EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Proposal to move the QSPEC work forward Thread-Index: AcbywKJ3UXRDJ772QOqamLbMkK5P9AAAmzRg From: "Geib, Ruediger" To: X-OriginalArrivalTime: 18 Oct 2006 15:09:00.0153 (UTC) FILETIME=[572BA690:01C6F2C7] X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Jerry, thanks for the response, after reading chapter 4 of the draft again I'd like=20 to ask others whether they have trouble in understanding=20 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."=20 I now understand the above. Maybe "populated" or "present" or=20 "applied" may be better than "existing". The sentence continues:=20 "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=20 I don't get it by just reading. As I understood after our dialogue,=20 the above says that those QSPEC-1 parameters which are populated due to=20 a particular QOSM specification (and that may only be a subset of all=20 QSPEC-1 parameters defined by your draft) must be remapped following=20 the rules determined by your draft. The particular remapping behaviour is determined by the specifcication of the QOSM executing the=20 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=20 to your draft. If this QOSMa interprets more complex QOSMb, it=20 should tell QOSMb what it doesn't support, if the authors of=20 QOSMa have specified that. The latter still worries=20 me. But you too don't seem to assume that anybody will try to=20 specify all possible interworkings when drafting a QOSM. The=20 default behaviour without specified interworking may also be "release" then (or a less stringent interpretation as=20 demanded by your draft). Is that correct too? Regards,=20 Rudiger |-----Original Message----- |From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] |Sent: Wednesday, October 18, 2006 4:11 PM |To: Geib, Rudiger |Cc: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org |Subject: RE: [NSIS] Proposal to move the QSPEC work forward | | |> What I feel to be worrying is that a box is expected to=20 |> touch parameters it doesn't care about. I know this behaviour |> as a backward compatibility support mechanism (an there it=20 |> is only used to indicate "don't understand"). Couldn't the=20 |> box just indicate what it does support/understand? |>=20 |> I didn't read the draft completely, but if users with two=20 |> different QOSM's, none of which supports preemption, try=20 |> to set up a call between each other it will require=20 |> QSPEC-1 interpretation. Could you describe how they=20 |> 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=20 |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 |nsis@ietf.org |https://www1.ietf.org/mailman/listinfo/nsis | _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 18 14:16:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaFxl-0001qg-0r; Wed, 18 Oct 2006 14:16:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaFxk-0001qa-6R for nsis@ietf.org; Wed, 18 Oct 2006 14:16:20 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaFxb-0008Si-Ae for nsis@ietf.org; Wed, 18 Oct 2006 14:16:20 -0400 Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id k9IIXoKj006546; Wed, 18 Oct 2006 13:33:53 -0500 Received: from eusrcmw740.eamcs.ericsson.se ([138.85.77.40]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Oct 2006 13:15:48 -0500 Received: from [142.133.72.102] ([142.133.72.102]) by eusrcmw740.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Oct 2006 13:15:47 -0500 Message-ID: <45366F47.6040200@ericsson.com> Date: Wed, 18 Oct 2006 14:15:35 -0400 From: Stephane Ouellette User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: Georgios Karagiannis Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt References: <001201c6f291$110fddb0$4c0d5982@dynamic.ewi.utwente.nl> In-Reply-To: <001201c6f291$110fddb0$4c0d5982@dynamic.ewi.utwente.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-OriginalArrivalTime: 18 Oct 2006 18:15:47.0630 (UTC) FILETIME=[6F58ECE0:01C6F2E1] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by imr2.ericy.com id k9IIXoKj006546 X-Spam-Score: 0.1 (/) X-Scan-Signature: bdfdd9dd835c9bb499f7c92933fef080 Cc: Lars.westberg@ericsson.com, nsis@ietf.org, "'Geib, Ruediger'" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, I also support Lars' point of view. Any other combination of Qos=20 parameters will lead to incompatibilities with existing or future QoS=20 models. Regards, Stephane. Georgios Karagiannis wrote: > Hi all > =20 > I also support the point of view of Lars that peak bandwdith is the onl= y=20 > parameter that can be used to provide interoperability. > =20 > Best regards, > Georgios > =20 >=20 > -------------------------------------------------------------------= ----- > *From:* Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > *Sent:* woensdag 18 oktober 2006 10:08 > *To:* Lars.westberg@ericsson.com > *Cc:* nsis@ietf.org > *Subject:* RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt >=20 > Lasse, > =20 > I fully support your view. *Peak Bandwidth* is sufficient as a > mandatory parameter. I too expect QoS by resource reservations to b= e > limited to the access. As soon as multiplexing effects can be > exploited, PCN, RMD or the like seem to be more effective than per > flow reservations. So if admission control based on resource > reservations is applied, peak bandwidth is the parameter you look f= or. > =20 > The QOSM should carry information on the DSCP(s) to be used. > =20 > Regards, > =20 > R=FCdiger > =20 >=20 > .... Inter-operabillity solved by: > 1) Overprovisioning in the core such as all QoS-requirments are > solved. > 2) Interoperabillity for different QoS-models =3D>Peak-allocati= on > of bandwidth. >=20 > ......=20 > My suggestion is that the Template is changed so it's only > contain optional parameters description. >=20 > regards Lasse >=20 >=20 >=20 >=20 > Georgios Karagiannis wrote: >> Hi Radhika >> =20 >> I think that Jukka just suggested a very good solution to this >> problem! >> =20 >> Best Regards, >> Georgios >> =20 >> =20 >> >> ----------------------------------------------------------= -------------- >> *From:* RADHIKA.R.ROY@saic.com >> [mailto:RADHIKA.R.ROY@saic.com] >> *Sent:* dinsdag 17 oktober 2006 16:58 >> *To:* Georgios Karagiannis; john.loughney@nokia.com; >> Lars.westberg@ericsson.com >> *Cc:* gash@att.com; nsis@ietf.org >> *Subject:* RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.= txt >> >> Georgios: >> >> I fear that it will also not solve the basic problem of >> incompatibility. Please see my email. It is just too much >> to solve as these are still subjective interpretations and >> too complex to implement for clear interworking. >> >> Best regards, >> >> Radhika >> >> ----------------------------------------------------------= -------------- >> >> *From:* nsis-bounces@ietf.org >> [mailto:nsis-bounces@ietf.org] *On Behalf Of *Georgios >> Karagiannis >> *Sent:* Tuesday, October 17, 2006 10:51 AM >> *To:* john.loughney@nokia.com; Lars.westberg@ericsson.com >> *Cc:* gash@att.com; nsis@ietf.org >> *Subject:* RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.= txt >> >> Hi John >> >> A solution of this can be as follows. >> >> First of all: the QSPEC template does not specify >> mandatory parameters. >> >> However, an end-to-end QoS model may mandate the use of a >> QSPEC parameter. >> >> Any QNE that suopports this end-to-end QoS model then it >> will have to interpret >> >> (strictly or remap) this parameter. The remapping is then >> specified in the end -to-end QOSM draft. >> >> Another local QoS model that needs to interoperate with >> the end-to-end QoS model it will either >> >> have to strictly interpret the parameter specified by the >> end -to- end QoS model, or to remap it.=20 >> >> The remapping is also specified in the local QOSM draft. >> >> However, if a QNE does not support the end-to-end QoS >> model then it will just set the >> >> NON-QOSM Hop flag. >> >> In this way we achieve both modularity and interoperabilit= y. >> >> Best Regards, >> >> Georgios >> >> ------------------------------------------------------= ------------------ >> >> *From:* john.loughney@nokia.com >> [mailto:john.loughney@nokia.com] >> *Sent:* dinsdag 17 oktober 2006 16:21 >> *To:* karagian@cs.utwente.nl; Lars.westberg@ericsson.c= om >> *Cc:* gash@att.com; nsis@ietf.org >> *Subject:* RE: [NSIS] I-D >> ACTION:draft-ietf-nsis-qspec-12.txt >> >> Georgios, >> >> About having the QoS Models specifying manditory >> parameters - could you explain how we would get >> interoperability between two different QoS models that >> have different sets of manditory parameters? >> >> I think we need to have a baseline QSPEC with >> manditory parameters to ensure interoperability - we >> should have the lowest common denominator between the >> QoS models to ensure some way of being able to signal >> across multiple QoS model deployments. >> >> John >> >> --------------------------------------------------= ---------------------- >> >> *From:* ext Georgios Karagiannis >> [mailto:karagian@cs.utwente.nl] >> *Sent:* 17 October, 2006 01:40 >> *To:* 'Lars Westberg' >> *Cc:* gash@att.com; nsis@ietf.org >> *Subject:* RE: [NSIS] I-D >> ACTION:draft-ietf-nsis-qspec-12.txt >> >> Hi Lars >> >> I think that I agree with you! >> >> However, we may just need one QSPEC parameter, say >> Traffic (Tocken Bucket and Bandwidth) >> >> that can be mandatory. In this way we will provide >> the required interoperability between the >> >> QoS models. >> >> Actually this was also the conclusion that >> Xiaoming deduced after studying a couple of exampl= es. >> >> Furthermore, we could however provide the ability >> to QoS models to specify which >> >> QSPEC parameters should be mandatory or not. >> >> What do you think? >> >> Best regards, >> >> Georgios >> >> ----------------------------------------------= -------------------------- >> >> *From:* Lars Westberg >> [mailto:Lars.westberg@ericsson.com] >> *Sent:* dinsdag 17 oktober 2006 8:46 >> *To:* Georgios Karagiannis >> *Cc:* gash@att.com; nsis@ietf.org >> *Subject:* Re: [NSIS] I-D >> ACTION:draft-ietf-nsis-qspec-12.txt >> >> yes. >> the main problem is that IETF is not the only >> Standardization organization that like to >> discuss "bearer services". Just as an example = : >> If we specify the those parameters, How can we >> use NSIS for SLAs specified by MEF???? >> >> How can we use it for 3GPP-Qos definitiions ? >> >> >> In the draft I also see that we the draft >> specify a new bearer service. It is not >> compliant to old Int.serv architecture. This >> is a completely new one with new parameters >> like priority. >> >> I can sure that we can have a never-ending >> discussion about the "optimal"-set of paramete= rs. >> >> I think we agree in beggining the working >> group discussion that we should not specify >> any "bearer-service" because NSIS should be a >> modular architecture with more flexibillity >> than RSVP. Therefore, I am surprised that we >> are doing the same mistake as in RSVP: >> Integrating a bearer service definition into >> the NSIS-architecture. >> >> If we go this track, the QoS-part of NSIS has >> much less use. RSVP is in this case >> significantly better in terms of performance >> and have the same functionality than NSIS. >> If have to choose I would select RSVP rather >> than a much more complex three layer protocol >> stack. >> >> regards Lasse >> >> Georgios Karagiannis wrote: >> >> Hi Lars >> >> =20 >> >> Do you mean that the QSPEC template must not c= ontain any mandatory >> >> (QSPEC-1) parameters? >> >> =20 >> >> =20 >> >> Best Regards, >> >> Georgios >> >> =20 >> >> =20 >> >> =20 >> >> On 10/16/2006, "Lars Westberg" wrote: >> >> =20 >> >> =20 >> >>> Hi, >>> The template seems not to be a template becau= se the mandatory part is >>> more or less the same as Intserv. >>> The main idea with QoS-template was to make a= n modular solution that >>> could allow flexibillity for different Qos-mo= dels >>> =20 >>> Therefore, I do not understand the scope of t= he specification. >>> =20 >>> I suggest that we move the major part of the = parameters to a separate >>> "Int.serv. over NSIS" specification. >>> Int.serv. can be seen as a common bearer serv= ice. >>> =20 >>> regards Lasse >>> =20 >>> Ash, Gerald R (Jerry), ALABS wrote: >>> =20 >>> =20 >>>> Lars, >>>> =20 >>>> =20 >>>>> You mention in the below e-mail that there = are no open issues, >>>>> while there is a huge discussion on the nsi= s mailing list >>>>> regarding the QSPEC-1 parameters. >>>>> =20 >>>> John can call a different consensus if he se= es one (I've asked him a >>>> couple of times to do that). What I saw was >>>> =20 >>>> 1. Many posts supported the QSPEC-1 concept,= only one (or maybe two) I >>>> saw opposed. The opposing view was repeated= *many* times (and is still >>>> being repeated) but it only counts as one op= inion. >>>> 2. Many posts supported retaining the 4 QSPE= C-1 parameters, only one I >>>> saw opposed. The opposing view was repeated= many times. >>>> 3. There was only one opinion expressed to b= e able to ignore QSPEC-1 >>>> parameters. That one opinion has been repea= ted many times but it only >>>> counts as one opinion. >>>> =20 >>>> John asked a while ago for new opinions on t= hese issues, that would be >>>> good if there are any *new* opinions. We do= n't need to hear opinions >>>> repeated that we've seen so many times. >>>> =20 >>>> I invite John once again to make a consensus= call so we can move on >>>> here. I think it is time to make progress a= nd stop repeating ourselves, >>>> we're not generating any new light in this r= ather endless discussion. >>>> =20 >>>> Thanks, >>>> Jerry >>>> =20 >>>> =20 >> =20 >> >> =20 >=20 >=20 > -----------------------------------------------------------------------= - >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 18 15:53:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaHSu-0004E5-H0; Wed, 18 Oct 2006 15:52:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaHRd-0002aL-GZ for nsis@ietf.org; Wed, 18 Oct 2006 15:51:17 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaHRc-0003vt-6m for nsis@ietf.org; Wed, 18 Oct 2006 15:51:17 -0400 Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Wed, 18 Oct 2006 22:51:10 +0300 id 000AFDA7.453685AE.00005F91 Date: Wed, 18 Oct 2006 22:51:10 +0300 (EEST) From: Jukka MJ Manner To: Matthias Friedrich In-Reply-To: <20061018152328.GA3034@mafr.de> Message-ID: References: <20061018152328.GA3034@mafr.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: nsis@ietf.org Subject: [NSIS] Re: NATFW+AUTH_SESSION: Scenarios with multiple authorization tokens X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, I'll let the NATFW authors answer to your detailed question. Still, as an overall comment, if you think multiple authentication pairs should be possible, then we could just allow multiple AUTH_SESSION objects within a single message. However, how do we define, which entity checks which token? Jukka On Wed, 18 Oct 2006, Matthias Friedrich wrote: > Hi, > > I think one AUTH_SESSION object isn't enough. Consider the following > scenario, for example: > > A trusted party inside the NR's domain ("receiver domain") issues an > autorization token (in AUTH_SESSION syntax). It is passed to the NI > which has to include it in CREATE messages. Otherwise the NFs inside the > receiver domain won't let the message pass. > > Now suppose the sender domain also relies on AUTH_SESSION objects. > Local NFs only accept messages if they contain authorization tokens > issued by a trusted party from the sender domain. The usage of a token > has the advantage that it can be granted on a user basis. In contrast, > an NF querying a policy server based on a NATFW message has no user > information available and can only make a decision based on addresses. > > So we have two tokens (and thus two AUTH_SESSION objects) but only one > ID, according to draft-manner-nsis-nslp-auth-01, Section 7. To cover > this use case, I think we either have to assign multiple IDs or extend > AUTH_SESSION to carry multiple (authorizing entity, signature) pairs. > > Regards, > Matthias > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 18 18:26:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaJrD-00036x-8w; Wed, 18 Oct 2006 18:25:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaJ6A-0001b5-HC for nsis@ietf.org; Wed, 18 Oct 2006 17:37:14 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaHtP-0007kS-1b for nsis@ietf.org; Wed, 18 Oct 2006 16:20:01 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx2.ira.uni-karlsruhe.de with esmtps id 1GaHtL-0000U6-GK for ; Wed, 18 Oct 2006 22:19:56 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 5F4D6B651 for ; Wed, 18 Oct 2006 22:19:55 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1GaHtL-0006al-35 for nsis@ietf.org; Wed, 18 Oct 2006 22:19:55 +0200 Message-ID: <45368C74.9020507@tm.uka.de> Date: Wed, 18 Oct 2006 22:20:04 +0200 From: Roland Bless User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8.0.7) Gecko/20060909 Thunderbird/1.5.0.7 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: nsis@ietf.org X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.1 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.3 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [NSIS] New Draft about Inter-Domain Reservation Aggregation for QoS NSLP X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, as already mentioned at the Dallas meeting, we wanted to work on inter-domain issues (as it was mentioned in early NSIS charters). Maybe this is a topic that the WG can deal with after we got the basic protocol drafts off the table. Though the following draft was submitted before the meeting deadline, it may take a while until it is available in the I-D repository. Thus probably some of you who are interested in the topic may have a chance to read it earlier when downloading it from here in the meantime: http://doc.tm.uka.de/2006/draft-bless-nsis-resv-aggr-00.txt The draft should serve as base for discussion and aims at describing the basic problems as well as a straw-man proposal for solutions. If time permits, I also want to present/discuss it in San Diego. Abstract QoS NSLP is a recently proposed signaling protocol that allows to establish QoS reservations in the Internet. In order to enable large scale deployment, inter-domain aggregation should be considered as mechanism to allow for the necessary scalability. This draft describes the major problems that must be solved and proposes also solutions to these problems, requiring only modest modifications and extensions to the currently defined GIST and QoS NSLP specifications. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 18 19:11:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaKYg-00080l-Cz; Wed, 18 Oct 2006 19:10:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaKYe-0007zU-Gb for nsis@ietf.org; Wed, 18 Oct 2006 19:10:44 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaKYb-0007Bn-SD for nsis@ietf.org; Wed, 18 Oct 2006 19:10:44 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx2.ira.uni-karlsruhe.de with esmtps id 1GaKYY-000125-IM; Thu, 19 Oct 2006 01:10:39 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 6685EB5D2; Thu, 19 Oct 2006 01:10:38 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1GaKYX-0006kU-Ua; Thu, 19 Oct 2006 01:10:38 +0200 Message-ID: <4536B477.9000104@tm.uka.de> Date: Thu, 19 Oct 2006 01:10:47 +0200 From: Roland Bless User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8.0.7) Gecko/20060909 Thunderbird/1.5.0.7 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Robert Hancock References: <4536AC75.1040204@tm.uka.de> In-Reply-To: <4536AC75.1040204@tm.uka.de> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit X-Spam-Score: -4.1 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.3 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: nsis@ietf.org Subject: [NSIS] Re: GIST issue - MA-Hello reply X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert, I just saw that the state diagram in figure 8 gives a more detailed hint, that one should reply with an MA-Hello message (cf. Rule 3, IMHO, the text in 5.1 should state this also clearly then). But I don't quite understand why Rule 7 says "stop SendHello timer". This leads to the situation that we don't send any MA-Hello messages anymore and the other side will go to Idle and Death as well leading us to MA-Death, so the MA is closed down. Isn't it the intention to keep the MA open by sending MA-Hellos? Regards, Roland Roland Bless wrote: > the current Spec says in sec. 5.1: > MA-Hello: .... > The R flag MAY be set > (R=1); if so, the peer MUST send another message back along the > messaging association. > > I need some guidance here: what message should be sent as response? > If one is queued for transmission no problem, but if sending > an MA-Hello back I guess it makes sense to require that the > R flag MUST not be set if an MA-Hello is sent back as response > to an incoming MA-Hello with R flag set. Otherwise both sides > would keep sending MA-Hellos without pause. > > Regards, > Roland > -- Dr. Roland Bless -- WWW: http://www.tm.uka.de/~bless Institut für Telematik, Universität Karlsruhe (TH), Germany Zirkel 2, D-76128 Karlsruhe -- Geb. 20.20, 3.OG, Raum 358 Tel.: +49 721 608-6413 Fax: +49 721 608-6789 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 18 19:22:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaK2i-0003wY-65; Wed, 18 Oct 2006 18:37:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaK2f-0003pP-H2 for nsis@ietf.org; Wed, 18 Oct 2006 18:37:41 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaK1Y-0000X5-I9 for nsis@ietf.org; Wed, 18 Oct 2006 18:36:55 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx2.ira.uni-karlsruhe.de with esmtps id 1GaK1T-0002ge-Te; Thu, 19 Oct 2006 00:36:31 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id B6B23B5B3; Thu, 19 Oct 2006 00:36:27 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1GaK1T-0006hT-FH; Thu, 19 Oct 2006 00:36:27 +0200 Message-ID: <4536AC75.1040204@tm.uka.de> Date: Thu, 19 Oct 2006 00:36:37 +0200 From: Roland Bless User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8.0.7) Gecko/20060909 Thunderbird/1.5.0.7 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Robert Hancock X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.1 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.3 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: nsis@ietf.org Subject: [NSIS] GIST issue - MA-Hello reply X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert, the current Spec says in sec. 5.1: MA-Hello: .... The R flag MAY be set (R=1); if so, the peer MUST send another message back along the messaging association. I need some guidance here: what message should be sent as response? If one is queued for transmission no problem, but if sending an MA-Hello back I guess it makes sense to require that the R flag MUST not be set if an MA-Hello is sent back as response to an incoming MA-Hello with R flag set. Otherwise both sides would keep sending MA-Hellos without pause. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 18 20:16:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaLZS-0006pH-CY; Wed, 18 Oct 2006 20:15:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaLZR-0006mL-HI for nsis@ietf.org; Wed, 18 Oct 2006 20:15:37 -0400 Received: from mail-red.research.att.com ([192.20.225.110]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaLZQ-0002yQ-1Y for nsis@ietf.org; Wed, 18 Oct 2006 20:15:37 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Date: Wed, 18 Oct 2006 20:15:31 -0400 Message-ID: In-Reply-To: <62D92A9A02BCC845B202323D49A48426230EC9@0591-ITS-EXMP02.us.saic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt thread-index: Acbye4IZ7vmeaP4vRWSoYWr8MvZn4AARbEXAABPFuNA= From: To: , , X-Spam-Score: 0.2 (/) X-Scan-Signature: 354d6627469d0be959806e15912c47f1 Cc: gash@att.com, karagian@cs.utwente.nl, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1770960865==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============1770960865== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F313.B13E90CF" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F313.B13E90CF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Radhika =20 Water and oil aside, the Y.1541 QoS classes are not "implementation-specific" as you say. They may use DiffServ, they may use RSVP, they may use something else. How is that implementation-specific? =20 For me, this misunderstanding by you is the root cause of your criticism. (I understand your argument-I just do not agree with it, because it is inaccurate.) =20 The Y.1541 classes are QoS classes that many experts around the world agreed capture, in a reasonably small number, distinct combinations of IP performance parameters capable of supporting virtually all user applications with the requisite QoS. On an e2e basis, a user may for example indicate "I am using IPTV and want to request Y.1541 Class 5, which would satisfy my QoS needs." Networks in the path may implement different QoS schemes (per-hop, per-domain, whatever), but a good NSIS method will still allow the e2e QoS classes (of Y.1541) to be addressed. =20 But there is no effective way to signal this e2e today, and that is what many of us wanted NSIS to do-signal this e2e need, with enough hooks to be useful.=20 =20 If all that is done in NSIS is to make incremental improvements to RSVP, or to focus primarily on signaling peak bandwidth needs, then IMO the end result will not be nearly as useful as many of us had hoped. =20 Chuck Dvorak AT&T Labs Research ________________________________ From: Roy, Radhika R. [mailto:RADHIKA.R.ROY@saic.com]=20 Sent: Wednesday, October 18, 2006 10:37 AM To: lars.westberg@ericsson.com; john.loughney@nokia.com Cc: gash@att.com; Georgios Karagiannis; RADHIKA.R.ROY@saic.com; nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt =20 Lars: =20 You are right. That is why, the QOS model like DiffServ comes into picture. =20 There is another aspect of these QOS models so far the standardization is concerned. That is called interwoking between the different QOS modeling standards. For example, you have mentioned as follows: =20 Inter-operabillity solved by:=20 1) Overprovisioning in the core such as all QoS-requirments are solved. 2) Interoperabillity for different QoS-models =3D>Peak-allocation of bandwidth. =20 All the trends of QOS models have been basically like the above. =20 Recently, we also see some fertile brains have created some so-called "Implementation-specific QOS schemes" that are based on "values" of all QOS parameters. The fundamental problems are that they also called these as QOS models (instead of saying that these are some QOS "implementation" schemes, NOT QOS models). They have even convinced few folks here and there of different standard organizations that they need "interworking" between different QOS models. =20 Here the fundamental problems come. Who is kidding whom trying to mixing between water and oil?=20 =20 Best regards, Radhika ------_=_NextPart_001_01C6F313.B13E90CF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Radhika

=

 

Water and oil aside, the Y.1541 QoS = classes are not “implementation-specific” as you say. They = may use DiffServ, they may use RSVP, they may use something else. How is that implementation-specific?

 

For me, this misunderstanding by = you is the root cause of your criticism. (I understand your argument—I = just do not agree with it, because it is = inaccurate.)

 

The Y.1541 classes are QoS classes = that many experts around the world agreed capture, in a reasonably small = number, distinct combinations of IP performance parameters capable of supporting = virtually all user applications with the requisite QoS. On an e2e basis, a user may for = example indicate “I am using IPTV and want to request Y.1541 Class 5, which would = satisfy my QoS needs.” Networks in the path may implement different = QoS schemes (per-hop, per-domain, whatever), but a good NSIS method will = still allow the e2e QoS classes (of Y.1541) to be = addressed.

 

But there is no effective way to = signal this e2e today, and that is what many of us wanted NSIS to do—signal = this e2e need, with enough hooks to be useful.

 

If all that is done in NSIS is to = make incremental improvements to RSVP, or to focus primarily on signaling peak bandwidth = needs, then IMO the end result will not be nearly as useful as many of us had = hoped.

 

Chuck = Dvorak

AT&T Labs = Research

From: Roy, Radhika R. [mailto:RADHIKA.R.ROY@saic.com]
Sent: Wednesday, October = 18, 2006 10:37 AM
To: = lars.westberg@ericsson.com; john.loughney@nokia.com
Cc: gash@att.com; = Georgios Karagiannis; RADHIKA.R.ROY@saic.com; nsis@ietf.org
Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

 

Lars:

 

You are right. That is why, the QOS = model like DiffServ comes into picture.

 

There is another aspect of these = QOS models so far the standardization is concerned. That is called = interwoking between the different QOS modeling standards. For example, you have mentioned as follows:

 

Inter-operabillity solved by:
1) Overprovisioning in the core such as all QoS-requirments are = solved.
2) Interoperabillity for different QoS-models =3D>Peak-allocation of bandwidth.

 

All the trends of QOS models have = been basically like the above.

 

Recently, we also see some fertile = brains have created some so-called “Implementation-specific QOS = schemes” that are based on “values” of all QOS parameters. The = fundamental problems are that they also called these as QOS models (instead of = saying that these are some QOS “implementation” schemes, NOT QOS = models). They have even convinced few folks here and there of different standard organizations that they need “interworking” between = different QOS models.

 

Here the fundamental problems come. = Who is kidding whom trying to mixing between water and oil? =

 

Best = regards,

Radhika

=
------_=_NextPart_001_01C6F313.B13E90CF-- --===============1770960865== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============1770960865==-- From nsis-bounces@ietf.org Thu Oct 19 01:08:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaQ7h-0000Xa-LF; Thu, 19 Oct 2006 01:07:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaQ7f-0000Q1-SH for nsis@ietf.org; Thu, 19 Oct 2006 01:07:15 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaQ7f-0008W1-63 for nsis@ietf.org; Thu, 19 Oct 2006 01:07:15 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 18 Oct 2006 22:07:14 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9J57Ep1030217; Wed, 18 Oct 2006 22:07:14 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k9J573OV022563; Wed, 18 Oct 2006 22:07:09 -0700 (PDT) Received: from [10.0.0.77] (ams3-vpn-dhcp39.cisco.com [10.61.64.39]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k9J4sv1b002734; Wed, 18 Oct 2006 21:54:59 -0700 In-Reply-To: <4534CD6E.1050507@ericsson.com> References: <4534CD6E.1050507@ericsson.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <72A0C76B-6118-4734-92EF-FBAB4577B0CA@cisco.com> Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Date: Thu, 19 Oct 2006 01:05:59 -0400 To: Lars Westberg X-Mailer: Apple Mail (2.752.2) Authentication-Results: sj-dkim-7.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=8860; t=1161234434; x=1162098434; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:David=20R=20Oran=20 |Subject:Re=3A=20AW=3A=20AW=3A=20[NSIS]=20I-D=20ACTION=3Adraft-ietf-nsis-qspec-12 .txt; X=v=3Dcisco.com=3B=20h=3Df+6Vf90G0v+1In+pNmK/Ey+4Q0M=3D; b=UnoUtxvfgFfCO3wuS/qsy8i1WzOsGk+b1dayLYhvXNqqVkFn1zZ1LViXZEqysBGL4pzG21wM c+2NDEykrkkRYOTWizIGaBFeuKtBQ7ryDc9uUZWsuAG4CDqIeB/iO8dx; X-Spam-Score: 0.0 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e Cc: gash@att.com, Georgios Karagiannis , nsis@ietf.org, "Kappler, Cornelia" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org One more time from left-field (I know... I've lost this one before and should keep my mouth shut). Much of this confusion is because I believe the qspec draft and the current notion of "QoS models" has a poor architectural partitioning and hence falls into these kinds of discussions of what is over and under specification, what it means for a parameter to be mandatory, etc. A long time ago I proposed a different architectural partitioning (and moving some things like priority outside the qspec entirely since it was a general admission control parameter and not a QoS parameter). I won't resurrect the whole thing here but remind people if they want to go back a couple of years in the archives they;ll find the outline of the proposal and the ensuing discussion. I shut up because the WG consensus was against my proposal and I'm not in the habit of continuing to make a pain of myself when I lose an argument. However, it does strike me that this long thread and the last-minute discussions on the qspec draft do have a flavor of the issues I was raising way back when. Just to remind folks, I proposed, more or less: a) a set of parameters, all mandatory, that describe the traffic source in a mathematically complete way. b) a set of parameters, all optional, which give additional hints about characteristics of the source traffic which may allow network elements to optimize their treatment (compressibility hints, pre- encryption hints) c) a set of parameters, mostly optional, that describe the QoS constraints the source wishes applied to the treatment of this traffic (loss rate, jitter, sensitivity to out of order delivery, etc.) d) a set of handling directives, all optional, which specify the source's preferences for for traffic handling (e.g. excess treatment) I think there are a number of ways to close down this discussion , through which I notice there have been only a few people complaining: a) tell them to shut up, that the WG consensus stands, and see what happens during last call. b) rethink the spec along the lines I outline above and ask those folks if that would address their concerns c) ask for a formal outside review, either by raising these issues explicitly in the last call and requesting comments, or punting to the IESG to solicit such advice. I promise not to rock the boat if you choose (a). Dave Oran. On Oct 17, 2006, at 8:32 AM, Lars Westberg wrote: > > The specification of Qspec1 is mandatory and therefore as I can see > can not be avoided and > The parameter description in The Qspec-1 is more detalied than > Int.serv. > The reason for dividing NSIS in three layers was that Int.serv. > was too tightly built-into RSVP. > Now, I see that this benefit is gone and what's the gain with NSIS > for QoS ? > > If one just read the specification, and compare it with Int.serv. > oe can conclude the following: > 1) More parameters than Intserv. (excess treatment, priority???) > 2) More functionality required for implementation even if its never > used. > > issues like : > how to model MEF bearer service definition ????? > > ...more layers with more functionality in each layer stacked on > each other. I do not know what to do..... > > regards Lasse > > > > Kappler, Cornelia wrote: >> Hi Lasse, >> >> "specification of treatment of a flow" should be done in the QOSM >> Specs (e.g. RMD, CLS), it is not at an issue of the QSPEC. >> >> The job of the QSPEC draft is to define a set of parameters that >> QOSM specs can choose from to define this treatment. (Would you >> agree this is a reasonable approach?) >> > if the collection of paramters does not limit the applicabillity of > QoS-models that may be ok. > >> Could you more concretely point out where in the QSPEC a specific >> flow treatment is defined - beyond the (necessary) description of >> how a particular parameter should be dealt with? > I have sent out pointer to Metro-Ethernet forum specification. >> >> Cornelia >> >> Von: Lars Westberg [mailto:Lars.westberg@ericsson.com] >> Gesendet: Dienstag, 17. Oktober 2006 10:56 >> An: Kappler, Cornelia >> Cc: Georgios Karagiannis; gash@att.com; nsis@ietf.org >> Betreff: Re: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt >> >> comments inline >> >> Kappler, Cornelia wrote: >>> Hi Lars, >>> >>> could you explain why the qspec draft defines a new bearer service? >>> >> let's define it as "Specification of the Controlled-Load Network >> Element Service" >> =>a specifiaction of treatment of a "flow". >>> What is a bearer service? This concept exists in 3GPP, but it >>> does not exist in IETF I dont think, and I dont think the 3GPP >>> definition is transferrable to IETF. So what exactly are you >>> stating? >>> >> see above. >>> Cornelia >>> >>> Von: Lars Westberg [mailto:Lars.westberg@ericsson.com] >>> Gesendet: Dienstag, 17. Oktober 2006 08:46 >>> An: Georgios Karagiannis >>> Cc: gash@att.com; nsis@ietf.org >>> Betreff: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt >>> >>> yes. >>> the main problem is that IETF is not the only Standardization >>> organization that like to discuss "bearer services". Just as an >>> example : >>> If we specify the those parameters, How can we use NSIS for SLAs >>> specified by MEF???? >>> >>> How can we use it for 3GPP-Qos definitiions ? >>> >>> >>> In the draft I also see that we the draft specify a new bearer >>> service. It is not compliant to old Int.serv architecture. This >>> is a completely new one with new parameters like priority. >>> >>> I can sure that we can have a never-ending discussion about the >>> "optimal"-set of parameters. >>> >>> I think we agree in beggining the working group discussion that >>> we should not specify any "bearer-service" because NSIS should be >>> a modular architecture with more flexibillity than RSVP. >>> Therefore, I am surprised that we are doing the same mistake as >>> in RSVP: Integrating a bearer service definition into the NSIS- >>> architecture. >>> >>> If we go this track, the QoS-part of NSIS has much less use. RSVP >>> is in this case significantly better in terms of performance and >>> have the same functionality than NSIS. >>> If have to choose I would select RSVP rather than a much more >>> complex three layer protocol stack. >>> >>> regards Lasse >>> >>> Georgios Karagiannis wrote: >>>> Hi Lars Do you mean that the QSPEC template must not contain any >>>> mandatory (QSPEC-1) parameters? Best Regards, Georgios On >>>> 10/16/2006, "Lars Westberg" wrote: >>>>> Hi, The template seems not to be a template because the >>>>> mandatory part is more or less the same as Intserv. The main >>>>> idea with QoS-template was to make an modular solution that >>>>> could allow flexibillity for different Qos-models Therefore, I >>>>> do not understand the scope of the specification. I suggest >>>>> that we move the major part of the parameters to a separate >>>>> "Int.serv. over NSIS" specification. Int.serv. can be seen as a >>>>> common bearer service. regards Lasse Ash, Gerald R (Jerry), >>>>> ALABS wrote: >>>>>> Lars, >>>>>>> You mention in the below e-mail that there are no open >>>>>>> issues, while there is a huge discussion on the nsis mailing >>>>>>> list regarding the QSPEC-1 parameters. >>>>>> John can call a different consensus if he sees one (I've asked >>>>>> him a couple of times to do that). What I saw was 1. Many >>>>>> posts supported the QSPEC-1 concept, only one (or maybe two) I >>>>>> saw opposed. The opposing view was repeated *many* times (and >>>>>> is still being repeated) but it only counts as one opinion. 2. >>>>>> Many posts supported retaining the 4 QSPEC-1 parameters, only >>>>>> one I saw opposed. The opposing view was repeated many times. >>>>>> 3. There was only one opinion expressed to be able to ignore >>>>>> QSPEC-1 parameters. That one opinion has been repeated many >>>>>> times but it only counts as one opinion. John asked a while >>>>>> ago for new opinions on these issues, that would be good if >>>>>> there are any *new* opinions. We don't need to hear opinions >>>>>> repeated that we've seen so many times. I invite John once >>>>>> again to make a consensus call so we can move on here. I think >>>>>> it is time to make progress and stop repeating ourselves, >>>>>> we're not generating any new light in this rather endless >>>>>> discussion. Thanks, Jerry > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 19 03:15:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaS7Y-0004lz-28; Thu, 19 Oct 2006 03:15:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaS7V-0004UL-8w for nsis@ietf.org; Thu, 19 Oct 2006 03:15:13 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaS7D-0000Sm-4Y for nsis@ietf.org; Thu, 19 Oct 2006 03:15:07 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 34D4911B3; Thu, 19 Oct 2006 09:14:46 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 09:14:45 +0200 Received: from ericsson.com ([147.214.26.58]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 09:14:45 +0200 Message-ID: <453725E5.6030409@ericsson.com> Date: Thu, 19 Oct 2006 09:14:45 +0200 From: Lars Westberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: cdvorak@research.att.com Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt References: In-Reply-To: X-OriginalArrivalTime: 19 Oct 2006 07:14:45.0429 (UTC) FILETIME=[413F1650:01C6F34E] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: a630332fa112280ecc4c4186b5c9ea83 Cc: john.loughney@nokia.com, gash@att.com, karagian@cs.utwente.nl, RADHIKA.R.ROY@saic.com, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0927975730==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0927975730== Content-Type: multipart/alternative; boundary="------------030508060403030406070009" This is a multi-part message in MIME format. --------------030508060403030406070009 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit The basic problem is that NSIS only mandating only one service type in the basic set of protocol specifications. In RSVP one can change parameters without make a new revision of the basic protocol specs. regards Lasse cdvorak@research.att.com wrote: > Radhika > > > > Water and oil aside, the Y.1541 QoS classes are not > "implementation-specific" as you say. They may use DiffServ, they may > use RSVP, they may use something else. How is that > implementation-specific? > > > > For me, this misunderstanding by you is the root cause of your > criticism. (I understand your argument--I just do not agree with it, > because it is inaccurate.) > > > > The Y.1541 classes are QoS classes that many experts around the world > agreed capture, in a reasonably small number, distinct combinations of > IP performance parameters capable of supporting virtually all user > applications with the requisite QoS. On an e2e basis, a user may for > example indicate "I am using IPTV and want to request Y.1541 Class 5, > which would satisfy my QoS needs." Networks in the path may implement > different QoS schemes (per-hop, per-domain, whatever), but a good NSIS > method will still allow the e2e QoS classes (of Y.1541) to be addressed. > > > > But there is no effective way to signal this e2e today, and that is > what many of us wanted NSIS to do--signal this e2e need, with enough > hooks to be useful. > > > > If all that is done in NSIS is to make incremental improvements to > RSVP, or to focus primarily on signaling peak bandwidth needs, then > IMO the end result will not be nearly as useful as many of us had hoped. > > > I am very interested to get more information. Send me a mail directly. > Chuck Dvorak > > AT&T Labs Research > > ------------------------------------------------------------------------ > > From: Roy, Radhika R. [mailto:RADHIKA.R.ROY@saic.com] > Sent: Wednesday, October 18, 2006 10:37 AM > To: lars.westberg@ericsson.com; john.loughney@nokia.com > Cc: gash@att.com; Georgios Karagiannis; RADHIKA.R.ROY@saic.com; > nsis@ietf.org > Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt > > > > Lars: > > > > You are right. That is why, the QOS model like DiffServ comes into > picture. > > > > There is another aspect of these QOS models so far the standardization > is concerned. That is called interwoking between the different QOS > modeling standards. For example, you have mentioned as follows: > > > > Inter-operabillity solved by: > 1) Overprovisioning in the core such as all QoS-requirments are solved. > 2) Interoperabillity for different QoS-models =>Peak-allocation of > bandwidth. > > > > All the trends of QOS models have been basically like the above. > > > > Recently, we also see some fertile brains have created some so-called > "Implementation-specific QOS schemes" that are based on "values" of > all QOS parameters. The fundamental problems are that they also called > these as QOS models (instead of saying that these are some QOS > "implementation" schemes, NOT QOS models). They have even convinced > few folks here and there of different standard organizations that they > need "interworking" between different QOS models. > > > > Here the fundamental problems come. Who is kidding whom trying to > mixing between water and oil? > > > > Best regards, > > Radhika > --------------030508060403030406070009 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit The basic problem is that NSIS only mandating only one service type in the basic set of protocol specifications. In RSVP one can change parameters without make a new revision of the basic protocol specs.

regards Lasse
cdvorak@research.att.com wrote:

Radhika

 

Water and oil aside, the Y.1541 QoS classes are not “implementation-specific” as you say. They may use DiffServ, they may use RSVP, they may use something else. How is that implementation-specific?

 

For me, this misunderstanding by you is the root cause of your criticism. (I understand your argument—I just do not agree with it, because it is inaccurate.)

 

The Y.1541 classes are QoS classes that many experts around the world agreed capture, in a reasonably small number, distinct combinations of IP performance parameters capable of supporting virtually all user applications with the requisite QoS. On an e2e basis, a user may for example indicate “I am using IPTV and want to request Y.1541 Class 5, which would satisfy my QoS needs.” Networks in the path may implement different QoS schemes (per-hop, per-domain, whatever), but a good NSIS method will still allow the e2e QoS classes (of Y.1541) to be addressed.

 

But there is no effective way to signal this e2e today, and that is what many of us wanted NSIS to do—signal this e2e need, with enough hooks to be useful.

 

If all that is done in NSIS is to make incremental improvements to RSVP, or to focus primarily on signaling peak bandwidth needs, then IMO the end result will not be nearly as useful as many of us had hoped.

 

I am very interested to get more information.  Send me a mail directly.

Chuck Dvorak

AT&T Labs Research

From: Roy, Radhika R. [mailto:RADHIKA.R.ROY@saic.com]
Sent: Wednesday, October 18, 2006 10:37 AM
To: lars.westberg@ericsson.com; john.loughney@nokia.com
Cc: gash@att.com; Georgios Karagiannis; RADHIKA.R.ROY@saic.com; nsis@ietf.org
Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

 

Lars:

 

You are right. That is why, the QOS model like DiffServ comes into picture.

 

There is another aspect of these QOS models so far the standardization is concerned. That is called interwoking between the different QOS modeling standards. For example, you have mentioned as follows:

 

Inter-operabillity solved by:
1) Overprovisioning in the core such as all QoS-requirments are solved.
2) Interoperabillity for different QoS-models =>Peak-allocation of bandwidth.

 

All the trends of QOS models have been basically like the above.

 

Recently, we also see some fertile brains have created some so-called “Implementation-specific QOS schemes” that are based on “values” of all QOS parameters. The fundamental problems are that they also called these as QOS models (instead of saying that these are some QOS “implementation” schemes, NOT QOS models). They have even convinced few folks here and there of different standard organizations that they need “interworking” between different QOS models.

 

Here the fundamental problems come. Who is kidding whom trying to mixing between water and oil?

 

Best regards,

Radhika

--------------030508060403030406070009-- --===============0927975730== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0927975730==-- From nsis-bounces@ietf.org Thu Oct 19 03:35:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaSQc-000161-10; Thu, 19 Oct 2006 03:34:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaSQb-00015u-4I for nsis@ietf.org; Thu, 19 Oct 2006 03:34:57 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaSQX-0003ij-FU for nsis@ietf.org; Thu, 19 Oct 2006 03:34:57 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k9J7Xa2A005910; Thu, 19 Oct 2006 08:33:36 +0100 Received: from victor ([193.118.192.66]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 08:33:36 +0100 From: "Robert Hancock" To: "'David R Oran'" , "'Lars Westberg'" Subject: RE: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Date: Thu, 19 Oct 2006 09:33:55 +0200 Message-ID: <079b01c6f350$ef85bb90$946b0a0a@comm.ad.roke.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <72A0C76B-6118-4734-92EF-FBAB4577B0CA@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Importance: Normal X-OriginalArrivalTime: 19 Oct 2006 07:33:36.0569 (UTC) FILETIME=[E3755A90:01C6F350] X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: gash@att.com, 'Georgios Karagiannis' , nsis@ietf.org, "'Kappler, Cornelia'" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Dave, I'm still listening, anyway :-) My understanding of the situation is that the a/b/c/d classification you describe below is not so far from the intentions of the current Qspec. One open question is about which parameters fall into which category; other people are saying "give up and make everything optional". Please see further below. > -----Original Message----- > From: David R Oran [mailto:oran@cisco.com] > Sent: 19 October 2006 07:06 > To: Lars Westberg > Cc: gash@att.com; Georgios Karagiannis; nsis@ietf.org; > Kappler, Cornelia > Subject: Re: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt > > > One more time from left-field (I know... I've lost this one before > and should keep my mouth shut). > > Much of this confusion is because I believe the qspec draft and the > current notion of "QoS models" has a poor architectural partitioning > and hence falls into these kinds of discussions of what is over and > under specification, what it means for a parameter to be > mandatory, etc. > > A long time ago I proposed a different architectural partitioning > (and moving some things like priority outside the qspec entirely > since it was a general admission control parameter and not a QoS > parameter). I won't resurrect the whole thing here but remind people > if they want to go back a couple of years in the archives they;ll > find the outline of the proposal and the ensuing discussion. I shut > up because the WG consensus was against my proposal and I'm not in > the habit of continuing to make a pain of myself when I lose an > argument. > > However, it does strike me that this long thread and the last-minute > discussions on the qspec draft do have a flavor of the issues I was > raising way back when. Just to remind folks, I proposed, more or less: > > a) a set of parameters, all mandatory, that describe the traffic > source in a mathematically complete way. The current spec includes bandwidth and a token bucket in this category. Most people seem to agree that it is reasonable to demand that everyone understand the bandwidth parameter; personally I don't know how to interpret a bandwidth except over a timescale which is then basically a token bucket anyway. > b) a set of parameters, all optional, which give additional hints > about characteristics of the source traffic which may allow network > elements to optimize their treatment (compressibility hints, pre- > encryption hints) I don't think we have any of these yet, but since they are all optional they are easy to add. > c) a set of parameters, mostly optional, that describe the QoS > constraints the source wishes applied to the treatment of this > traffic (loss rate, jitter, sensitivity to out of order > delivery, etc.) > d) a set of handling directives, all optional, which specify the > source's preferences for for traffic handling (e.g. excess treatment) > > I think there are a number of ways to close down this discussion , > through which I notice there have been only a few people complaining: > > a) tell them to shut up, that the WG consensus stands, and see what > happens during last call. > b) rethink the spec along the lines I outline above and ask those > folks if that would address their concerns > c) ask for a formal outside review, either by raising these issues > explicitly in the last call and requesting comments, or punting to > the IESG to solicit such advice. Well, Jukka has suggested to ask the IAB, on which you sit... Robert H. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 19 03:52:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaShC-0001Ta-EG; Thu, 19 Oct 2006 03:52:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaShB-0001TV-Ur for nsis@ietf.org; Thu, 19 Oct 2006 03:52:05 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaSh5-0007VN-64 for nsis@ietf.org; Thu, 19 Oct 2006 03:52:05 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 34DF04F0001; Thu, 19 Oct 2006 09:51:48 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 09:51:47 +0200 Received: from ericsson.com ([147.214.26.58]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 09:51:47 +0200 Message-ID: <45372E93.4040704@ericsson.com> Date: Thu, 19 Oct 2006 09:51:47 +0200 From: Lars Westberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Jukka MJ Manner" Subject: Re: [NSIS] Proposal to move the QSPEC work forward References: In-Reply-To: X-OriginalArrivalTime: 19 Oct 2006 07:51:47.0210 (UTC) FILETIME=[6D87F6A0:01C6F353] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: Georgios Karagiannis , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0242360757==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0242360757== Content-Type: multipart/alternative; boundary="------------020909030403060506030003" This is a multi-part message in MIME format. --------------020909030403060506030003 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I haven't see this mail before so... I aggree with Jukka regards Lasse > > --- Original Message --- > Date: 10/17/2006 > From: "Jukka MJ Manner" > 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 > > 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 > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > --------------020909030403060506030003 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I haven't see this mail before so...

I aggree with Jukka

regards Lasse

--- Original Message ---
Date: 10/17/2006
From: "Jukka MJ Manner" <jmanner@cs.Helsinki.FI>
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

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
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis

--------------020909030403060506030003-- --===============0242360757== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0242360757==-- From nsis-bounces@ietf.org Thu Oct 19 03:55:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaSjx-0005Ys-6o; Thu, 19 Oct 2006 03:54:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaSjv-0005SR-Dc for nsis@ietf.org; Thu, 19 Oct 2006 03:54:55 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaSjt-00085M-SH for nsis@ietf.org; Thu, 19 Oct 2006 03:54:55 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 19 Oct 2006 00:54:53 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9J7sr8J010102; Thu, 19 Oct 2006 00:54:53 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k9J7srin022206; Thu, 19 Oct 2006 00:54:53 -0700 (PDT) Received: from [10.51.0.33] (rtp-vpn2-97.cisco.com [10.82.240.97]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k9J7gm2r006483; Thu, 19 Oct 2006 00:42:49 -0700 In-Reply-To: <079b01c6f350$ef85bb90$946b0a0a@comm.ad.roke.co.uk> References: <079b01c6f350$ef85bb90$946b0a0a@comm.ad.roke.co.uk> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 (Normal) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <85444989-6B83-4349-A8C8-3454B8304FAE@cisco.com> Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Date: Thu, 19 Oct 2006 03:53:49 -0400 To: "Robert Hancock" X-Mailer: Apple Mail (2.752.2) Authentication-Results: sj-dkim-3.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=6187; t=1161244493; x=1162108493; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:David=20R=20Oran=20 |Subject:Re=3A=20AW=3A=20AW=3A=20[NSIS]=20I-D=20ACTION=3Adraft-ietf-nsis-qspec-12 .txt; X=v=3Dcisco.com=3B=20h=3Df+6Vf90G0v+1In+pNmK/Ey+4Q0M=3D; b=EdjPcY6IPMrtSvPE8QK2IvZuP6cmHgMFnNd73APw1aOST809HSgG9KpenoxykQmQ06cjrdrb /4rJFlULX9Ki+w/TAvkO9mop6rkGX5kW9n9w9qXpCLqVrilk74JYriEu; X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: gash@att.com, 'Georgios Karagiannis' , 'Lars Westberg' , nsis@ietf.org, "'Kappler, Cornelia'" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org On Oct 19, 2006, at 3:33 AM, Robert Hancock wrote: > Dave, > > I'm still listening, anyway :-) > > My understanding of the situation is that the a/b/c/d classification > you describe below is not so far from the intentions of the current > Qspec. No, it isn't too far, because we all know that the various things/ parameters you want to talk about have certain semantics and we (at least so far) don't have a deep disagreement about the semantics. The disagreement is about the systematics/taxonomy and the relationship between things which describe the source traffic, the things which describe the constraints the source believes have to be met to believe that its traffic has been admitted when the NSIS signaling says it's been admitted., and the things which the source would like to tell the network about traffic handling when things do not "go according to plan", or if there are extra resources or good news of some sort. > One open question is about which parameters fall into which > category; other people are saying "give up and make everything > optional". Please see further below. > I don't see any benefit to making parameters which are necessary to mathematically describe the source traffic optional. >> -----Original Message----- >> From: David R Oran [mailto:oran@cisco.com] >> Sent: 19 October 2006 07:06 >> To: Lars Westberg >> Cc: gash@att.com; Georgios Karagiannis; nsis@ietf.org; >> Kappler, Cornelia >> Subject: Re: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt >> >> >> One more time from left-field (I know... I've lost this one before >> and should keep my mouth shut). >> >> Much of this confusion is because I believe the qspec draft and the >> current notion of "QoS models" has a poor architectural partitioning >> and hence falls into these kinds of discussions of what is over and >> under specification, what it means for a parameter to be >> mandatory, etc. >> >> A long time ago I proposed a different architectural partitioning >> (and moving some things like priority outside the qspec entirely >> since it was a general admission control parameter and not a QoS >> parameter). I won't resurrect the whole thing here but remind people >> if they want to go back a couple of years in the archives they;ll >> find the outline of the proposal and the ensuing discussion. I shut >> up because the WG consensus was against my proposal and I'm not in >> the habit of continuing to make a pain of myself when I lose an >> argument. >> >> However, it does strike me that this long thread and the last-minute >> discussions on the qspec draft do have a flavor of the issues I was >> raising way back when. Just to remind folks, I proposed, more or >> less: >> >> a) a set of parameters, all mandatory, that describe the traffic >> source in a mathematically complete way. > > The current spec includes bandwidth and a token bucket in this > category. Most people seem to agree that it is reasonable to > demand that everyone understand the bandwidth parameter; personally > I don't know how to interpret a bandwidth except over a timescale > which is then basically a token bucket anyway. > Right. I fail to understand how "bandwidth" differs from "average rate" in a token bucket if your QoS treatment is only capable of meeting the bandwidth demands over an arbitrarily long time scale. in other words, it makes things complicated and very confusing to have both. I think there's a big difference between a source that says it needs "1mbps" and generates 100mbps in a burst and then shuts up for 99 seconds, expecting the network to absorb and shape that burst, and a source that actually states the TSPEC to describe its traffic generation process. My argument is that this is totally independent of this notion of "QOS models" which has been adopted by the NSIS community. QOS models are all about defining equivalence classes of constraints a given set of machinery deployed in a portion of the internet are capable of meeting when the traffic arrives. I am also of the view that defining QOS models has limited or no utility, but that is a separate discussion and a battle I have no desire to fight in parallel. >> b) a set of parameters, all optional, which give additional hints >> about characteristics of the source traffic which may allow network >> elements to optimize their treatment (compressibility hints, pre- >> encryption hints) > > I don't think we have any of these yet, but since they are all > optional > they are easy to add. > 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. >> c) a set of parameters, mostly optional, that describe the QoS >> constraints the source wishes applied to the treatment of this >> traffic (loss rate, jitter, sensitivity to out of order >> delivery, etc.) >> d) a set of handling directives, all optional, which specify the >> source's preferences for for traffic handling (e.g. excess treatment) >> >> I think there are a number of ways to close down this discussion , >> through which I notice there have been only a few people complaining: >> >> a) tell them to shut up, that the WG consensus stands, and see what >> happens during last call. >> b) rethink the spec along the lines I outline above and ask those >> folks if that would address their concerns >> c) ask for a formal outside review, either by raising these issues >> explicitly in the last call and requesting comments, or punting to >> the IESG to solicit such advice. > > Well, Jukka has suggested to ask the IAB, on which you sit... > And I am mindful that I take care to not to exploit my IAB role to attempt to derail a WG consensus. I'm saying my views as an individual and will continue to do so (if you don't ask me to shut up). > Robert H. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 19 04:13:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaT1U-0004QZ-Ub; Thu, 19 Oct 2006 04:13:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaT1M-00047u-QE for nsis@ietf.org; Thu, 19 Oct 2006 04:12:57 -0400 Received: from moutng.kundenserver.de ([212.227.126.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaSrW-0000uY-Ln for nsis@ietf.org; Thu, 19 Oct 2006 04:02:48 -0400 Received: from [84.163.54.109] (helo=alanis.mafr.de) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis), id 0ML29c-1GaSrU0De2-00006N; Thu, 19 Oct 2006 10:02:44 +0200 Received: by alanis.mafr.de (Postfix, from userid 1000) id 2069C5E81DA; Thu, 19 Oct 2006 10:02:06 +0200 (CEST) Date: Thu, 19 Oct 2006 10:02:06 +0200 From: Matthias Friedrich To: Jukka MJ Manner Message-ID: <20061019080205.GA7303@mafr.de> Mail-Followup-To: Jukka MJ Manner , nsis@ietf.org References: <20061018152328.GA3034@mafr.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 X-Provags-ID: kundenserver.de abuse@kundenserver.de login:b369618fd1a3462119ba5a921f6f235b X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: nsis@ietf.org Subject: [NSIS] Re: NATFW+AUTH_SESSION: Scenarios with multiple authorization tokens X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, thanks for your reply. Comments inline. On Wednesday, 2006-10-18, Jukka MJ Manner wrote: [...] > Still, as an overall comment, if you think multiple authentication pairs > should be possible, then we could just allow multiple AUTH_SESSION objects > within a single message. However, how do we define, which entity checks > which token? The AUTH_SESSION object contains the ID of an authorizing entity, so the NSLP nodes on the path can choose the token from the authorizing entity they trust. Allowing multiple AUTH_SESSION objects is fine, but I'd suggest to assign different IDs to each of them. As far as I know, none of the other NSIS protocols allows multiple objects with the same ID. This way, it's very easy to store them in arrays or hash maps in an implementation. In case only two different tokens should be supported, two IDs could be assigned: One for the sender domain and one for the receiver domain. I'm not sure if more than two tokens are realistic. Cheers, Matthias _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 19 04:15:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaT3P-0006Yg-Ss; Thu, 19 Oct 2006 04:15:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaT3O-0006QH-BK for nsis@ietf.org; Thu, 19 Oct 2006 04:15:02 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaT3K-0003ls-My for nsis@ietf.org; Thu, 19 Oct 2006 04:15:02 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 091234F0004; Thu, 19 Oct 2006 10:12:09 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 10:12:08 +0200 Received: from ericsson.com ([147.214.26.58]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 10:12:07 +0200 Message-ID: <45373357.8080507@ericsson.com> Date: Thu, 19 Oct 2006 10:12:07 +0200 From: Lars Westberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com Subject: Re: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt References: In-Reply-To: X-OriginalArrivalTime: 19 Oct 2006 08:12:07.0401 (UTC) FILETIME=[44D25590:01C6F356] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: gash@att.com, karagian@cs.utwente.nl, oran@cisco.com, nsis@ietf.org, cornelia.kappler@siemens.com X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2075899725==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============2075899725== Content-Type: multipart/alternative; boundary="------------090705080902000808040109" This is a multi-part message in MIME format. --------------090705080902000808040109 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit if you should call for consensus, you have to consider other alternative as well, not just one person opinion. Jukkas proposal should be one of them. -lasse john.loughney@nokia.com wrote: > Dave, > > Thanks for your mail, I've been rolling some concepts in my head > but you have boiled them down to 4 concise points: > > >However, it does strike me that this long thread and the > >last-minute discussions on the qspec draft do have a flavor of > >the issues I was raising way back when. Just to remind folks, > >I proposed, more or less: > > > >a) a set of parameters, all mandatory, that describe the > >traffic source in a mathematically complete way. > > > >b) a set of parameters, all optional, which give additional > >hints about characteristics of the source traffic which may > >allow network elements to optimize their treatment > >(compressibility hints, pre- encryption hints) > > > >c) a set of parameters, mostly optional, that describe the QoS > >constraints the source wishes applied to the treatment of this > >traffic (loss rate, jitter, sensitivity to out of order delivery, etc.) > > > >d) a set of handling directives, all optional, which specify > >the source's preferences for for traffic handling (e.g. excess > >treatment) > > So, at this point, I cannot think of a better set of concepts > to call concensus on. I'm going to issue a concensus call > to finalize this. I see your points as the basic issue to resolve. > > thanks, > John > --------------090705080902000808040109 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit if you should call for consensus, you have to consider other alternative as well, not just one person opinion.

Jukkas proposal should be one of them.

-lasse

john.loughney@nokia.com wrote:
RE: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

Dave,

Thanks for your mail, I've been rolling some concepts in my head
but you have boiled them down to 4 concise points:

>However, it does strike me that this long thread and the
>last-minute discussions on the qspec draft do have a flavor of
>the issues I was raising way back when. Just to remind folks,
>I proposed, more or less:
>
>a) a set of parameters, all mandatory, that describe the
>traffic source in a mathematically complete way.
>
>b) a set of parameters, all optional, which give additional
>hints about characteristics of the source traffic which may
>allow network elements to optimize their treatment
>(compressibility hints, pre- encryption hints)
>
>c) a set of parameters, mostly optional, that describe the QoS
>constraints the source wishes applied to the treatment of this
>traffic (loss rate, jitter, sensitivity to out of order delivery, etc.)
>
>d) a set of handling directives, all optional, which specify
>the source's preferences for for traffic handling (e.g. excess
>treatment)

So, at this point, I cannot think of a better set of concepts
to call concensus on.  I'm going to issue a concensus call
to finalize this.  I see your points as the basic issue to resolve.

thanks,
John

--------------090705080902000808040109-- --===============2075899725== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============2075899725==-- From nsis-bounces@ietf.org Thu Oct 19 04:37:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaTO7-0006ZO-Dh; Thu, 19 Oct 2006 04:36:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaTO6-0006YY-1K for nsis@ietf.org; Thu, 19 Oct 2006 04:36:26 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaTO3-0007Y5-Co for nsis@ietf.org; Thu, 19 Oct 2006 04:36:26 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9J8aEWr026173; Thu, 19 Oct 2006 11:36:14 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 11:36:13 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 11:36:13 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Date: Thu, 19 Oct 2006 11:36:12 +0300 Message-ID: In-Reply-To: <45373357.8080507@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Thread-Index: AcbzVsvzY8oaWrjDTguSC+IaKCQy/gAAsnag From: To: X-OriginalArrivalTime: 19 Oct 2006 08:36:13.0727 (UTC) FILETIME=[A2E62AF0:01C6F359] X-Spam-Score: 0.3 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Cc: gash@att.com, karagian@cs.utwente.nl, oran@cisco.com, nsis@ietf.org, cornelia.kappler@siemens.com X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1087894845==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============1087894845== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F359.A23A9CC1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F359.A23A9CC1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think that Jukka's suggestion basically falls under Dave's choice D. =20 John ________________________________ From: ext Lars Westberg [mailto:Lars.westberg@ericsson.com]=20 Sent: 19 October, 2006 11:12 To: Loughney John (Nokia-NRC/Helsinki) Cc: oran@cisco.com; gash@att.com; karagian@cs.utwente.nl; nsis@ietf.org; cornelia.kappler@siemens.com Subject: Re: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt =09 =09 if you should call for consensus, you have to consider other alternative as well, not just one person opinion. =09 Jukkas proposal should be one of them. =09 -lasse =09 john.loughney@nokia.com wrote: =09 Dave, =09 Thanks for your mail, I've been rolling some concepts in my head but you have boiled them down to 4 concise points: =09 >However, it does strike me that this long thread and the >last-minute discussions on the qspec draft do have a flavor of >the issues I was raising way back when. Just to remind folks, >I proposed, more or less: > >a) a set of parameters, all mandatory, that describe the >traffic source in a mathematically complete way. > >b) a set of parameters, all optional, which give additional >hints about characteristics of the source traffic which may >allow network elements to optimize their treatment >(compressibility hints, pre- encryption hints) > >c) a set of parameters, mostly optional, that describe the QoS >constraints the source wishes applied to the treatment of this >traffic (loss rate, jitter, sensitivity to out of order delivery, etc.) > >d) a set of handling directives, all optional, which specify >the source's preferences for for traffic handling (e.g. excess >treatment) =09 So, at this point, I cannot think of a better set of concepts to call concensus on. I'm going to issue a concensus call to finalize this. I see your points as the basic issue to resolve. =09 thanks, John =09 ------_=_NextPart_001_01C6F359.A23A9CC1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I think that Jukka's suggestion basically falls = under=20 Dave's choice D.
 
John

From: ext Lars Westberg=20 [mailto:Lars.westberg@ericsson.com]
Sent: 19 October, 2006=20 11:12
To: Loughney John (Nokia-NRC/Helsinki)
Cc:=20 oran@cisco.com; gash@att.com; karagian@cs.utwente.nl; nsis@ietf.org;=20 cornelia.kappler@siemens.com
Subject: Re: AW: AW: [NSIS] I-D = ACTION:draft-ietf-nsis-qspec-12.txt

if you should call for consensus, you have to consider = other=20 alternative as well, not just one person opinion.

Jukkas = proposal=20 should be one of them.

-lasse

john.loughney@nokia.com = wrote:

Dave,

Thanks for your mail, I've been = rolling some=20 concepts in my head
but you have boiled them down to 4 concise=20 points:

>However, it does strike me that this long thread = and=20 the
>last-minute discussions on the qspec draft do have a = flavor=20 of
>the issues I was raising way back when. Just to remind=20 folks,
>I proposed, more or less:
>
>a) a set of=20 parameters, all mandatory, that describe the
>traffic source = in a=20 mathematically complete way.
>
>b) a set of parameters, = all=20 optional, which give additional
>hints about characteristics = of the=20 source traffic which may
>allow network elements to optimize = their=20 treatment
>(compressibility hints, pre- encryption=20 hints)
>
>c) a set of parameters, mostly optional, that = describe=20 the QoS
>constraints the source wishes applied to the = treatment of=20 this
>traffic (loss rate, jitter, sensitivity to out of order=20 delivery, etc.)
>
>d) a set of handling directives, all=20 optional, which specify
>the source's preferences for for = traffic=20 handling (e.g. excess
>treatment)

So, at this point, I = cannot=20 think of a better set of concepts
to call concensus on.  I'm = going=20 to issue a concensus call
to finalize this.  I see your = points as=20 the basic issue to=20 resolve.

thanks,
John

<= /BODY> ------_=_NextPart_001_01C6F359.A23A9CC1-- --===============1087894845== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============1087894845==-- From nsis-bounces@ietf.org Thu Oct 19 05:04:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaToD-00048r-EL; Thu, 19 Oct 2006 05:03:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaToD-00048m-19 for nsis@ietf.org; Thu, 19 Oct 2006 05:03:25 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaToB-0003Sf-Jw for nsis@ietf.org; Thu, 19 Oct 2006 05:03:25 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx2.ira.uni-karlsruhe.de with esmtps id 1GaTnw-0006Op-32; Thu, 19 Oct 2006 11:03:13 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id C4CDDB55C; Thu, 19 Oct 2006 11:03:07 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1GaTnv-00079e-Gn; Thu, 19 Oct 2006 11:03:07 +0200 Message-ID: <45373F4A.1090808@tm.uka.de> Date: Thu, 19 Oct 2006 11:03:06 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Robert Hancock Subject: Re: [NSIS] Proposal to move the QSPEC work forward References: <011401c6f289$e7885230$946b0a0a@comm.ad.roke.co.uk> In-Reply-To: <011401c6f289$e7885230$946b0a0a@comm.ad.roke.co.uk> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.2 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: john.loughney@nokia.com, 'Georgios Karagiannis' , 'Jukka MJ Manner' , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, Robert Hancock wrote: > 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. 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. > (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.) 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. > 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. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 19 05:05:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaTpO-0005fh-Qk; Thu, 19 Oct 2006 05:04:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaTpN-0005fA-Jz for nsis@ietf.org; Thu, 19 Oct 2006 05:04:37 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaTpM-0003aa-8S for nsis@ietf.org; Thu, 19 Oct 2006 05:04:37 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 19 Oct 2006 02:04:35 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9J94ZB8016949; Thu, 19 Oct 2006 02:04:35 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9J94ZAo008847; Thu, 19 Oct 2006 02:04:35 -0700 (PDT) Received: from [10.51.0.33] (rtp-vpn2-97.cisco.com [10.82.240.97]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k9J8qIfl007981; Thu, 19 Oct 2006 01:52:28 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Date: Thu, 19 Oct 2006 05:03:20 -0400 To: X-Mailer: Apple Mail (2.752.2) Authentication-Results: sj-dkim-1.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=3211; t=1161248675; x=1162112675; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:David=20R=20Oran=20 |Subject:Re=3A=20AW=3A=20AW=3A=20[NSIS]=20I-D=20ACTION=3Adraft-ietf-nsis-qspec-12 .txt; X=v=3Dcisco.com=3B=20h=3Df+6Vf90G0v+1In+pNmK/Ey+4Q0M=3D; b=cYCioYLWO5AgXTLhsMwRIa20JW+t31bZVYi1MIdjOibzC/ku71J8ePflqkOMdUyT4yNLFJKJ Ep3ss6YrweZK6qro8gUZQgfeAOeuR9AkfmY36wt9bwYQdm4pKc86bkYV; X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: gash@att.com, karagian@cs.utwente.nl, Lars.westberg@ericsson.com, nsis@ietf.org, cornelia.kappler@siemens.com X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org On Oct 19, 2006, at 4:36 AM, wrote: > I think that Jukka's suggestion basically falls under Dave's choice D. > Uh I didn't posit those as choices. I posited the group as a single choice, and (a)-(d) as a formal taxonometric system for how to describe the parameters. The fact that parameters in groups (b)-(d) are mostly optional is a separate degree of freedom. If you buy my taxonomy it becomes much more obvious (at least to me) what should be mandatory and it gives us a handle to identify, and hopefully eliminate parameters that have highly overlapping semantics (e.g. average rate versus bandwidth). For example, if the user puts in a certain parameter in group (c)"QoS constraints", and the requested value cannot be met by the "QoS Model" somewhere along the path, then admission control fails and the user is told "no". Conversely, if the user does not care about some QoS constraint parameter, or sets it to a loose constraint e.g. 10% loss is ok, then many QoS models can meet the traffic description in a given TSPEC from group (a). Another property of this taxonomy is that it makes QoS models much less important in the architecture of NSIS, which some people might find an advantage, and some not. Dave Oran. > > John > > From: ext Lars Westberg [mailto:Lars.westberg@ericsson.com] > Sent: 19 October, 2006 11:12 > To: Loughney John (Nokia-NRC/Helsinki) > Cc: oran@cisco.com; gash@att.com; karagian@cs.utwente.nl; > nsis@ietf.org; cornelia.kappler@siemens.com > Subject: Re: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt > > if you should call for consensus, you have to consider other > alternative as well, not just one person opinion. > > Jukkas proposal should be one of them. > > -lasse > > john.loughney@nokia.com wrote: >> Dave, >> >> Thanks for your mail, I've been rolling some concepts in my head >> but you have boiled them down to 4 concise points: >> >> >However, it does strike me that this long thread and the >> >last-minute discussions on the qspec draft do have a flavor of >> >the issues I was raising way back when. Just to remind folks, >> >I proposed, more or less: >> > >> >a) a set of parameters, all mandatory, that describe the >> >traffic source in a mathematically complete way. >> > >> >b) a set of parameters, all optional, which give additional >> >hints about characteristics of the source traffic which may >> >allow network elements to optimize their treatment >> >(compressibility hints, pre- encryption hints) >> > >> >c) a set of parameters, mostly optional, that describe the QoS >> >constraints the source wishes applied to the treatment of this >> >traffic (loss rate, jitter, sensitivity to out of order delivery, >> etc.) >> > >> >d) a set of handling directives, all optional, which specify >> >the source's preferences for for traffic handling (e.g. excess >> >treatment) >> >> So, at this point, I cannot think of a better set of concepts >> to call concensus on. I'm going to issue a concensus call >> to finalize this. I see your points as the basic issue to resolve. >> >> thanks, >> John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 19 05:07:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaTrL-0001JC-DH; Thu, 19 Oct 2006 05:06:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaTrK-0001J7-Ov for nsis@ietf.org; Thu, 19 Oct 2006 05:06:38 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaTrJ-0003r6-Ds for nsis@ietf.org; Thu, 19 Oct 2006 05:06:38 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-1.cisco.com with ESMTP; 19 Oct 2006 02:06:37 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9J96aaf026094; Thu, 19 Oct 2006 02:06:36 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k9J96ZOV025401; Thu, 19 Oct 2006 02:06:35 -0700 (PDT) Received: from [10.51.0.33] (rtp-vpn2-97.cisco.com [10.82.240.97]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k9J8sRGO008029; Thu, 19 Oct 2006 01:54:30 -0700 In-Reply-To: <45373F4A.1090808@tm.uka.de> References: <011401c6f289$e7885230$946b0a0a@comm.ad.roke.co.uk> <45373F4A.1090808@tm.uka.de> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [NSIS] Proposal to move the QSPEC work forward Date: Thu, 19 Oct 2006 05:05:28 -0400 To: Roland Bless X-Mailer: Apple Mail (2.752.2) Authentication-Results: sj-dkim-8.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=2409; t=1161248796; x=1162112796; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:David=20R=20Oran=20 |Subject:Re=3A=20[NSIS]=20Proposal=20to=20move=20the=20QSPEC=20work=20forward; X=v=3Dcisco.com=3B=20h=3DnjGkRzfeaTz56ILMnMysXHoWo1Y=3D; b=j/yc2B+uXkgPBsA1QKeM73t0EpU79wheaRlznBLOtlHzbLMs75u+znhOkl842QE78ANZ7AIk HPeNtb32K7HzmrdEdTKJC7YyxS5MfkZJ65DDjoLtbVY1akz44yudaCkM; X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: john.loughney@nokia.com, 'Georgios Karagiannis' , 'Jukka MJ Manner' , nsis@ietf.org, Robert Hancock X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org On Oct 19, 2006, at 5:03 AM, Roland Bless wrote: > Hi, > > Robert Hancock wrote: >> 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. > Templates are a way of institutionalizing non-interoperability. I agree with Robert that this is an admission of a major defeat. Dave Oran. > 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. > >> (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.) > > 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. > >> 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. > > Regards, > Roland > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 19 05:24:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaU8H-0004Wg-16; Thu, 19 Oct 2006 05:24:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaU8F-0004W8-Pe for nsis@ietf.org; Thu, 19 Oct 2006 05:24:07 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaSwD-0001gu-V6 for nsis@ietf.org; Thu, 19 Oct 2006 04:07:40 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9J87LNp020446; Thu, 19 Oct 2006 11:07:21 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 11:07:21 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 11:07:20 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Date: Thu, 19 Oct 2006 11:07:20 +0300 Message-ID: In-Reply-To: <72A0C76B-6118-4734-92EF-FBAB4577B0CA@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Thread-Index: AcbzPNs/7miN3KWJSwG9SPRi90n8ugAF/deQ From: To: , X-OriginalArrivalTime: 19 Oct 2006 08:07:20.0864 (UTC) FILETIME=[9A084200:01C6F355] X-Spam-Score: 0.2 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: gash@att.com, karagian@cs.utwente.nl, nsis@ietf.org, cornelia.kappler@siemens.com X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Dave, Thanks for your mail, I've been rolling some concepts in my head but you have boiled them down to 4 concise points: >However, it does strike me that this long thread and the=20 >last-minute discussions on the qspec draft do have a flavor of=20 >the issues I was raising way back when. Just to remind folks,=20 >I proposed, more or less: > >a) a set of parameters, all mandatory, that describe the=20 >traffic source in a mathematically complete way. > >b) a set of parameters, all optional, which give additional=20 >hints about characteristics of the source traffic which may=20 >allow network elements to optimize their treatment=20 >(compressibility hints, pre- encryption hints) > >c) a set of parameters, mostly optional, that describe the QoS=20 >constraints the source wishes applied to the treatment of this=20 >traffic (loss rate, jitter, sensitivity to out of order delivery, etc.) > >d) a set of handling directives, all optional, which specify=20 >the source's preferences for for traffic handling (e.g. excess=20 >treatment) So, at this point, I cannot think of a better set of concepts to call concensus on. I'm going to issue a concensus call to finalize this. I see your points as the basic issue to resolve. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 19 05:32:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaUG6-0006lW-Ql; Thu, 19 Oct 2006 05:32:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaUG4-0006fL-Sp for nsis@ietf.org; Thu, 19 Oct 2006 05:32:12 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaUG3-0000d3-G6 for nsis@ietf.org; Thu, 19 Oct 2006 05:32:12 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx2.ira.uni-karlsruhe.de with esmtps id 1GaUFz-0002ON-Bo; Thu, 19 Oct 2006 11:32:08 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 0202DB5A5; Thu, 19 Oct 2006 11:32:07 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1GaUFy-0007Bp-NO; Thu, 19 Oct 2006 11:32:06 +0200 Message-ID: <45374616.6010304@tm.uka.de> Date: Thu, 19 Oct 2006 11:32:06 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: David R Oran Subject: Re: [NSIS] Proposal to move the QSPEC work forward References: <011401c6f289$e7885230$946b0a0a@comm.ad.roke.co.uk> <45373F4A.1090808@tm.uka.de> In-Reply-To: X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.2 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: john.loughney@nokia.com, 'Georgios Karagiannis' , 'Jukka MJ Manner' , nsis@ietf.org, Robert Hancock X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Dave, David R Oran wrote: >> Robert Hancock wrote: >>> 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. >> > 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 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 19 05:37:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaUK8-0001xy-GL; Thu, 19 Oct 2006 05:36:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaUK6-0001xn-Nt for nsis@ietf.org; Thu, 19 Oct 2006 05:36:22 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaUK5-0001RF-3D for nsis@ietf.org; Thu, 19 Oct 2006 05:36:22 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx2.ira.uni-karlsruhe.de with esmtps id 1GaUJx-00033b-Ba; Thu, 19 Oct 2006 11:36:20 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 1A1A9B5A5; Thu, 19 Oct 2006 11:36:13 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1GaUJw-0007C5-NE; Thu, 19 Oct 2006 11:36:12 +0200 Message-ID: <4537470C.7050802@tm.uka.de> Date: Thu, 19 Oct 2006 11:36:12 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: john.loughney@nokia.com Subject: Re: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt References: In-Reply-To: X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.2 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi John. john.loughney@nokia.com wrote: > So, at this point, I cannot think of a better set of concepts > to call concensus on. I'm going to issue a concensus call > to finalize this. I see your points as the basic issue to resolve. Hmm, I guess that you misunderstood Dave's proposal, because as far as I understood these were not alternatives to choose from, but a coarse classification of parameter types, so a QSPEC template would be structured according to a),b),c),d) Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 19 05:40:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaUNI-0004Dy-Eo; Thu, 19 Oct 2006 05:39:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaUNG-00046V-RH for nsis@ietf.org; Thu, 19 Oct 2006 05:39:38 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaUNF-00029s-Hk for nsis@ietf.org; Thu, 19 Oct 2006 05:39:38 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 19 Oct 2006 02:39:37 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9J9daIw015515; Thu, 19 Oct 2006 02:39:36 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k9J9daW4014245; Thu, 19 Oct 2006 02:39:36 -0700 (PDT) Received: from [10.51.0.33] (rtp-vpn2-97.cisco.com [10.82.240.97]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k9J9RUUn008788; Thu, 19 Oct 2006 02:27:30 -0700 In-Reply-To: <4537470C.7050802@tm.uka.de> References: <4537470C.7050802@tm.uka.de> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <74C6C1B7-EAD0-4853-BE57-1173FA249AD8@cisco.com> Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Date: Thu, 19 Oct 2006 05:38:28 -0400 To: Roland Bless X-Mailer: Apple Mail (2.752.2) Authentication-Results: sj-dkim-1.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=768; t=1161250776; x=1162114776; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:David=20R=20Oran=20 |Subject:Re=3A=20AW=3A=20AW=3A=20[NSIS]=20I-D=20ACTION=3Adraft-ietf-nsis-qspec-12 .txt; X=v=3Dcisco.com=3B=20h=3DrF+W4YfHmiE20Ma7XYT6T1viA70=3D; b=W0tdZbaE4KOzN0KhBK2xmGE1WxjfUJyKWmlAJsW8TMa9d/kTY6w/pg0KzlKTkRAiN+u2trZY O5bkSFhjqjR/dDVg5xCUyW60UgIAurRIn6iLyagxzcbxNg0nOO+9cFps; X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: john.loughney@nokia.com, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org On Oct 19, 2006, at 5:36 AM, Roland Bless wrote: > Hi John. > > john.loughney@nokia.com wrote: > >> So, at this point, I cannot think of a better set of concepts >> to call concensus on. I'm going to issue a concensus call >> to finalize this. I see your points as the basic issue to resolve. > > Hmm, I guess that you misunderstood Dave's proposal, because > as far as I understood these were not alternatives to choose from, > but a coarse classification of parameter types, so a QSPEC > template would be structured according to a),b),c),d) > Correct. this is what I intended. > Regards, > Roland > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 19 05:40:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaUNM-0004M2-Pq; Thu, 19 Oct 2006 05:39:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaUNL-0004G6-7M for nsis@ietf.org; Thu, 19 Oct 2006 05:39:43 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaUNJ-0002A1-Kq for nsis@ietf.org; Thu, 19 Oct 2006 05:39:43 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k9J9dPer020341; Thu, 19 Oct 2006 11:39:33 +0200 (MEST) From: "Georgios Karagiannis" To: , Subject: RE: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Date: Thu, 19 Oct 2006 11:39:24 +0200 Message-ID: <000f01c6f362$7c63aed0$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcbzVsvzY8oaWrjDTguSC+IaKCQy/gAAsnagAAIt37A= X-Spam-Score: -5.479 () ALL_TRUSTED, AWL, BAYES_00, FVGT_s_OBFU_Q1, HTML_50_60, HTML_MESSAGE, HTML_TITLE_EMPTY X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Thu, 19 Oct 2006 11:39:34 +0200 (MEST) X-Spam-Score: 0.1 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b Cc: gash@att.com, oran@cisco.com, nsis@ietf.org, cornelia.kappler@siemens.com X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0711426033==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0711426033== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01C6F373.3FEC7ED0" This is a multi-part message in MIME format. ------=_NextPart_000_0010_01C6F373.3FEC7ED0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi John I think that Jukka's proposal could cover b), c) and d). Best regards, Georgios _____ From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: donderdag 19 oktober 2006 10:36 To: Lars.westberg@ericsson.com Cc: oran@cisco.com; gash@att.com; karagian@cs.utwente.nl; nsis@ietf.org; cornelia.kappler@siemens.com Subject: RE: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt I think that Jukka's suggestion basically falls under Dave's choice D. John _____ From: ext Lars Westberg [mailto:Lars.westberg@ericsson.com] Sent: 19 October, 2006 11:12 To: Loughney John (Nokia-NRC/Helsinki) Cc: oran@cisco.com; gash@att.com; karagian@cs.utwente.nl; nsis@ietf.org; cornelia.kappler@siemens.com Subject: Re: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt if you should call for consensus, you have to consider other alternative as well, not just one person opinion. Jukkas proposal should be one of them. -lasse john.loughney@nokia.com wrote: Dave, Thanks for your mail, I've been rolling some concepts in my head but you have boiled them down to 4 concise points: >However, it does strike me that this long thread and the >last-minute discussions on the qspec draft do have a flavor of >the issues I was raising way back when. Just to remind folks, >I proposed, more or less: > >a) a set of parameters, all mandatory, that describe the >traffic source in a mathematically complete way. > >b) a set of parameters, all optional, which give additional >hints about characteristics of the source traffic which may >allow network elements to optimize their treatment >(compressibility hints, pre- encryption hints) > >c) a set of parameters, mostly optional, that describe the QoS >constraints the source wishes applied to the treatment of this >traffic (loss rate, jitter, sensitivity to out of order delivery, etc.) > >d) a set of handling directives, all optional, which specify >the source's preferences for for traffic handling (e.g. excess >treatment) So, at this point, I cannot think of a better set of concepts to call concensus on. I'm going to issue a concensus call to finalize this. I see your points as the basic issue to resolve. thanks, John ------=_NextPart_000_0010_01C6F373.3FEC7ED0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi John
 
I think that Jukka's proposal could cover b), = c) and=20 d).
 
Best regards,
Georgios
 

From: john.loughney@nokia.com=20 [mailto:john.loughney@nokia.com]
Sent: donderdag 19 oktober = 2006=20 10:36
To: Lars.westberg@ericsson.com
Cc: = oran@cisco.com;=20 gash@att.com; karagian@cs.utwente.nl; nsis@ietf.org;=20 cornelia.kappler@siemens.com
Subject: RE: AW: AW: [NSIS] I-D = ACTION:draft-ietf-nsis-qspec-12.txt

I think that Jukka's suggestion basically = falls under=20 Dave's choice D.
 
John

From: ext Lars Westberg=20 [mailto:Lars.westberg@ericsson.com]
Sent: 19 October, = 2006=20 11:12
To: Loughney John (Nokia-NRC/Helsinki)
Cc: = oran@cisco.com; gash@att.com; karagian@cs.utwente.nl; nsis@ietf.org; = cornelia.kappler@siemens.com
Subject: Re: AW: AW: [NSIS] = I-D=20 ACTION:draft-ietf-nsis-qspec-12.txt

if you should call for consensus, you have to consider = other=20 alternative as well, not just one person opinion.

Jukkas = proposal=20 should be one of them.

-lasse

john.loughney@nokia.com = wrote:

Dave,

Thanks for your mail, I've been = rolling some=20 concepts in my head
but you have boiled them down to 4 concise=20 points:

>However, it does strike me that this long = thread and=20 the
>last-minute discussions on the qspec draft do have a = flavor=20 of
>the issues I was raising way back when. Just to remind=20 folks,
>I proposed, more or less:
>
>a) a set of = parameters, all mandatory, that describe the
>traffic source = in a=20 mathematically complete way.
>
>b) a set of = parameters, all=20 optional, which give additional
>hints about characteristics = of the=20 source traffic which may
>allow network elements to optimize = their=20 treatment
>(compressibility hints, pre- encryption=20 hints)
>
>c) a set of parameters, mostly optional, = that=20 describe the QoS
>constraints the source wishes applied to = the=20 treatment of this
>traffic (loss rate, jitter, sensitivity = to out of=20 order delivery, etc.)
>
>d) a set of handling = directives, all=20 optional, which specify
>the source's preferences for for = traffic=20 handling (e.g. excess
>treatment)

So, at this point, = I cannot=20 think of a better set of concepts
to call concensus on.  = I'm going=20 to issue a concensus call
to finalize this.  I see your = points as=20 the basic issue to=20 = resolve.

thanks,
John

<= /BLOCKQUOTE> ------=_NextPart_000_0010_01C6F373.3FEC7ED0-- --===============0711426033== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0711426033==-- From nsis-bounces@ietf.org Thu Oct 19 05:56:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaUca-0008MN-S3; Thu, 19 Oct 2006 05:55:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaUcZ-0008Lz-M8 for nsis@ietf.org; Thu, 19 Oct 2006 05:55:27 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaUcY-0005h3-77 for nsis@ietf.org; Thu, 19 Oct 2006 05:55:27 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx2.ira.uni-karlsruhe.de with esmtps id 1GaUcR-0006HI-PP for ; Thu, 19 Oct 2006 11:55:25 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 16435B58B for ; Thu, 19 Oct 2006 11:55:19 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1GaUcQ-0007DT-Pd for nsis@ietf.org; Thu, 19 Oct 2006 11:55:18 +0200 Message-ID: <45374B86.3070404@tm.uka.de> Date: Thu, 19 Oct 2006 11:55:18 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: nsis@ietf.org X-Enigmail-Version: 0.94.1.1 Content-Type: multipart/mixed; boundary="------------070305090804000404080408" X-Spam-Score: -4.2 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Subject: [NSIS] [Fwd: I-D ACTION:draft-bless-nsis-resv-aggr-00.txt] X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --------------070305090804000404080408 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Hi all, the earlier mentioned draft was now published in the I-D repository: -------- Original-Message -------- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Inter-Domain Reservation Aggregation for QoS NSLP Author(s) : R. Bless, M. Doll Filename : draft-bless-nsis-resv-aggr-00.txt Pages : 19 Date : 2006-10-18 QoS NSLP is a recently proposed signaling protocol that allows to establish QoS reservations in the Internet. In order to enable large scale deployment, inter-domain aggregation should be considered as mechanism to allow for the necessary scalability. This draft describes the major problems that must be solved and proposes also solutions to these problems, requiring only modest modifications and extensions to the currently defined GIST and QoS NSLP specifications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bless-nsis-resv-aggr-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-bless-nsis-resv-aggr-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-bless-nsis-resv-aggr-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------070305090804000404080408 Content-Type: Message/External-body; name="draft-bless-nsis-resv-aggr-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-bless-nsis-resv-aggr-00.txt" Content-Type: text/plain Content-ID: <2006-10-18142715.I-D@ietf.org> --------------070305090804000404080408 Content-Type: text/plain; name="file:///tmp/nsmail.asc" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="file:///tmp/nsmail.asc" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --------------070305090804000404080408 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --------------070305090804000404080408-- From nsis-bounces@ietf.org Thu Oct 19 06:05:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaUlH-0003Wr-Rm; Thu, 19 Oct 2006 06:04:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaUlG-0003WR-VY for nsis@ietf.org; Thu, 19 Oct 2006 06:04:26 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaUlF-0007Qy-DX for nsis@ietf.org; Thu, 19 Oct 2006 06:04:26 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k9JA4CuX025723; Thu, 19 Oct 2006 12:04:16 +0200 (MEST) From: "Georgios Karagiannis" To: , Subject: RE: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Date: Thu, 19 Oct 2006 12:04:09 +0200 Message-ID: <002101c6f365$eeb23260$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcbzVsvzY8oaWrjDTguSC+IaKCQy/gAAsnagAALt/QA= X-Spam-Score: -5.222 () ALL_TRUSTED, AWL, BAYES_00, FVGT_s_OBFU_Q1, HTML_MESSAGE, HTML_TITLE_EMPTY, J_CHICKENPOX_35 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Thu, 19 Oct 2006 12:04:19 +0200 (MEST) X-Spam-Score: 0.1 (/) X-Scan-Signature: 453b1bfcf0292bffe4cab90ba115f503 Cc: gash@att.com, oran@cisco.com, nsis@ietf.org, cornelia.kappler@siemens.com X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0033042523==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0033042523== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0022_01C6F376.B23B0260" This is a multi-part message in MIME format. ------=_NextPart_000_0022_01C6F376.B23B0260 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi John After studying the a) to d) points of Dave in more detail I think that they are different than the proposal of Jukka! Actually point a) falls under the responability of an interworking activity, while points b) c) and d) fall under the QSPEC tem[plate activity! Thus I thinkl that the call should first of all cover the proposal of Jukka! If we follow the proposal of Jukka, then we can a) to provide the interworking and follow b), c) and d) to finalise the QSPEC template, that in my opinion means: make all mandator optional and we are done with the QWSPEC template draft! best regards, Georgios _____ From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: donderdag 19 oktober 2006 10:36 To: Lars.westberg@ericsson.com Cc: oran@cisco.com; gash@att.com; karagian@cs.utwente.nl; nsis@ietf.org; cornelia.kappler@siemens.com Subject: RE: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt I think that Jukka's suggestion basically falls under Dave's choice D. John _____ From: ext Lars Westberg [mailto:Lars.westberg@ericsson.com] Sent: 19 October, 2006 11:12 To: Loughney John (Nokia-NRC/Helsinki) Cc: oran@cisco.com; gash@att.com; karagian@cs.utwente.nl; nsis@ietf.org; cornelia.kappler@siemens.com Subject: Re: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt if you should call for consensus, you have to consider other alternative as well, not just one person opinion. Jukkas proposal should be one of them. -lasse john.loughney@nokia.com wrote: Dave, Thanks for your mail, I've been rolling some concepts in my head but you have boiled them down to 4 concise points: >However, it does strike me that this long thread and the >last-minute discussions on the qspec draft do have a flavor of >the issues I was raising way back when. Just to remind folks, >I proposed, more or less: > >a) a set of parameters, all mandatory, that describe the >traffic source in a mathematically complete way. > >b) a set of parameters, all optional, which give additional >hints about characteristics of the source traffic which may >allow network elements to optimize their treatment >(compressibility hints, pre- encryption hints) > >c) a set of parameters, mostly optional, that describe the QoS >constraints the source wishes applied to the treatment of this >traffic (loss rate, jitter, sensitivity to out of order delivery, etc.) > >d) a set of handling directives, all optional, which specify >the source's preferences for for traffic handling (e.g. excess >treatment) So, at this point, I cannot think of a better set of concepts to call concensus on. I'm going to issue a concensus call to finalize this. I see your points as the basic issue to resolve. thanks, John ------=_NextPart_000_0022_01C6F376.B23B0260 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi John
 
After studying the a) to d) points of Dave in = more detail=20
I think that they are different than the = proposal of=20 Jukka!
 
Actually point a) falls under the responability = of an=20 interworking activity, while points b) c) and d)
fall under the QSPEC tem[plate=20 activity!
 
Thus I thinkl that the call should first of all = cover the=20 proposal of Jukka!
 
If we follow the proposal of Jukka, then we can = a) to=20 provide the interworking
and follow b), c) and d)
to finalise the QSPEC template, that in my = opinion=20 means:
make all mandator optional and we are done with = the QWSPEC=20 template draft!
 
best regards,
Georgios
 

From: john.loughney@nokia.com=20 [mailto:john.loughney@nokia.com]
Sent: donderdag 19 oktober = 2006=20 10:36
To: Lars.westberg@ericsson.com
Cc: = oran@cisco.com;=20 gash@att.com; karagian@cs.utwente.nl; nsis@ietf.org;=20 cornelia.kappler@siemens.com
Subject: RE: AW: AW: [NSIS] I-D = ACTION:draft-ietf-nsis-qspec-12.txt

I think that Jukka's suggestion basically = falls under=20 Dave's choice D.
 
John

From: ext Lars Westberg=20 [mailto:Lars.westberg@ericsson.com]
Sent: 19 October, = 2006=20 11:12
To: Loughney John (Nokia-NRC/Helsinki)
Cc: = oran@cisco.com; gash@att.com; karagian@cs.utwente.nl; nsis@ietf.org; = cornelia.kappler@siemens.com
Subject: Re: AW: AW: [NSIS] = I-D=20 ACTION:draft-ietf-nsis-qspec-12.txt

if you should call for consensus, you have to consider = other=20 alternative as well, not just one person opinion.

Jukkas = proposal=20 should be one of them.

-lasse

john.loughney@nokia.com = wrote:

Dave,

Thanks for your mail, I've been = rolling some=20 concepts in my head
but you have boiled them down to 4 concise=20 points:

>However, it does strike me that this long = thread and=20 the
>last-minute discussions on the qspec draft do have a = flavor=20 of
>the issues I was raising way back when. Just to remind=20 folks,
>I proposed, more or less:
>
>a) a set of = parameters, all mandatory, that describe the
>traffic source = in a=20 mathematically complete way.
>
>b) a set of = parameters, all=20 optional, which give additional
>hints about characteristics = of the=20 source traffic which may
>allow network elements to optimize = their=20 treatment
>(compressibility hints, pre- encryption=20 hints)
>
>c) a set of parameters, mostly optional, = that=20 describe the QoS
>constraints the source wishes applied to = the=20 treatment of this
>traffic (loss rate, jitter, sensitivity = to out of=20 order delivery, etc.)
>
>d) a set of handling = directives, all=20 optional, which specify
>the source's preferences for for = traffic=20 handling (e.g. excess
>treatment)

So, at this point, = I cannot=20 think of a better set of concepts
to call concensus on.  = I'm going=20 to issue a concensus call
to finalize this.  I see your = points as=20 the basic issue to=20 = resolve.

thanks,
John

<= /BLOCKQUOTE> ------=_NextPart_000_0022_01C6F376.B23B0260-- --===============0033042523== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0033042523==-- From nsis-bounces@ietf.org Thu Oct 19 06:26:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaV5d-0003Mp-Pg; Thu, 19 Oct 2006 06:25:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaV5c-0003M6-PG for nsis@ietf.org; Thu, 19 Oct 2006 06:25:28 -0400 Received: from smtp.mei.co.jp ([133.183.129.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaUwm-0001Af-9f for nsis@ietf.org; Thu, 19 Oct 2006 06:16:21 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/bulls) with ESMTP id k9JAGHEp028001 for ; Thu, 19 Oct 2006 19:16:17 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id k9JAGIE03077 for ; Thu, 19 Oct 2006 19:16:18 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/whitesox) with SMTP id k9JAGHF26235 for ; Thu, 19 Oct 2006 19:16:17 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 19 Oct 2006 18:06:05 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD013E36CC@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-marwaha-nsis-aggregation-teardown-signaling-00.txt Thread-Index: Acby71dX/jFmWZBoSLWIqY951EzRPgALbs8gABIMeSA= From: "Shivanajay Marwaha" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: Toyoki Ue , Cheng Hong , Takako Sanda Subject: [NSIS] FW: I-D ACTION:draft-marwaha-nsis-aggregation-teardown-signaling-00.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, We have published an I-D on NSIS Aggregation. Kindly have a look and = send your comments/suggestions. Thanks, Shivanajay -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Thursday, October 19, 2006 3:50 AM To: i-d-announce@ietf.org Subject: I-D = ACTION:draft-marwaha-nsis-aggregation-teardown-signaling-00.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : Problems Analysis of NSIS Aggregation Teardown Signaling in = Mobility Scenarios=20 Author(s) : S. Marwaha, et al. Filename : draft-marwaha-nsis-aggregation-teardown-signaling-00.txt Pages : 13 Date : 2006-10-18 =09 If a Mobile Node communicates with different Corresponding Nodes = and=20 there exists a common path for these sessions, NSIS allows these=20 reservations to be aggregated. However, change of aggregation path=20 caused by mobility event creates problems related to the prompt = removal=20 of the old aggregation state in case Correspondent Nodes are NSIS=20 Initiators, i.e. multiple Correspondent Nodes will send = multiple=20 teardown messages for tearing down the same unused aggregated = section=20 and may cause problems of extra signaling overhead, delay in = tearing=20 down, reliability, redundancy and extra processing overhead. This = draft=20 presents the analysis of these problems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-marwaha-nsis-aggregation-teardo= wn-signaling-00.txt To remove yourself from the I-D Announcement list, send a message to = i-d-announce-request@ietf.org with the word unsubscribe in the body of = the message.=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the = username "anonymous" and a password of your e-mail address. After = logging in, type "cd internet-drafts" and then "get = draft-marwaha-nsis-aggregation-teardown-signaling-00.txt". A list of Internet-Drafts directories can be found in = http://www.ietf.org/shadow.html or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE = /internet-drafts/draft-marwaha-nsis-aggregation-teardown-signaling-00.txt= ". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader = implementation to automatically retrieve the ASCII version of the = Internet-Draft. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 19 06:55:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaVY8-0005YC-Ew; Thu, 19 Oct 2006 06:54:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaVY7-0005Y7-2g for nsis@ietf.org; Thu, 19 Oct 2006 06:54:55 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaVY5-0000ew-NW for nsis@ietf.org; Thu, 19 Oct 2006 06:54:55 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 19 Oct 2006 03:54:54 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9JAsrJa032231; Thu, 19 Oct 2006 03:54:53 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k9JAsrbF012143; Thu, 19 Oct 2006 03:54:53 -0700 (PDT) Received: from [10.51.0.33] (ams3-vpn-dhcp32.cisco.com [10.61.64.32]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k9JAglWF010444; Thu, 19 Oct 2006 03:42:48 -0700 In-Reply-To: <002101c6f365$eeb23260$4c0d5982@dynamic.ewi.utwente.nl> References: <002101c6f365$eeb23260$4c0d5982@dynamic.ewi.utwente.nl> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Date: Thu, 19 Oct 2006 06:53:50 -0400 To: "Georgios Karagiannis" X-Mailer: Apple Mail (2.752.2) Authentication-Results: sj-dkim-8.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=3728; t=1161255293; x=1162119293; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:David=20R=20Oran=20 |Subject:Re=3A=20AW=3A=20AW=3A=20[NSIS]=20I-D=20ACTION=3Adraft-ietf-nsis-qspec-12 .txt; X=v=3Dcisco.com=3B=20h=3Df+6Vf90G0v+1In+pNmK/Ey+4Q0M=3D; b=um9x9Sjg+5wJv9VALxRN60M/LGKvzn5t1ZZdiTYh8SBdh16xH5dxcMGd6z2d77RB7idKierc sDdRfQeHo5AgZnm5uJmmd/rAFPxlQPvtQNrGObapbCLS7evUrCh5TZ2W; X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: john.loughney@nokia.com, gash@att.com, Lars.westberg@ericsson.com, nsis@ietf.org, cornelia.kappler@Siemens.com X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org On Oct 19, 2006, at 6:04 AM, Georgios Karagiannis wrote: > Hi John > > After studying the a) to d) points of Dave in more detail > I think that they are different than the proposal of Jukka! > That is correct. My point was quite different. > Actually point a) falls under the responability of an interworking > activity, while points b) c) and d) > fall under the QSPEC tem[plate activity! > That is not what I intended. The idea was to separate the issue of source traffic description from the questions of exactly what constraints on QoS delivery for such a traffic source have to be met by the QoS elements on the path in order to admission control to succeed. > Thus I thinkl that the call should first of all cover the proposal > of Jukka! > Jukka's proposal is to define a unstructured data schema for QoS parameters so there are no constraints on what can be expressed in an NSIS admission control and QoS signaling transaction. I think this approach basically institutionalizes non-interoperability, and hence I think it is not a good idea. > If we follow the proposal of Jukka, then we can a) to provide the > interworking > and follow b), c) and d) > to finalise the QSPEC template, that in my opinion means: > make all mandator optional and we are done with the QWSPEC template > draft! > We are certainly done, but what then will we have accomplished? > best regards, > Georgios > > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: donderdag 19 oktober 2006 10:36 > To: Lars.westberg@ericsson.com > Cc: oran@cisco.com; gash@att.com; karagian@cs.utwente.nl; > nsis@ietf.org; cornelia.kappler@siemens.com > Subject: RE: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt > > I think that Jukka's suggestion basically falls under Dave's choice D. > > John > > From: ext Lars Westberg [mailto:Lars.westberg@ericsson.com] > Sent: 19 October, 2006 11:12 > To: Loughney John (Nokia-NRC/Helsinki) > Cc: oran@cisco.com; gash@att.com; karagian@cs.utwente.nl; > nsis@ietf.org; cornelia.kappler@siemens.com > Subject: Re: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt > > if you should call for consensus, you have to consider other > alternative as well, not just one person opinion. > > Jukkas proposal should be one of them. > > -lasse > > john.loughney@nokia.com wrote: >> Dave, >> >> Thanks for your mail, I've been rolling some concepts in my head >> but you have boiled them down to 4 concise points: >> >> >However, it does strike me that this long thread and the >> >last-minute discussions on the qspec draft do have a flavor of >> >the issues I was raising way back when. Just to remind folks, >> >I proposed, more or less: >> > >> >a) a set of parameters, all mandatory, that describe the >> >traffic source in a mathematically complete way. >> > >> >b) a set of parameters, all optional, which give additional >> >hints about characteristics of the source traffic which may >> >allow network elements to optimize their treatment >> >(compressibility hints, pre- encryption hints) >> > >> >c) a set of parameters, mostly optional, that describe the QoS >> >constraints the source wishes applied to the treatment of this >> >traffic (loss rate, jitter, sensitivity to out of order delivery, >> etc.) >> > >> >d) a set of handling directives, all optional, which specify >> >the source's preferences for for traffic handling (e.g. excess >> >treatment) >> >> So, at this point, I cannot think of a better set of concepts >> to call concensus on. I'm going to issue a concensus call >> to finalize this. I see your points as the basic issue to resolve. >> >> thanks, >> John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 19 07:27:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaW2q-00031d-J5; Thu, 19 Oct 2006 07:26:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaW2p-0002xX-BP for nsis@ietf.org; Thu, 19 Oct 2006 07:26:39 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaW2n-0006YI-Rq for nsis@ietf.org; Thu, 19 Oct 2006 07:26:39 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9JBQTnw023615; Thu, 19 Oct 2006 14:26:29 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 14:26:29 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 14:26:29 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Date: Thu, 19 Oct 2006 14:26:28 +0300 Message-ID: In-Reply-To: <72A0C76B-6118-4734-92EF-FBAB4577B0CA@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Thread-Index: AcbzPNs/7miN3KWJSwG9SPRi90n8ugANAkxQ From: To: , X-OriginalArrivalTime: 19 Oct 2006 11:26:29.0525 (UTC) FILETIME=[6BFD3C50:01C6F371] X-Spam-Score: 0.2 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: gash@att.com, karagian@cs.utwente.nl, nsis@ietf.org, cornelia.kappler@siemens.com X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Dave, I know that noone bit when you dangled your proposal in front of=20 the wg, but ... >However, it does strike me that this long thread and the=20 >last-minute discussions on the qspec draft do have a flavor of=20 >the issues I was raising way back when. Just to remind folks,=20 >I proposed, more or less: > >a) a set of parameters, all mandatory, that describe the=20 >traffic source in a mathematically complete way. I do see a big value in having this. This could be what all QoS models could map to for interoperability reasons. I think you had said you had such a model in your back pocket, based upon some other work you had been involved in. Would you be able to=20 forward this to the WG? John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 19 07:30:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaW5q-00013w-IC; Thu, 19 Oct 2006 07:29:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaW5q-00011Y-1m for nsis@ietf.org; Thu, 19 Oct 2006 07:29:46 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaW5o-0007Lx-JE for nsis@ietf.org; Thu, 19 Oct 2006 07:29:46 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9JBTWbp010591; Thu, 19 Oct 2006 14:29:32 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 14:29:32 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 14:29:32 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Proposal to move the QSPEC work forward Date: Thu, 19 Oct 2006 14:29:31 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Proposal to move the QSPEC work forward Thread-Index: AcbzXg+ku+AqpAN0QICaadDbJL8ZogAE4zKQ From: To: , X-OriginalArrivalTime: 19 Oct 2006 11:29:32.0025 (UTC) FILETIME=[D8C48690:01C6F371] X-Spam-Score: 0.2 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: karagian@cs.utwente.nl, jmanner@cs.Helsinki.FI, nsis@ietf.org, robert.hancock@roke.co.uk X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Dave, >> Robert Hancock wrote: >>> personally, i don't think this would be a good idea. without a=20 >>> 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=20 >>> sidesteps the interoperability questions. >> >Templates are a way of institutionalizing=20 >non-interoperability. I agree with Robert that this is an=20 >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 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 19 07:31:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaW6g-0002Fw-BI; Thu, 19 Oct 2006 07:30:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaW6f-0002Fn-EY for nsis@ietf.org; Thu, 19 Oct 2006 07:30:37 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaW6d-0007a4-Qv for nsis@ietf.org; Thu, 19 Oct 2006 07:30:37 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9JBUYZL027044; Thu, 19 Oct 2006 14:30:34 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 14:30:34 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 14:30:34 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Date: Thu, 19 Oct 2006 14:30:34 +0300 Message-ID: In-Reply-To: <4537470C.7050802@tm.uka.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Thread-Index: AcbzYk5359i3BUtOT2CYTVLJx/f8kgAD6TvQ From: To: X-OriginalArrivalTime: 19 Oct 2006 11:30:34.0477 (UTC) FILETIME=[FDFDF1D0:01C6F371] X-Spam-Score: 0.2 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Yes, I got the point ... I'll revise my mail. John=20 >-----Original Message----- >From: ext Roland Bless [mailto:bless@tm.uka.de]=20 >Sent: 19 October, 2006 12:36 >To: Loughney John (Nokia-NRC/Helsinki) >Cc: nsis@ietf.org >Subject: Re: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt > >Hi John. > >john.loughney@nokia.com wrote: > >> So, at this point, I cannot think of a better set of=20 >concepts to call=20 >> concensus on. I'm going to issue a concensus call to=20 >finalize this. =20 >> I see your points as the basic issue to resolve. > >Hmm, I guess that you misunderstood Dave's proposal, because=20 >as far as I understood these were not alternatives to choose=20 >from, but a coarse classification of parameter types, so a=20 >QSPEC template would be structured according to a),b),c),d) > >Regards, > Roland > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 19 07:42:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaWHk-0007Zu-Kw; Thu, 19 Oct 2006 07:42:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaWHi-0007Za-KI for nsis@ietf.org; Thu, 19 Oct 2006 07:42:02 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaWHh-0001Pw-20 for nsis@ietf.org; Thu, 19 Oct 2006 07:42:02 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k9JBfaPJ006920; Thu, 19 Oct 2006 13:41:45 +0200 (MEST) From: "Georgios Karagiannis" To: "'David R Oran'" Subject: RE: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Date: Thu, 19 Oct 2006 13:41:32 +0200 Message-ID: <004901c6f373$89ef5570$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcbzbQUmtghxtNbkR6qpPnrPQv+YPAABFCiQ X-Spam-Score: -5.223 () ALL_TRUSTED, AWL, BAYES_00, FVGT_s_OBFU_Q1, J_CHICKENPOX_35 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Thu, 19 Oct 2006 13:41:49 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: john.loughney@nokia.com, gash@att.com, Lars.westberg@ericsson.com, nsis@ietf.org, cornelia.kappler@Siemens.com X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Dave Please see in line! > -----Original Message----- > From: David R Oran [mailto:oran@cisco.com] > Sent: donderdag 19 oktober 2006 12:54 > To: Georgios Karagiannis > Cc: john.loughney@nokia.com; Lars.westberg@ericsson.com; > gash@att.com; nsis@ietf.org; cornelia.kappler@Siemens.com > Subject: Re: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt > > > On Oct 19, 2006, at 6:04 AM, Georgios Karagiannis wrote: > > > Hi John > > > > After studying the a) to d) points of Dave in more detail I > think that > > they are different than the proposal of Jukka! > > > That is correct. My point was quite different. > > > Actually point a) falls under the responability of an interworking > > activity, while points b) c) and d) fall under the QSPEC tem[plate > > activity! > > > That is not what I intended. The idea was to separate the > issue of source traffic description from the questions of > exactly what constraints on QoS delivery for such a traffic > source have to be met by the QoS elements on the path in > order to admission control to succeed. > > > Thus I thinkl that the call should first of all cover the > proposal of > > Jukka! > > > Jukka's proposal is to define a unstructured data schema for > QoS parameters so there are no constraints on what can be > expressed in an NSIS admission control and QoS signaling > transaction. I think this approach basically > institutionalizes non-interoperability, and hence I think it > is not a good idea. Georgios: I think that what Jukka meant is as follows: First let the QSPEC template define the encoding of the QSPEC object and its parameters. However, the QSPEC template will not define which of these parameters are mandatory and which not. Here I however, I could agree with you that the QSPEC template could specify the Traaffic descriptor, i.e., Bandwidth, as a manadtory parameter. This is diferent then having 13 mandatory parameters in the QSPEC template. This will give the opportunity to QoS models to start the deployment phase. Furthermore, the QOS models can however define which of the QSPEc pasrameters (assocaited with the QoS model) can be mandatory and which optional. The problem that remains to be solved is to find out how to interwork between the QoS models. As a starting point the QSPEC template could define one mandatory parameter and that is Bandwidth. This will give the opportunity to let QoS models start the deployment phase. If during the deployment phase we will see that more parameters must be made mandatory then we can start an interworking activity to work out the interoperability problem. > > If we follow the proposal of Jukka, then we can a) to provide the > > interworking and follow b), c) and d) to finalise the QSPEC > template, > > that in my opinion means: > > make all mandator optional and we are done with the QWSPEC template > > draft! > > > We are certainly done, but what then will we have accomplished? Georgios: Please see above. Please note that I agree with you regarding the need of having a mandatory Traffic description, which in my opinion should be Bandwdith. This will allow a basis for interoperability between QoS models. What do you think? Best regards, Georgios > > > > > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > Sent: donderdag 19 oktober 2006 10:36 > > To: Lars.westberg@ericsson.com > > Cc: oran@cisco.com; gash@att.com; karagian@cs.utwente.nl; > > nsis@ietf.org; cornelia.kappler@siemens.com > > Subject: RE: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt > > > > I think that Jukka's suggestion basically falls under > Dave's choice D. > > > > John > > > > From: ext Lars Westberg [mailto:Lars.westberg@ericsson.com] > > Sent: 19 October, 2006 11:12 > > To: Loughney John (Nokia-NRC/Helsinki) > > Cc: oran@cisco.com; gash@att.com; karagian@cs.utwente.nl; > > nsis@ietf.org; cornelia.kappler@siemens.com > > Subject: Re: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt > > > > if you should call for consensus, you have to consider other > > alternative as well, not just one person opinion. > > > > Jukkas proposal should be one of them. > > > > -lasse > > > > john.loughney@nokia.com wrote: > >> Dave, > >> > >> Thanks for your mail, I've been rolling some concepts in > my head but > >> you have boiled them down to 4 concise points: > >> > >> >However, it does strike me that this long thread and the > last-minute > >> >discussions on the qspec draft do have a flavor of the > issues I was > >> >raising way back when. Just to remind folks, I proposed, more or > >> >less: > >> > > >> >a) a set of parameters, all mandatory, that describe the traffic > >> >source in a mathematically complete way. > >> > > >> >b) a set of parameters, all optional, which give additional hints > >> >about characteristics of the source traffic which may > allow network > >> >elements to optimize their treatment (compressibility hints, pre- > >> >encryption hints) > >> > > >> >c) a set of parameters, mostly optional, that describe the QoS > >> >constraints the source wishes applied to the treatment of this > >> >traffic (loss rate, jitter, sensitivity to out of order delivery, > >> etc.) > >> > > >> >d) a set of handling directives, all optional, which specify the > >> >source's preferences for for traffic handling (e.g. excess > >> >treatment) > >> > >> So, at this point, I cannot think of a better set of > concepts to call > >> concensus on. I'm going to issue a concensus call to > finalize this. > >> I see your points as the basic issue to resolve. > >> > >> thanks, > >> John > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 19 07:44:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaWJA-0008Fu-MR; Thu, 19 Oct 2006 07:43:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaWJ9-0008Fh-Hu for nsis@ietf.org; Thu, 19 Oct 2006 07:43:31 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaWJ6-0001mA-OG for nsis@ietf.org; Thu, 19 Oct 2006 07:43:31 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9JBhQVh009295; Thu, 19 Oct 2006 14:43:26 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 14:43:25 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 14:43:26 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 19 Oct 2006 14:43:25 +0300 Message-ID: In-Reply-To: <74C6C1B7-EAD0-4853-BE57-1173FA249AD8@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: QSPEC proposal Thread-Index: AcbzYpnyMxv7/qs3TlWOHIkWh44uegAD3jfw From: To: X-OriginalArrivalTime: 19 Oct 2006 11:43:26.0165 (UTC) FILETIME=[C9F43050:01C6F373] X-Spam-Score: 0.2 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: nsis@ietf.org Subject: [NSIS] QSPEC proposal X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, I've been in transit for a few days, so trying to catch-up on all mails is somewhat challenging. Here's a partially baked proposal, considering the mails on this thread. My proposal for the WG to consider is: 1) We take Dave's proposal as a baseline QSPEC: a) a set of parameters, all mandatory, that describe the traffic source in a mathematically complete way. b) a set of parameters, all optional, which give additional hints about characteristics of the source traffic which may allow network elements to optimize their treatment (compressibility hints, pre- encryption hints) c) a set of parameters, mostly optional, that describe the QoS constraints the source wishes applied to the treatment of this traffic (loss rate, jitter, sensitivity to out of order delivery, etc.) d) a set of handling directives, all optional, which specify the source's preferences for for traffic handling (e.g. excess treatment) 2) Allow QoS Models to use a secondary QSPEC, that may not be mathmetically complete. 3) QoS models specify how to map to the baseline QSPEC. 4) Add a MAP/NO MAP byte, which a QoS Model can use if they want their model mapped (or not) to domains support QoS models. Would this meet people's needs? I could see that point 4 might allow use cases that Lars/Georgios would like. Robert and Dave seem to agree that point 1) is not too far from the current QSPEC. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 19 07:59:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaWY2-0002Ys-JN; Thu, 19 Oct 2006 07:58:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaWY1-0002Yc-RC for nsis@ietf.org; Thu, 19 Oct 2006 07:58:53 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaWY0-0004Kc-R1 for nsis@ietf.org; Thu, 19 Oct 2006 07:58:53 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9JBwfJt001757; Thu, 19 Oct 2006 14:58:42 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 14:58:41 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 14:58:41 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Date: Thu, 19 Oct 2006 14:58:40 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Thread-Index: Acbye4IZ7vmeaP4vRWSoYWr8MvZn4AARbEXAABPFuNAAGO1bQA== From: To: , , X-OriginalArrivalTime: 19 Oct 2006 11:58:41.0357 (UTC) FILETIME=[EB7367D0:01C6F375] X-Spam-Score: 0.2 (/) X-Scan-Signature: 4f585e1bcd209294c6b9386034cecfc6 Cc: gash@att.com, karagian@cs.utwente.nl, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1385583507==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============1385583507== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F375.EB378A8F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F375.EB378A8F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I've got to agree with Chuck on this. How Y.1541 fufills QoS classes is not an NSIS issue. I think it is clear how to carry them, but how the domain deploying Y.1541 verifies things are fufilled is outslide of NSIS. =20 John ________________________________ From: ext cdvorak@research.att.com [mailto:cdvorak@research.att.com]=20 Sent: 19 October, 2006 03:16 To: RADHIKA.R.ROY@saic.com; lars.westberg@ericsson.com; Loughney John (Nokia-NRC/Helsinki) Cc: gash@att.com; karagian@cs.utwente.nl; nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt =09 =09 Radhika =20 Water and oil aside, the Y.1541 QoS classes are not "implementation-specific" as you say. They may use DiffServ, they may use RSVP, they may use something else. How is that implementation-specific? =20 For me, this misunderstanding by you is the root cause of your criticism. (I understand your argument-I just do not agree with it, because it is inaccurate.) =20 The Y.1541 classes are QoS classes that many experts around the world agreed capture, in a reasonably small number, distinct combinations of IP performance parameters capable of supporting virtually all user applications with the requisite QoS. On an e2e basis, a user may for example indicate "I am using IPTV and want to request Y.1541 Class 5, which would satisfy my QoS needs." Networks in the path may implement different QoS schemes (per-hop, per-domain, whatever), but a good NSIS method will still allow the e2e QoS classes (of Y.1541) to be addressed. =20 But there is no effective way to signal this e2e today, and that is what many of us wanted NSIS to do-signal this e2e need, with enough hooks to be useful.=20 =20 If all that is done in NSIS is to make incremental improvements to RSVP, or to focus primarily on signaling peak bandwidth needs, then IMO the end result will not be nearly as useful as many of us had hoped. =20 Chuck Dvorak AT&T Labs Research =09 ________________________________ From: Roy, Radhika R. [mailto:RADHIKA.R.ROY@saic.com]=20 Sent: Wednesday, October 18, 2006 10:37 AM To: lars.westberg@ericsson.com; john.loughney@nokia.com Cc: gash@att.com; Georgios Karagiannis; RADHIKA.R.ROY@saic.com; nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt =20 Lars: =20 You are right. That is why, the QOS model like DiffServ comes into picture. =20 There is another aspect of these QOS models so far the standardization is concerned. That is called interwoking between the different QOS modeling standards. For example, you have mentioned as follows: =20 Inter-operabillity solved by:=20 1) Overprovisioning in the core such as all QoS-requirments are solved. 2) Interoperabillity for different QoS-models =3D>Peak-allocation of bandwidth. =20 All the trends of QOS models have been basically like the above. =20 Recently, we also see some fertile brains have created some so-called "Implementation-specific QOS schemes" that are based on "values" of all QOS parameters. The fundamental problems are that they also called these as QOS models (instead of saying that these are some QOS "implementation" schemes, NOT QOS models). They have even convinced few folks here and there of different standard organizations that they need "interworking" between different QOS models. =20 Here the fundamental problems come. Who is kidding whom trying to mixing between water and oil?=20 =20 Best regards, Radhika ------_=_NextPart_001_01C6F375.EB378A8F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I've got to agree with Chuck on = this.   How=20 Y.1541 fufills QoS classes is not an NSIS issue.  I think it is = clear how=20 to carry them, but how the domain deploying Y.1541 verifies things are = fufilled=20 is outslide of NSIS.
 
John

From: ext cdvorak@research.att.com = [mailto:cdvorak@research.att.com]
Sent: 19 October, 2006=20 03:16
To: RADHIKA.R.ROY@saic.com; = lars.westberg@ericsson.com;=20 Loughney John (Nokia-NRC/Helsinki)
Cc: gash@att.com;=20 karagian@cs.utwente.nl; nsis@ietf.org
Subject: RE: [NSIS] = I-D=20 ACTION:draft-ietf-nsis-qspec-12.txt

Radhika

 

Water and = oil aside,=20 the Y.1541 QoS classes are not = “implementation-specific” as you say.=20 They may use DiffServ, they may use RSVP, they may use something else. = How is=20 that implementation-specific?

 

For me, = this=20 misunderstanding by you is the root cause of your criticism. (I = understand=20 your argument—I just do not agree with it, because it is=20 inaccurate.)

 

The Y.1541 = classes=20 are QoS classes that many experts around the world agreed capture, in = a=20 reasonably small number, distinct combinations of IP performance = parameters=20 capable of supporting virtually all user applications with the = requisite QoS.=20 On an e2e basis, a user may for example indicate “I am using = IPTV and want to=20 request Y.1541 Class 5, which would satisfy my QoS needs.” = Networks in the=20 path may implement different QoS schemes (per-hop, per-domain,=20 whatever), but a good NSIS method will still allow the e2e QoS = classes=20 (of Y.1541) to be addressed.

 

But there = is no=20 effective way to signal this e2e today, and that is what many of us = wanted=20 NSIS to do—signal this e2e need, with enough hooks to be = useful.=20

 

If all that = is done=20 in NSIS is to make incremental improvements to RSVP, or to focus = primarily on=20 signaling peak bandwidth needs, then IMO the end result will not be = nearly as=20 useful as many of us had hoped.

 

Chuck=20 Dvorak

AT&T = Labs=20 Research

From: = Roy, Radhika=20 R. [mailto:RADHIKA.R.ROY@saic.com]
Sent: Wednesday, October 18, = 2006 10:37=20 AM
To:=20 lars.westberg@ericsson.com; john.loughney@nokia.com
Cc: gash@att.com; Georgios = Karagiannis;=20 RADHIKA.R.ROY@saic.com; nsis@ietf.org
Subject: RE: [NSIS] I-D=20 ACTION:draft-ietf-nsis-qspec-12.txt

 

Lars:

 

You are = right. That=20 is why, the QOS model like DiffServ comes into=20 picture.

 

There is = another=20 aspect of these QOS models so far the standardization is concerned. = That is=20 called interwoking between the different QOS modeling standards. For = example,=20 you have mentioned as follows:

 

Inter-operabillity solved by:
1) = Overprovisioning=20 in the core such as all QoS-requirments are solved.
2) = Interoperabillity=20 for different QoS-models =3D>Peak-allocation of=20 bandwidth.

 

All the = trends of QOS=20 models have been basically like the = above.

 

Recently, = we also see=20 some fertile brains have created some so-called = “Implementation-specific QOS=20 schemes” that are based on “values” of all QOS = parameters. The fundamental=20 problems are that they also called these as QOS models (instead of = saying that=20 these are some QOS “implementation” schemes, NOT QOS = models). They have even=20 convinced few folks here and there of different standard organizations = that=20 they need “interworking” between different QOS=20 models.

 

Here the = fundamental=20 problems come. Who is kidding whom trying to mixing between water and = oil?=20

 

Best=20 regards,

Radhika

------_=_NextPart_001_01C6F375.EB378A8F-- --===============1385583507== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============1385583507==-- From nsis-bounces@ietf.org Thu Oct 19 07:59:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaWYN-0002vE-Pc; Thu, 19 Oct 2006 07:59:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaWYM-0002tg-GN for nsis@ietf.org; Thu, 19 Oct 2006 07:59:14 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaWOq-0002ny-Vr for nsis@ietf.org; Thu, 19 Oct 2006 07:49:26 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx2.ira.uni-karlsruhe.de with esmtps id 1GaWOp-00085X-Jm for ; Thu, 19 Oct 2006 13:49:24 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 6BE15B5D9 for ; Thu, 19 Oct 2006 13:49:23 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1GaWOo-0007LA-WF for nsis@ietf.org; Thu, 19 Oct 2006 13:49:23 +0200 Message-ID: <45376642.7020908@tm.uka.de> Date: Thu, 19 Oct 2006 13:49:22 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: "nsis@ietf.org" X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.2 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.5 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [NSIS] GIST issue - PATH MTU v4/v6 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, short question. The draft says: Any message sent in D-mode MUST have a size below a conservative estimate of the path MTU, for which this specification takes the value 512 bytes as a default. It is possible that fragmented Would it be reasonable to have different path MTUs for v4 and v6? For the latter the path MTU could be larger due to its 1280 bytes requirement. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 19 07:59:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaWYS-00031m-IB; Thu, 19 Oct 2006 07:59:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaWYR-0002wv-1d for nsis@ietf.org; Thu, 19 Oct 2006 07:59:19 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaWNX-0002WM-5l for nsis@ietf.org; Thu, 19 Oct 2006 07:48:04 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k9JBlmv8007466; Thu, 19 Oct 2006 13:47:52 +0200 (MEST) From: "Georgios Karagiannis" To: , , Subject: RE: [NSIS] Proposal to move the QSPEC work forward Date: Thu, 19 Oct 2006 13:47:44 +0200 Message-ID: <004a01c6f374$673ffb00$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcbzXg+ku+AqpAN0QICaadDbJL8ZogAE4zKQAACNKdA= X-Spam-Score: -5.523 () ALL_TRUSTED,AWL,BAYES_00,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Thu, 19 Oct 2006 13:47:54 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: jmanner@cs.Helsinki.FI, nsis@ietf.org, robert.hancock@roke.co.uk X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org 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 > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: donderdag 19 oktober 2006 13:30 > To: oran@cisco.com; bless@tm.uka.de > Cc: robert.hancock@roke.co.uk; karagian@cs.utwente.nl; > jmanner@cs.Helsinki.FI; nsis@ietf.org > Subject: RE: [NSIS] Proposal to move the QSPEC work forward > > Dave, > > >> Robert Hancock wrote: > >>> 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. > >> > >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 > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 19 08:00:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaWYd-0003Cn-Tr; Thu, 19 Oct 2006 07:59:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaWYc-0003CN-2T for nsis@ietf.org; Thu, 19 Oct 2006 07:59:30 -0400 Received: from amer-mta08.csc.com ([20.137.52.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaWYa-0005Fk-JJ for nsis@ietf.org; Thu, 19 Oct 2006 07:59:29 -0400 Received: from amer-gw09.csc.com (amer-gw09.csc.com [20.6.39.245]) by amer-mta08.csc.com (Switch-3.1.6/Switch-3.1.0) with ESMTP id k9JBxQwB011493 for ; Thu, 19 Oct 2006 07:59:26 -0400 (EDT) In-Reply-To: Subject: Re: [NSIS] QSPEC proposal To: X-Mailer: Lotus Notes 652HF83 November 04, 2004 Message-ID: From: Janet P Gunn Date: Thu, 19 Oct 2006 07:59:55 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 6.5.3|September 14, 2004) at 10/19/2006 07:58:18 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: oran@cisco.com, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Can you please rephrase number 4? I don't understand it the way it is currently written. Thanks Janet wrote on 10/19/2006 07:43:25 AM: > Hi all, > > I've been in transit for a few days, so trying to catch-up on all mails > is somewhat challenging. Here's a partially baked proposal, considering > the mails on this thread. My proposal for the WG to consider is: > > 1) We take Dave's proposal as a baseline QSPEC: > > a) a set of parameters, all mandatory, that describe the traffic source > in a mathematically complete way. > b) a set of parameters, all optional, which give additional hints about > characteristics of the source traffic which may allow network elements > to optimize their treatment (compressibility hints, pre- encryption > hints) > c) a set of parameters, mostly optional, that describe the QoS > constraints the source wishes applied to the treatment of this traffic > (loss rate, jitter, sensitivity to out of order delivery, etc.) > d) a set of handling directives, all optional, which specify the > source's preferences for for traffic handling (e.g. excess treatment) > > 2) Allow QoS Models to use a secondary QSPEC, that may not be > mathmetically complete. > 3) QoS models specify how to map to the baseline QSPEC. > 4) Add a MAP/NO MAP byte, which a QoS Model can use if they want their > model mapped (or not) to domains support QoS models. > > Would this meet people's needs? I could see that point 4 might allow > use cases that Lars/Georgios would like. > > Robert and Dave seem to agree that point 1) is not too far from the > current QSPEC. > > John > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 19 08:03:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaWcD-0000jS-PD; Thu, 19 Oct 2006 08:03:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaWcB-0000UM-HE for nsis@ietf.org; Thu, 19 Oct 2006 08:03:11 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaWcA-00065p-6H for nsis@ietf.org; Thu, 19 Oct 2006 08:03:11 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 19 Oct 2006 05:03:09 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9JC39YG017555; Thu, 19 Oct 2006 05:03:09 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k9JC39W4023064; Thu, 19 Oct 2006 05:03:09 -0700 (PDT) Received: from [10.51.0.33] (ams3-vpn-dhcp32.cisco.com [10.61.64.32]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k9JBp4QV012214; Thu, 19 Oct 2006 04:51:04 -0700 In-Reply-To: <004a01c6f374$673ffb00$4c0d5982@dynamic.ewi.utwente.nl> References: <004a01c6f374$673ffb00$4c0d5982@dynamic.ewi.utwente.nl> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [NSIS] Proposal to move the QSPEC work forward Date: Thu, 19 Oct 2006 08:02:06 -0400 To: "Georgios Karagiannis" X-Mailer: Apple Mail (2.752.2) Authentication-Results: sj-dkim-4.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=2991; t=1161259389; x=1162123389; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:David=20R=20Oran=20 |Subject:Re=3A=20[NSIS]=20Proposal=20to=20move=20the=20QSPEC=20work=20forward; X=v=3Dcisco.com=3B=20h=3DnjGkRzfeaTz56ILMnMysXHoWo1Y=3D; b=DWqT5Wl9oFBfd+U18spPIMS3QN5X+w6CTLKzrg8rzPUKRRE6ixIGES/qMwovt0xCHYyIqU37 oDGZVwbwxT7lXjBfyPhJM7icFlIDGQKn3iphLCEthLTwIeYvRsSqrEoT; X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: john.loughney@nokia.com, bless@tm.uka.de, jmanner@cs.Helsinki.FI, nsis@ietf.org, robert.hancock@roke.co.uk X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org On Oct 19, 2006, at 7:47 AM, Georgios Karagiannis wrote: > 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. > 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. > 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 - minimum quantum (what RSVP TSPEC calls minimum policed unit) for a complete description of a traffic source. > Best regards, > Georgios > > > > > >> -----Original Message----- >> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] >> Sent: donderdag 19 oktober 2006 13:30 >> To: oran@cisco.com; bless@tm.uka.de >> Cc: robert.hancock@roke.co.uk; karagian@cs.utwente.nl; >> jmanner@cs.Helsinki.FI; nsis@ietf.org >> Subject: RE: [NSIS] Proposal to move the QSPEC work forward >> >> Dave, >> >>>> Robert Hancock wrote: >>>>> 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. >>>> >>> 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 >> _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 19 08:07:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaWfe-0006Do-AH; Thu, 19 Oct 2006 08:06:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaWfd-0006Dj-5Z for nsis@ietf.org; Thu, 19 Oct 2006 08:06:45 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaWfb-0006fO-AQ for nsis@ietf.org; Thu, 19 Oct 2006 08:06:45 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k9JC6Svg009481; Thu, 19 Oct 2006 14:06:32 +0200 (MEST) From: "Georgios Karagiannis" To: , , , Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Date: Thu, 19 Oct 2006 14:06:25 +0200 Message-ID: <005101c6f377$02ee0950$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: Acbye4IZ7vmeaP4vRWSoYWr8MvZn4AARbEXAABPFuNAAGO1bQAAAkQgQ X-Spam-Score: -5.522 () ALL_TRUSTED,AWL,BAYES_00,FVGT_s_OBFU_Q1,HTML_MESSAGE X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Thu, 19 Oct 2006 14:06:36 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2d1100b36d83fed07afbc292d8848e10 Cc: gash@att.com, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0359270276==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0359270276== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0052_01C6F387.C676D950" This is a multi-part message in MIME format. ------=_NextPart_000_0052_01C6F387.C676D950 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi John >> I've got to agree with Chuck on this. How Y.1541 fufills QoS classes >> is not an NSIS issue. I think it is clear how to carry them, but >> how the domain deploying Y.1541 verifies things are fufilled is outslide of NSIS. What do you mean? If NSIS specifies that the QOS classes MUST be interpreted, then it means that they MUST be interpreted by all the QNEs, because the QSPEC template is requirig that from them, even if they do not need to interpret them! Thus actually what NSIS requires from the nodes is to be Diffserv, MPLS and Y.1541 aware, otherwise they will not be able to use NSIS. Is this what we want with NSIS? Best regards, Georgios _____ From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: donderdag 19 oktober 2006 13:59 To: cdvorak@research.att.com; RADHIKA.R.ROY@saic.com; lars.westberg@ericsson.com Cc: gash@att.com; karagian@cs.utwente.nl; nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt I've got to agree with Chuck on this. How Y.1541 fufills QoS classes is not an NSIS issue. I think it is clear how to carry them, but how the domain deploying Y.1541 verifies things are fufilled is outslide of NSIS. John _____ From: ext cdvorak@research.att.com [mailto:cdvorak@research.att.com] Sent: 19 October, 2006 03:16 To: RADHIKA.R.ROY@saic.com; lars.westberg@ericsson.com; Loughney John (Nokia-NRC/Helsinki) Cc: gash@att.com; karagian@cs.utwente.nl; nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Radhika Water and oil aside, the Y.1541 QoS classes are not "implementation-specific" as you say. They may use DiffServ, they may use RSVP, they may use something else. How is that implementation-specific? For me, this misunderstanding by you is the root cause of your criticism. (I understand your argument-I just do not agree with it, because it is inaccurate.) The Y.1541 classes are QoS classes that many experts around the world agreed capture, in a reasonably small number, distinct combinations of IP performance parameters capable of supporting virtually all user applications with the requisite QoS. On an e2e basis, a user may for example indicate "I am using IPTV and want to request Y.1541 Class 5, which would satisfy my QoS needs." Networks in the path may implement different QoS schemes (per-hop, per-domain, whatever), but a good NSIS method will still allow the e2e QoS classes (of Y.1541) to be addressed. But there is no effective way to signal this e2e today, and that is what many of us wanted NSIS to do-signal this e2e need, with enough hooks to be useful. If all that is done in NSIS is to make incremental improvements to RSVP, or to focus primarily on signaling peak bandwidth needs, then IMO the end result will not be nearly as useful as many of us had hoped. Chuck Dvorak AT&T Labs Research _____ From: Roy, Radhika R. [mailto:RADHIKA.R.ROY@saic.com] Sent: Wednesday, October 18, 2006 10:37 AM To: lars.westberg@ericsson.com; john.loughney@nokia.com Cc: gash@att.com; Georgios Karagiannis; RADHIKA.R.ROY@saic.com; nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Lars: You are right. That is why, the QOS model like DiffServ comes into picture. There is another aspect of these QOS models so far the standardization is concerned. That is called interwoking between the different QOS modeling standards. For example, you have mentioned as follows: Inter-operabillity solved by: 1) Overprovisioning in the core such as all QoS-requirments are solved. 2) Interoperabillity for different QoS-models =>Peak-allocation of bandwidth. All the trends of QOS models have been basically like the above. Recently, we also see some fertile brains have created some so-called "Implementation-specific QOS schemes" that are based on "values" of all QOS parameters. The fundamental problems are that they also called these as QOS models (instead of saying that these are some QOS "implementation" schemes, NOT QOS models). They have even convinced few folks here and there of different standard organizations that they need "interworking" between different QOS models. Here the fundamental problems come. Who is kidding whom trying to mixing between water and oil? Best regards, Radhika ------=_NextPart_000_0052_01C6F387.C676D950 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi John
 
>> = I've=20 got to agree with Chuck on this.   How Y.1541 fufills QoS = classes=20
>> is not an NSIS issue.  I = think it=20 is clear how to carry them, but =
>> = how=20 the domain deploying Y.1541 verifies things are fufilled is outslide of=20 NSIS.
 
What do you=20 mean?
If NSIS specifies=20 that the QOS classes MUST be interpreted, then it means that they MUST = be=20
interpreted by=20 all the QNEs, because the QSPEC template is requirig =
that from them,=20 even if they do not need to interpret them!
Thus actually=20 what NSIS requires from the nodes is
to be Diffserv,=20 MPLS and Y.1541 aware, otherwise they will not be able to=20
use=20 NSIS.
Is this what we=20 want with NSIS?
 
Best=20 regards,
Georgios
 
 
 
 
 
 
 
 
 

From: john.loughney@nokia.com=20 [mailto:john.loughney@nokia.com]
Sent: donderdag 19 oktober = 2006=20 13:59
To: cdvorak@research.att.com; RADHIKA.R.ROY@saic.com;=20 lars.westberg@ericsson.com
Cc: gash@att.com; = karagian@cs.utwente.nl;=20 nsis@ietf.org
Subject: RE: [NSIS] I-D=20 ACTION:draft-ietf-nsis-qspec-12.txt

I've got to agree with Chuck on = this.   How=20 Y.1541 fufills QoS classes is not an NSIS issue.  I think it is = clear how=20 to carry them, but how the domain deploying Y.1541 verifies things are = fufilled is outslide of NSIS.
 
John

From: ext = cdvorak@research.att.com=20 [mailto:cdvorak@research.att.com]
Sent: 19 October, 2006=20 03:16
To: RADHIKA.R.ROY@saic.com; = lars.westberg@ericsson.com;=20 Loughney John (Nokia-NRC/Helsinki)
Cc: gash@att.com;=20 karagian@cs.utwente.nl; nsis@ietf.org
Subject: RE: [NSIS] = I-D=20 ACTION:draft-ietf-nsis-qspec-12.txt

Radhika

 

Water and = oil=20 aside, the Y.1541 QoS classes are not = “implementation-specific” as=20 you say. They may use DiffServ, they may use RSVP, they may use = something=20 else. How is that = implementation-specific?

 

For me, = this=20 misunderstanding by you is the root cause of your criticism. (I = understand=20 your argument—I just do not agree with it, because it is=20 inaccurate.)

 

The = Y.1541 classes=20 are QoS classes that many experts around the world agreed capture, = in a=20 reasonably small number, distinct combinations of IP performance = parameters=20 capable of supporting virtually all user applications with the = requisite=20 QoS. On an e2e basis, a user may for example indicate “I am = using IPTV and=20 want to request Y.1541 Class 5, which would satisfy my QoS = needs.” Networks=20 in the path may implement different QoS schemes (per-hop, = per-domain,=20 whatever), but a good NSIS method will still allow the e2e QoS=20 classes (of Y.1541) to be = addressed.

 

But there = is no=20 effective way to signal this e2e today, and that is what many of us = wanted=20 NSIS to do—signal this e2e need, with enough hooks to be = useful.=20

 

If all = that is done=20 in NSIS is to make incremental improvements to RSVP, or to focus = primarily=20 on signaling peak bandwidth needs, then IMO the end result will not = be=20 nearly as useful as many of us had = hoped.

 

Chuck=20 Dvorak

AT&T = Labs=20 Research

From: = Roy,=20 Radhika R. [mailto:RADHIKA.R.ROY@saic.com]
Sent: Wednesday, October 18, = 2006 10:37=20 AM
To:=20 lars.westberg@ericsson.com; john.loughney@nokia.com
Cc: gash@att.com; Georgios = Karagiannis;=20 RADHIKA.R.ROY@saic.com; nsis@ietf.org
Subject: RE: [NSIS] I-D=20 ACTION:draft-ietf-nsis-qspec-12.txt

 

Lars:

 

You are = right. That=20 is why, the QOS model like DiffServ comes into=20 picture.

 

There is = another=20 aspect of these QOS models so far the standardization is concerned. = That is=20 called interwoking between the different QOS modeling standards. For = example, you have mentioned as follows:

 

Inter-operabillity solved by:
1)=20 Overprovisioning in the core such as all QoS-requirments are = solved.
2)=20 Interoperabillity for different QoS-models =3D>Peak-allocation of = bandwidth.

 

All the = trends of=20 QOS models have been basically like the = above.

 

Recently, = we also=20 see some fertile brains have created some so-called = “Implementation-specific=20 QOS schemes” that are based on “values” of all QOS = parameters. The=20 fundamental problems are that they also called these as QOS models = (instead=20 of saying that these are some QOS “implementation” = schemes, NOT QOS models).=20 They have even convinced few folks here and there of different = standard=20 organizations that they need “interworking” between = different QOS=20 models.

 

Here the=20 fundamental problems come. Who is kidding whom trying to mixing = between=20 water and oil?

 

Best=20 regards,

Radhika

------=_NextPart_000_0052_01C6F387.C676D950-- --===============0359270276== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0359270276==-- From nsis-bounces@ietf.org Thu Oct 19 08:10:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaWiC-0007Jv-Ji; Thu, 19 Oct 2006 08:09:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaWiB-0007Jd-Jh for nsis@ietf.org; Thu, 19 Oct 2006 08:09:23 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaWi6-00071s-Sv for nsis@ietf.org; Thu, 19 Oct 2006 08:09:23 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k9JC7w25001898; Thu, 19 Oct 2006 13:07:58 +0100 Received: from victor ([193.118.192.66]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 13:07:58 +0100 From: "Robert Hancock" To: "'Roland Bless'" , Subject: RE: [NSIS] GIST issue - PATH MTU v4/v6 Date: Thu, 19 Oct 2006 14:08:17 +0200 Message-ID: <085f01c6f377$431d2880$946b0a0a@comm.ad.roke.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <45376642.7020908@tm.uka.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Importance: Normal X-OriginalArrivalTime: 19 Oct 2006 12:07:58.0211 (UTC) FILETIME=[375C9530:01C6F377] X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi roland, if you are interested in MTU issues, you might in any case like to check the revised text at http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue124 (this is following up Lar's DISCUSS comments). on the v4/v6 question, i'd rather not distinguish between the two: - i don't know how it would cope with some transition mechanisms (you could still get fragmentation) - we know 512 is fine for v4 or v6 (if it isn't we are in trouble) - if you know you are in a homogeneous v6 network, you know the larger PMTU anyway as 1280 so that case is covered in the new text. cheers, robert h. > -----Original Message----- > From: Roland Bless [mailto:bless@tm.uka.de] > Sent: 19 October 2006 13:49 > To: nsis@ietf.org > Subject: [NSIS] GIST issue - PATH MTU v4/v6 > > > Hi, > > short question. The draft says: > Any message sent in D-mode MUST have a size below a conservative > estimate of the path MTU, for which this specification takes the > value 512 bytes as a default. It is possible that fragmented > > Would it be reasonable to have different path MTUs for v4 and > v6? For the latter the path MTU could be larger due to its > 1280 bytes requirement. > > Regards, > Roland > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 19 08:14:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaWmq-0001Uo-Gv; Thu, 19 Oct 2006 08:14:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaWmo-0001Ua-IU for nsis@ietf.org; Thu, 19 Oct 2006 08:14:10 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaWmn-0008Bu-6m for nsis@ietf.org; Thu, 19 Oct 2006 08:14:10 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 19 Oct 2006 05:14:09 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9JCE8VQ008977; Thu, 19 Oct 2006 05:14:08 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k9JCE8bF029668; Thu, 19 Oct 2006 05:14:08 -0700 (PDT) Received: from [10.51.0.33] (ams3-vpn-dhcp32.cisco.com [10.61.64.32]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k9JC23XD012460; Thu, 19 Oct 2006 05:02:04 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: David R Oran Date: Thu, 19 Oct 2006 08:13:07 -0400 To: X-Mailer: Apple Mail (2.752.2) Authentication-Results: sj-dkim-6.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=3063; t=1161260048; x=1162124048; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:David=20R=20Oran=20 |Subject:Re=3A=20QSPEC=20proposal; X=v=3Dcisco.com=3B=20h=3DtjyiAVD4WMrPwDaF1dczELghGxI=3D; b=pg9zMzAT2r+uJ/izmP+WCi1ihMTQW06uTnyqHAsrJin5ZM8t69DkWau2GF8GBgIz1u4AE3Ly 6grIhlPTkGlx/hvMVvk/72Pd0e8gQEuWfTQTgCaGxr6CnmIIokbVuCgr; X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: nsis@ietf.org Subject: [NSIS] Re: QSPEC proposal X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org On Oct 19, 2006, at 7:43 AM, wrote: > Hi all, > > I've been in transit for a few days, so trying to catch-up on all > mails > is somewhat challenging. Here's a partially baked proposal, > considering > the mails on this thread. My proposal for the WG to consider is: > > 1) We take Dave's proposal as a baseline QSPEC: > > a) a set of parameters, all mandatory, that describe the traffic > source > in a mathematically complete way. > b) a set of parameters, all optional, which give additional hints > about > characteristics of the source traffic which may allow network elements > to optimize their treatment (compressibility hints, pre- encryption > hints) > c) a set of parameters, mostly optional, that describe the QoS > constraints the source wishes applied to the treatment of this traffic > (loss rate, jitter, sensitivity to out of order delivery, etc.) > d) a set of handling directives, all optional, which specify the > source's preferences for for traffic handling (e.g. excess treatment) > > 2) Allow QoS Models to use a secondary QSPEC, that may not be > mathmetically complete. I don't see why you need this? > 3) QoS models specify how to map to the baseline QSPEC. I would rather say a QoS model says which of the constraint expressions it is capable of understanding and enforcing, and possibly some bounds on the constraints that the user had better not exceed or he risks his request deterministically failing admission control. For example, if the user specifies a deterministic upper bound of delay, a QoS model without the capability to enforce such a bound will reject the request. If he specifies a probabilistic upper bound as his constraint, any number of QoS models might be able to admit the traffic, depending on the particular resource availability and the granularity of the schedulers, and the maximum queue depths allowed. > 4) Add a MAP/NO MAP byte, which a QoS Model can use if they want their > model mapped (or not) to domains support QoS models. > In my world view there is no mapping in the NSIS signaling. There is only local mapping at the points in the domain providing a given QoS capability to determine whether the traffic should be admitted. If we want to allow a domain to carry "domain private" stuff piggybacked on the NSIS signaling that's fine, and if we want to allow such domain private stuff to have a public schema ala "QoS models" I'm not opposed to that as long as we don't try to define common semantics across these "QoS models". > Would this meet people's needs? I could see that point 4 might allow > use cases that Lars/Georgios would like. > > Robert and Dave seem to agree that point 1) is not too far from the > current QSPEC. > I don't think the current QSPEC has parameters that directly express the constraints that I defined in (c). I'll leave it to the WG if they think this is just too major surgery for this late in the game. > John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 19 08:21:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaWtY-00005e-Pt; Thu, 19 Oct 2006 08:21:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaWtY-00005Z-5f for nsis@ietf.org; Thu, 19 Oct 2006 08:21:08 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaWtV-00014W-42 for nsis@ietf.org; Thu, 19 Oct 2006 08:21:08 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9JCKxrT027651; Thu, 19 Oct 2006 15:21:02 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 15:21:00 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 15:20:59 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Re: QSPEC proposal Date: Thu, 19 Oct 2006 15:20:59 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Re: QSPEC proposal Thread-Index: AcbzeE/E/NW8SEPTSzWBbYmMHq+ztAAABXvw From: To: X-OriginalArrivalTime: 19 Oct 2006 12:20:59.0734 (UTC) FILETIME=[092F8760:01C6F379] X-Spam-Score: 0.2 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Dave, See in-line: >> I've been in transit for a few days, so trying to catch-up on all=20 >> mails is somewhat challenging. Here's a partially baked proposal,=20 >> considering the mails on this thread. My proposal for the WG to=20 >> consider is: >> >> 1) We take Dave's proposal as a baseline QSPEC: >> >> a) a set of parameters, all mandatory, that describe the traffic=20 >> source in a mathematically complete way. >> b) a set of parameters, all optional, which give additional hints=20 >> about characteristics of the source traffic which may allow network=20 >> elements to optimize their treatment (compressibility hints, pre-=20 >> encryption >> hints) >> c) a set of parameters, mostly optional, that describe the QoS=20 >> constraints the source wishes applied to the treatment of=20 >this traffic=20 >> (loss rate, jitter, sensitivity to out of order delivery, etc.) >> d) a set of handling directives, all optional, which specify the=20 >> source's preferences for for traffic handling (e.g. excess treatment) >> >> 2) Allow QoS Models to use a secondary QSPEC, that may not be=20 >> mathmetically complete. > >I don't see why you need this? See my comment after point 4. >> 3) QoS models specify how to map to the baseline QSPEC. >I would rather say a QoS model says which of the constraint=20 >expressions it is capable of understanding and enforcing, and=20 >possibly some bounds on the constraints that the user had=20 >better not exceed or he risks his request deterministically=20 >failing admission control. For example, if the user specifies=20 >a deterministic upper bound of delay, a QoS model without the=20 >capability to enforce such a bound will reject the request. If=20 >he specifies a probabilistic upper bound as his constraint,=20 >any number of QoS models might be able to admit the traffic,=20 >depending on the particular resource availability and the=20 >granularity of the schedulers, and the maximum queue depths allowed. This makes sense, as long as it is achievable with what people have been planning on in their QoS Model work. > >> 4) Add a MAP/NO MAP byte, which a QoS Model can use if they want their=20 >> model mapped (or not) to domains support QoS models. >> >In my world view there is no mapping in the NSIS signaling.=20 >There is only local mapping at the points in the domain=20 >providing a given QoS capability to determine whether the=20 >traffic should be admitted. If we want to allow a domain to=20 >carry "domain private" stuff piggybacked on the NSIS signaling=20 >that's fine, and if we want to allow such domain private stuff=20 >to have a public schema ala "QoS models" I'm not opposed to=20 >that as long as we don't try to define common semantics across=20 >these "QoS models". This is what I meant by the secondary QSPEC. It could be transparently transmitted across other domains. >> Would this meet people's needs? I could see that point 4 might allow >> use cases that Lars/Georgios would like. >> >> Robert and Dave seem to agree that point 1) is not too far from the=20 >> current QSPEC. >> >I don't think the current QSPEC has parameters that directly=20 >express the constraints that I defined in (c). > >I'll leave it to the WG if they think this is just too major=20 >surgery for this late in the game. Well, it seems that we need some amount of surgery to achieve this. I don't think we can pass the documents onto the IESG with out rough concensus. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 19 08:24:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaWwd-0003iQ-56; Thu, 19 Oct 2006 08:24:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaWwc-0003iL-Ky for nsis@ietf.org; Thu, 19 Oct 2006 08:24:18 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaWwa-0001V8-76 for nsis@ietf.org; Thu, 19 Oct 2006 08:24:18 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx2.ira.uni-karlsruhe.de with esmtps id 1GaWwQ-00051u-7h; Thu, 19 Oct 2006 14:24:07 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id DC91FB5EB; Thu, 19 Oct 2006 14:24:05 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1GaWwP-0007NV-99; Thu, 19 Oct 2006 14:24:05 +0200 Message-ID: <45376E64.3090806@tm.uka.de> Date: Thu, 19 Oct 2006 14:24:04 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: David R Oran Subject: Re: [NSIS] Proposal to move the QSPEC work forward References: <004a01c6f374$673ffb00$4c0d5982@dynamic.ewi.utwente.nl> In-Reply-To: X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.2 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: john.loughney@nokia.com, Georgios Karagiannis , jmanner@cs.Helsinki.FI, nsis@ietf.org, robert.hancock@roke.co.uk X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Dave, comments inline. David R Oran wrote: > On Oct 19, 2006, at 7:47 AM, Georgios Karagiannis wrote: > >> 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. >> > 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. I fully agree here, without a defined time period, it's pretty useless. >> 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 > - minimum quantum (what RSVP TSPEC calls minimum policed unit) > > 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 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 19 08:25:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaWxS-0003y1-UX; Thu, 19 Oct 2006 08:25:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaWxS-0003xv-10 for nsis@ietf.org; Thu, 19 Oct 2006 08:25:10 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaWxM-0001cx-PL for nsis@ietf.org; Thu, 19 Oct 2006 08:25:10 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9JCOsov018685; Thu, 19 Oct 2006 15:24:59 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 15:24:57 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 15:24:56 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] QSPEC proposal Date: Thu, 19 Oct 2006 15:24:56 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QSPEC proposal Thread-Index: AcbzdhipoftX8wQISZKQcheyV5RpSwAAhjcw From: To: X-OriginalArrivalTime: 19 Oct 2006 12:24:56.0971 (UTC) FILETIME=[969705B0:01C6F379] X-Spam-Score: 0.2 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: oran@cisco.com, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Janet, What I mean is that there could be a way to transparently pass the QoS Model QSPEC without mapping it to the baseline QSPEC. John=20 >-----Original Message----- >From: ext Janet P Gunn [mailto:jgunn6@csc.com]=20 >Sent: 19 October, 2006 15:00 >To: Loughney John (Nokia-NRC/Helsinki) >Cc: nsis@ietf.org; oran@cisco.com >Subject: Re: [NSIS] QSPEC proposal > > > > > > > >Can you please rephrase number 4? I don't understand it the=20 >way it is currently written. > >Thanks > >Janet > > > wrote on 10/19/2006 07:43:25 AM: > >> Hi all, >> >> I've been in transit for a few days, so trying to catch-up on all=20 >> mails is somewhat challenging. Here's a partially baked proposal,=20 >> considering the mails on this thread. My proposal for the=20 >WG to consider is: >> >> 1) We take Dave's proposal as a baseline QSPEC: >> >> a) a set of parameters, all mandatory, that describe the traffic=20 >> source in a mathematically complete way. >> b) a set of parameters, all optional, which give additional hints=20 >> about characteristics of the source traffic which may allow network=20 >> elements to optimize their treatment (compressibility hints, pre-=20 >> encryption >> hints) >> c) a set of parameters, mostly optional, that describe the QoS=20 >> constraints the source wishes applied to the treatment of=20 >this traffic=20 >> (loss rate, jitter, sensitivity to out of order delivery, etc.) >> d) a set of handling directives, all optional, which specify the=20 >> source's preferences for for traffic handling (e.g. excess treatment) >> >> 2) Allow QoS Models to use a secondary QSPEC, that may not be=20 >> mathmetically complete. >> 3) QoS models specify how to map to the baseline QSPEC. >> 4) Add a MAP/NO MAP byte, which a QoS Model can use if they=20 >want their=20 >> model mapped (or not) to domains support QoS models. >> >> Would this meet people's needs? I could see that point 4=20 >might allow=20 >> use cases that Lars/Georgios would like. >> >> Robert and Dave seem to agree that point 1) is not too far from the=20 >> current QSPEC. >> >> John >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 19 08:26:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaWy4-0004GY-JF; Thu, 19 Oct 2006 08:25:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaWy2-0004Eo-Ep for nsis@ietf.org; Thu, 19 Oct 2006 08:25:46 -0400 Received: from mclmx2.mail.saic.com ([149.8.64.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaWxx-0001jG-Qc for nsis@ietf.org; Thu, 19 Oct 2006 08:25:46 -0400 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com; Thu, 19 Oct 2006 08:25:26 -0400 Received: from 0015-ITS-EXBH01.us.saic.com ([10.43.229.18]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006101908252611083 ; Thu, 19 Oct 2006 08:25:26 -0400 Received: from 0591-ITS-EXMP02.us.saic.com ([10.42.81.248]) by 0015-ITS-EXBH01.us.saic.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 08:25:25 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Date: Thu, 19 Oct 2006 08:25:21 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426E1CEE1@0591-ITS-EXMP02.us.saic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Thread-Index: Acbye4IZ7vmeaP4vRWSoYWr8MvZn4AARbEXAABPFuNAAGO1bQAAA14pR References: From: "Roy, Radhika R." To: , , X-OriginalArrivalTime: 19 Oct 2006 12:25:25.0431 (UTC) FILETIME=[A78DAC70:01C6F379] X-Spam-Score: 0.0 (/) X-Scan-Signature: b6e18fadcfab41fa5e7faede753de4c2 Cc: gash@att.com, karagian@cs.utwente.nl, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0998439886==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0998439886== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F379.A53E2C94" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F379.A53E2C94 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Again the same logic of generalization - Mixing "apples" with "oranges" = when "interworking" is concerned! =20 Is it an isolated stand-alone debate that people will "just" look into = Y.1541 value-based QOS class parameters all by itself? =20 If it is stand-alone Y.1541 value-based QOS implementations for using = NSIS QOS signaling protocol why a separate stand-alone Y.1541-specific = drat is not written? For example, people can "assume" a Y.1541 = implementation-based QOS policy "somehow" does magic to do so. What is = the problem? =20 People can "carry" any values of any parameters in NSIS QOS signaling = protocol and, it could be 100s of any so-called QOS classes like Y.1541. = It is NOT a rocket science. =20 Why then so-called Y.1541 QOS value-based implementation-specific model = is drawn in the same level like that of non-value-based = non-implementation-based DiffServ and RSVP for interworking? It will = NEVER interwork. =20 Why do they need to be done in the same draft creating a problem of = generalization between apples and oranges? =20 The issue is interworking of the QSPEC template carry the QOS = parameters: Value-based and Non-Value-based. =20 Radhika ________________________________ From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Thu 10/19/2006 7:58 AM To: cdvorak@research.att.com; RADHIKA.R.ROY@saic.com; = lars.westberg@ericsson.com Cc: gash@att.com; karagian@cs.utwente.nl; nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt I've got to agree with Chuck on this. How Y.1541 fufills QoS classes = is not an NSIS issue. I think it is clear how to carry them, but how = the domain deploying Y.1541 verifies things are fufilled is outslide of = NSIS. =20 John ________________________________ From: ext cdvorak@research.att.com [mailto:cdvorak@research.att.com]=20 Sent: 19 October, 2006 03:16 To: RADHIKA.R.ROY@saic.com; lars.westberg@ericsson.com; Loughney John = (Nokia-NRC/Helsinki) Cc: gash@att.com; karagian@cs.utwente.nl; nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt =09 =09 Radhika =20 Water and oil aside, the Y.1541 QoS classes are not = "implementation-specific" as you say. They may use DiffServ, they may = use RSVP, they may use something else. How is that = implementation-specific? =20 For me, this misunderstanding by you is the root cause of your = criticism. (I understand your argument-I just do not agree with it, = because it is inaccurate.) =20 The Y.1541 classes are QoS classes that many experts around the world = agreed capture, in a reasonably small number, distinct combinations of = IP performance parameters capable of supporting virtually all user = applications with the requisite QoS. On an e2e basis, a user may for = example indicate "I am using IPTV and want to request Y.1541 Class 5, = which would satisfy my QoS needs." Networks in the path may implement = different QoS schemes (per-hop, per-domain, whatever), but a good NSIS = method will still allow the e2e QoS classes (of Y.1541) to be addressed. =20 But there is no effective way to signal this e2e today, and that is = what many of us wanted NSIS to do-signal this e2e need, with enough = hooks to be useful.=20 =20 If all that is done in NSIS is to make incremental improvements to = RSVP, or to focus primarily on signaling peak bandwidth needs, then IMO = the end result will not be nearly as useful as many of us had hoped. =20 Chuck Dvorak AT&T Labs Research =09 ________________________________ From: Roy, Radhika R. [mailto:RADHIKA.R.ROY@saic.com]=20 Sent: Wednesday, October 18, 2006 10:37 AM To: lars.westberg@ericsson.com; john.loughney@nokia.com Cc: gash@att.com; Georgios Karagiannis; RADHIKA.R.ROY@saic.com; = nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt =20 Lars: =20 You are right. That is why, the QOS model like DiffServ comes into = picture. =20 There is another aspect of these QOS models so far the standardization = is concerned. That is called interwoking between the different QOS = modeling standards. For example, you have mentioned as follows: =20 Inter-operabillity solved by:=20 1) Overprovisioning in the core such as all QoS-requirments are solved. 2) Interoperabillity for different QoS-models =3D>Peak-allocation of = bandwidth. =20 All the trends of QOS models have been basically like the above. =20 Recently, we also see some fertile brains have created some so-called = "Implementation-specific QOS schemes" that are based on "values" of all = QOS parameters. The fundamental problems are that they also called these = as QOS models (instead of saying that these are some QOS = "implementation" schemes, NOT QOS models). They have even convinced few = folks here and there of different standard organizations that they need = "interworking" between different QOS models. =20 Here the fundamental problems come. Who is kidding whom trying to = mixing between water and oil?=20 =20 Best regards, Radhika ------_=_NextPart_001_01C6F379.A53E2C94 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A=
=0A=
Again the = same logic of generalization - Mixing "apples" with "oranges" when = "interworking" is concerned!
=0A=
 
=0A=
Is it an isolated = stand-alone debate that people will "just" look into Y.1541 = value-based QOS class parameters all by itself?
=0A=
 
=0A=
If it is stand-alone Y.1541 = value-based QOS implementations for using NSIS QOS signaling protocol = why a separate stand-alone Y.1541-specific drat is not written? For = example, people can "assume" a Y.1541 implementation-based QOS policy = "somehow" does magic to do so. What is the problem?
=0A=
 
=0A=
People can "carry" any values = of any parameters in NSIS QOS signaling protocol and, it could be 100s = of any so-called QOS classes like Y.1541. It is NOT a rocket = science.
=0A=
 
=0A=
Why then so-called Y.1541 QOS = value-based implementation-specific model is drawn in the same = level like that of non-value-based non-implementation-based DiffServ and = RSVP for interworking? It will NEVER interwork.
=0A=
 
=0A=
Why do they need to be done = in the same draft creating a problem of generalization between apples = and oranges?
=0A=
 
=0A=
The issue is interworking of = the QSPEC template carry the QOS parameters: Value-based and = Non-Value-based.
=0A=
 
=0A=
Radhika
=0A=

=0A=
=0A= From: john.loughney@nokia.com = [mailto:john.loughney@nokia.com]
Sent: Thu 10/19/2006 7:58 = AM
To: cdvorak@research.att.com; RADHIKA.R.ROY@saic.com; = lars.westberg@ericsson.com
Cc: gash@att.com; = karagian@cs.utwente.nl; nsis@ietf.org
Subject: RE: [NSIS] I-D = ACTION:draft-ietf-nsis-qspec-12.txt

=0A=
=0A=
I've got to agree with Chuck on = this.   How Y.1541 fufills QoS classes is not an NSIS = issue.  I think it is clear how to carry them, but how the domain = deploying Y.1541 verifies things are fufilled is outslide of = NSIS.
=0A=
 
=0A=
John

=0A=
=0A=
=0A=
=0A= From: ext cdvorak@research.att.com = [mailto:cdvorak@research.att.com]
Sent: 19 October, 2006 = 03:16
To: RADHIKA.R.ROY@saic.com; lars.westberg@ericsson.com; = Loughney John (Nokia-NRC/Helsinki)
Cc: gash@att.com; = karagian@cs.utwente.nl; nsis@ietf.org
Subject: RE: [NSIS] I-D = ACTION:draft-ietf-nsis-qspec-12.txt

=0A=
=0A=
=0A=

Radhika

=0A=

 

=0A=

Water and oil = aside, the Y.1541 QoS classes are not = “implementation-specific” as you say. They may use DiffServ, = they may use RSVP, they may use something else. How is that = implementation-specific?

=0A=

 

=0A=

For me, this = misunderstanding by you is the root cause of your criticism. (I = understand your argument—I just do not agree with it, because it = is inaccurate.)

=0A=

 

=0A=

The Y.1541 = classes are QoS classes that many experts around the world agreed = capture, in a reasonably small number, distinct combinations of IP = performance parameters capable of supporting virtually all user = applications with the requisite QoS. On an e2e basis, a user may for = example indicate “I am using IPTV and want to request Y.1541 Class = 5, which would satisfy my QoS needs.” Networks in the path may = implement different QoS schemes (per-hop, per-domain, whatever), = but a good NSIS method will still allow the e2e QoS classes (of = Y.1541) to be addressed.

=0A=

 

=0A=

But there is = no effective way to signal this e2e today, and that is what many of us = wanted NSIS to do—signal this e2e need, with enough hooks to be = useful.

=0A=

 

=0A=

If all that = is done in NSIS is to make incremental improvements to RSVP, or to focus = primarily on signaling peak bandwidth needs, then IMO the end result = will not be nearly as useful as many of us had hoped.

=0A=

 

=0A=

Chuck = Dvorak

=0A=

AT&T Labs = Research

=0A=
=0A=
=0A=
=0A=
=0A=

From: Roy, Radhika R. = [mailto:RADHIKA.R.ROY@saic.com]
Sent: Wednesday, October 18, 2006 10:37 AM
To: lars.westberg@ericsson.com; = john.loughney@nokia.com
Cc: gash@att.com; Georgios Karagiannis; = RADHIKA.R.ROY@saic.com; nsis@ietf.org
Subject: RE: [NSIS] I-D = ACTION:draft-ietf-nsis-qspec-12.txt

=0A=

 

=0A=

Lars:

=0A=

 

=0A=

You are = right. That is why, the QOS model like DiffServ comes into = picture.

=0A=

 

=0A=

There is = another aspect of these QOS models so far the standardization is = concerned. That is called interwoking between the different QOS modeling = standards. For example, you have mentioned as follows:

=0A=

 

=0A=

Inter-operabillity solved by: =
1) Overprovisioning in the core such as all QoS-requirments are = solved.
2) Interoperabillity for different QoS-models = =3D>Peak-allocation of bandwidth.

=0A=

 

=0A=

All the = trends of QOS models have been basically like the = above.

=0A=

 

=0A=

Recently, we = also see some fertile brains have created some so-called = “Implementation-specific QOS schemes” that are based on = “values” of all QOS parameters. The fundamental problems are = that they also called these as QOS models (instead of saying that these = are some QOS “implementation” schemes, NOT QOS models). They = have even convinced few folks here and there of different standard = organizations that they need “interworking” between = different QOS models.

=0A=

 

=0A=

Here the = fundamental problems come. Who is kidding whom trying to mixing between = water and oil?

=0A=

 

=0A=

Best = regards,

=0A=

Radhika

------_=_NextPart_001_01C6F379.A53E2C94-- --===============0998439886== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0998439886==-- From nsis-bounces@ietf.org Thu Oct 19 08:35:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaX6p-0002Zb-LR; Thu, 19 Oct 2006 08:34:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaX6o-0002X2-Rv for nsis@ietf.org; Thu, 19 Oct 2006 08:34:50 -0400 Received: from sbcsmtp3.sbc.com ([144.160.112.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaX6k-0003lv-8J for nsis@ietf.org; Thu, 19 Oct 2006 08:34:50 -0400 Received: from enaf.dadc.sbc.com (localhost.localdomain [127.0.0.1]) by sbcsmtp3.sbc.com (8.13.7/8.13.7) with ESMTP id k9JCYjuj027604; Thu, 19 Oct 2006 07:34:45 -0500 Received: from flph023.ffdc.sbc.com (flph023.ffdc.sbc.com [150.234.117.36]) by tlph033.enaf.dadc.sbc.com (8.13.7/8.13.7) with ESMTP id k9JCYgKv027588; Thu, 19 Oct 2006 07:34:42 -0500 Received: from ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flph023.ffdc.sbc.com (8.13.7/8.13.7) with ESMTP id k9JCYgwC030472; Thu, 19 Oct 2006 05:34:42 -0700 Received: from kcclust06evs1.ugd.att.com (kcst11.ugd.att.com [135.38.164.88]) by flph023.ffdc.sbc.com (8.13.7/8.13.7) with ESMTP id k9JCYbcM030445; Thu, 19 Oct 2006 05:34:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Date: Thu, 19 Oct 2006 07:34:36 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7E7F@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <72A0C76B-6118-4734-92EF-FBAB4577B0CA@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Thread-Index: AcbzPHfjvb4QOwXcRXS4MVBYbTxP1QAOfOQg From: "Ash, Gerald R \(Jerry\), ALABS" To: "David R Oran" X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: "Ash, Gerald R \(Jerry\), ALABS" , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Dave, Many thanks for stepping in here. Please see below.=20 > -----Original Message----- > From: David R Oran [mailto:oran@cisco.com]=20 > Sent: Thursday, October 19, 2006 1:06 AM > To: Lars Westberg > Cc: Kappler, Cornelia; Ash, Gerald R (Jerry), ALABS; Georgios=20 > Karagiannis; nsis@ietf.org > Subject: Re: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt >=20 > One more time from left-field (I know... I've lost this one before =20 > and should keep my mouth shut). >=20 > Much of this confusion is because I believe the qspec draft and the =20 > current notion of "QoS models" has a poor architectural partitioning =20 > and hence falls into these kinds of discussions of what is over and =20 > under specification, what it means for a parameter to be=20 > mandatory, etc. >=20 > A long time ago I proposed a different architectural partitioning =20 > (and moving some things like priority outside the qspec entirely =20 > since it was a general admission control parameter and not a QoS =20 > parameter). I won't resurrect the whole thing here but remind people =20 > if they want to go back a couple of years in the archives they'll =20 > find the outline of the proposal and the ensuing discussion. I shut =20 > up because the WG consensus was against my proposal and I'm not in =20 > the habit of continuing to make a pain of myself when I lose an =20 > argument. I recall the discussion quite well, and my understanding was that we adopted your proposal as we understood it. I could go back to the threads but I recall no conclusion that what we have progressed is contrary to any of your proposals. Indeed, we would be unwise to not follow your advice IMO. =20 > However, it does strike me that this long thread and the last-minute =20 > discussions on the qspec draft do have a flavor of the issues I was =20 > raising way back when. Just to remind folks, I proposed, more or less: >=20 > a) a set of parameters, all mandatory, that describe the traffic =20 > source in a mathematically complete way. > b) a set of parameters, all optional, which give additional hints =20 > about characteristics of the source traffic which may allow network =20 > elements to optimize their treatment (compressibility hints, pre-=20 > encryption hints) > c) a set of parameters, mostly optional, that describe the QoS =20 > constraints the source wishes applied to the treatment of this =20 > traffic (loss rate, jitter, sensitivity to out of order=20 > delivery, etc.) > d) a set of handling directives, all optional, which specify the =20 > source's preferences for traffic handling (e.g. excess treatment) I agree with Robert that the present qspec is mostly consistent and aligned with a) -> d). This is in fact what I recall you suggesting 2 years ago, and we had much discussion on the list as to how this was being adopted in the qspec. We may not have the mandatory/optional split exactly as you envision, or the specific suggestions in b), but those things can be re-aligned better going forward. =20 Thanks, Regards, Jerry > I think there are a number of ways to close down this discussion , =20 > through which I notice there have been only a few people complaining: >=20 > a) tell them to shut up, that the WG consensus stands, and see what =20 > happens during last call. > b) rethink the spec along the lines I outline above and ask those =20 > folks if that would address their concerns > c) ask for a formal outside review, either by raising these issues =20 > explicitly in the last call and requesting comments, or punting to =20 > the IESG to solicit such advice. >=20 > I promise not to rock the boat if you choose (a). >=20 > Dave Oran. > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 19 08:36:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaX7x-0003XZ-8W; Thu, 19 Oct 2006 08:36:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaX7w-0003X0-LX for nsis@ietf.org; Thu, 19 Oct 2006 08:36:00 -0400 Received: from sbcsmtp3.sbc.com ([144.160.112.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaX7u-00047k-Bi for nsis@ietf.org; Thu, 19 Oct 2006 08:36:00 -0400 Received: from enaf.dadc.sbc.com (localhost.localdomain [127.0.0.1]) by sbcsmtp3.sbc.com (8.13.7/8.13.7) with ESMTP id k9JCZvlS027984; Thu, 19 Oct 2006 07:35:57 -0500 Received: from flph023.ffdc.sbc.com (flph023.ffdc.sbc.com [150.234.117.36]) by tlph033.enaf.dadc.sbc.com (8.13.7/8.13.7) with ESMTP id k9JCZaCV027913; Thu, 19 Oct 2006 07:35:56 -0500 Received: from ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flph023.ffdc.sbc.com (8.13.7/8.13.7) with ESMTP id k9JCZQ35030708; Thu, 19 Oct 2006 05:35:26 -0700 Received: from kcclust06evs1.ugd.att.com (kcst11.ugd.att.com [135.38.164.88]) by flph023.ffdc.sbc.com (8.13.7/8.13.7) with ESMTP id k9JCZLYE030682; Thu, 19 Oct 2006 05:35:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Re: QSPEC proposal Date: Thu, 19 Oct 2006 07:35:21 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7E80@KCCLUST06EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Re: QSPEC proposal Thread-Index: AcbzeDzndAK9O5PhQeO0m6ZYeDM1YwAAEciw From: "Ash, Gerald R \(Jerry\), ALABS" To: "David R Oran" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: "Ash, Gerald R \(Jerry\), ALABS" , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Dave, John, Please see below.=20 > -----Original Message----- > From: David R Oran [mailto:oran@cisco.com]=20 > Sent: Thursday, October 19, 2006 8:13 AM > To: john.loughney@nokia.com > Cc: nsis@ietf.org > Subject: [NSIS] Re: QSPEC proposal >=20 >=20 > On Oct 19, 2006, at 7:43 AM, wrote: >=20 > > Hi all, > > > > I've been in transit for a few days, so trying to catch-up on all =20 > > mails > > is somewhat challenging. Here's a partially baked proposal, =20 > > considering > > the mails on this thread. My proposal for the WG to consider is: > > > > 1) We take Dave's proposal as a baseline QSPEC: > > > > a) a set of parameters, all mandatory, that describe the traffic =20 > > source > > in a mathematically complete way. > > b) a set of parameters, all optional, which give additional hints =20 > > about > > characteristics of the source traffic which may allow=20 > > network elements > > to optimize their treatment (compressibility hints, pre- encryption > > hints) > > c) a set of parameters, mostly optional, that describe the QoS > > constraints the source wishes applied to the treatment of=20 > > this traffic > > (loss rate, jitter, sensitivity to out of order delivery, etc.) > > d) a set of handling directives, all optional, which specify the > > source's preferences for traffic handling (e.g. excess=20 > > treatment) I agree with the taxonomy, and believe the current qspec basically aligns with a) --> d). Details can be re-aligned as needed (e.g., add the specifics in b). > > 2) Allow QoS Models to use a secondary QSPEC, that may not be > > mathematically complete. =20 > I don't see why you need this? I agree with Dave, I don't see a need for a 'secondary QSPEC'. Perhaps you are referring here to stacking a 'local qspec' on top of an initiator qspec, which is of course allowed in the current scheme of things? If not, please clarify what is a 'secondary qspec'. > > 3) QoS models specify how to map to the baseline QSPEC. > I would rather say a QoS model says which of the constraint =20 > expressions it is capable of understanding and enforcing, and =20 > possibly some bounds on the constraints that the user had better not =20 > exceed or he risks his request deterministically failing admission =20 > control. For example, if the user specifies a deterministic upper =20 > bound of delay, a QoS model without the capability to enforce such a =20 > bound will reject the request. If he specifies a probabilistic upper =20 > bound as his constraint, any number of QoS models might be able to =20 > admit the traffic, depending on the particular resource availability =20 > and the granularity of the schedulers, and the maximum queue depths =20 > allowed. I agree with Dave's characterization here of what QoS models should do. =20 > > 4) Add a MAP/NO MAP byte, which a QoS Model can use if they=20 > > want their > > model mapped (or not) to domains support QoS models. > In my world view there is no mapping in the NSIS signaling. There is =20 > only local mapping at the points in the domain providing a given QoS =20 > capability to determine whether the traffic should be=20 > admitted. If we =20 > want to allow a domain to carry "domain private" stuff=20 > piggybacked on =20 > the NSIS signaling that's fine, and if we want to allow such domain =20 > private stuff to have a public schema ala "QoS models" I'm not =20 > opposed to that as long as we don't try to define common semantics =20 > across these "QoS models". I agree with Dave. Most of the confusion and objection on this long discussion is regarding 'remapping' qspec parameters. In many (most) cases there is no sensible 'remapping' from qspec parameter apple-1 to qspec parameter orange-2. We might consider defining only specific allowed remappings (very few IMO) and leave it at that. > > Would this meet people's needs? I could see that point 4=20 > > might allow > > use cases that Lars/Georgios would like. > > > > Robert and Dave seem to agree that point 1) is not too far from the > > current QSPEC. > I don't think the current QSPEC has parameters that directly express =20 > the constraints that I defined in (c). > I'll leave it to the WG if they think this is just too major surgery =20 > for this late in the game. Barring the above caveats on 2) and 4), I don't think this is major surgery at this point. Thanks, Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 19 08:40:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaXBk-0005Ll-EG; Thu, 19 Oct 2006 08:39:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaXBj-0005Et-5t for nsis@ietf.org; Thu, 19 Oct 2006 08:39:55 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaXBh-0004jr-J9 for nsis@ietf.org; Thu, 19 Oct 2006 08:39:55 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9JCdi0W009500; Thu, 19 Oct 2006 15:39:47 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 15:39:46 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 15:39:46 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Date: Thu, 19 Oct 2006 15:39:45 +0300 Message-ID: In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC7E7F@KCCLUST06EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Thread-Index: AcbzPHfjvb4QOwXcRXS4MVBYbTxP1QAOfOQgAAFDyHA= From: To: , X-OriginalArrivalTime: 19 Oct 2006 12:39:46.0231 (UTC) FILETIME=[A8A15470:01C6F37B] X-Spam-Score: 0.2 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Dave & Jerry, It would be great if you could propose a resolution to meet Dave's 'requirement.' It would be fine to discuss off-list and propose something to move forward. thanks, John=20 >-----Original Message----- >From: ext Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com]=20 >Sent: 19 October, 2006 15:35 >To: David R Oran >Cc: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org >Subject: RE: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt > >Hi Dave, > >Many thanks for stepping in here. Please see below.=20 > >> -----Original Message----- >> From: David R Oran [mailto:oran@cisco.com] >> Sent: Thursday, October 19, 2006 1:06 AM >> To: Lars Westberg >> Cc: Kappler, Cornelia; Ash, Gerald R (Jerry), ALABS; Georgios=20 >> Karagiannis; nsis@ietf.org >> Subject: Re: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt >>=20 >> One more time from left-field (I know... I've lost this one=20 >before and=20 >> should keep my mouth shut). >>=20 >> Much of this confusion is because I believe the qspec draft and the=20 >> current notion of "QoS models" has a poor architectural partitioning=20 >> and hence falls into these kinds of discussions of what is over and=20 >> under specification, what it means for a parameter to be mandatory,=20 >> etc. >>=20 >> A long time ago I proposed a different architectural=20 >partitioning (and=20 >> moving some things like priority outside the qspec entirely since it=20 >> was a general admission control parameter and not a QoS=20 >parameter). I=20 >> won't resurrect the whole thing here but remind people if=20 >they want to=20 >> go back a couple of years in the archives they'll find the=20 >outline of=20 >> the proposal and the ensuing discussion. I shut up because the WG=20 >> consensus was against my proposal and I'm not in the habit of=20 >> continuing to make a pain of myself when I lose an argument. > >I recall the discussion quite well, and my understanding was=20 >that we adopted your proposal as we understood it. I could go=20 >back to the threads but I recall no conclusion that what we=20 >have progressed is contrary to any of your proposals. Indeed,=20 >we would be unwise to not follow your advice IMO. >=20 >> However, it does strike me that this long thread and the last-minute=20 >> discussions on the qspec draft do have a flavor of the issues I was=20 >> raising way back when. Just to remind folks, I proposed,=20 >more or less: >>=20 >> a) a set of parameters, all mandatory, that describe the traffic=20 >> source in a mathematically complete way. >> b) a set of parameters, all optional, which give additional hints=20 >> about characteristics of the source traffic which may allow network=20 >> elements to optimize their treatment (compressibility hints, pre-=20 >> encryption hints) >> c) a set of parameters, mostly optional, that describe the QoS=20 >> constraints the source wishes applied to the treatment of=20 >this traffic=20 >> (loss rate, jitter, sensitivity to out of order delivery, etc.) >> d) a set of handling directives, all optional, which specify the=20 >> source's preferences for traffic handling (e.g. excess treatment) > >I agree with Robert that the present qspec is mostly=20 >consistent and aligned with a) -> d). This is in fact what I=20 >recall you suggesting 2 years ago, and we had much discussion=20 >on the list as to how this was being adopted in the qspec. We=20 >may not have the mandatory/optional split exactly as you=20 >envision, or the specific suggestions in b), but those things=20 >can be re-aligned better going forward. =20 > >Thanks, >Regards, >Jerry > >> I think there are a number of ways to close down this discussion ,=20 >> through which I notice there have been only a few people complaining: >>=20 >> a) tell them to shut up, that the WG consensus stands, and see what=20 >> happens during last call. >> b) rethink the spec along the lines I outline above and ask those=20 >> folks if that would address their concerns >> c) ask for a formal outside review, either by raising these issues=20 >> explicitly in the last call and requesting comments, or=20 >punting to the=20 >> IESG to solicit such advice. >>=20 >> I promise not to rock the boat if you choose (a). >>=20 >> Dave Oran. >> > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 19 08:43:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaXEb-0001ni-3X; Thu, 19 Oct 2006 08:42:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaXEZ-0001mD-OC for nsis@ietf.org; Thu, 19 Oct 2006 08:42:51 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaXES-0005A0-PS for nsis@ietf.org; Thu, 19 Oct 2006 08:42:51 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx2.ira.uni-karlsruhe.de with esmtps id 1GaXEM-0007s7-MX; Thu, 19 Oct 2006 14:42:44 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 88A62B5EB; Thu, 19 Oct 2006 14:42:38 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1GaXEM-0007Om-8W; Thu, 19 Oct 2006 14:42:38 +0200 Message-ID: <453772BD.7020402@tm.uka.de> Date: Thu, 19 Oct 2006 14:42:37 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: David R Oran Subject: Re: [NSIS] Re: QSPEC proposal References: In-Reply-To: X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.2 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: john.loughney@nokia.com, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Dave, David R Oran wrote: > On Oct 19, 2006, at 7:43 AM, wrote: > >> 2) Allow QoS Models to use a secondary QSPEC, that may not be >> mathmetically complete. > > I don't see why you need this? I don't understand that fully, too. Maybe it has to do with some implicitly set parameters depending on the QoS model? >> 3) QoS models specify how to map to the baseline QSPEC. > I would rather say a QoS model says which of the constraint expressions > it is capable of understanding and enforcing, and possibly some bounds > on the constraints that the user had better not exceed or he risks his > request deterministically failing admission control. For example, if the > user specifies a deterministic upper bound of delay, a QoS model without > the capability to enforce such a bound will reject the request. If he > specifies a probabilistic upper bound as his constraint, any number of > QoS models might be able to admit the traffic, depending on the > particular resource availability and the granularity of the schedulers, > and the maximum queue depths allowed. Yep, and the details are up to the QoS model... >> 4) Add a MAP/NO MAP byte, which a QoS Model can use if they want their >> model mapped (or not) to domains support QoS models. >> > In my world view there is no mapping in the NSIS signaling. There is > only local mapping at the points in the domain providing a given QoS > capability to determine whether the traffic should be admitted. If we Exactly! > want to allow a domain to carry "domain private" stuff piggybacked on > the NSIS signaling that's fine, and if we want to allow such domain > private stuff to have a public schema ala "QoS models" I'm not opposed > to that as long as we don't try to define common semantics across these > "QoS models". Yep, which also seems to be not an easy task... The advantage of the new proposal is that you only need a local 1:1 mapping instead of an n:1 mapping for n different services from different QoS models. The current difficulties may stem from the fact that we tossed all different parameter sets from different models together and try to find a common denominator. I guess it's much harder to map from = to my own QoS model rather than from Dave's proposed parameter set a)-d) to my own. >> Would this meet people's needs? I could see that point 4 might allow >> use cases that Lars/Georgios would like. >> >> Robert and Dave seem to agree that point 1) is not too far from the >> current QSPEC. >> > I don't think the current QSPEC has parameters that directly express the > constraints that I defined in (c). > > I'll leave it to the WG if they think this is just too major surgery for > this late in the game. I'd prefer to rethink the QSPEC approach along your proposal and I guess it would be easier to support then...:-) Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 19 08:53:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaXOT-0003an-7I; Thu, 19 Oct 2006 08:53:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaXOS-0003ah-8S for nsis@ietf.org; Thu, 19 Oct 2006 08:53:04 -0400 Received: from mclmx2.mail.saic.com ([149.8.64.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaXOQ-0006fY-NL for nsis@ietf.org; Thu, 19 Oct 2006 08:53:04 -0400 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com; Thu, 19 Oct 2006 08:52:54 -0400 Received: from 0015-ITS-EXBH01.us.saic.com ([10.43.229.18]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006101908525314971 ; Thu, 19 Oct 2006 08:52:53 -0400 Received: from 0591-ITS-EXMP02.us.saic.com ([10.42.81.248]) by 0015-ITS-EXBH01.us.saic.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 08:52:52 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [NSIS] QSPEC proposal Date: Thu, 19 Oct 2006 08:52:52 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426E1CEE2@0591-ITS-EXMP02.us.saic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QSPEC proposal Thread-Index: AcbzdhipoftX8wQISZKQcheyV5RpSwAAhjcwAAB1P1o= References: From: "Roy, Radhika R." To: , X-OriginalArrivalTime: 19 Oct 2006 12:52:52.0875 (UTC) FILETIME=[7D81ADB0:01C6F37D] X-Spam-Score: 0.1 (/) X-Scan-Signature: f8ee348dcc4be4a59bc395f7cd6343ad Cc: oran@cisco.com, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0815652190==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0815652190== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F37D.7D22C700" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F37D.7D22C700 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Janet and John: =20 It seems to be an innocent proposal: "Transparent" passing of OQS = classes using NSIS signaling protocol. =20 It depends. =20 It is not all so easy to pass "transparently" because they have some = sort of dependency while the QOS parameters of the QSPEC template is = concerned. There has to be a minimum level common understanding what can = be transferred transparently what cannot be considering the = heterogeneous models mainly of two classes: Value-based versus = non-value-based. =20 So, the suggestion is this: Make two separate drafts: 1. = Non-Implementation-specific non-valued-based (DiffServ, RSVP, IntServ) = and 2. Implementation-specific value-based (Y.1541 and DSTE). =20 The second draft will be called implementation draft of NSIS QOS = signaling protocol using Y.1541 and DSTE as they are value-based. It is = not a standard. =20 For example, Dave already observed how RSVP using the "generalized" QOS = parameters.=20 =20 Another key observation is this: If one uses some values of Y.1541 = parameters in RSVP signaling messages, it will perfectly implement = Y.1541 QOS classes for which no separate implementation draft or = standardization is required. Please note that the opposite is NOT true. = That is why so-called Y.1541 and DSTE QOS schemes are NOT QOS model. = They are called implementation-specific QOS schemes (NOT "model"). =20 So, why has NSIS WG so much headache to make a separate standard for = carrying so-called implementation-specific value-based Y.1541 QOS = parameters as it has been proposed about 2 years ago? NSIS QOS signaling = messages can carry any values of any QOS parameters and, one set of = values of those QOS parameters will represent Y.1541 QOS class. Same is = the case for DSTE. =20 Can people convince anyone why people want a separate standard (?) in = NSIS for carrying some "values" of some QOS parameters that are being = used so-called Y.1541 QOS parameters? Who will restrict the users not to = use some values as they like? =20 It is ridiculous to say that Y.1541 is a kind of a generalized QOS = model!!! =20 I hope that it is clear to you all. =20 Best regards, Radhika ________________________________ From: nsis-bounces@ietf.org on behalf of john.loughney@nokia.com Sent: Thu 10/19/2006 8:24 AM To: jgunn6@csc.com Cc: oran@cisco.com; nsis@ietf.org Subject: RE: [NSIS] QSPEC proposal Hi Janet, What I mean is that there could be a way to transparently pass the QoS Model QSPEC without mapping it to the baseline QSPEC. John >-----Original Message----- >From: ext Janet P Gunn [mailto:jgunn6@csc.com] >Sent: 19 October, 2006 15:00 >To: Loughney John (Nokia-NRC/Helsinki) >Cc: nsis@ietf.org; oran@cisco.com >Subject: Re: [NSIS] QSPEC proposal > > > > > > > >Can you please rephrase number 4? I don't understand it the >way it is currently written. > >Thanks > >Janet > > > wrote on 10/19/2006 07:43:25 AM: > >> Hi all, >> >> I've been in transit for a few days, so trying to catch-up on all >> mails is somewhat challenging. Here's a partially baked proposal, >> considering the mails on this thread. My proposal for the >WG to consider is: >> >> 1) We take Dave's proposal as a baseline QSPEC: >> >> a) a set of parameters, all mandatory, that describe the traffic >> source in a mathematically complete way. >> b) a set of parameters, all optional, which give additional hints >> about characteristics of the source traffic which may allow network >> elements to optimize their treatment (compressibility hints, pre- >> encryption >> hints) >> c) a set of parameters, mostly optional, that describe the QoS >> constraints the source wishes applied to the treatment of >this traffic >> (loss rate, jitter, sensitivity to out of order delivery, etc.) >> d) a set of handling directives, all optional, which specify the >> source's preferences for for traffic handling (e.g. excess treatment) >> >> 2) Allow QoS Models to use a secondary QSPEC, that may not be >> mathmetically complete. >> 3) QoS models specify how to map to the baseline QSPEC. >> 4) Add a MAP/NO MAP byte, which a QoS Model can use if they >want their >> model mapped (or not) to domains support QoS models. >> >> Would this meet people's needs? I could see that point 4 >might allow >> use cases that Lars/Georgios would like. >> >> Robert and Dave seem to agree that point 1) is not too far from the >> current QSPEC. >> >> John >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis ------_=_NextPart_001_01C6F37D.7D22C700 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [NSIS] QSPEC proposal=0A= =0A= =0A= =0A=
=0A=
Janet and = John:
=0A=
 
=0A=
It seems to be an innocent = proposal: "Transparent" passing of OQS classes using NSIS signaling = protocol.
=0A=
 
=0A=
It depends.
=0A=
 
=0A=
It is not all so easy to pass = "transparently" because they have some sort of dependency while the QOS = parameters of the QSPEC template is concerned. There has to be a minimum = level common understanding what can be transferred transparently what = cannot be considering the heterogeneous models mainly of two classes: = Value-based versus non-value-based.
=0A=
 
=0A=
So, the suggestion is this: = Make two separate drafts: 1. Non-Implementation-specific = non-valued-based (DiffServ, RSVP, IntServ) and 2. = Implementation-specific value-based (Y.1541 and DSTE).
=0A=
 
=0A=
The second draft will be = called implementation draft of NSIS QOS signaling protocol using Y.1541 = and DSTE as they are value-based. It is not a standard.
=0A=
 
=0A=
For example, Dave already = observed how RSVP using the "generalized" QOS parameters.
=0A=
 
=0A=
Another key observation is = this: If one uses some values of Y.1541 parameters in RSVP signaling = messages, it will perfectly implement Y.1541 QOS classes for which no = separate implementation draft or standardization is required. Please = note that the opposite is NOT true. That is why so-called Y.1541 and = DSTE QOS schemes are NOT QOS model. They are called = implementation-specific QOS schemes (NOT "model").
=0A=
 
=0A=
So, why has NSIS WG so much = headache to make a separate standard for carrying so-called = implementation-specific value-based Y.1541 QOS parameters as it has been = proposed about 2 years ago? NSIS QOS signaling messages can carry any = values of any QOS parameters and, one set of values of those QOS = parameters will represent Y.1541 QOS class. Same is the case for = DSTE.
=0A=
 
=0A=
Can people convince anyone = why people want a separate standard (?) in NSIS for carrying some = "values" of some QOS parameters that are being used so-called Y.1541 QOS = parameters? Who will restrict the users not to use some values as they = like?
=0A=
 
=0A=
It is ridiculous to say that = Y.1541 is a kind of a generalized QOS model!!!
=0A=
 
=0A=
I hope that it is clear to = you all.
=0A=
 
=0A=
Best regards,
=0A=
Radhika
=0A=

=0A=
=0A= From: nsis-bounces@ietf.org on = behalf of john.loughney@nokia.com
Sent: Thu 10/19/2006 8:24 = AM
To: jgunn6@csc.com
Cc: oran@cisco.com; = nsis@ietf.org
Subject: RE: [NSIS] QSPEC = proposal

=0A=
=0A=

Hi Janet,

What I mean is that there could be a = way to transparently pass the QoS
Model QSPEC without mapping it to = the baseline QSPEC.

John

>-----Original = Message-----
>From: ext Janet P Gunn [mailto:jgunn6@csc.com]
>Sent: = 19 October, 2006 15:00
>To: Loughney John = (Nokia-NRC/Helsinki)
>Cc: nsis@ietf.org; = oran@cisco.com
>Subject: Re: [NSIS] QSPEC = proposal
>
>
>
>
>
>
>
>C= an you please rephrase number 4?  I don't understand it = the
>way it is currently = written.
>
>Thanks
>
>Janet
>
>
&g= t;<john.loughney@nokia.com> wrote on 10/19/2006 07:43:25 = AM:
>
>> Hi all,
>>
>> I've been in = transit for a few days, so trying to catch-up on all
>> mails = is somewhat challenging.  Here's a partially baked = proposal,
>> considering the mails on this thread.  My = proposal for the
>WG to consider  is:
>>
>> = 1) We take Dave's proposal as a baseline QSPEC:
>>
>> = a) a set of parameters, all mandatory, that describe the = traffic
>> source in a mathematically complete way.
>> = b) a set of parameters, all optional, which give additional = hints
>> about characteristics of the source traffic which may = allow network
>> elements to optimize their treatment = (compressibility hints, pre-
>> encryption
>> = hints)
>> c) a set of parameters, mostly optional, that = describe the QoS
>> constraints the source wishes applied to = the treatment of
>this traffic
>> (loss rate, jitter, = sensitivity to out of order delivery, etc.)
>> d) a set of = handling directives, all optional, which specify the
>> = source's preferences for for traffic handling (e.g. excess = treatment)
>>
>> 2) Allow QoS Models to use a = secondary QSPEC, that may not be
>> mathmetically = complete.
>> 3) QoS models specify how to map to the baseline = QSPEC.
>> 4) Add a MAP/NO MAP byte, which a QoS Model can use = if they
>want their
>> model mapped (or not) to domains = support QoS models.
>>
>> Would this meet people's = needs?  I could see that point 4
>might allow
>> use = cases that Lars/Georgios would like.
>>
>> Robert and = Dave seem to agree that point 1) is not too far from the
>> = current QSPEC.
>>
>> John
>>
>> = _______________________________________________
>> nsis mailing = list
>> nsis@ietf.org
>> https://www1.ietf.or= g/mailman/listinfo/nsis
>
>

______________________= _________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.or= g/mailman/listinfo/nsis

------_=_NextPart_001_01C6F37D.7D22C700-- --===============0815652190== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0815652190==-- From nsis-bounces@ietf.org Thu Oct 19 08:59:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaXUA-0004I8-3C; Thu, 19 Oct 2006 08:58:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaXU9-0004EN-Ez for nsis@ietf.org; Thu, 19 Oct 2006 08:58:57 -0400 Received: from sbcsmtp3.sbc.com ([144.160.112.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaXU3-0007lE-Ih for nsis@ietf.org; Thu, 19 Oct 2006 08:58:57 -0400 Received: from enaf.dadc.sbc.com (localhost.localdomain [127.0.0.1]) by sbcsmtp3.sbc.com (8.13.7/8.13.7) with ESMTP id k9JCwo75008628; Thu, 19 Oct 2006 07:58:50 -0500 Received: from flph023.ffdc.sbc.com (flph023.ffdc.sbc.com [150.234.117.36]) by tlph033.enaf.dadc.sbc.com (8.13.7/8.13.7) with ESMTP id k9JCwmTF008611; Thu, 19 Oct 2006 07:58:48 -0500 Received: from ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flph023.ffdc.sbc.com (8.13.7/8.13.7) with ESMTP id k9JCwmWU008951; Thu, 19 Oct 2006 05:58:48 -0700 Received: from kcclust06evs1.ugd.att.com (kcst11.ugd.att.com [135.38.164.88]) by flph023.ffdc.sbc.com (8.13.7/8.13.7) with ESMTP id k9JCwhtD008901; Thu, 19 Oct 2006 05:58:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Date: Thu, 19 Oct 2006 07:58:43 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7E81@KCCLUST06EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Thread-Index: AcbzPHfjvb4QOwXcRXS4MVBYbTxP1QAOfOQgAAFDyHAAAIlooA== From: "Ash, Gerald R \(Jerry\), ALABS" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: "Ash, Gerald R \(Jerry\), ALABS" , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org John and Dave,=20 > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 > Sent: Thursday, October 19, 2006 8:40 AM > To: Ash, Gerald R (Jerry), ALABS; oran@cisco.com > Cc: nsis@ietf.org > Subject: RE: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt >=20 > Dave & Jerry, >=20 > It would be great if you could propose a resolution to meet Dave's > 'requirement.' It would be fine to discuss off-list and propose > something to move forward. This would be fine by me. Thanks, Jerry >=20 > thanks, > John=20 >=20 > >-----Original Message----- > >From: ext Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com]=20 > >Sent: 19 October, 2006 15:35 > >To: David R Oran > >Cc: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org > >Subject: RE: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt > > > >Hi Dave, > > > >Many thanks for stepping in here. Please see below.=20 > > > >> -----Original Message----- > >> From: David R Oran [mailto:oran@cisco.com] > >> Sent: Thursday, October 19, 2006 1:06 AM > >> To: Lars Westberg > >> Cc: Kappler, Cornelia; Ash, Gerald R (Jerry), ALABS; Georgios=20 > >> Karagiannis; nsis@ietf.org > >> Subject: Re: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt > >>=20 > >> One more time from left-field (I know... I've lost this one=20 > >> before and=20 > >> should keep my mouth shut). > >>=20 > >> Much of this confusion is because I believe the qspec=20 > >> draft and the=20 > >> current notion of "QoS models" has a poor architectural=20 > >> partitioning=20 > >> and hence falls into these kinds of discussions of what is=20 > >> over and=20 > >> under specification, what it means for a parameter to be=20 > >> mandatory,=20 > >> etc. > >>=20 > >> A long time ago I proposed a different architectural=20 > >> partitioning (and=20 > >> moving some things like priority outside the qspec=20 > >> entirely since it=20 > >> was a general admission control parameter and not a QoS=20 > >> parameter). I=20 > >> won't resurrect the whole thing here but remind people if=20 > >> they want to=20 > >> go back a couple of years in the archives they'll find the=20 > >> outline of=20 > >> the proposal and the ensuing discussion. I shut up because the WG=20 > >> consensus was against my proposal and I'm not in the habit of=20 > >> continuing to make a pain of myself when I lose an argument. > > > >I recall the discussion quite well, and my understanding was=20 > >that we adopted your proposal as we understood it. I could go=20 > >back to the threads but I recall no conclusion that what we=20 > >have progressed is contrary to any of your proposals. Indeed,=20 > >we would be unwise to not follow your advice IMO. > >=20 > >> However, it does strike me that this long thread and the=20 > >> last-minute=20 > >> discussions on the qspec draft do have a flavor of the=20 > >> issues I was=20 > >> raising way back when. Just to remind folks, I proposed,=20 > >> more or less: > >>=20 > >> a) a set of parameters, all mandatory, that describe the traffic=20 > >> source in a mathematically complete way. > >> b) a set of parameters, all optional, which give additional hints=20 > >> about characteristics of the source traffic which may=20 > >> allow network=20 > >> elements to optimize their treatment (compressibility hints, pre-=20 > >> encryption hints) > >> c) a set of parameters, mostly optional, that describe the QoS=20 > >> constraints the source wishes applied to the treatment of=20 > >> this traffic=20 > >> (loss rate, jitter, sensitivity to out of order delivery, etc.) > >> d) a set of handling directives, all optional, which specify the=20 > >> source's preferences for traffic handling (e.g. excess treatment) > > > >I agree with Robert that the present qspec is mostly=20 > >consistent and aligned with a) -> d). This is in fact what I=20 > >recall you suggesting 2 years ago, and we had much discussion=20 > >on the list as to how this was being adopted in the qspec. We=20 > >may not have the mandatory/optional split exactly as you=20 > >envision, or the specific suggestions in b), but those things=20 > >can be re-aligned better going forward. =20 > > > >Thanks, > >Regards, > >Jerry > > > >> I think there are a number of ways to close down this discussion ,=20 > >> through which I notice there have been only a few people=20 > >> complaining: > >>=20 > >> a) tell them to shut up, that the WG consensus stands, and=20 > >> see what=20 > >> happens during last call. > >> b) rethink the spec along the lines I outline above and ask those=20 > >> folks if that would address their concerns > >> c) ask for a formal outside review, either by raising these issues=20 > >> explicitly in the last call and requesting comments, or=20 > >> punting to the=20 > >> IESG to solicit such advice. > >>=20 > >> I promise not to rock the boat if you choose (a). > >>=20 > >> Dave Oran. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 19 09:01:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaXWT-0007e6-7k; Thu, 19 Oct 2006 09:01:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaXWR-0007dy-IS for nsis@ietf.org; Thu, 19 Oct 2006 09:01:19 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaXWP-0008FC-36 for nsis@ietf.org; Thu, 19 Oct 2006 09:01:19 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k9JD14VE017257; Thu, 19 Oct 2006 15:01:09 +0200 (MEST) From: "Georgios Karagiannis" To: "'David R Oran'" Subject: RE: [NSIS] Proposal to move the QSPEC work forward Date: Thu, 19 Oct 2006 15:01:00 +0200 Message-ID: <005f01c6f37e$a371c950$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcbzdrOC+BmBzNYfSe6dceCCZajlaAAB2dCg X-Spam-Score: -5.522 () ALL_TRUSTED,AWL,BAYES_00,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Thu, 19 Oct 2006 15:01:11 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: john.loughney@nokia.com, bless@tm.uka.de, jmanner@cs.Helsinki.FI, nsis@ietf.org, robert.hancock@roke.co.uk X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org 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 > -----Original Message----- > From: David R Oran [mailto:oran@cisco.com] > Sent: donderdag 19 oktober 2006 14:02 > To: Georgios Karagiannis > Cc: john.loughney@nokia.com; bless@tm.uka.de; > jmanner@cs.Helsinki.FI; nsis@ietf.org; robert.hancock@roke.co.uk > Subject: Re: [NSIS] Proposal to move the QSPEC work forward > > > On Oct 19, 2006, at 7:47 AM, Georgios Karagiannis wrote: > > > 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. > > > 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. > > > 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 > - minimum quantum (what RSVP TSPEC calls minimum policed unit) > > for a complete description of a traffic source. > > > Best regards, > > Georgios > > > > > > > > > > > >> -----Original Message----- > >> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > >> Sent: donderdag 19 oktober 2006 13:30 > >> To: oran@cisco.com; bless@tm.uka.de > >> Cc: robert.hancock@roke.co.uk; karagian@cs.utwente.nl; > >> jmanner@cs.Helsinki.FI; nsis@ietf.org > >> Subject: RE: [NSIS] Proposal to move the QSPEC work forward > >> > >> Dave, > >> > >>>> Robert Hancock wrote: > >>>>> 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. > >>>> > >>> 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 > >> > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 19 09:09:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaXdm-0000qN-Pd; Thu, 19 Oct 2006 09:08:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaXdl-0000k5-6n for nsis@ietf.org; Thu, 19 Oct 2006 09:08:53 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaXdj-0000zl-P0 for nsis@ietf.org; Thu, 19 Oct 2006 09:08:53 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k9JD8KXk018274; Thu, 19 Oct 2006 15:08:24 +0200 (MEST) From: "Georgios Karagiannis" To: , Subject: RE: [NSIS] QSPEC proposal Date: Thu, 19 Oct 2006 15:08:16 +0200 Message-ID: <006001c6f37f$a7498fd0$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcbzdhipoftX8wQISZKQcheyV5RpSwAAhjcwAAG2+1A= X-Spam-Score: -5.321 () ALL_TRUSTED, AWL, BAYES_00, FVGT_m_MULTI_ODD, FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Thu, 19 Oct 2006 15:08:25 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: oran@cisco.com, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi John I also still do not understand point 4)? Is this relkated to the possibility of ignoring mandatory parameters? How many mandatory parameters will then the base QSPEC have? I assume that Dave, proposed to have one mandatory parameter and that is the Token Bucket specification. Best Regards, Georgios > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: donderdag 19 oktober 2006 14:25 > To: jgunn6@csc.com > Cc: oran@cisco.com; nsis@ietf.org > Subject: RE: [NSIS] QSPEC proposal > > Hi Janet, > > What I mean is that there could be a way to transparently > pass the QoS Model QSPEC without mapping it to the baseline QSPEC. > > John > > >-----Original Message----- > >From: ext Janet P Gunn [mailto:jgunn6@csc.com] > >Sent: 19 October, 2006 15:00 > >To: Loughney John (Nokia-NRC/Helsinki) > >Cc: nsis@ietf.org; oran@cisco.com > >Subject: Re: [NSIS] QSPEC proposal > > > > > > > > > > > > > > > >Can you please rephrase number 4? I don't understand it the > way it is > >currently written. > > > >Thanks > > > >Janet > > > > > > wrote on 10/19/2006 07:43:25 AM: > > > >> Hi all, > >> > >> I've been in transit for a few days, so trying to catch-up on all > >> mails is somewhat challenging. Here's a partially baked proposal, > >> considering the mails on this thread. My proposal for the > >WG to consider is: > >> > >> 1) We take Dave's proposal as a baseline QSPEC: > >> > >> a) a set of parameters, all mandatory, that describe the traffic > >> source in a mathematically complete way. > >> b) a set of parameters, all optional, which give additional hints > >> about characteristics of the source traffic which may > allow network > >> elements to optimize their treatment (compressibility hints, pre- > >> encryption > >> hints) > >> c) a set of parameters, mostly optional, that describe the QoS > >> constraints the source wishes applied to the treatment of > >this traffic > >> (loss rate, jitter, sensitivity to out of order delivery, etc.) > >> d) a set of handling directives, all optional, which specify the > >> source's preferences for for traffic handling (e.g. excess > treatment) > >> > >> 2) Allow QoS Models to use a secondary QSPEC, that may not be > >> mathmetically complete. > >> 3) QoS models specify how to map to the baseline QSPEC. > >> 4) Add a MAP/NO MAP byte, which a QoS Model can use if they > >want their > >> model mapped (or not) to domains support QoS models. > >> > >> Would this meet people's needs? I could see that point 4 > >might allow > >> use cases that Lars/Georgios would like. > >> > >> Robert and Dave seem to agree that point 1) is not too far > from the > >> current QSPEC. > >> > >> John > >> > >> _______________________________________________ > >> nsis mailing list > >> nsis@ietf.org > >> https://www1.ietf.org/mailman/listinfo/nsis > > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 19 09:19:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaXnZ-0004ey-Je; Thu, 19 Oct 2006 09:19:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaXnX-0004en-WF for nsis@ietf.org; Thu, 19 Oct 2006 09:19:00 -0400 Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaXnT-00030W-Cg for nsis@ietf.org; Thu, 19 Oct 2006 09:18:59 -0400 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx.mail.saic.com; Thu, 19 Oct 2006 09:18:44 -0400 Received: from 0015-ITS-EXBH01.us.saic.com ([10.43.229.18]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006101909184319562 ; Thu, 19 Oct 2006 09:18:43 -0400 Received: from 0591-ITS-EXMP02.us.saic.com ([10.42.81.248]) by 0015-ITS-EXBH01.us.saic.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 09:18:43 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Date: Thu, 19 Oct 2006 09:18:41 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426E1CEE3@0591-ITS-EXMP02.us.saic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Thread-Index: AcbzbQUmtghxtNbkR6qpPnrPQv+YPAABFCiQAAM0x1Q= References: <004901c6f373$89ef5570$4c0d5982@dynamic.ewi.utwente.nl> From: "Roy, Radhika R." To: "Georgios Karagiannis" , "David R Oran" X-OriginalArrivalTime: 19 Oct 2006 13:18:43.0112 (UTC) FILETIME=[19851280:01C6F381] X-Spam-Score: 0.1 (/) X-Scan-Signature: 3f2cf88677bfbdeff30feb2c80e2257d Cc: john.loughney@nokia.com, gash@att.com, Lars.westberg@ericsson.com, nsis@ietf.org, cornelia.kappler@Siemens.com X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0861667956==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0861667956== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F381.18C088FC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F381.18C088FC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Georgios and Dave: =20 Like you, all of us are also extremely worried to solve the fundamental = problem as stated again and again as follows: =20 "The problem that remains to be solved is to find out how to interwork = between the QoS models." The only way is to solve the interworking between different QOS models, = we need to do deep "surgery" of our understanding what we mean by QOS = models in the first place. =20 What properties of a QOS model make it a QOS model? In my other emails, = I have clarified this. Let me try again. =20 We have DiffServ, RSVP, and IntServ QOS models. These QOS models = interwork among themselves. What are the properties of these QOS models? =20 We have another set of so-called QOS implementation schemes: Y.1541 and = DSTE. They even do NOT interwork among themselves. What are the = properties of these two? Are these two represent QOS models? If so, why = do they qualify for being QOS models? =20 The key is this: If one put some specific values in RSVP QOS parameters, = one cane easily get all so-called QOS classes implemented, for example, = people will get Y.1541 and DSTE implementations. =20 The question is this: How do you interwork between = non-implementation-specific non-value-based (DiffServ, RSVP, IntServ) = and implementation-specific value-based (Y.1541 and DSTE) system? =20 It is a problem of mixing between "apples" and "oranges." The technical = miracle will NEVER happen just because Dave have made one high level = proposal. Let us not dance around this proposal yet unless it solves the = interworking problems of QOS models. =20 The clear proposal is this as articulated in earlier email: Make two = separate drafts -=20 =20 1. Non-implementation-specific non-value-based (DiffServ, RSVP, IntServ) = and=20 2. Implementation-specific value-based (Y.1541 and DSTE) =20 Best regards, Radhika ________________________________ From: nsis-bounces@ietf.org on behalf of Georgios Karagiannis Sent: Thu 10/19/2006 7:41 AM To: 'David R Oran' Cc: john.loughney@nokia.com; gash@att.com; Lars.westberg@ericsson.com; = nsis@ietf.org; cornelia.kappler@Siemens.com Subject: RE: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Hi Dave Please see in line! > -----Original Message----- > From: David R Oran [mailto:oran@cisco.com] > Sent: donderdag 19 oktober 2006 12:54 > To: Georgios Karagiannis > Cc: john.loughney@nokia.com; Lars.westberg@ericsson.com; > gash@att.com; nsis@ietf.org; cornelia.kappler@Siemens.com > Subject: Re: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt > > > On Oct 19, 2006, at 6:04 AM, Georgios Karagiannis wrote: > > > Hi John > > > > After studying the a) to d) points of Dave in more detail I > think that > > they are different than the proposal of Jukka! > > > That is correct. My point was quite different. > > > Actually point a) falls under the responability of an interworking > > activity, while points b) c) and d) fall under the QSPEC tem[plate > > activity! > > > That is not what I intended. The idea was to separate the > issue of source traffic description from the questions of > exactly what constraints on QoS delivery for such a traffic > source have to be met by the QoS elements on the path in > order to admission control to succeed. > > > Thus I thinkl that the call should first of all cover the > proposal of > > Jukka! > > > Jukka's proposal is to define a unstructured data schema for > QoS parameters so there are no constraints on what can be > expressed in an NSIS admission control and QoS signaling > transaction. I think this approach basically > institutionalizes non-interoperability, and hence I think it > is not a good idea. Georgios: I think that what Jukka meant is as follows: First let the QSPEC template define the encoding of the QSPEC object and = its parameters. However, the QSPEC template will not define which of these parameters = are mandatory and which not. Here I however, I could agree with you that the QSPEC template could specify the Traaffic descriptor, i.e., Bandwidth, as a manadtory parameter. This is diferent then having 13 mandatory parameters in the QSPEC = template. This will give the opportunity to QoS models to start the deployment = phase. Furthermore, the QOS models can however define which of the QSPEc pasrameters (assocaited with the QoS model) can be mandatory and which optional. The problem that remains to be solved is to find out how to interwork between the QoS models. As a starting point the QSPEC template could define one mandatory = parameter and that is Bandwidth. This will give the opportunity to let QoS models start the deployment = phase. If during the deployment phase we will see that more parameters must be made mandatory then we can start an interworking activity to work out = the interoperability problem. > > If we follow the proposal of Jukka, then we can a) to provide the > > interworking and follow b), c) and d) to finalise the QSPEC > template, > > that in my opinion means: > > make all mandator optional and we are done with the QWSPEC template > > draft! > > > We are certainly done, but what then will we have accomplished? Georgios: Please see above. Please note that I agree with you regarding the need of having a mandatory Traffic description, which in my opinion should be Bandwdith. This will allow a basis for interoperability between QoS models. What do you think? Best regards, Georgios > > > > ------_=_NextPart_001_01C6F381.18C088FC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: AW: AW: [NSIS] I-D = ACTION:draft-ietf-nsis-qspec-12.txt=0A= =0A= =0A= =0A=
=0A=
Hi, Georgios = and Dave:
=0A=
 
=0A=
Like you, all of us are also = extremely worried to solve the fundamental problem as stated again and = again as follows:
=0A=
 
=0A=
"The problem that remains to be solved is = to find out how to interwork between the QoS models."
=0A=
The only way is to solve the = interworking between different QOS models, we need to do deep "surgery" = of our understanding what we mean by QOS models in the first = place.
=0A=
 
=0A=
What properties of a QOS = model make it a QOS model? In my other emails, I have clarified this. = Let me try again.
=0A=
 
=0A=
We have DiffServ, RSVP, and = IntServ QOS models. These QOS models interwork among themselves. What = are the properties of these QOS models?
=0A=
 
=0A=
We have another set of = so-called QOS implementation schemes: Y.1541 and DSTE. They even do NOT = interwork among themselves. What are the properties of these two? Are = these two represent QOS models? If so, why do they qualify for being QOS = models?
=0A=
 
=0A=
The key is this: If one put = some specific values in RSVP QOS parameters, one cane easily get all = so-called QOS classes implemented, for example, people will get Y.1541 = and DSTE implementations.
=0A=
 
=0A=
The question is this: How do = you interwork between non-implementation-specific non-value-based = (DiffServ, RSVP, IntServ) and implementation-specific value-based = (Y.1541 and DSTE) system?
=0A=
 
=0A=
It is a problem of = mixing between "apples" and "oranges." The technical miracle will = NEVER happen just because Dave have made one high level proposal. = Let us not dance around this proposal yet unless it solves the = interworking problems of QOS models.
=0A=
 
=0A=
The clear proposal is this as = articulated in earlier email: Make two separate drafts -
=0A=
 
=0A=
1. = Non-implementation-specific non-value-based (DiffServ, RSVP, IntServ) = and
=0A=
2. Implementation-specific = value-based (Y.1541 and DSTE)
=0A=
 
=0A=
Best regards,
=0A=
Radhika
=0A=

=0A=
=0A= From: nsis-bounces@ietf.org on = behalf of Georgios Karagiannis
Sent: Thu 10/19/2006 7:41 = AM
To: 'David R Oran'
Cc: john.loughney@nokia.com; = gash@att.com; Lars.westberg@ericsson.com; nsis@ietf.org; = cornelia.kappler@Siemens.com
Subject: RE: AW: AW: [NSIS] I-D = ACTION:draft-ietf-nsis-qspec-12.txt

=0A=
=0A=

Hi Dave

 Please see in line!

> = -----Original Message-----
> From: David R Oran [mailto:oran@cisco.com]
> Sent: = donderdag 19 oktober 2006 12:54
> To: Georgios Karagiannis
> = Cc: john.loughney@nokia.com; Lars.westberg@ericsson.com;
> = gash@att.com; nsis@ietf.org; cornelia.kappler@Siemens.com
> = Subject: Re: AW: AW: [NSIS] I-D = ACTION:draft-ietf-nsis-qspec-12.txt
>
>
> On Oct 19, = 2006, at 6:04 AM, Georgios Karagiannis wrote:
>
> > Hi = John
> >
> > After studying the a) to d) points of = Dave in more detail I
> think that
> > they are different = than the proposal of Jukka!
> >
> That is correct. My = point was quite different.
>
> > Actually point a) falls = under the responability of an interworking
> > activity, while = points b) c) and d) fall under the QSPEC tem[plate
> > = activity!
> >
> That is not what I intended. The idea was = to separate the
> issue of source traffic description from the = questions of
> exactly what constraints on QoS delivery for such a = traffic
> source have to be met by the QoS elements on the path = in
> order to admission control to succeed.
>
> > = Thus I thinkl that the call should first of all cover the
> = proposal of
> > Jukka!
> >
> Jukka's proposal is = to define a unstructured data schema for
> QoS parameters so there = are no constraints on what can be
> expressed in an NSIS admission = control and QoS signaling
> transaction. I think this approach = basically
> institutionalizes non-interoperability, and hence I = think it
> is not a good idea.

Georgios:
I think that = what Jukka meant is as follows:
First let the QSPEC template define = the encoding of the QSPEC object and its
parameters.
However, the = QSPEC template will not define which of these parameters = are
mandatory and which not.

Here I however, I could agree = with you
that the QSPEC template could specify the Traaffic = descriptor,
i.e., Bandwidth, as a manadtory parameter.
This is = diferent then having 13 mandatory parameters in the QSPEC = template.
This will give the opportunity to QoS models to start the = deployment phase.

Furthermore, the QOS models can however define = which of the
QSPEc pasrameters (assocaited with the QoS model)
can = be mandatory and which optional.

The problem that remains to be = solved is to find out how to interwork
between the QoS models.
As = a starting point the QSPEC template could define one mandatory = parameter
and that is Bandwidth.
This will give the opportunity to = let QoS models start the deployment phase.

If during the = deployment phase we will see that more parameters must be
made = mandatory then we can start an interworking activity to work out = the
interoperability problem.







> = > If we follow the proposal of Jukka, then we can a) to provide = the
> > interworking and follow b), c) and d) to finalise the = QSPEC
> template,
> > that in my opinion means:
> = > make all mandator optional and we are done with the QWSPEC = template
> > draft!
> >
> We are certainly done, = but what then will we have accomplished?

Georgios: Please see = above. Please note that I agree with you regarding
the need of having = a mandatory Traffic description,
which in my opinion should be = Bandwdith. This will allow
a basis for interoperability between QoS = models.

What do you think?

Best = regards,
Georgios

> >
> = >

------_=_NextPart_001_01C6F381.18C088FC-- --===============0861667956== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0861667956==-- From nsis-bounces@ietf.org Thu Oct 19 09:20:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaXoD-0004x8-6F; Thu, 19 Oct 2006 09:19:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaXoB-0004vl-S7 for nsis@ietf.org; Thu, 19 Oct 2006 09:19:39 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaXny-00037Y-P8 for nsis@ietf.org; Thu, 19 Oct 2006 09:19:39 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id F311B4F0001; Thu, 19 Oct 2006 15:19:23 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 15:19:23 +0200 Received: from ericsson.com ([147.214.26.58]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 15:19:23 +0200 Message-ID: <45377B5B.4090209@ericsson.com> Date: Thu, 19 Oct 2006 15:19:23 +0200 From: Lars Westberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David R Oran Subject: Re: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt References: <002101c6f365$eeb23260$4c0d5982@dynamic.ewi.utwente.nl> In-Reply-To: X-OriginalArrivalTime: 19 Oct 2006 13:19:23.0455 (UTC) FILETIME=[3190ECF0:01C6F381] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: fb93e867a11a29ac1dc5018706b412ac Cc: john.loughney@nokia.com, gash@att.com, Georgios Karagiannis , nsis@ietf.org, cornelia.kappler@Siemens.com X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1115127497==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============1115127497== Content-Type: multipart/alternative; boundary="------------010606090806090604040104" This is a multi-part message in MIME format. --------------010606090806090604040104 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit comment inline David R Oran wrote: > > On Oct 19, 2006, at 6:04 AM, Georgios Karagiannis wrote: > > > Hi John > > > > After studying the a) to d) points of Dave in more detail > > I think that they are different than the proposal of Jukka! > > > That is correct. My point was quite different. > > > Actually point a) falls under the responability of an interworking > > activity, while points b) c) and d) > > fall under the QSPEC tem[plate activity! > > > That is not what I intended. The idea was to separate the issue of > source traffic description from the questions of exactly what > constraints on QoS delivery for such a traffic source have to be met > by the QoS elements on the path in order to admission control to > succeed. > > > Thus I thinkl that the call should first of all cover the proposal > > of Jukka! > > > Jukka's proposal is to define a unstructured data schema for QoS > parameters so there are no constraints on what can be expressed in an > NSIS admission control and QoS signaling transaction. I think this > approach basically institutionalizes non-interoperability, and hence > I think it is not a good idea. > Mandating one single parameter se into the core NSIS-specification seems not a good idea. In reality, I would rather prefer to include this as topic into a re-chartering of the working group. > > > If we follow the proposal of Jukka, then we can a) to provide the > > interworking > > and follow b), c) and d) > > to finalise the QSPEC template, that in my opinion means: > > make all mandator optional and we are done with the QWSPEC template > > draft! > > > We are certainly done, but what then will we have accomplished? > > > best regards, > > Georgios > > > > > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > Sent: donderdag 19 oktober 2006 10:36 > > To: Lars.westberg@ericsson.com > > Cc: oran@cisco.com; gash@att.com; karagian@cs.utwente.nl; > > nsis@ietf.org; cornelia.kappler@siemens.com > > Subject: RE: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt > > > > I think that Jukka's suggestion basically falls under Dave's choice D. > > > > John > > > > From: ext Lars Westberg [mailto:Lars.westberg@ericsson.com] > > Sent: 19 October, 2006 11:12 > > To: Loughney John (Nokia-NRC/Helsinki) > > Cc: oran@cisco.com; gash@att.com; karagian@cs.utwente.nl; > > nsis@ietf.org; cornelia.kappler@siemens.com > > Subject: Re: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt > > > > if you should call for consensus, you have to consider other > > alternative as well, not just one person opinion. > > > > Jukkas proposal should be one of them. > > > > -lasse > > > > john.loughney@nokia.com wrote: > >> Dave, > >> > >> Thanks for your mail, I've been rolling some concepts in my head > >> but you have boiled them down to 4 concise points: > >> > >> >However, it does strike me that this long thread and the > >> >last-minute discussions on the qspec draft do have a flavor of > >> >the issues I was raising way back when. Just to remind folks, > >> >I proposed, more or less: > >> > > >> >a) a set of parameters, all mandatory, that describe the > >> >traffic source in a mathematically complete way. > >> > > >> >b) a set of parameters, all optional, which give additional > >> >hints about characteristics of the source traffic which may > >> >allow network elements to optimize their treatment > >> >(compressibility hints, pre- encryption hints) > >> > > >> >c) a set of parameters, mostly optional, that describe the QoS > >> >constraints the source wishes applied to the treatment of this > >> >traffic (loss rate, jitter, sensitivity to out of order delivery, > >> etc.) > >> > > >> >d) a set of handling directives, all optional, which specify > >> >the source's preferences for for traffic handling (e.g. excess > >> >treatment) > >> > >> So, at this point, I cannot think of a better set of concepts > >> to call concensus on. I'm going to issue a concensus call > >> to finalize this. I see your points as the basic issue to resolve. > >> > >> thanks, > >> John > --------------010606090806090604040104 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit comment inline

David R Oran wrote:
Re: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

On Oct 19, 2006, at 6:04 AM, Georgios Karagiannis wrote:

> Hi John
>
> After studying the a) to d) points of Dave in more detail
> I think that they are different than the proposal of Jukka!
>
That is correct. My point was quite different.

> Actually point a) falls under the responability of an interworking 
> activity, while points b) c) and d)
> fall under the QSPEC tem[plate activity!
>
That is not what I intended. The idea was to separate the issue of 
source traffic description from the questions of exactly what 
constraints on QoS delivery for such a traffic source have to be met 
by the QoS elements on the path in order to admission control to 
succeed.

> Thus I thinkl that the call should first of all cover the proposal 
> of Jukka!
>
Jukka's proposal is to define a unstructured data schema for QoS 
parameters so there are no constraints on what can be expressed in an 
NSIS admission control and QoS signaling transaction. I think this 
approach basically institutionalizes non-interoperability, and hence 
I think it is not a good idea.


Mandating one single parameter se into the core NSIS-specification seems not a good idea. 
In reality, I would rather prefer to include this as topic into a re-chartering of the working group.


> If we follow the proposal of Jukka, then we can a) to provide the 
> interworking
> and follow b), c) and d)
> to finalise the QSPEC template, that in my opinion means:
> make all mandator optional and we are done with the QWSPEC template 
> draft!
>
We are certainly done, but what then will we have accomplished?

> best regards,
> Georgios
>
>
> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> Sent: donderdag 19 oktober 2006 10:36
> To: Lars.westberg@ericsson.com
> Cc: oran@cisco.com; gash@att.com; karagian@cs.utwente.nl; 
> nsis@ietf.org; cornelia.kappler@siemens.com
> Subject: RE: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt
>
> I think that Jukka's suggestion basically falls under Dave's choice D.
>
> John
>
> From: ext Lars Westberg [mailto:Lars.westberg@ericsson.com]
> Sent: 19 October, 2006 11:12
> To: Loughney John (Nokia-NRC/Helsinki)
> Cc: oran@cisco.com; gash@att.com; karagian@cs.utwente.nl; 
> nsis@ietf.org; cornelia.kappler@siemens.com
> Subject: Re: AW: AW: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt
>
> if you should call for consensus, you have to consider other 
> alternative as well, not just one person opinion.
>
> Jukkas proposal should be one of them.
>
> -lasse
>
> john.loughney@nokia.com wrote:
>> Dave,
>>
>> Thanks for your mail, I've been rolling some concepts in my head
>> but you have boiled them down to 4 concise points:
>>
>> >However, it does strike me that this long thread and the
>> >last-minute discussions on the qspec draft do have a flavor of
>> >the issues I was raising way back when. Just to remind folks,
>> >I proposed, more or less:
>> >
>> >a) a set of parameters, all mandatory, that describe the
>> >traffic source in a mathematically complete way.
>> >
>> >b) a set of parameters, all optional, which give additional
>> >hints about characteristics of the source traffic which may
>> >allow network elements to optimize their treatment
>> >(compressibility hints, pre- encryption hints)
>> >
>> >c) a set of parameters, mostly optional, that describe the QoS
>> >constraints the source wishes applied to the treatment of this
>> >traffic (loss rate, jitter, sensitivity to out of order delivery, 
>> etc.)
>> >
>> >d) a set of handling directives, all optional, which specify
>> >the source's preferences for for traffic handling (e.g. excess
>> >treatment)
>>
>> So, at this point, I cannot think of a better set of concepts
>> to call concensus on.  I'm going to issue a concensus call
>> to finalize this.  I see your points as the basic issue to resolve.
>>
>> thanks,
>> John

--------------010606090806090604040104-- --===============1115127497== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============1115127497==-- From nsis-bounces@ietf.org Thu Oct 19 09:26:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaXuZ-00048L-1O; Thu, 19 Oct 2006 09:26:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaXuY-00048C-2i for nsis@ietf.org; Thu, 19 Oct 2006 09:26:14 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaXuU-0004Ti-Go for nsis@ietf.org; Thu, 19 Oct 2006 09:26:14 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 19 Oct 2006 06:26:10 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9JDQ9iP024571; Thu, 19 Oct 2006 06:26:09 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9JDQ9Ao027820; Thu, 19 Oct 2006 06:26:09 -0700 (PDT) Received: from [10.51.0.33] (ams3-vpn-dhcp32.cisco.com [10.61.64.32]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k9JDE2AR014033; Thu, 19 Oct 2006 06:14:03 -0700 In-Reply-To: <006001c6f37f$a7498fd0$4c0d5982@dynamic.ewi.utwente.nl> References: <006001c6f37f$a7498fd0$4c0d5982@dynamic.ewi.utwente.nl> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <019FBEA8-325B-4231-903F-46EA066CA1A8@cisco.com> Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [NSIS] QSPEC proposal Date: Thu, 19 Oct 2006 09:25:06 -0400 To: "Georgios Karagiannis" X-Mailer: Apple Mail (2.752.2) Authentication-Results: sj-dkim-1.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=4516; t=1161264370; x=1162128370; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:David=20R=20Oran=20 |Subject:Re=3A=20[NSIS]=20QSPEC=20proposal; X=v=3Dcisco.com=3B=20h=3DAj9Mtmc0PVpZZ3Af6wEK3YC3SxM=3D; b=X//mv2oThD2w8JduuCqhASrhkuL6fqEYOAWTzIx+A1U2xS5KFcEvwOKulhRSZPGTWcNHkKZ0 e1tDQAxHSAo+Jw3AAOIj0/QbQgnXnrR7uarMFVOcIb5yD8CnoMk5qhZe; X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: john.loughney@nokia.com, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org On Oct 19, 2006, at 9:08 AM, Georgios Karagiannis wrote: > Hi John > > I also still do not understand point 4)? > > Is this relkated to the possibility of ignoring mandatory parameters? > > How many mandatory parameters will then the base QSPEC have? > I assume that Dave, proposed to have one mandatory parameter and > that is the > > Token Bucket specification. > I still think we are talking past each other. Please tell me which of the following is your intended definition of "mandatory" w) must be present in any QSPEC formulated by the end user x) must be understood by every QOS NSLP-capable network element in the universe y) must result in admission control success in any NSLP-capable network element that has sufficient resources to comply with the specified value by the user. My preferred formulation is actually none of the above. 1. that only the TSPEC-like parameters in my traffic description proposal be mandatory in the sense that your request is syntactically invalid if they are not present. 2. That all the traffic description in my (b) category be optional both for inclusion and for interpretation by the network elements. 3. That for the constraint parameters, we explicitly encode in the protocol whether the user wants to have admission control succeed IF AND ONLY IF the parameter is understood, and the constraint satisfied, by each QOS NSLP-capable network element on the signaling path. I do not like the ideaq of statically binning the constraint parameters in architectural "mandatory/optional" categories. Cheers, Dave. > Best Regards, > Georgios > > > > > >> -----Original Message----- >> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] >> Sent: donderdag 19 oktober 2006 14:25 >> To: jgunn6@csc.com >> Cc: oran@cisco.com; nsis@ietf.org >> Subject: RE: [NSIS] QSPEC proposal >> >> Hi Janet, >> >> What I mean is that there could be a way to transparently >> pass the QoS Model QSPEC without mapping it to the baseline QSPEC. >> >> John >> >>> -----Original Message----- >>> From: ext Janet P Gunn [mailto:jgunn6@csc.com] >>> Sent: 19 October, 2006 15:00 >>> To: Loughney John (Nokia-NRC/Helsinki) >>> Cc: nsis@ietf.org; oran@cisco.com >>> Subject: Re: [NSIS] QSPEC proposal >>> >>> >>> >>> >>> >>> >>> >>> Can you please rephrase number 4? I don't understand it the >> way it is >>> currently written. >>> >>> Thanks >>> >>> Janet >>> >>> >>> wrote on 10/19/2006 07:43:25 AM: >>> >>>> Hi all, >>>> >>>> I've been in transit for a few days, so trying to catch-up on all >>>> mails is somewhat challenging. Here's a partially baked proposal, >>>> considering the mails on this thread. My proposal for the >>> WG to consider is: >>>> >>>> 1) We take Dave's proposal as a baseline QSPEC: >>>> >>>> a) a set of parameters, all mandatory, that describe the traffic >>>> source in a mathematically complete way. >>>> b) a set of parameters, all optional, which give additional hints >>>> about characteristics of the source traffic which may >> allow network >>>> elements to optimize their treatment (compressibility hints, pre- >>>> encryption >>>> hints) >>>> c) a set of parameters, mostly optional, that describe the QoS >>>> constraints the source wishes applied to the treatment of >>> this traffic >>>> (loss rate, jitter, sensitivity to out of order delivery, etc.) >>>> d) a set of handling directives, all optional, which specify the >>>> source's preferences for for traffic handling (e.g. excess >> treatment) >>>> >>>> 2) Allow QoS Models to use a secondary QSPEC, that may not be >>>> mathmetically complete. >>>> 3) QoS models specify how to map to the baseline QSPEC. >>>> 4) Add a MAP/NO MAP byte, which a QoS Model can use if they >>> want their >>>> model mapped (or not) to domains support QoS models. >>>> >>>> Would this meet people's needs? I could see that point 4 >>> might allow >>>> use cases that Lars/Georgios would like. >>>> >>>> Robert and Dave seem to agree that point 1) is not too far >> from the >>>> current QSPEC. >>>> >>>> John >>>> >>>> _______________________________________________ >>>> nsis mailing list >>>> nsis@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/nsis >>> >>> >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis >> _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 19 09:31:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaXzO-0008T8-3T; Thu, 19 Oct 2006 09:31:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaXzN-0008T1-6d for nsis@ietf.org; Thu, 19 Oct 2006 09:31:13 -0400 Received: from mclmx2.mail.saic.com ([149.8.64.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaXzK-0005QQ-Kh for nsis@ietf.org; Thu, 19 Oct 2006 09:31:13 -0400 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com; Thu, 19 Oct 2006 09:30:55 -0400 Received: from 0015-ITS-EXBH01.us.saic.com ([10.43.229.18]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006101909305422146 ; Thu, 19 Oct 2006 09:30:54 -0400 Received: from 0591-ITS-EXMP02.us.saic.com ([10.42.81.248]) by 0015-ITS-EXBH01.us.saic.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 09:30:54 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Date: Thu, 19 Oct 2006 09:30:53 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426E1CEE4@0591-ITS-EXMP02.us.saic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Thread-Index: Acbye4IZ7vmeaP4vRWSoYWr8MvZn4AARbEXAABPFuNAAHEeO0A== References: From: "Roy, Radhika R." To: , , X-OriginalArrivalTime: 19 Oct 2006 13:30:54.0198 (UTC) FILETIME=[CD47F160:01C6F382] X-Spam-Score: 0.0 (/) X-Scan-Signature: 509eeaf340e89c687918a6101c6def35 Cc: gash@att.com, karagian@cs.utwente.nl, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0943869882==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0943869882== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F382.CCDD46E8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F382.CCDD46E8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Chuck: =20 You just "remove" the "values" of the parameters of Y.1541. All bubbles = of Y.1541 will burst in the air.=20 =20 If you use those some specific values in RSVP, you can get all the = Y.1541 QOS classes implemented in it, but not vice versa. =20 You can easily see what QOS properties Y.1541 has. =20 When something is based on specific values it is called = implementation-specific. =20 Any implementation can be mapped to RSVP and DiffServ. That does not = mean implementations are QOS standards. =20 Best regards, Radhika =20 PS: Experts of the whole world will always be using Y.1541 for = implementations. Pl. advise them to express their opinions for all = emails that I have sent in the IETF mailing list. Otherwise, you can = send them all the emails that I sent. Let them read it and participate = in the IETF mailing list. Unlike ITU-T and 3GPP, this mailing list is = open to all. ________________________________ From: cdvorak@research.att.com [mailto:cdvorak@research.att.com] Sent: Wed 10/18/2006 8:15 PM To: RADHIKA.R.ROY@saic.com; lars.westberg@ericsson.com; = john.loughney@nokia.com Cc: gash@att.com; karagian@cs.utwente.nl; nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Radhika =20 Water and oil aside, the Y.1541 QoS classes are not = "implementation-specific" as you say. They may use DiffServ, they may = use RSVP, they may use something else. How is that = implementation-specific? =20 For me, this misunderstanding by you is the root cause of your = criticism. (I understand your argument-I just do not agree with it, = because it is inaccurate.) =20 The Y.1541 classes are QoS classes that many experts around the world = agreed capture, in a reasonably small number, distinct combinations of = IP performance parameters capable of supporting virtually all user = applications with the requisite QoS. On an e2e basis, a user may for = example indicate "I am using IPTV and want to request Y.1541 Class 5, = which would satisfy my QoS needs." Networks in the path may implement = different QoS schemes (per-hop, per-domain, whatever), but a good NSIS = method will still allow the e2e QoS classes (of Y.1541) to be addressed. =20 But there is no effective way to signal this e2e today, and that is what = many of us wanted NSIS to do-signal this e2e need, with enough hooks to = be useful.=20 =20 If all that is done in NSIS is to make incremental improvements to RSVP, = or to focus primarily on signaling peak bandwidth needs, then IMO the = end result will not be nearly as useful as many of us had hoped. =20 Chuck Dvorak AT&T Labs Research ________________________________ From: Roy, Radhika R. [mailto:RADHIKA.R.ROY@saic.com]=20 Sent: Wednesday, October 18, 2006 10:37 AM To: lars.westberg@ericsson.com; john.loughney@nokia.com Cc: gash@att.com; Georgios Karagiannis; RADHIKA.R.ROY@saic.com; = nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt =20 Lars: =20 You are right. That is why, the QOS model like DiffServ comes into = picture. =20 There is another aspect of these QOS models so far the standardization = is concerned. That is called interwoking between the different QOS = modeling standards. For example, you have mentioned as follows: =20 Inter-operabillity solved by:=20 1) Overprovisioning in the core such as all QoS-requirments are solved. 2) Interoperabillity for different QoS-models =3D>Peak-allocation of = bandwidth. =20 All the trends of QOS models have been basically like the above. =20 Recently, we also see some fertile brains have created some so-called = "Implementation-specific QOS schemes" that are based on "values" of all = QOS parameters. The fundamental problems are that they also called these = as QOS models (instead of saying that these are some QOS = "implementation" schemes, NOT QOS models). They have even convinced few = folks here and there of different standard organizations that they need = "interworking" between different QOS models. =20 Here the fundamental problems come. Who is kidding whom trying to mixing = between water and oil?=20 =20 Best regards, Radhika ------_=_NextPart_001_01C6F382.CCDD46E8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A=
=0A=
Chuck:
=0A=
 
=0A=
You just "remove" the = "values" of the parameters of Y.1541. All bubbles of Y.1541 will burst = in the air.
=0A=
 
=0A=
If you use those some = specific values in RSVP, you can get all the Y.1541 QOS classes = implemented in it, but not vice versa.
=0A=
 
=0A=
You can easily see what QOS = properties Y.1541 has.
=0A=
 
=0A=
When something is based on = specific values it is called implementation-specific.
=0A=
 
=0A=
Any implementation can be = mapped to RSVP and DiffServ. That does not mean implementations are QOS = standards.
=0A=
 
=0A=
Best regards,
=0A=
Radhika
=0A=
 
=0A=
PS: Experts of the whole = world will always be using Y.1541 for implementations. Pl. advise them = to express their opinions for all emails that I have sent in the IETF = mailing list. Otherwise, you can send them all the emails that I sent. = Let them read it and participate in the IETF mailing list. Unlike = ITU-T and 3GPP, this mailing list is open to all.
=0A=

=0A=
=0A= From: cdvorak@research.att.com = [mailto:cdvorak@research.att.com]
Sent: Wed 10/18/2006 8:15 = PM
To: RADHIKA.R.ROY@saic.com; lars.westberg@ericsson.com; = john.loughney@nokia.com
Cc: gash@att.com; = karagian@cs.utwente.nl; nsis@ietf.org
Subject: RE: [NSIS] I-D = ACTION:draft-ietf-nsis-qspec-12.txt

=0A=
=0A=
=0A=

Radhika

=0A=

 

=0A=

Water and oil = aside, the Y.1541 QoS classes are not = “implementation-specific” as you say. They may use DiffServ, = they may use RSVP, they may use something else. How is that = implementation-specific?

=0A=

 

=0A=

For me, this = misunderstanding by you is the root cause of your criticism. (I = understand your argument—I just do not agree with it, because it = is inaccurate.)

=0A=

 

=0A=

The Y.1541 = classes are QoS classes that many experts around the world agreed = capture, in a reasonably small number, distinct combinations of IP = performance parameters capable of supporting virtually all user = applications with the requisite QoS. On an e2e basis, a user may for = example indicate “I am using IPTV and want to request Y.1541 Class = 5, which would satisfy my QoS needs.” Networks in the path may = implement different QoS schemes (per-hop, per-domain, whatever), = but a good NSIS method will still allow the e2e QoS classes (of = Y.1541) to be addressed.

=0A=

 

=0A=

But there is = no effective way to signal this e2e today, and that is what many of us = wanted NSIS to do—signal this e2e need, with enough hooks to be = useful.

=0A=

 

=0A=

If all that = is done in NSIS is to make incremental improvements to RSVP, or to focus = primarily on signaling peak bandwidth needs, then IMO the end result = will not be nearly as useful as many of us had hoped.

=0A=

 

=0A=

Chuck = Dvorak

=0A=

AT&T Labs = Research

=0A=
=0A=
=0A=
=0A=
=0A=

From: Roy, Radhika R. = [mailto:RADHIKA.R.ROY@saic.com]
Sent: Wednesday, October 18, 2006 10:37 AM
To: lars.westberg@ericsson.com; = john.loughney@nokia.com
Cc: gash@att.com; Georgios Karagiannis; = RADHIKA.R.ROY@saic.com; nsis@ietf.org
Subject: RE: [NSIS] I-D = ACTION:draft-ietf-nsis-qspec-12.txt

=0A=

 

=0A=

Lars:

=0A=

 

=0A=

You are = right. That is why, the QOS model like DiffServ comes into = picture.

=0A=

 

=0A=

There is = another aspect of these QOS models so far the standardization is = concerned. That is called interwoking between the different QOS modeling = standards. For example, you have mentioned as follows:

=0A=

 

=0A=

Inter-operabillity solved by: =
1) Overprovisioning in the core such as all QoS-requirments are = solved.
2) Interoperabillity for different QoS-models = =3D>Peak-allocation of bandwidth.

=0A=

 

=0A=

All the = trends of QOS models have been basically like the = above.

=0A=

 

=0A=

Recently, we = also see some fertile brains have created some so-called = “Implementation-specific QOS schemes” that are based on = “values” of all QOS parameters. The fundamental problems are = that they also called these as QOS models (instead of saying that these = are some QOS “implementation” schemes, NOT QOS models). They = have even convinced few folks here and there of different standard = organizations that they need “interworking” between = different QOS models.

=0A=

 

=0A=

Here the = fundamental problems come. Who is kidding whom trying to mixing between = water and oil?

=0A=

 

=0A=

Best = regards,

=0A=

Radhika

------_=_NextPart_001_01C6F382.CCDD46E8-- --===============0943869882== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0943869882==-- From nsis-bounces@ietf.org Thu Oct 19 09:35:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaY3F-0001ur-1c; Thu, 19 Oct 2006 09:35:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaY3D-0001uk-VD for nsis@ietf.org; Thu, 19 Oct 2006 09:35:11 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaY3B-00065r-Em for nsis@ietf.org; Thu, 19 Oct 2006 09:35:11 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k9JDYHVB021960; Thu, 19 Oct 2006 15:34:25 +0200 (MEST) From: "Georgios Karagiannis" To: "'David R Oran'" Subject: RE: [NSIS] QSPEC proposal Date: Thu, 19 Oct 2006 15:34:14 +0200 Message-ID: <007001c6f383$4a2c2430$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <019FBEA8-325B-4231-903F-46EA066CA1A8@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: Acbzgiinb3nNC5k6SUyDFmBCju/S4wAAGRBQ X-Spam-Score: -5.321 () ALL_TRUSTED, AWL, BAYES_00, FVGT_m_MULTI_ODD, FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Thu, 19 Oct 2006 15:34:28 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Cc: john.loughney@nokia.com, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Dave By mandatory I mean: x) must be understood by every QOS NSLP-capable network element in the universe The current QSPEC template specification defines: 13 parameters that "must be understood by every QOS NSLP-capable network element in the universe" My question is: Is your proposal refering only to one parameter, i.e., Token Bucket that "must be understood by every QOS NSLP-capable network element in the universe"? Best regards, Georgios > -----Original Message----- > From: David R Oran [mailto:oran@cisco.com] > Sent: donderdag 19 oktober 2006 15:25 > To: Georgios Karagiannis > Cc: john.loughney@nokia.com; jgunn6@csc.com; nsis@ietf.org > Subject: Re: [NSIS] QSPEC proposal > > > On Oct 19, 2006, at 9:08 AM, Georgios Karagiannis wrote: > > > Hi John > > > > I also still do not understand point 4)? > > > > Is this relkated to the possibility of ignoring mandatory > parameters? > > > > How many mandatory parameters will then the base QSPEC have? > > I assume that Dave, proposed to have one mandatory > parameter and that > > is the > > > > Token Bucket specification. > > > I still think we are talking past each other. Please tell me > which of the following is your intended definition of "mandatory" > w) must be present in any QSPEC formulated by the end user > x) must be understood by every QOS NSLP-capable network > element in the universe > y) must result in admission control success in any > NSLP-capable network element that has sufficient resources to > comply with the specified value by the user. > > My preferred formulation is actually none of the above. > > 1. that only the TSPEC-like parameters in my traffic > description proposal be mandatory in the sense that your > request is syntactically invalid if they are not present. > 2. That all the traffic description in my (b) category be > optional both for inclusion and for interpretation by the > network elements. > 3. That for the constraint parameters, we explicitly encode > in the protocol whether the user wants to have admission > control succeed IF AND ONLY IF the parameter is understood, > and the constraint satisfied, by each QOS NSLP-capable > network element on the signaling path. I do not like the > ideaq of statically binning the constraint parameters in > architectural "mandatory/optional" categories. > > Cheers, Dave. > > > > Best Regards, > > Georgios > > > > > > > > > > > >> -----Original Message----- > >> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > >> Sent: donderdag 19 oktober 2006 14:25 > >> To: jgunn6@csc.com > >> Cc: oran@cisco.com; nsis@ietf.org > >> Subject: RE: [NSIS] QSPEC proposal > >> > >> Hi Janet, > >> > >> What I mean is that there could be a way to transparently pass the > >> QoS Model QSPEC without mapping it to the baseline QSPEC. > >> > >> John > >> > >>> -----Original Message----- > >>> From: ext Janet P Gunn [mailto:jgunn6@csc.com] > >>> Sent: 19 October, 2006 15:00 > >>> To: Loughney John (Nokia-NRC/Helsinki) > >>> Cc: nsis@ietf.org; oran@cisco.com > >>> Subject: Re: [NSIS] QSPEC proposal > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Can you please rephrase number 4? I don't understand it the > >> way it is > >>> currently written. > >>> > >>> Thanks > >>> > >>> Janet > >>> > >>> > >>> wrote on 10/19/2006 07:43:25 AM: > >>> > >>>> Hi all, > >>>> > >>>> I've been in transit for a few days, so trying to > catch-up on all > >>>> mails is somewhat challenging. Here's a partially baked > proposal, > >>>> considering the mails on this thread. My proposal for the > >>> WG to consider is: > >>>> > >>>> 1) We take Dave's proposal as a baseline QSPEC: > >>>> > >>>> a) a set of parameters, all mandatory, that describe the traffic > >>>> source in a mathematically complete way. > >>>> b) a set of parameters, all optional, which give > additional hints > >>>> about characteristics of the source traffic which may > >> allow network > >>>> elements to optimize their treatment (compressibility > hints, pre- > >>>> encryption > >>>> hints) > >>>> c) a set of parameters, mostly optional, that describe the QoS > >>>> constraints the source wishes applied to the treatment of > >>> this traffic > >>>> (loss rate, jitter, sensitivity to out of order delivery, etc.) > >>>> d) a set of handling directives, all optional, which specify the > >>>> source's preferences for for traffic handling (e.g. excess > >> treatment) > >>>> > >>>> 2) Allow QoS Models to use a secondary QSPEC, that may not be > >>>> mathmetically complete. > >>>> 3) QoS models specify how to map to the baseline QSPEC. > >>>> 4) Add a MAP/NO MAP byte, which a QoS Model can use if they > >>> want their > >>>> model mapped (or not) to domains support QoS models. > >>>> > >>>> Would this meet people's needs? I could see that point 4 > >>> might allow > >>>> use cases that Lars/Georgios would like. > >>>> > >>>> Robert and Dave seem to agree that point 1) is not too far > >> from the > >>>> current QSPEC. > >>>> > >>>> John > >>>> > >>>> _______________________________________________ > >>>> nsis mailing list > >>>> nsis@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/nsis > >>> > >>> > >> > >> _______________________________________________ > >> nsis mailing list > >> nsis@ietf.org > >> https://www1.ietf.org/mailman/listinfo/nsis > >> > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 19 09:46:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaYD9-0006uF-Gt; Thu, 19 Oct 2006 09:45:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaYD7-0006u2-LZ for nsis@ietf.org; Thu, 19 Oct 2006 09:45:25 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaYCw-0007hz-5s for nsis@ietf.org; Thu, 19 Oct 2006 09:45:25 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5466655C; Thu, 19 Oct 2006 15:43:45 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 15:43:44 +0200 Received: from ericsson.com ([147.214.26.58]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 15:43:44 +0200 Message-ID: <45378110.9090401@ericsson.com> Date: Thu, 19 Oct 2006 15:43:44 +0200 From: Lars Westberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lars Westberg Subject: Re: [NSIS] QSPEC proposal References: <453780C2.6090405@ericsson.com> In-Reply-To: <453780C2.6090405@ericsson.com> X-OriginalArrivalTime: 19 Oct 2006 13:43:44.0394 (UTC) FILETIME=[985A86A0:01C6F384] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: john.loughney@nokia.com, Ericsson IETF Strategy , Scott Bradner , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0420684688==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0420684688== Content-Type: multipart/alternative; boundary="------------030607090300000806040802" This is a multi-part message in MIME format. --------------030607090300000806040802 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I forgot the the official list -lasse Lars Westberg wrote: > How can you just incorporate one single proposal into the discussion ? > I am really confused .... > > 1)I propose to move this mandated parameter specifications to after > the re-chartering of the working group! > 2) let Qpsec-template become a template i.e. a definition of QOS-spec > witout any parameters. > > -Lasse > > > -----Original Message----- > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > Sent: donderdag 19 oktober 2006 13:43 > > To: oran@cisco.com > > Cc: nsis@ietf.org > > Subject: [NSIS] QSPEC proposal > > > > Hi all, > > > > I've been in transit for a few days, so trying to catch-up on > > all mails is somewhat challenging. Here's a partially baked > > proposal, considering the mails on this thread. My proposal > > for the WG to consider is: > > > > 1) We take Dave's proposal as a baseline QSPEC: > > > > a) a set of parameters, all mandatory, that describe the > > traffic source in a mathematically complete way. > > b) a set of parameters, all optional, which give additional > > hints about characteristics of the source traffic which may > > allow network elements to optimize their treatment > > (compressibility hints, pre- encryption > > hints) > > c) a set of parameters, mostly optional, that describe the > > QoS constraints the source wishes applied to the treatment of > > this traffic (loss rate, jitter, sensitivity to out of order > > delivery, etc.) > > d) a set of handling directives, all optional, which specify > > the source's preferences for for traffic handling (e.g. > > excess treatment) > > > > 2) Allow QoS Models to use a secondary QSPEC, that may not be > > mathmetically complete. > > 3) QoS models specify how to map to the baseline QSPEC. > > 4) Add a MAP/NO MAP byte, which a QoS Model can use if they > > want their model mapped (or not) to domains support QoS models. > > > > Would this meet people's needs? I could see that point 4 > > might allow use cases that Lars/Georgios would like. > > > > Robert and Dave seem to agree that point 1) is not too far > > from the current QSPEC. > > > > John > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > --------------030607090300000806040802 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I forgot the the official list

-lasse

Lars Westberg wrote:
How can you just incorporate one single proposal into the discussion ?
I am really confused ....

1)I propose to move this mandated parameter specifications to after the re-chartering of the working group!
2) let Qpsec-template become a template i.e. a definition of QOS-spec witout any parameters.

-Lasse

> -----Original Message-----
> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> Sent: donderdag 19 oktober 2006 13:43
> To: oran@cisco.com
> Cc: nsis@ietf.org
> Subject: [NSIS] QSPEC proposal
>
> Hi all,
>
> I've been in transit for a few days, so trying to catch-up on
> all mails is somewhat challenging.  Here's a partially baked
> proposal, considering the mails on this thread.  My proposal
> for the WG to consider  is:
>
> 1) We take Dave's proposal as a baseline QSPEC:
>
> a) a set of parameters, all mandatory, that describe the
> traffic source in a mathematically complete way.
> b) a set of parameters, all optional, which give additional
> hints about characteristics of the source traffic which may
> allow network elements to optimize their treatment
> (compressibility hints, pre- encryption
> hints)
> c) a set of parameters, mostly optional, that describe the
> QoS constraints the source wishes applied to the treatment of
> this traffic (loss rate, jitter, sensitivity to out of order
> delivery, etc.)
> d) a set of handling directives, all optional, which specify
> the source's preferences for for traffic handling (e.g.
> excess treatment)
>
> 2) Allow QoS Models to use a secondary QSPEC, that may not be
> mathmetically complete.
> 3) QoS models specify how to map to the baseline QSPEC.
> 4) Add a MAP/NO MAP byte, which a QoS Model can use if they
> want their model mapped (or not) to domains support QoS models.
>
> Would this meet people's needs?  I could see that point 4
> might allow use cases that Lars/Georgios would like.
>
> Robert and Dave seem to agree that point 1) is not too far
> from the current QSPEC.
>
> John
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>
--------------030607090300000806040802-- --===============0420684688== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0420684688==-- From nsis-bounces@ietf.org Thu Oct 19 09:54:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaYLU-0006rK-7k; Thu, 19 Oct 2006 09:54:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaYLT-0006pt-Mr for nsis@ietf.org; Thu, 19 Oct 2006 09:54:03 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaYLF-0000oH-2C for nsis@ietf.org; Thu, 19 Oct 2006 09:54:03 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 19 Oct 2006 06:53:48 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9JDrmIr023642; Thu, 19 Oct 2006 06:53:48 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k9JDrmin005091; Thu, 19 Oct 2006 06:53:48 -0700 (PDT) Received: from [10.51.0.33] (ams3-vpn-dhcp32.cisco.com [10.61.64.32]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k9JDffcQ014641; Thu, 19 Oct 2006 06:41:42 -0700 In-Reply-To: <007001c6f383$4a2c2430$4c0d5982@dynamic.ewi.utwente.nl> References: <007001c6f383$4a2c2430$4c0d5982@dynamic.ewi.utwente.nl> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <13531D3F-AB2A-4846-A8DF-2D22F0F3D312@cisco.com> Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [NSIS] QSPEC proposal Date: Thu, 19 Oct 2006 09:52:44 -0400 To: Georgios Karagiannis X-Mailer: Apple Mail (2.752.2) Authentication-Results: sj-dkim-4.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=5973; t=1161266028; x=1162130028; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:David=20R=20Oran=20 |Subject:Re=3A=20[NSIS]=20QSPEC=20proposal; X=v=3Dcisco.com=3B=20h=3DAj9Mtmc0PVpZZ3Af6wEK3YC3SxM=3D; b=sMnfdxmrpcjTI/cu+HPYeKYvoAdIHNuAl3fqmXdElCjQH01MDGfvYWWH1oNzo+fG2JbCieQO B9ygbcUc5w5zJRsjX/4i2DFd2K2nlOe5ddAsHD18zEXzBW0CZnZhNFPT; X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Cc: john.loughney@nokia.com, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org On Oct 19, 2006, at 9:34 AM, Georgios Karagiannis wrote: > Hi Dave > > By mandatory I mean: > x) must be understood by every QOS NSLP-capable network > element in the universe > > The current QSPEC template specification defines: > 13 parameters that "must be understood by every QOS NSLP-capable > network > element in the universe" > yes. that's a bug in my opinion. > My question is: > Is your proposal refering only to one parameter, i.e., Token Bucket > that > "must be understood by every QOS NSLP-capable network > element in the universe"? > Yes, with the proviso that I think the user needs the flexibility to control whether he wants admission control to fail if a constraint can't be satisfied due to the path going through something that doesn't understand the parameter. Reread what I wrote below. > Best regards, > Georgios > > > >> -----Original Message----- >> From: David R Oran [mailto:oran@cisco.com] >> Sent: donderdag 19 oktober 2006 15:25 >> To: Georgios Karagiannis >> Cc: john.loughney@nokia.com; jgunn6@csc.com; nsis@ietf.org >> Subject: Re: [NSIS] QSPEC proposal >> >> >> On Oct 19, 2006, at 9:08 AM, Georgios Karagiannis wrote: >> >>> Hi John >>> >>> I also still do not understand point 4)? >>> >>> Is this relkated to the possibility of ignoring mandatory >> parameters? >>> >>> How many mandatory parameters will then the base QSPEC have? >>> I assume that Dave, proposed to have one mandatory >> parameter and that >>> is the >>> >>> Token Bucket specification. >>> >> I still think we are talking past each other. Please tell me >> which of the following is your intended definition of "mandatory" >> w) must be present in any QSPEC formulated by the end user >> x) must be understood by every QOS NSLP-capable network >> element in the universe >> y) must result in admission control success in any >> NSLP-capable network element that has sufficient resources to >> comply with the specified value by the user. >> >> My preferred formulation is actually none of the above. >> >> 1. that only the TSPEC-like parameters in my traffic >> description proposal be mandatory in the sense that your >> request is syntactically invalid if they are not present. >> 2. That all the traffic description in my (b) category be >> optional both for inclusion and for interpretation by the >> network elements. >> 3. That for the constraint parameters, we explicitly encode >> in the protocol whether the user wants to have admission >> control succeed IF AND ONLY IF the parameter is understood, >> and the constraint satisfied, by each QOS NSLP-capable >> network element on the signaling path. I do not like the >> ideaq of statically binning the constraint parameters in >> architectural "mandatory/optional" categories. >> >> Cheers, Dave. >> >> >>> Best Regards, >>> Georgios >>> >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] >>>> Sent: donderdag 19 oktober 2006 14:25 >>>> To: jgunn6@csc.com >>>> Cc: oran@cisco.com; nsis@ietf.org >>>> Subject: RE: [NSIS] QSPEC proposal >>>> >>>> Hi Janet, >>>> >>>> What I mean is that there could be a way to transparently pass the >>>> QoS Model QSPEC without mapping it to the baseline QSPEC. >>>> >>>> John >>>> >>>>> -----Original Message----- >>>>> From: ext Janet P Gunn [mailto:jgunn6@csc.com] >>>>> Sent: 19 October, 2006 15:00 >>>>> To: Loughney John (Nokia-NRC/Helsinki) >>>>> Cc: nsis@ietf.org; oran@cisco.com >>>>> Subject: Re: [NSIS] QSPEC proposal >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Can you please rephrase number 4? I don't understand it the >>>> way it is >>>>> currently written. >>>>> >>>>> Thanks >>>>> >>>>> Janet >>>>> >>>>> >>>>> wrote on 10/19/2006 07:43:25 AM: >>>>> >>>>>> Hi all, >>>>>> >>>>>> I've been in transit for a few days, so trying to >> catch-up on all >>>>>> mails is somewhat challenging. Here's a partially baked >> proposal, >>>>>> considering the mails on this thread. My proposal for the >>>>> WG to consider is: >>>>>> >>>>>> 1) We take Dave's proposal as a baseline QSPEC: >>>>>> >>>>>> a) a set of parameters, all mandatory, that describe the traffic >>>>>> source in a mathematically complete way. >>>>>> b) a set of parameters, all optional, which give >> additional hints >>>>>> about characteristics of the source traffic which may >>>> allow network >>>>>> elements to optimize their treatment (compressibility >> hints, pre- >>>>>> encryption >>>>>> hints) >>>>>> c) a set of parameters, mostly optional, that describe the QoS >>>>>> constraints the source wishes applied to the treatment of >>>>> this traffic >>>>>> (loss rate, jitter, sensitivity to out of order delivery, etc.) >>>>>> d) a set of handling directives, all optional, which specify the >>>>>> source's preferences for for traffic handling (e.g. excess >>>> treatment) >>>>>> >>>>>> 2) Allow QoS Models to use a secondary QSPEC, that may not be >>>>>> mathmetically complete. >>>>>> 3) QoS models specify how to map to the baseline QSPEC. >>>>>> 4) Add a MAP/NO MAP byte, which a QoS Model can use if they >>>>> want their >>>>>> model mapped (or not) to domains support QoS models. >>>>>> >>>>>> Would this meet people's needs? I could see that point 4 >>>>> might allow >>>>>> use cases that Lars/Georgios would like. >>>>>> >>>>>> Robert and Dave seem to agree that point 1) is not too far >>>> from the >>>>>> current QSPEC. >>>>>> >>>>>> John >>>>>> >>>>>> _______________________________________________ >>>>>> nsis mailing list >>>>>> nsis@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/nsis >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> nsis mailing list >>>> nsis@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/nsis >>>> >> _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 19 10:17:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaYhP-0004Wr-NQ; Thu, 19 Oct 2006 10:16:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaYhO-0004WH-W0 for nsis@ietf.org; Thu, 19 Oct 2006 10:16:42 -0400 Received: from amer-mta08.csc.com ([20.137.52.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaYhK-0005Yk-KX for nsis@ietf.org; Thu, 19 Oct 2006 10:16:42 -0400 Received: from amer-gw09.csc.com (amer-gw09.csc.com [20.6.39.245]) by amer-mta08.csc.com (Switch-3.1.6/Switch-3.1.0) with ESMTP id k9JEGaSw006294 for ; Thu, 19 Oct 2006 10:16:36 -0400 (EDT) In-Reply-To: <62D92A9A02BCC845B202323D49A48426E1CEE2@0591-ITS-EXMP02.us.saic.com> Subject: RE: [NSIS] QSPEC proposal To: "Roy, Radhika R." X-Mailer: Lotus Notes 652HF83 November 04, 2004 Message-ID: From: Janet P Gunn Date: Thu, 19 Oct 2006 10:17:04 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 6.5.3|September 14, 2004) at 10/19/2006 10:15:28 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 1.1 (+) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: john.loughney@nokia.com, RADHIKA.R.ROY@saic.com, oran@cisco.com, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org RADHIKA.R.ROY@saic.com wrote on 10/19/2006 08:52:52 AM: > Janet and John: Oh dear- the connotations! Janet _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 19 10:22:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaYme-0003xt-LX; Thu, 19 Oct 2006 10:22:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaYmc-0003tr-Rp for nsis@ietf.org; Thu, 19 Oct 2006 10:22:07 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaYmI-0006gA-2j for nsis@ietf.org; Thu, 19 Oct 2006 10:22:06 -0400 Received: from S4DE8PSAAGT.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Thu, 19 Oct 2006 16:21:36 +0200 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by S4DE8PSAAGT.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 16:21:36 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [NSIS] Proposal to move the QSPEC work forward Date: Thu, 19 Oct 2006 16:21:35 +0200 Message-Id: <6439282641581441A36F7F6F83ED2ED2CBF8FB@S4DE8PSAAFQ.mitte.t-com.de> in-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Proposal to move the QSPEC work forward Thread-Index: AcbzevYWTO+ytQ2zT26fUdDV3WLOMQADncTw From: "Geib, Ruediger" To: X-OriginalArrivalTime: 19 Oct 2006 14:21:36.0319 (UTC) FILETIME=[E286C4F0:01C6F389] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Dave, in an environment where statistical multiplexing doesn't work,=20 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. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 19 10:30:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaYuT-0003eQ-RZ; Thu, 19 Oct 2006 10:30:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaYuS-0003eK-BV for nsis@ietf.org; Thu, 19 Oct 2006 10:30:12 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaYuQ-0008Mg-1e for nsis@ietf.org; Thu, 19 Oct 2006 10:30:12 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 19 Oct 2006 07:30:09 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9JEU9qf029016; Thu, 19 Oct 2006 07:30:09 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k9JEU9W4028354; Thu, 19 Oct 2006 07:30:09 -0700 (PDT) Received: from [10.51.0.33] (ams3-vpn-dhcp32.cisco.com [10.61.64.32]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k9JEI3Tg015425; Thu, 19 Oct 2006 07:18:05 -0700 In-Reply-To: <6439282641581441A36F7F6F83ED2ED2CBF8FB@S4DE8PSAAFQ.mitte.t-com.de> References: <6439282641581441A36F7F6F83ED2ED2CBF8FB@S4DE8PSAAFQ.mitte.t-com.de> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <25A762D7-AB90-44B6-8A0D-98F9AFCB225D@cisco.com> Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [NSIS] Proposal to move the QSPEC work forward Date: Thu, 19 Oct 2006 10:29:07 -0400 To: "Geib, Ruediger" X-Mailer: Apple Mail (2.752.2) Authentication-Results: sj-dkim-3.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=1230; t=1161268209; x=1162132209; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:David=20R=20Oran=20 |Subject:Re=3A=20[NSIS]=20Proposal=20to=20move=20the=20QSPEC=20work=20forward; X=v=3Dcisco.com=3B=20h=3DnjGkRzfeaTz56ILMnMysXHoWo1Y=3D; b=EsPSG+s9iC9IbfT14+Wb3SkW88HnPVY87U6OJbisGgIughnxHJ0+SAQhwlp9bv1sSuXUXmlR 4ON0l5YCSTAtHFce+qj1eRFCIfEh6FYa3IHppIC+1uHHoI3wPoq/1hq9; X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org On Oct 19, 2006, at 10:21 AM, Geib, Ruediger wrote: > Dave, > > in an environment where statistical multiplexing doesn't work, > 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. > 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. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 19 11:11:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaZXp-0004ng-Un; Thu, 19 Oct 2006 11:10:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaZXo-0004nW-K0 for nsis@ietf.org; Thu, 19 Oct 2006 11:10:52 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaZXi-0001Tu-JT for nsis@ietf.org; Thu, 19 Oct 2006 11:10:52 -0400 Received: from [192.168.178.22] (pD954AF23.dip0.t-ipconnect.de [217.84.175.35]) by kyoto.netlab.nec.de (Postfix) with ESMTP id EDBA91BAC99; Thu, 19 Oct 2006 17:10:45 +0200 (CEST) In-Reply-To: <4534EDCF.40101@christian-dickmann.de> References: <0CDAE977A7172A40A2A3A1C20C12BD650488B0C6@esealmw106.eemea.ericsson.se> <4534EDCF.40101@christian-dickmann.de> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0EEB483C-E230-4DDF-8422-F74DB31A6CAD@netlab.nec.de> Content-Transfer-Encoding: 7bit From: Martin Stiemerling Subject: Re: [NSIS] messages content Date: Thu, 19 Oct 2006 16:11:29 +0200 To: "Lars Westberg (KI/EAB)" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org (NSIS co-chair hat off -- implementors hat on) I have been also implementing the NTLP and it took me 2 weeks to get a basic version up and running. This version has been tested at the Paris interop event in Summer 2005. So my from point of view as an implementor I couldn't say which part of the NTLP draft is unclear or not easy to be implemented. It is an excellent protocol specification! Martin Am 17.10.2006 um 16:50 schrieb Christian Dickmann: > Hi, > > I am the main developer of the GIST implementation of the > University of Goettingen. > To me, the draft explains how messages look like pretty well and I > have no clue how > the draft could be more precise (from the structure point of view). > >> I can't all questions on the list. I would rather appreciate an >> example >> implementation of it with message shown in text-format. Does the >> implementation showing the messages in text ?? >> >> If so, I am interested in it. Is it possible to get a copy ??? >> > > We implemented an dissector, which is able to display GIST (and > QoS, NATFW, etc.) > messages in the popular network protocol analyzer Ethereal (now > known as Wireshark). > In addition, we got several captures of NSIS sessions (some of them > captured at the > recent Interop event) that we can provide. > So with this, you can look at every message, look at every detail > you want and see how > GIST works in real life. > > Please have a look at http://user.informatik.uni-goettingen.de/ > ~nsis/ethereal.html > > Christian Dickmann > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 19 11:11:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaZXq-0004ny-51; Thu, 19 Oct 2006 11:10:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaZXo-0004nb-Lf for nsis@ietf.org; Thu, 19 Oct 2006 11:10:52 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaZXi-0001Tt-A7 for nsis@ietf.org; Thu, 19 Oct 2006 11:10:52 -0400 Received: from [192.168.178.22] (pD954AF23.dip0.t-ipconnect.de [217.84.175.35]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 746AC1BAC4D; Thu, 19 Oct 2006 17:10:45 +0200 (CEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Martin Stiemerling Subject: Re: [NSIS] GIST issue on forwarders introducing errors Date: Thu, 19 Oct 2006 16:04:04 +0200 To: "Hancock, Robert" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert, My preference is a). Taking care for all sources of implementation errors is IMHO just impossible. Martin Am 12.10.2006 um 12:26 schrieb Hancock, Robert: > Hi all, > > An issue has been raised on GIST nodes that process and forward > messages introducing errors, and how to diagnose such errors. > It is in the tracker as issue #132 > (http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue132) > and the summary text > is included below. > > This is a solicitation for input, especially from the > implementors, on this matter. In the absence of input, my > preference would be to leave the current protocol unchanged, > but put stronger guidance in about it - this is essentially > (a) below, pointing to (c) or (d) as possible future extensions. > Or, we could extend the current specification along the lines of > (b) or (c'). Please provide your preferences! > > cheers, > > robert h. > > ============================================================== > [Following Routing Area Directorate comments from Adrian Farrel] > > The GIST specification allows nodes to forward messages, either after > consultation with the NSLP (section 4.3.2) or if there is no local > NSLP > (4.3.4). However, the forwarding process does not change the IP header > or > included Network-Layer-Information object. This means that any errors > introduced by the forwarding node will get reported back to the node > that first originated the message; this will get confused because > it is > being told about error conditions which it was not responsible for. > > There are several possible approaches for dealing with this: > > a) note more strongly in the text that the forwarder is supposed > not to > change > any of the GIST payloads, so it should not introduce any errors. > Disadvantage of this: we have to trust implementations which do > forwarding to be correctly > written so that they do not introduce message changes in the process. > > b) allow or force the forwarding node to introduce a new object to > indicate that it has processed the message in some non-trivial way > (effectively introducing route recording). Probably one would still > want > to report errors to the originator, but the error reporter would also > include the recorded route to make diagnostics easier. Disadvantage of > this approach: it makes the implementation of forwarding more complex, > and in particular rules out implementations which do simple in-place > modifications of the message (the goal for RMD for example). > > c) allow tFrom nsis-bounces@ietf.org Thu Oct 19 11:11:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaZXp-0004ng-Un; Thu, 19 Oct 2006 11:10:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaZXo-0004nW-K0 for nsis@ietf.org; Thu, 19 Oct 2006 11:10:52 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaZXi-0001Tu-JT for nsis@ietf.org; Thu, 19 Oct 2006 11:10:52 -0400 Received: from [192.168.178.22] (pD954AF23.dip0.t-ipconnect.de [217.84.175.35]) by kyoto.netlab.nec.de (Postfix) with ESMTP id EDBA91BAC99; Thu, 19 Oct 2006 17:10:45 +0200 (CEST) In-Reply-To: <4534EDCF.40101@christian-dickmann.de> References: <0CDAE977A7172A40A2A3A1C20C12BD650488B0C6@esealmw106.eemea.ericsson.se> <4534EDCF.40101@christian-dickmann.de> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0EEB483C-E230-4DDF-8422-F74DB31A6CAD@netlab.nec.de> Content-Transfer-Encoding: 7bit From: Martin Stiemerling Subject: Re: [NSIS] messages content Date: Thu, 19 Oct 2006 16:11:29 +0200 To: "Lars Westberg (KI/EAB)" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org (NSIS co-chair hat off -- implementors hat on) I have been also implementing the NTLP and it took me 2 weeks to get a basic version up and running. This version has been tested at the Paris interop event in Summer 2005. So my from point of view as an implementor I couldn't say which part of the NTLP draft is unclear or not easy to be implemented. It is an excellent protocol specification! Martin Am 17.10.2006 um 16:50 schrieb Christian Dickmann: > Hi, > > I am the main developer of the GIST implementation of the > University of Goettingen. > To me, the draft explains how messages look like pretty well and I > have no clue how > the draft could be more precise (from the structure point of view). > >> I can't all questions on the list. I would rather appreciate an >> example >> implementation of it with message shown in text-format. Does the >> implementation showing the messages in text ?? >> >> If so, I am interested in it. Is it possible to get a copy ??? >> > > We implemented an dissector, which is able to display GIST (and > QoS, NATFW, etc.) > messages in the popular network protocol analyzer Ethereal (now > known as Wireshark). > In addition, we got several captures of NSIS sessions (some of them > captured at the > recent Interop event) that we can provide. > So with this, you can look at every message, look at every detail > you want and see how > GIST works in real life. > > Please have a look at http://user.informatik.uni-goettingen.de/ > ~nsis/ethereal.html > > Christian Dickmann > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 19 11:11:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaZXq-0004ny-51; Thu, 19 Oct 2006 11:10:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaZXo-0004nb-Lf for nsis@ietf.org; Thu, 19 Oct 2006 11:10:5he originating node to include an object which records the > route taken through any forwarding nodes. this object would be of > extensibility class AB=10 (forward unchanged) or possibly AB=00 > (reject > if unknown). Typically, the > originating node would only include such an object for diagnostic > purposes (to > avoid putting additional processing load on the forwarders). > > c') same as (c), but define the object as part of the base > specification > (so all nodes would support it from the start). > > d) depend on a future GIST traceroute capability (e.g. the NSIS ping > approach) > to discover such forwarding nodes and find out what they are doing. > So, > the > diagnostics would not be built into the base protocol, but would be > available as an extension to support investigations if message > mangling > by forwarders turns out to be a problem. > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis 2 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaZXi-0001Tt-A7 for nsis@ietf.org; Thu, 19 Oct 2006 11:10:52 -0400 Received: from [192.168.178.22] (pD954AF23.dip0.t-ipconnect.de [217.84.175.35]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 746AC1BAC4D; Thu, 19 Oct 2006 17:10:45 +0200 (CEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Martin Stiemerling Subject: Re: [NSIS] GIST issue on forwarders introducing errors Date: Thu, 19 Oct 2006 16:04:04 +0200 To: "Hancock, Robert" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert, My preference is a). Taking care for all sources of implementation errors is IMHO just impossible. Martin Am 12.10.2006 um 12:26 schrieb Hancock, Robert: > Hi all, > > An issue has been raised on GIST nodes that process and forward > messages introducing errors, and how to diagnose such errors. > It is in the tracker as issue #132 > (http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue132) > and the summary text > is included below. > > This is a solicitation for input, especially from the > implementors, on this matter. In the absence of input, my > preference would be to leave the current protocol unchanged, > but put stronger guidance in about it - this is essentially > (a) below, pointing to (c) or (d) as possible future extensions. > Or, we could extend the current specification along the lines of > (b) or (c'). Please provide your preferences! > > cheers, > > robert h. > > ============================================================== > [Following Routing Area Directorate comments from Adrian Farrel] > > The GIST specification allows nodes to forward messages, either after > consultation with the NSLP (section 4.3.2) or if there is no local > NSLP > (4.3.4). However, the forwarding process does not change the IP header > or > included Network-Layer-Information object. This means that any errors > introduced by the forwarding node will get reported back to the node > that first originated the message; this will get confused because > it is > being told about error conditions which it was not responsible for. > > There are several possible approaches for dealing with this: > > a) note more strongly in the text that the forwarder is supposed > not to > change > any of the GIST payloads, so it should not introduce any errors. > Disadvantage of this: we have to trust implementations which do > forwarding to be correctly > written so that they do not introduce message changes in the process. > > b) allow or force the forwarding node to introduce a new object to > indicate that it has processed the message in some non-trivial way > (effectively introducing route recording). Probably one would still > want > to report errors to the originator, but the error reporter would also > include the recorded route to make diagnostics easier. Disadvantage of > this approach: it makes the implementation of forwarding more complex, > and in particular rules out implementations which do simple in-place > modifications of the message (the goal for RMD for example). > > c) allow the originating node to include an object which records the > route taken through any forwarding nodes. this object would be of > extensibility class AB=10 (forward unchanged) or possibly AB=00 > (reject > if unknown). Typically, the > originating node would only include such an object for diagnostic > purposes (to > avoid putting additional processing load on the forwarders). > > c') same as (c), but define the object as part of the base > specification > (so all nodes would support it from the start). > > d) depend on a future GIST traceroute capability (e.g. the NSIS ping > approach) > to discover such forwarding nodes and find out what they are doing. > So, > the > diagnostics would not be built into the base protocol, but would be > available as an extension to support investigations if message > mangling > by forwarders turns out to be a problem. > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 19 11:17:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaZdM-0003ja-EJ; Thu, 19 Oct 2006 11:16:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaZdL-0003jS-Ko for nsis@ietf.org; Thu, 19 Oct 2006 11:16:35 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaZdJ-0002yJ-5S for nsis@ietf.org; Thu, 19 Oct 2006 11:16:35 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 19 Oct 2006 08:16:33 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9JFGW3A030903; Thu, 19 Oct 2006 08:16:32 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9JFGVAo003497; Thu, 19 Oct 2006 08:16:31 -0700 (PDT) Received: from [10.51.0.33] (ams3-vpn-dhcp32.cisco.com [10.61.64.32]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k9JF44GI016443; Thu, 19 Oct 2006 08:04:26 -0700 In-Reply-To: <45376E64.3090806@tm.uka.de> References: <004a01c6f374$673ffb00$4c0d5982@dynamic.ewi.utwente.nl> <45376E64.3090806@tm.uka.de> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5DA48DD5-3CD6-44C0-BBE7-33CFDFAFDB84@cisco.com> Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [NSIS] Proposal to move the QSPEC work forward Date: Thu, 19 Oct 2006 11:15:29 -0400 To: Roland Bless X-Mailer: Apple Mail (2.752.2) Authentication-Results: sj-dkim-4.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=4504; t=1161270992; x=1162134992; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:David=20R=20Oran=20 |Subject:Re=3A=20[NSIS]=20Proposal=20to=20move=20the=20QSPEC=20work=20forward; X=v=3Dcisco.com=3B=20h=3DnjGkRzfeaTz56ILMnMysXHoWo1Y=3D; b=ZenhOwJOyEjLdfzxStkEF53lrQzD4eBLnChdCpxSrTx9cJLNgrxTeaBpfIiMiZU5o2DvosUi 9j9e9K7OZ75lCg//dbmCR/qPSSu+uyAgrzPFiityIyJsiRyjshwVpHzA; X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: john.loughney@nokia.com, Georgios Karagiannis , jmanner@cs.Helsinki.FI, nsis@ietf.org, robert.hancock@roke.co.uk X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org On Oct 19, 2006, at 8:24 AM, Roland Bless wrote: > Hi Dave, > > comments inline. > > David R Oran wrote: >> On Oct 19, 2006, at 7:47 AM, Georgios Karagiannis wrote: >> >>> 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. >>> >> 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. > > I fully agree here, without a defined time period, it's pretty > useless. > >>> 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 >> - minimum quantum (what RSVP TSPEC calls minimum policed unit) >> >> 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. 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 > constraints or not depends in which PDB (cf. RFC3086) > 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 > profiles that each define a certain constraint parameter > 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 > own service/traffic classes in order to meet a certain > 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 > 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... > 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. > Regards, > Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 19 11:20:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaZgR-0004vg-5i; Thu, 19 Oct 2006 11:19:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaZgQ-0004va-M9 for nsis@ietf.org; Thu, 19 Oct 2006 11:19:46 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaZgM-0003kh-34 for nsis@ietf.org; Thu, 19 Oct 2006 11:19:46 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k9JFJSjI006135; Thu, 19 Oct 2006 17:19:33 +0200 (MEST) From: "Georgios Karagiannis" To: Date: Thu, 19 Oct 2006 17:19:25 +0200 Message-ID: <007d01c6f391$f9c03a90$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcbzhgO1mxdXPWzzQVWJbHwlDLyR8QACgzSg X-Spam-Score: -5.32 () ALL_TRUSTED, AWL, BAYES_00, FVGT_m_MULTI_ODD, FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Thu, 19 Oct 2006 17:19:39 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1 Cc: lars.westberg@ericsson.com, nsis@ietf.org Subject: [NSIS] Finally agreement on QSPEC-1/QSPEC-2 division X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi John The main problems that we have had in NSIS since 8 months now are related to the fact that 13 parameters were specified in the QSPEC template draft as being mandatory/QSPEC-1 parameters. >From what I understood, see below, we finally reached an agreement and solved the QSPEC mandatory/optional discussion that started +/- 8 months ago. Thus actually we come to an agreement! I am assuming that this means that: * the QSPEC template will specify only one QSPEC-1 (mandatory) parameter, i.e., Token Bucket that could be remapped to peak bandwidth * the rest of the QSPEC parameters are considered as QSPEC-2 (optional) parameters! Now we can finalise the NSIS base specification and start with the deployment phase! John do you agree! Best regards, Georgios > -----Original Message----- > From: David R Oran [mailto:oran@cisco.com] > Sent: donderdag 19 oktober 2006 15:53 > To: Georgios Karagiannis > Cc: john.loughney@nokia.com; jgunn6@csc.com; nsis@ietf.org > Subject: Re: [NSIS] QSPEC proposal > > > On Oct 19, 2006, at 9:34 AM, Georgios Karagiannis wrote: > > > Hi Dave > > > > By mandatory I mean: > > x) must be understood by every QOS NSLP-capable network > element in the > > universe > > > > The current QSPEC template specification defines: > > 13 parameters that "must be understood by every QOS NSLP-capable > > network element in the universe" > > > yes. that's a bug in my opinion. > > > My question is: > > Is your proposal refering only to one parameter, i.e., Token Bucket > > that "must be understood by every QOS NSLP-capable network > element in > > the universe"? > > > Yes, with the proviso that I think the user needs the > flexibility to control whether he wants admission control to > fail if a constraint can't be satisfied due to the path going > through something that doesn't understand the parameter. > Reread what I wrote below. > > > Best regards, > > Georgios > > > > > > > >> -----Original Message----- > >> From: David R Oran [mailto:oran@cisco.com] > >> Sent: donderdag 19 oktober 2006 15:25 > >> To: Georgios Karagiannis > >> Cc: john.loughney@nokia.com; jgunn6@csc.com; nsis@ietf.org > >> Subject: Re: [NSIS] QSPEC proposal > >> > >> > >> On Oct 19, 2006, at 9:08 AM, Georgios Karagiannis wrote: > >> > >>> Hi John > >>> > >>> I also still do not understand point 4)? > >>> > >>> Is this relkated to the possibility of ignoring mandatory > >> parameters? > >>> > >>> How many mandatory parameters will then the base QSPEC have? > >>> I assume that Dave, proposed to have one mandatory > >> parameter and that > >>> is the > >>> > >>> Token Bucket specification. > >>> > >> I still think we are talking past each other. Please tell > me which of > >> the following is your intended definition of "mandatory" > >> w) must be present in any QSPEC formulated by the end user > >> x) must be understood by every QOS NSLP-capable network element in > >> the universe > >> y) must result in admission control success in any NSLP-capable > >> network element that has sufficient resources to comply with the > >> specified value by the user. > >> > >> My preferred formulation is actually none of the above. > >> > >> 1. that only the TSPEC-like parameters in my traffic description > >> proposal be mandatory in the sense that your request is > syntactically > >> invalid if they are not present. > >> 2. That all the traffic description in my (b) category be optional > >> both for inclusion and for interpretation by the network elements. > >> 3. That for the constraint parameters, we explicitly encode in the > >> protocol whether the user wants to have admission control > succeed IF > >> AND ONLY IF the parameter is understood, and the constraint > >> satisfied, by each QOS NSLP-capable network element on the > signaling > >> path. I do not like the ideaq of statically binning the constraint > >> parameters in architectural "mandatory/optional" categories. > >> > >> Cheers, Dave. > >> > >> > >>> Best Regards, > >>> Georgios > >>> > >>> > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > >>>> Sent: donderdag 19 oktober 2006 14:25 > >>>> To: jgunn6@csc.com > >>>> Cc: oran@cisco.com; nsis@ietf.org > >>>> Subject: RE: [NSIS] QSPEC proposal > >>>> > >>>> Hi Janet, > >>>> > >>>> What I mean is that there could be a way to > transparently pass the > >>>> QoS Model QSPEC without mapping it to the baseline QSPEC. > >>>> > >>>> John > >>>> > >>>>> -----Original Message----- > >>>>> From: ext Janet P Gunn [mailto:jgunn6@csc.com] > >>>>> Sent: 19 October, 2006 15:00 > >>>>> To: Loughney John (Nokia-NRC/Helsinki) > >>>>> Cc: nsis@ietf.org; oran@cisco.com > >>>>> Subject: Re: [NSIS] QSPEC proposal > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Can you please rephrase number 4? I don't understand it the > >>>> way it is > >>>>> currently written. > >>>>> > >>>>> Thanks > >>>>> > >>>>> Janet > >>>>> > >>>>> > >>>>> wrote on 10/19/2006 07:43:25 AM: > >>>>> > >>>>>> Hi all, > >>>>>> > >>>>>> I've been in transit for a few days, so trying to > >> catch-up on all > >>>>>> mails is somewhat challenging. Here's a partially baked > >> proposal, > >>>>>> considering the mails on this thread. My proposal for the > >>>>> WG to consider is: > >>>>>> > >>>>>> 1) We take Dave's proposal as a baseline QSPEC: > >>>>>> > >>>>>> a) a set of parameters, all mandatory, that describe > the traffic > >>>>>> source in a mathematically complete way. > >>>>>> b) a set of parameters, all optional, which give > >> additional hints > >>>>>> about characteristics of the source traffic which may > >>>> allow network > >>>>>> elements to optimize their treatment (compressibility > >> hints, pre- > >>>>>> encryption > >>>>>> hints) > >>>>>> c) a set of parameters, mostly optional, that describe the QoS > >>>>>> constraints the source wishes applied to the treatment of > >>>>> this traffic > >>>>>> (loss rate, jitter, sensitivity to out of order delivery, etc.) > >>>>>> d) a set of handling directives, all optional, which > specify the > >>>>>> source's preferences for for traffic handling (e.g. excess > >>>> treatment) > >>>>>> > >>>>>> 2) Allow QoS Models to use a secondary QSPEC, that may not be > >>>>>> mathmetically complete. > >>>>>> 3) QoS models specify how to map to the baseline QSPEC. > >>>>>> 4) Add a MAP/NO MAP byte, which a QoS Model can use if they > >>>>> want their > >>>>>> model mapped (or not) to domains support QoS models. > >>>>>> > >>>>>> Would this meet people's needs? I could see that point 4 > >>>>> might allow > >>>>>> use cases that Lars/Georgios would like. > >>>>>> > >>>>>> Robert and Dave seem to agree that point 1) is not too far > >>>> from the > >>>>>> current QSPEC. > >>>>>> > >>>>>> John > >>>>>> > >>>>>> _______________________________________________ > >>>>>> nsis mailing list > >>>>>> nsis@ietf.org > >>>>>> https://www1.ietf.org/mailman/listinfo/nsis > >>>>> > >>>>> > >>>> > >>>> _______________________________________________ > >>>> nsis mailing list > >>>> nsis@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/nsis > >>>> > >> > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 19 11:39:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaZyr-0003Te-Tj; Thu, 19 Oct 2006 11:38:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaZyq-0003Pu-Q0 for nsis@ietf.org; Thu, 19 Oct 2006 11:38:48 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaZrr-0006lF-5u for nsis@ietf.org; Thu, 19 Oct 2006 11:31:36 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 19 Oct 2006 08:31:33 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9JFVXbB009215; Thu, 19 Oct 2006 08:31:33 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k9JFVXW4015805; Thu, 19 Oct 2006 08:31:33 -0700 (PDT) Received: from [10.51.0.33] (ams3-vpn-dhcp32.cisco.com [10.61.64.32]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k9JFJR8h016779; Thu, 19 Oct 2006 08:19:28 -0700 In-Reply-To: <007d01c6f391$f9c03a90$4c0d5982@dynamic.ewi.utwente.nl> References: <007d01c6f391$f9c03a90$4c0d5982@dynamic.ewi.utwente.nl> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9EE3F1F6-402E-43B4-862E-0F284FF70541@cisco.com> Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [NSIS] Finally agreement on QSPEC-1/QSPEC-2 division Date: Thu, 19 Oct 2006 11:30:31 -0400 To: "Georgios Karagiannis" X-Mailer: Apple Mail (2.752.2) Authentication-Results: sj-dkim-3.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=8715; t=1161271893; x=1162135893; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:David=20R=20Oran=20 |Subject:Re=3A=20[NSIS]=20Finally=20agreement=20on=20QSPEC-1/QSPEC-2=20division; X=v=3Dcisco.com=3B=20h=3DxHf5+CmjyfQBxOZydJzQo/wON7w=3D; b=i9YJIiHP2+UrIUxOvSwS4tSWrLAzF145w4Gf4ZEMKUyN30OeKrHpzoVwZByv2nLiG+gqMKkj ma6APuCtbpMRlUEdYMhzS9HHXnqadXf35iH1rcrbWsTGt8Xw/Gt3UjUG; X-Spam-Score: 0.0 (/) X-Scan-Signature: 83e9494d829b08cc3f644ef6ac1b9bd4 Cc: john.loughney@nokia.com, lars.westberg@ericsson.com, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Georgios, You conveniently ignored the part of my message which said: > 3. That for the constraint parameters, we explicitly encode in the > protocol whether the user wants to have admission control succeed IF > AND ONLY IF the parameter is understood, and the constraint > satisfied, by each QOS NSLP-capable network element on the signaling > path. I do not like the ideaq of statically binning the constraint > parameters in architectural "mandatory/optional" categories. In the absence of this or something like it, if all you have is the source traffic descriptor we are back to having no way for the user draw any conclusions about what it means for a QOS NSLP reservation to be admitted. The debate isn't really about mandatory versus optional parameters, but finding some architecturally clean way to define a protocol that allows flexible QoS state installation in the data plane while retaining some meaningful semantics for admission control. Cheers, Dave. On Oct 19, 2006, at 11:19 AM, Georgios Karagiannis wrote: > > Hi John > > The main problems that we have had in NSIS since 8 months now > are related to the fact that 13 parameters were specified in the > QSPEC template draft as being mandatory/QSPEC-1 parameters. > >> From what I understood, see below, we finally reached an agreement > and solved the QSPEC mandatory/optional discussion > that started +/- 8 months ago. > Thus actually we come to an agreement! > > > I am assuming that this means that: > > * the QSPEC template will specify only one QSPEC-1 (mandatory) > parameter, > i.e., > Token Bucket that could be remapped to peak bandwidth > > * the rest of the QSPEC parameters are considered as QSPEC-2 > (optional) > parameters! > > Now we can finalise the NSIS base specification > and start with the deployment phase! > > John do you agree! > > Best regards, > Georgios > > > >> -----Original Message----- >> From: David R Oran [mailto:oran@cisco.com] >> Sent: donderdag 19 oktober 2006 15:53 >> To: Georgios Karagiannis >> Cc: john.loughney@nokia.com; jgunn6@csc.com; nsis@ietf.org >> Subject: Re: [NSIS] QSPEC proposal >> >> >> On Oct 19, 2006, at 9:34 AM, Georgios Karagiannis wrote: >> >>> Hi Dave >>> >>> By mandatory I mean: >>> x) must be understood by every QOS NSLP-capable network >> element in the >>> universe >>> >>> The current QSPEC template specification defines: >>> 13 parameters that "must be understood by every QOS NSLP-capable >>> network element in the universe" >>> >> yes. that's a bug in my opinion. >> >>> My question is: >>> Is your proposal refering only to one parameter, i.e., Token Bucket >>> that "must be understood by every QOS NSLP-capable network >> element in >>> the universe"? >>> >> Yes, with the proviso that I think the user needs the >> flexibility to control whether he wants admission control to >> fail if a constraint can't be satisfied due to the path going >> through something that doesn't understand the parameter. >> Reread what I wrote below. >> >>> Best regards, >>> Georgios >>> >>> >>> >>>> -----Original Message----- >>>> From: David R Oran [mailto:oran@cisco.com] >>>> Sent: donderdag 19 oktober 2006 15:25 >>>> To: Georgios Karagiannis >>>> Cc: john.loughney@nokia.com; jgunn6@csc.com; nsis@ietf.org >>>> Subject: Re: [NSIS] QSPEC proposal >>>> >>>> >>>> On Oct 19, 2006, at 9:08 AM, Georgios Karagiannis wrote: >>>> >>>>> Hi John >>>>> >>>>> I also still do not understand point 4)? >>>>> >>>>> Is this relkated to the possibility of ignoring mandatory >>>> parameters? >>>>> >>>>> How many mandatory parameters will then the base QSPEC have? >>>>> I assume that Dave, proposed to have one mandatory >>>> parameter and that >>>>> is the >>>>> >>>>> Token Bucket specification. >>>>> >>>> I still think we are talking past each other. Please tell >> me which of >>>> the following is your intended definition of "mandatory" >>>> w) must be present in any QSPEC formulated by the end user >>>> x) must be understood by every QOS NSLP-capable network element in >>>> the universe >>>> y) must result in admission control success in any NSLP-capable >>>> network element that has sufficient resources to comply with the >>>> specified value by the user. >>>> >>>> My preferred formulation is actually none of the above. >>>> >>>> 1. that only the TSPEC-like parameters in my traffic description >>>> proposal be mandatory in the sense that your request is >> syntactically >>>> invalid if they are not present. >>>> 2. That all the traffic description in my (b) category be optional >>>> both for inclusion and for interpretation by the network elements. >>>> 3. That for the constraint parameters, we explicitly encode in the >>>> protocol whether the user wants to have admission control >> succeed IF >>>> AND ONLY IF the parameter is understood, and the constraint >>>> satisfied, by each QOS NSLP-capable network element on the >> signaling >>>> path. I do not like the ideaq of statically binning the constraint >>>> parameters in architectural "mandatory/optional" categories. >>>> >>>> Cheers, Dave. >>>> >>>> >>>>> Best Regards, >>>>> Georgios >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] >>>>>> Sent: donderdag 19 oktober 2006 14:25 >>>>>> To: jgunn6@csc.com >>>>>> Cc: oran@cisco.com; nsis@ietf.org >>>>>> Subject: RE: [NSIS] QSPEC proposal >>>>>> >>>>>> Hi Janet, >>>>>> >>>>>> What I mean is that there could be a way to >> transparently pass the >>>>>> QoS Model QSPEC without mapping it to the baseline QSPEC. >>>>>> >>>>>> John >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: ext Janet P Gunn [mailto:jgunn6@csc.com] >>>>>>> Sent: 19 October, 2006 15:00 >>>>>>> To: Loughney John (Nokia-NRC/Helsinki) >>>>>>> Cc: nsis@ietf.org; oran@cisco.com >>>>>>> Subject: Re: [NSIS] QSPEC proposal >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Can you please rephrase number 4? I don't understand it the >>>>>> way it is >>>>>>> currently written. >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> Janet >>>>>>> >>>>>>> >>>>>>> wrote on 10/19/2006 07:43:25 AM: >>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I've been in transit for a few days, so trying to >>>> catch-up on all >>>>>>>> mails is somewhat challenging. Here's a partially baked >>>> proposal, >>>>>>>> considering the mails on this thread. My proposal for the >>>>>>> WG to consider is: >>>>>>>> >>>>>>>> 1) We take Dave's proposal as a baseline QSPEC: >>>>>>>> >>>>>>>> a) a set of parameters, all mandatory, that describe >> the traffic >>>>>>>> source in a mathematically complete way. >>>>>>>> b) a set of parameters, all optional, which give >>>> additional hints >>>>>>>> about characteristics of the source traffic which may >>>>>> allow network >>>>>>>> elements to optimize their treatment (compressibility >>>> hints, pre- >>>>>>>> encryption >>>>>>>> hints) >>>>>>>> c) a set of parameters, mostly optional, that describe the QoS >>>>>>>> constraints the source wishes applied to the treatment of >>>>>>> this traffic >>>>>>>> (loss rate, jitter, sensitivity to out of order delivery, etc.) >>>>>>>> d) a set of handling directives, all optional, which >> specify the >>>>>>>> source's preferences for for traffic handling (e.g. excess >>>>>> treatment) >>>>>>>> >>>>>>>> 2) Allow QoS Models to use a secondary QSPEC, that may not be >>>>>>>> mathmetically complete. >>>>>>>> 3) QoS models specify how to map to the baseline QSPEC. >>>>>>>> 4) Add a MAP/NO MAP byte, which a QoS Model can use if they >>>>>>> want their >>>>>>>> model mapped (or not) to domains support QoS models. >>>>>>>> >>>>>>>> Would this meet people's needs? I could see that point 4 >>>>>>> might allow >>>>>>>> use cases that Lars/Georgios would like. >>>>>>>> >>>>>>>> Robert and Dave seem to agree that point 1) is not too far >>>>>> from the >>>>>>>> current QSPEC. >>>>>>>> >>>>>>>> John >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> nsis mailing list >>>>>>>> nsis@ietf.org >>>>>>>> https://www1.ietf.org/mailman/listinfo/nsis >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> nsis mailing list >>>>>> nsis@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/nsis >>>>>> >>>> >> > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 19 11:39:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaZzL-0003qF-MI; Thu, 19 Oct 2006 11:39:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaZzJ-0003pD-Qf for nsis@ietf.org; Thu, 19 Oct 2006 11:39:17 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaZzG-0000qZ-GY for nsis@ietf.org; Thu, 19 Oct 2006 11:39:17 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k9JFcw64008508; Thu, 19 Oct 2006 17:39:06 +0200 (MEST) From: "Georgios Karagiannis" To: "'David R Oran'" Subject: RE: [NSIS] Finally agreement on QSPEC-1/QSPEC-2 division Date: Thu, 19 Oct 2006 17:38:55 +0200 Message-ID: <007e01c6f394$b5771ef0$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <9EE3F1F6-402E-43B4-862E-0F284FF70541@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: Acbzk63nd97dC57YRo6xpyZIZ0YwOAAAG2JQ X-Spam-Score: -5.319 () ALL_TRUSTED, AWL, BAYES_00, FVGT_m_MULTI_ODD, FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Thu, 19 Oct 2006 17:39:10 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4515df9441674711565101d9d5c4f63f Cc: john.loughney@nokia.com, lars.westberg@ericsson.com, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Dave I think that what you mentioned in 3. is already specified in the current version of the QSPEC template draft, even when the base for interoperability between QoS models is considered to (only) be the Token Bucket specification. Best regards, Georgios > -----Original Message----- > From: David R Oran [mailto:oran@cisco.com] > Sent: donderdag 19 oktober 2006 17:31 > To: Georgios Karagiannis > Cc: john.loughney@nokia.com; lars.westberg@ericsson.com; nsis@ietf.org > Subject: Re: [NSIS] Finally agreement on QSPEC-1/QSPEC-2 division > > Georgios, > > You conveniently ignored the part of my message which said: > > > 3. That for the constraint parameters, we explicitly encode in the > > protocol whether the user wants to have admission control > succeed IF > > AND ONLY IF the parameter is understood, and the constraint > satisfied, > > by each QOS NSLP-capable network element on the signaling > path. I do > > not like the ideaq of statically binning the constraint > parameters in > > architectural "mandatory/optional" categories. > > In the absence of this or something like it, if all you have > is the source traffic descriptor we are back to having no way > for the user draw any conclusions about what it means for a > QOS NSLP reservation to be admitted. The debate isn't really > about mandatory versus optional parameters, but finding some > architecturally clean way to define a protocol that allows > flexible QoS state installation in the data plane while > retaining some meaningful semantics for admission control. > > Cheers, Dave. > > > On Oct 19, 2006, at 11:19 AM, Georgios Karagiannis wrote: > > > > > Hi John > > > > The main problems that we have had in NSIS since 8 months now > > are related to the fact that 13 parameters were specified in the > > QSPEC template draft as being mandatory/QSPEC-1 parameters. > > > >> From what I understood, see below, we finally reached an agreement > > and solved the QSPEC mandatory/optional discussion > > that started +/- 8 months ago. > > Thus actually we come to an agreement! > > > > > > I am assuming that this means that: > > > > * the QSPEC template will specify only one QSPEC-1 (mandatory) > > parameter, > > i.e., > > Token Bucket that could be remapped to peak bandwidth > > > > * the rest of the QSPEC parameters are considered as QSPEC-2 > > (optional) > > parameters! > > > > Now we can finalise the NSIS base specification > > and start with the deployment phase! > > > > John do you agree! > > > > Best regards, > > Georgios > > > > > > > >> -----Original Message----- > >> From: David R Oran [mailto:oran@cisco.com] > >> Sent: donderdag 19 oktober 2006 15:53 > >> To: Georgios Karagiannis > >> Cc: john.loughney@nokia.com; jgunn6@csc.com; nsis@ietf.org > >> Subject: Re: [NSIS] QSPEC proposal > >> > >> > >> On Oct 19, 2006, at 9:34 AM, Georgios Karagiannis wrote: > >> > >>> Hi Dave > >>> > >>> By mandatory I mean: > >>> x) must be understood by every QOS NSLP-capable network > >> element in the > >>> universe > >>> > >>> The current QSPEC template specification defines: > >>> 13 parameters that "must be understood by every QOS NSLP-capable > >>> network element in the universe" > >>> > >> yes. that's a bug in my opinion. > >> > >>> My question is: > >>> Is your proposal refering only to one parameter, i.e., > Token Bucket > >>> that "must be understood by every QOS NSLP-capable network > >> element in > >>> the universe"? > >>> > >> Yes, with the proviso that I think the user needs the > >> flexibility to control whether he wants admission control to > >> fail if a constraint can't be satisfied due to the path going > >> through something that doesn't understand the parameter. > >> Reread what I wrote below. > >> > >>> Best regards, > >>> Georgios > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: David R Oran [mailto:oran@cisco.com] > >>>> Sent: donderdag 19 oktober 2006 15:25 > >>>> To: Georgios Karagiannis > >>>> Cc: john.loughney@nokia.com; jgunn6@csc.com; nsis@ietf.org > >>>> Subject: Re: [NSIS] QSPEC proposal > >>>> > >>>> > >>>> On Oct 19, 2006, at 9:08 AM, Georgios Karagiannis wrote: > >>>> > >>>>> Hi John > >>>>> > >>>>> I also still do not understand point 4)? > >>>>> > >>>>> Is this relkated to the possibility of ignoring mandatory > >>>> parameters? > >>>>> > >>>>> How many mandatory parameters will then the base QSPEC have? > >>>>> I assume that Dave, proposed to have one mandatory > >>>> parameter and that > >>>>> is the > >>>>> > >>>>> Token Bucket specification. > >>>>> > >>>> I still think we are talking past each other. Please tell > >> me which of > >>>> the following is your intended definition of "mandatory" > >>>> w) must be present in any QSPEC formulated by the end user > >>>> x) must be understood by every QOS NSLP-capable network > element in > >>>> the universe > >>>> y) must result in admission control success in any NSLP-capable > >>>> network element that has sufficient resources to comply with the > >>>> specified value by the user. > >>>> > >>>> My preferred formulation is actually none of the above. > >>>> > >>>> 1. that only the TSPEC-like parameters in my traffic description > >>>> proposal be mandatory in the sense that your request is > >> syntactically > >>>> invalid if they are not present. > >>>> 2. That all the traffic description in my (b) category > be optional > >>>> both for inclusion and for interpretation by the network > elements. > >>>> 3. That for the constraint parameters, we explicitly > encode in the > >>>> protocol whether the user wants to have admission control > >> succeed IF > >>>> AND ONLY IF the parameter is understood, and the constraint > >>>> satisfied, by each QOS NSLP-capable network element on the > >> signaling > >>>> path. I do not like the ideaq of statically binning the > constraint > >>>> parameters in architectural "mandatory/optional" categories. > >>>> > >>>> Cheers, Dave. > >>>> > >>>> > >>>>> Best Regards, > >>>>> Georgios > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > >>>>>> Sent: donderdag 19 oktober 2006 14:25 > >>>>>> To: jgunn6@csc.com > >>>>>> Cc: oran@cisco.com; nsis@ietf.org > >>>>>> Subject: RE: [NSIS] QSPEC proposal > >>>>>> > >>>>>> Hi Janet, > >>>>>> > >>>>>> What I mean is that there could be a way to > >> transparently pass the > >>>>>> QoS Model QSPEC without mapping it to the baseline QSPEC. > >>>>>> > >>>>>> John > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: ext Janet P Gunn [mailto:jgunn6@csc.com] > >>>>>>> Sent: 19 October, 2006 15:00 > >>>>>>> To: Loughney John (Nokia-NRC/Helsinki) > >>>>>>> Cc: nsis@ietf.org; oran@cisco.com > >>>>>>> Subject: Re: [NSIS] QSPEC proposal > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Can you please rephrase number 4? I don't understand it the > >>>>>> way it is > >>>>>>> currently written. > >>>>>>> > >>>>>>> Thanks > >>>>>>> > >>>>>>> Janet > >>>>>>> > >>>>>>> > >>>>>>> wrote on 10/19/2006 07:43:25 AM: > >>>>>>> > >>>>>>>> Hi all, > >>>>>>>> > >>>>>>>> I've been in transit for a few days, so trying to > >>>> catch-up on all > >>>>>>>> mails is somewhat challenging. Here's a partially baked > >>>> proposal, > >>>>>>>> considering the mails on this thread. My proposal for the > >>>>>>> WG to consider is: > >>>>>>>> > >>>>>>>> 1) We take Dave's proposal as a baseline QSPEC: > >>>>>>>> > >>>>>>>> a) a set of parameters, all mandatory, that describe > >> the traffic > >>>>>>>> source in a mathematically complete way. > >>>>>>>> b) a set of parameters, all optional, which give > >>>> additional hints > >>>>>>>> about characteristics of the source traffic which may > >>>>>> allow network > >>>>>>>> elements to optimize their treatment (compressibility > >>>> hints, pre- > >>>>>>>> encryption > >>>>>>>> hints) > >>>>>>>> c) a set of parameters, mostly optional, that > describe the QoS > >>>>>>>> constraints the source wishes applied to the treatment of > >>>>>>> this traffic > >>>>>>>> (loss rate, jitter, sensitivity to out of order > delivery, etc.) > >>>>>>>> d) a set of handling directives, all optional, which > >> specify the > >>>>>>>> source's preferences for for traffic handling (e.g. excess > >>>>>> treatment) > >>>>>>>> > >>>>>>>> 2) Allow QoS Models to use a secondary QSPEC, that may not be > >>>>>>>> mathmetically complete. > >>>>>>>> 3) QoS models specify how to map to the baseline QSPEC. > >>>>>>>> 4) Add a MAP/NO MAP byte, which a QoS Model can use if they > >>>>>>> want their > >>>>>>>> model mapped (or not) to domains support QoS models. > >>>>>>>> > >>>>>>>> Would this meet people's needs? I could see that point 4 > >>>>>>> might allow > >>>>>>>> use cases that Lars/Georgios would like. > >>>>>>>> > >>>>>>>> Robert and Dave seem to agree that point 1) is not too far > >>>>>> from the > >>>>>>>> current QSPEC. > >>>>>>>> > >>>>>>>> John > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> nsis mailing list > >>>>>>>> nsis@ietf.org > >>>>>>>> https://www1.ietf.org/mailman/listinfo/nsis > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> nsis mailing list > >>>>>> nsis@ietf.org > >>>>>> https://www1.ietf.org/mailman/listinfo/nsis > >>>>>> > >>>> > >> > > > > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 19 11:43:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gaa2f-0007tr-9f; Thu, 19 Oct 2006 11:42:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gaa2d-0007tc-NL for nsis@ietf.org; Thu, 19 Oct 2006 11:42:44 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gaa2Z-0001Rz-E4 for nsis@ietf.org; Thu, 19 Oct 2006 11:42:43 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx2.ira.uni-karlsruhe.de with esmtps id 1Gaa2C-0000a5-2n; Thu, 19 Oct 2006 17:42:26 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id DA645B5B6; Thu, 19 Oct 2006 17:42:15 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1Gaa2B-0007bq-Jf; Thu, 19 Oct 2006 17:42:15 +0200 Message-ID: <45379CD7.9050004@tm.uka.de> Date: Thu, 19 Oct 2006 17:42:15 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Robert Hancock Subject: Re: [NSIS] GIST issue - PATH MTU v4/v6 References: <085f01c6f377$431d2880$946b0a0a@comm.ad.roke.co.uk> In-Reply-To: <085f01c6f377$431d2880$946b0a0a@comm.ad.roke.co.uk> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.2 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert, Robert Hancock wrote: > if you are interested in MTU issues, you might in any case > like to check the revised text at > http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue124 > (this is following up Lar's DISCUSS comments). > > on the v4/v6 question, i'd rather not distinguish between the two: > > - i don't know how it would cope with some transition mechanisms > (you could still get fragmentation) Hmm, this might be a problem... > - we know 512 is fine for v4 or v6 (if it isn't we are in trouble) Yep. However, it would be good to also state this explicitly so that v6 implementations follow the same max size as with v4, e.g. "...value 512 bytes as a default (also for IPv6). " > - if you know you are in a homogeneous v6 network, you know the > larger PMTU anyway as 1280 so that case is covered in the new text. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 19 12:53:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gab87-0001xp-Q8; Thu, 19 Oct 2006 12:52:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gab86-0001xZ-PZ for nsis@ietf.org; Thu, 19 Oct 2006 12:52:26 -0400 Received: from mclmx2.mail.saic.com ([149.8.64.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gab82-0000gA-EO for nsis@ietf.org; Thu, 19 Oct 2006 12:52:26 -0400 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com; Thu, 19 Oct 2006 12:52:02 -0400 Received: from 0015-ITS-EXBH01.us.saic.com ([10.43.229.18]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006101912520128812 ; Thu, 19 Oct 2006 12:52:01 -0400 Received: from 0591-ITS-EXMP02.us.saic.com ([10.42.81.248]) by 0015-ITS-EXBH01.us.saic.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 12:52:01 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [NSIS] Proposal to move the QSPEC work forward Date: Thu, 19 Oct 2006 12:51:03 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426E1CEE5@0591-ITS-EXMP02.us.saic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Proposal to move the QSPEC work forward Thread-Index: AcbzizqRU1Gfq4f/Rq+qFzvHwZbPVwAE4iG3 References: <6439282641581441A36F7F6F83ED2ED2CBF8FB@S4DE8PSAAFQ.mitte.t-com.de> <25A762D7-AB90-44B6-8A0D-98F9AFCB225D@cisco.com> From: "Roy, Radhika R." To: "David R Oran" , "Geib, Ruediger" X-OriginalArrivalTime: 19 Oct 2006 16:52:01.0644 (UTC) FILETIME=[E60A12C0:01C6F39E] X-Spam-Score: 0.1 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1567889176==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============1567889176== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F39E.E5917E1E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F39E.E5917E1E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Right! =20 RSVP spec is clear about these things. =20 BR/Radhika ________________________________ From: nsis-bounces@ietf.org on behalf of David R Oran Sent: Thu 10/19/2006 10:29 AM To: Geib, Ruediger Cc: nsis@ietf.org Subject: Re: [NSIS] Proposal to move the QSPEC work forward On Oct 19, 2006, at 10:21 AM, Geib, Ruediger wrote: > Dave, > > in an environment where statistical multiplexing doesn't work, > peak bandwidth and quantum would do, wouldn't it? > In a packet based system you also need the minimum quantum since the=20 scheduling isn't accurate to the bit level. For CBR flows peak=3Daverage and burst=3Dquantum. It is actually a=20 feature that you can detect a CBR flow by the equality of these pairs=20 of parameters in the traffic description. so it's in some sense there=20 are some benefits to always including them. If you have a VBR flow with short term bursts (which can exceed peak=20 over small time scales) the burst size in the traffic description=20 tells you how much burst buffering you have to set aside to avoid drops. If you have enough statistical multiplexing gain and lightly loaded=20 links, you can admit at the average bandwidth as long as the peak=20 rate does not exceed the link capacity. All this is basic QoS-101. Dave Oran. > 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. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis ------_=_NextPart_001_01C6F39E.E5917E1E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [NSIS] Proposal to move the QSPEC work = forward=0A= =0A= =0A= =0A=
=0A=
Right!
=0A=
 
=0A=
RSVP spec is clear about = these things.
=0A=
 
=0A=
BR/Radhika
=0A=

=0A=
=0A= From: nsis-bounces@ietf.org on = behalf of David R Oran
Sent: Thu 10/19/2006 10:29 = AM
To: Geib, Ruediger
Cc: = nsis@ietf.org
Subject: Re: [NSIS] Proposal to move the QSPEC = work forward

=0A=

=0A=

On Oct 19, 2006, at 10:21 AM, Geib, Ruediger = wrote:

> Dave,
>
> in an environment where = statistical multiplexing doesn't work,
> 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=3Daverage and = burst=3Dquantum. 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.

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

_______________________________________________
nsis = mailing list
nsis@ietf.org
https://www1.ietf.or= g/mailman/listinfo/nsis

------_=_NextPart_001_01C6F39E.E5917E1E-- --===============1567889176== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============1567889176==-- From nsis-bounces@ietf.org Thu Oct 19 13:13:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GabRu-0006Zm-C0; Thu, 19 Oct 2006 13:12:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GabQP-0005C8-Kz for nsis@ietf.org; Thu, 19 Oct 2006 13:11:21 -0400 Received: from mclmx2.mail.saic.com ([149.8.64.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GabCG-0001wn-0C for nsis@ietf.org; Thu, 19 Oct 2006 12:56:47 -0400 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com; Thu, 19 Oct 2006 12:56:36 -0400 Received: from 0015-ITS-EXBH01.us.saic.com ([10.43.229.18]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006101912563329662 ; Thu, 19 Oct 2006 12:56:34 -0400 Received: from 0591-ITS-EXMP02.us.saic.com ([10.42.81.248]) by 0015-ITS-EXBH01.us.saic.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 12:56:32 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [NSIS] Finally agreement on QSPEC-1/QSPEC-2 division Date: Thu, 19 Oct 2006 12:52:53 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426E1CEE6@0591-ITS-EXMP02.us.saic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Finally agreement on QSPEC-1/QSPEC-2 division Thread-Index: AcbzlOgXDkTCe3BRTS+rLmMAOCe8JAAChysi References: <007d01c6f391$f9c03a90$4c0d5982@dynamic.ewi.utwente.nl> <9EE3F1F6-402E-43B4-862E-0F284FF70541@cisco.com> From: "Roy, Radhika R." To: "David R Oran" , "Georgios Karagiannis" X-OriginalArrivalTime: 19 Oct 2006 16:56:32.0699 (UTC) FILETIME=[8799C8B0:01C6F39F] X-Spam-Score: 0.1 (/) X-Scan-Signature: d424907374faffed8e9e11e94f671eb2 Cc: john.loughney@nokia.com, lars.westberg@ericsson.com, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0398855793==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0398855793== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F39F.8712B784" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F39F.8712B784 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A clear alternative elaborate proposal will help to understand how we = can address these problems. =20 We can then discuss the pros and cons about this proposal. =20 BR/Radhika =20 PS: Did you also have the chance to study the interworking between = different QOS models? Is it possible to generalize in the same draft = without splitting into two? ________________________________ From: nsis-bounces@ietf.org on behalf of David R Oran Sent: Thu 10/19/2006 11:30 AM To: Georgios Karagiannis Cc: john.loughney@nokia.com; lars.westberg@ericsson.com; nsis@ietf.org Subject: Re: [NSIS] Finally agreement on QSPEC-1/QSPEC-2 division Georgios, You conveniently ignored the part of my message which said: > 3. That for the constraint parameters, we explicitly encode in the > protocol whether the user wants to have admission control succeed IF > AND ONLY IF the parameter is understood, and the constraint > satisfied, by each QOS NSLP-capable network element on the signaling > path. I do not like the ideaq of statically binning the constraint > parameters in architectural "mandatory/optional" categories. In the absence of this or something like it, if all you have is the=20 source traffic descriptor we are back to having no way for the user=20 draw any conclusions about what it means for a QOS NSLP reservation=20 to be admitted. The debate isn't really about mandatory versus=20 optional parameters, but finding some architecturally clean way to=20 define a protocol that allows flexible QoS state installation in the=20 data plane while retaining some meaningful semantics for admission=20 control. Cheers, Dave. On Oct 19, 2006, at 11:19 AM, Georgios Karagiannis wrote: > > Hi John > > The main problems that we have had in NSIS since 8 months now > are related to the fact that 13 parameters were specified in the > QSPEC template draft as being mandatory/QSPEC-1 parameters. > >> From what I understood, see below, we finally reached an agreement > and solved the QSPEC mandatory/optional discussion > that started +/- 8 months ago. > Thus actually we come to an agreement! > > > I am assuming that this means that: > > * the QSPEC template will specify only one QSPEC-1 (mandatory)=20 > parameter, > i.e., > Token Bucket that could be remapped to peak bandwidth > > * the rest of the QSPEC parameters are considered as QSPEC-2=20 > (optional) > parameters! > > Now we can finalise the NSIS base specification > and start with the deployment phase! > > John do you agree! > > Best regards, > Georgios > > > >> -----Original Message----- >> From: David R Oran [mailto:oran@cisco.com] >> Sent: donderdag 19 oktober 2006 15:53 >> To: Georgios Karagiannis >> Cc: john.loughney@nokia.com; jgunn6@csc.com; nsis@ietf.org >> Subject: Re: [NSIS] QSPEC proposal >> >> >> On Oct 19, 2006, at 9:34 AM, Georgios Karagiannis wrote: >> >>> Hi Dave >>> >>> By mandatory I mean: >>> x) must be understood by every QOS NSLP-capable network >> element in the >>> universe >>> >>> The current QSPEC template specification defines: >>> 13 parameters that "must be understood by every QOS NSLP-capable >>> network element in the universe" >>> >> yes. that's a bug in my opinion. >> >>> My question is: >>> Is your proposal refering only to one parameter, i.e., Token Bucket >>> that "must be understood by every QOS NSLP-capable network >> element in >>> the universe"? >>> >> Yes, with the proviso that I think the user needs the >> flexibility to control whether he wants admission control to >> fail if a constraint can't be satisfied due to the path going >> through something that doesn't understand the parameter. >> Reread what I wrote below. >> >>> Best regards, >>> Georgios >>> >>> >>> >>>> -----Original Message----- >>>> From: David R Oran [mailto:oran@cisco.com] >>>> Sent: donderdag 19 oktober 2006 15:25 >>>> To: Georgios Karagiannis >>>> Cc: john.loughney@nokia.com; jgunn6@csc.com; nsis@ietf.org >>>> Subject: Re: [NSIS] QSPEC proposal >>>> >>>> >>>> On Oct 19, 2006, at 9:08 AM, Georgios Karagiannis wrote: >>>> >>>>> Hi John >>>>> >>>>> I also still do not understand point 4)? >>>>> >>>>> Is this relkated to the possibility of ignoring mandatory >>>> parameters? >>>>> >>>>> How many mandatory parameters will then the base QSPEC have? >>>>> I assume that Dave, proposed to have one mandatory >>>> parameter and that >>>>> is the >>>>> >>>>> Token Bucket specification. >>>>> >>>> I still think we are talking past each other. Please tell >> me which of >>>> the following is your intended definition of "mandatory" >>>> w) must be present in any QSPEC formulated by the end user >>>> x) must be understood by every QOS NSLP-capable network element in >>>> the universe >>>> y) must result in admission control success in any NSLP-capable >>>> network element that has sufficient resources to comply with the >>>> specified value by the user. >>>> >>>> My preferred formulation is actually none of the above. >>>> >>>> 1. that only the TSPEC-like parameters in my traffic description >>>> proposal be mandatory in the sense that your request is >> syntactically >>>> invalid if they are not present. >>>> 2. That all the traffic description in my (b) category be optional >>>> both for inclusion and for interpretation by the network elements. >>>> 3. That for the constraint parameters, we explicitly encode in the >>>> protocol whether the user wants to have admission control >> succeed IF >>>> AND ONLY IF the parameter is understood, and the constraint >>>> satisfied, by each QOS NSLP-capable network element on the >> signaling >>>> path. I do not like the ideaq of statically binning the constraint >>>> parameters in architectural "mandatory/optional" categories. >>>> >>>> Cheers, Dave. >>>> >>>> >>>>> Best Regards, >>>>> Georgios >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] >>>>>> Sent: donderdag 19 oktober 2006 14:25 >>>>>> To: jgunn6@csc.com >>>>>> Cc: oran@cisco.com; nsis@ietf.org >>>>>> Subject: RE: [NSIS] QSPEC proposal >>>>>> >>>>>> Hi Janet, >>>>>> >>>>>> What I mean is that there could be a way to >> transparently pass the >>>>>> QoS Model QSPEC without mapping it to the baseline QSPEC. >>>>>> >>>>>> John >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: ext Janet P Gunn [mailto:jgunn6@csc.com] >>>>>>> Sent: 19 October, 2006 15:00 >>>>>>> To: Loughney John (Nokia-NRC/Helsinki) >>>>>>> Cc: nsis@ietf.org; oran@cisco.com >>>>>>> Subject: Re: [NSIS] QSPEC proposal >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Can you please rephrase number 4? I don't understand it the >>>>>> way it is >>>>>>> currently written. >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> Janet >>>>>>> >>>>>>> >>>>>>> wrote on 10/19/2006 07:43:25 AM: >>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I've been in transit for a few days, so trying to >>>> catch-up on all >>>>>>>> mails is somewhat challenging. Here's a partially baked >>>> proposal, >>>>>>>> considering the mails on this thread. My proposal for the >>>>>>> WG to consider is: >>>>>>>> >>>>>>>> 1) We take Dave's proposal as a baseline QSPEC: >>>>>>>> >>>>>>>> a) a set of parameters, all mandatory, that describe >> the traffic >>>>>>>> source in a mathematically complete way. >>>>>>>> b) a set of parameters, all optional, which give >>>> additional hints >>>>>>>> about characteristics of the source traffic which may >>>>>> allow network >>>>>>>> elements to optimize their treatment (compressibility >>>> hints, pre- >>>>>>>> encryption >>>>>>>> hints) >>>>>>>> c) a set of parameters, mostly optional, that describe the QoS >>>>>>>> constraints the source wishes applied to the treatment of >>>>>>> this traffic >>>>>>>> (loss rate, jitter, sensitivity to out of order delivery, etc.) >>>>>>>> d) a set of handling directives, all optional, which >> specify the >>>>>>>> source's preferences for for traffic handling (e.g. excess >>>>>> treatment) >>>>>>>> >>>>>>>> 2) Allow QoS Models to use a secondary QSPEC, that may not be >>>>>>>> mathmetically complete. >>>>>>>> 3) QoS models specify how to map to the baseline QSPEC. >>>>>>>> 4) Add a MAP/NO MAP byte, which a QoS Model can use if they >>>>>>> want their >>>>>>>> model mapped (or not) to domains support QoS models. >>>>>>>> >>>>>>>> Would this meet people's needs? I could see that point 4 >>>>>>> might allow >>>>>>>> use cases that Lars/Georgios would like. >>>>>>>> >>>>>>>> Robert and Dave seem to agree that point 1) is not too far >>>>>> from the >>>>>>>> current QSPEC. >>>>>>>> >>>>>>>> John >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> nsis mailing list >>>>>>>> nsis@ietf.org >>>>>>>> https://www1.ietf.org/mailman/listinfo/nsis >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> nsis mailing list >>>>>> nsis@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/nsis >>>>>> >>>> >> > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis ------_=_NextPart_001_01C6F39F.8712B784 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [NSIS] Finally agreement on = QSPEC-1/QSPEC-2 division=0A= =0A= =0A= =0A=
=0A=
A clear = alternative elaborate proposal will help to understand how we can = address these problems.
=0A=
 
=0A=
We can then discuss the pros = and cons about this proposal.
=0A=
 
=0A=
BR/Radhika
=0A=
 
=0A=
PS: Did you also have the = chance to study the interworking between different QOS models? Is it = possible to generalize in the same draft without splitting into = two?
=0A=

=0A=
=0A= From: nsis-bounces@ietf.org on = behalf of David R Oran
Sent: Thu 10/19/2006 11:30 = AM
To: Georgios Karagiannis
Cc: = john.loughney@nokia.com; lars.westberg@ericsson.com; = nsis@ietf.org
Subject: Re: [NSIS] Finally agreement on = QSPEC-1/QSPEC-2 division

=0A=
=0A=

Georgios,

You conveniently ignored the part of = my message which said:

> 3. That for the constraint = parameters, we explicitly encode in the
> protocol whether the = user wants to have admission control succeed  IF
> AND ONLY = IF the parameter is understood, and the constraint
> satisfied, by = each QOS NSLP-capable network element on the signaling
> path. I = do not like the ideaq of statically binning the constraint
> = parameters in architectural "mandatory/optional" categories.

In = the absence of this or something like it, if all you have is = the 
source traffic descriptor we are back to having no way for = the user 
draw any conclusions about what it means for a QOS = NSLP reservation 
to be admitted. The debate isn't really about = mandatory versus 
optional parameters, but finding some = architecturally clean way to 
define a protocol that allows = flexible QoS state installation in the 
data plane while = retaining some meaningful semantics for = admission 
control.

Cheers, Dave.


On Oct 19, = 2006, at 11:19 AM, Georgios Karagiannis wrote:

>
> Hi = John
>
> The main problems that we have had in NSIS since 8 = months now
> are related to the fact that 13 parameters were = specified in the
> QSPEC template draft as being mandatory/QSPEC-1 = parameters.
>
>> From what I understood, see below, we = finally reached an agreement
> and solved the QSPEC = mandatory/optional discussion
> that started +/- 8 months = ago.
> Thus actually we come to an = agreement!
>
>
> I am assuming that this means = that:
>
> * the QSPEC template will specify only one QSPEC-1 = (mandatory) 
> parameter,
> i.e.,
>  Token = Bucket that could be remapped to peak bandwidth
>
> * the = rest of the QSPEC parameters are considered as QSPEC-2 
> = (optional)
>    parameters!
>
> Now we = can finalise the NSIS base specification
> and start with the = deployment phase!
>
> John do you agree!
>
> = Best regards,
> Georgios
>
>
>
>> = -----Original Message-----
>> From: David R Oran [mailto:oran@cisco.com]
>> = Sent: donderdag 19 oktober 2006 15:53
>> To: Georgios = Karagiannis
>> Cc: john.loughney@nokia.com; jgunn6@csc.com; = nsis@ietf.org
>> Subject: Re: [NSIS] QSPEC = proposal
>>
>>
>> On Oct 19, 2006, at 9:34 = AM, Georgios Karagiannis wrote:
>>
>>> Hi = Dave
>>>
>>> By mandatory I = mean:
>>> x) must be understood by every QOS NSLP-capable = network
>> element in the
>>> = universe
>>>
>>> The current QSPEC template = specification defines:
>>> 13 parameters that "must be = understood by every QOS NSLP-capable
>>> network element in = the universe"
>>>
>> yes. that's a bug in my = opinion.
>>
>>> My question is:
>>> Is = your proposal refering only to one parameter, i.e., Token = Bucket
>>> that "must be understood by every QOS = NSLP-capable network
>> element in
>>> the = universe"?
>>>
>> Yes, with the proviso that I = think the user needs the
>> flexibility to control whether he = wants admission control to
>> fail if a constraint can't be = satisfied due to the path going
>> through something that = doesn't understand the parameter.
>> Reread what I wrote = below.
>>
>>> Best regards,
>>> = Georgios
>>>
>>>
>>>
>>>&= gt; -----Original Message-----
>>>> From: David R Oran = [mailto:oran@cisco.com]
>>>= > Sent: donderdag 19 oktober 2006 15:25
>>>> To: = Georgios Karagiannis
>>>> Cc: john.loughney@nokia.com; = jgunn6@csc.com; nsis@ietf.org
>>>> Subject: Re: [NSIS] = QSPEC = proposal
>>>>
>>>>
>>>> On = Oct 19, 2006, at 9:08 AM, Georgios Karagiannis = wrote:
>>>>
>>>>> Hi = John
>>>>>
>>>>> I also still do not = understand point 4)?
>>>>>
>>>>> Is = this relkated to the possibility of ignoring = mandatory
>>>> = parameters?
>>>>>
>>>>> How many = mandatory parameters will then the base QSPEC = have?
>>>>> I assume that Dave, proposed to have one = mandatory
>>>> parameter and that
>>>>> = is the
>>>>>
>>>>> Token Bucket = specification.
>>>>>
>>>> I still think = we are talking past each other. Please tell
>> me which = of
>>>> the following is your intended definition of = "mandatory"
>>>> w) must be present in any QSPEC = formulated by the end user
>>>> x) must be understood by = every QOS NSLP-capable network element in
>>>> the = universe
>>>> y) must result in admission control success = in any NSLP-capable
>>>> network element that has = sufficient resources to comply with the
>>>> specified = value by the user.
>>>>
>>>> My preferred = formulation is actually none of the = above.
>>>>
>>>> 1. that only the = TSPEC-like parameters in my traffic description
>>>> = proposal be mandatory in the sense that your request is
>> = syntactically
>>>> invalid if they are not = present.
>>>> 2. That all the traffic description in my = (b) category be optional
>>>> both for inclusion and for = interpretation by the network elements.
>>>> 3. That for = the constraint parameters, we explicitly encode in = the
>>>> protocol whether the user wants to have = admission control
>> succeed  IF
>>>> AND = ONLY IF the parameter is understood, and the = constraint
>>>> satisfied, by each QOS NSLP-capable = network element on the
>> signaling
>>>> path. I = do not like the ideaq of statically binning the = constraint
>>>> parameters in architectural = "mandatory/optional" categories.
>>>>
>>>> = Cheers, = Dave.
>>>>
>>>>
>>>>> = Best Regards,
>>>>> = Georgios
>>>>>
>>>>>
>>>&= gt;>
>>>>>
>>>>>
>>>&g= t;>> -----Original Message-----
>>>>>> From: = john.loughney@nokia.com [mailto:john.loughney@nokia.com]
>>>>>> Sent: donderdag 19 oktober 2006 = 14:25
>>>>>> To: = jgunn6@csc.com
>>>>>> Cc: oran@cisco.com; = nsis@ietf.org
>>>>>> Subject: RE: [NSIS] QSPEC = proposal
>>>>>>
>>>>>> Hi = Janet,
>>>>>>
>>>>>> What I = mean is that there could be a way to
>> transparently pass = the
>>>>>> QoS Model QSPEC without mapping it to = the baseline = QSPEC.
>>>>>>
>>>>>> = John
>>>>>>
>>>>>>> = -----Original Message-----
>>>>>>> From: ext = Janet P Gunn [mailto:jgunn6@csc.com]
>>>= >>>> Sent: 19 October, 2006 = 15:00
>>>>>>> To: Loughney John = (Nokia-NRC/Helsinki)
>>>>>>> Cc: nsis@ietf.org; = oran@cisco.com
>>>>>>> Subject: Re: [NSIS] QSPEC = proposal
>>>>>>>
>>>>>>><= BR>>>>>>>>
>>>>>>>
>&g= t;>>>>>
>>>>>>>
>>>>= ;>>>
>>>>>>> Can you please rephrase = number 4?  I don't understand it the
>>>>>> = way it is
>>>>>>> currently = written.
>>>>>>>
>>>>>>> = Thanks
>>>>>>>
>>>>>>> = Janet
>>>>>>>
>>>>>>>
= >>>>>>> <john.loughney@nokia.com> wrote on = 10/19/2006 07:43:25 = AM:
>>>>>>>
>>>>>>>> = Hi = all,
>>>>>>>>
>>>>>>>&= gt; I've been in transit for a few days, so trying = to
>>>> catch-up on = all
>>>>>>>> mails is somewhat = challenging.  Here's a partially baked
>>>> = proposal,
>>>>>>>> considering the mails on = this thread.  My proposal for the
>>>>>>> = WG to consider  = is:
>>>>>>>>
>>>>>>>&g= t; 1) We take Dave's proposal as a baseline = QSPEC:
>>>>>>>>
>>>>>>>= ;> a) a set of parameters, all mandatory, that describe
>> = the traffic
>>>>>>>> source in a = mathematically complete way.
>>>>>>>> b) a = set of parameters, all optional, which give
>>>> = additional hints
>>>>>>>> about = characteristics of the source traffic which = may
>>>>>> allow = network
>>>>>>>> elements to optimize their = treatment (compressibility
>>>> hints, = pre-
>>>>>>>> = encryption
>>>>>>>> = hints)
>>>>>>>> c) a set of parameters, = mostly optional, that describe the = QoS
>>>>>>>> constraints the source wishes = applied to the treatment of
>>>>>>> this = traffic
>>>>>>>> (loss rate, jitter, = sensitivity to out of order delivery, = etc.)
>>>>>>>> d) a set of handling = directives, all optional, which
>> specify = the
>>>>>>>> source's preferences for for = traffic handling (e.g. excess
>>>>>> = treatment)
>>>>>>>>
>>>>>>= ;>> 2) Allow QoS Models to use a secondary QSPEC, that may not = be
>>>>>>>> mathmetically = complete.
>>>>>>>> 3) QoS models specify how = to map to the baseline QSPEC.
>>>>>>>> 4) Add = a MAP/NO MAP byte, which a QoS Model can use if = they
>>>>>>> want = their
>>>>>>>> model mapped (or not) to = domains support QoS = models.
>>>>>>>>
>>>>>>&g= t;> Would this meet people's needs?  I could see that point = 4
>>>>>>> might = allow
>>>>>>>> use cases that Lars/Georgios = would = like.
>>>>>>>>
>>>>>>>= > Robert and Dave seem to agree that point 1) is not too = far
>>>>>> from = the
>>>>>>>> current = QSPEC.
>>>>>>>>
>>>>>>>= ;> = John
>>>>>>>>
>>>>>>>&= gt; = _______________________________________________
>>>>>&g= t;>> nsis mailing list
>>>>>>>> = nsis@ietf.org
>>>>>>>> https://www1.ietf.or= g/mailman/listinfo/nsis
>>>>>>>
>>&g= t;>>>>
>>>>>>
>>>>>>= ; = _______________________________________________
>>>>>&g= t; nsis mailing list
>>>>>> = nsis@ietf.org
>>>>>> https://www1.ietf.or= g/mailman/listinfo/nsis
>>>>>>
>>>&g= t;
>>
>
>
>
> = _______________________________________________
> nsis mailing = list
> nsis@ietf.org
> https://www1.ietf.or= g/mailman/listinfo/nsis

______________________________________= _________
nsis mailing list
nsis@ietf.org
https://www1.ietf.or= g/mailman/listinfo/nsis

------_=_NextPart_001_01C6F39F.8712B784-- --===============0398855793== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0398855793==-- From nsis-bounces@ietf.org Fri Oct 20 10:11:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gav4u-0007fR-GW; Fri, 20 Oct 2006 10:10:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gav4s-0007f6-Ss for nsis@ietf.org; Fri, 20 Oct 2006 10:10:26 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gav4X-0005ch-A2 for nsis@ietf.org; Fri, 20 Oct 2006 10:10:26 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx2.ira.uni-karlsruhe.de with esmtps id 1Gav3z-0003GU-Un; Fri, 20 Oct 2006 16:09:53 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id B58E0B55F; Fri, 20 Oct 2006 16:09:31 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1Gav3z-0002yh-EF; Fri, 20 Oct 2006 16:09:31 +0200 Message-ID: <4538D89B.1060506@tm.uka.de> Date: Fri, 20 Oct 2006 16:09:31 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: "Hancock, Robert" X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.2 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: "nsis@ietf.org" Subject: [NSIS] GIST MA Keep-alive/Liveliness X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert, After trying to understand the exact semantics of the mechanism described in section 6.4 I found it somewhat confusing with all the different timers (NoActivity/NoHello) and trying to match what should be actually achieved by the state machine in Fig. 8. I guess that this needs more motivation and clarification. Some statements are confusing and IMHO a short paragraph about the overall goals of this concept is missing. What are we trying to achieve with this mechanism? Is it just a keep-alive or is it failure detection, or both? However, just in order to keep the connection open after the last message was sent or received, MA-Hellos are not necessary (see below). Let me try to summarize: Each peer has an MA-Hold-Time which is exchanged at session setup. So I would expect that the other side keeps the connection at least until this period has passed after the last message was exchanged. Thus if I want to keep the connection beyond the other side's MA-Hold-Time but have nothing else to send, I should sent an MA-Hello to the other side. So far so good, that is pretty clear. Now the situation is like this: Instead of using the maximum of both hold-times and then both going to death, the peer with an internal NoActivity timer period greater than the other peers MA-Hold-Time has to send MA-Hellos to the other peer in order to keep the connection open. Thus, the real internal timeout policy is actually determined by the NoActivity timer period (and which must be >= own-MA-Hold-Time (=NoHello Timer period)). Let's say we choose NoHello=NoActivity=own-MA-Hold-Time. Then each side will keep sending MA-Hellos until the own-MA-Hold-Time expired. Then both go to IDLE and after a further NoHello timeout to death. Thus each side will really close down after NoActivity+own-MA-Hold-Time (so this is the _real_ MA-Hold-Time). So now the questions (maybe I'm puzzled, because both functions are mixed together right now): 1.) if we only want to keep the connection open, it would probably be sufficient to use the minimum proposed MA-Hold-Time as timeout without sending any MA-Hellos around. If the connection broke due to a failure of the peer, this would have been probably noticed and indicated by the transport layer. If not, we need a liveliness test. 2.) if this is meant to be also a liveliness check mechanism, I would appreciate more reasoning for having a NoActivity timeout which may be different than NoHello. The statement: "The period of this timer is implementation-specific but is likely to be related to the period of the NoHello timer." is too fuzzy. Why isn't NoActivity==NoHello reasonable? If not we probably should rename MA-Hold-Time and NoActivity... The current use of MA-Hold-Time in the initial handshake is more or less the notification when the MA-Hellos should be send and not how long the connection is really available. This is confusing... However, I'm missing a rationale and a clear description of the objectives that this should achieve. One more thing: A default time of 30s for an MA-Hold-Time would probably require to send refreshing RESERVEs by QoS NSLP before that time in order to avoid close down and re-setup of the connection. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Oct 20 10:52:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaviQ-0001qO-3g; Fri, 20 Oct 2006 10:51:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaviO-0001po-F4 for nsis@ietf.org; Fri, 20 Oct 2006 10:51:16 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaviN-0004XI-1T for nsis@ietf.org; Fri, 20 Oct 2006 10:51:16 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx2.ira.uni-karlsruhe.de with esmtps id 1GaviC-00016S-Ly; Fri, 20 Oct 2006 16:51:10 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 61BA8B5AF; Fri, 20 Oct 2006 16:51:04 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1GaviC-000331-2z; Fri, 20 Oct 2006 16:51:04 +0200 Message-ID: <4538E257.8000500@tm.uka.de> Date: Fri, 20 Oct 2006 16:51:03 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: "Hancock, Robert" Subject: Re: [NSIS] GIST MA Keep-alive/Liveliness References: <4538D89B.1060506@tm.uka.de> In-Reply-To: <4538D89B.1060506@tm.uka.de> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.2 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: "nsis@ietf.org" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert, [I pressed send too early...] Roland Bless wrote: > One more thing: > A default time of 30s for an MA-Hold-Time would probably > require to send refreshing RESERVEs by QoS NSLP before > that time in order to avoid close down and re-setup > of the connection. ...so, the real Hold-time (noActivity) may be longer (but we don't know) and we may have luck, or the recommended MA-Hold-Time depends much on the application... Another one: Currently, requesting a reply to an MA-Hello has the effect of getting an MA-Hello back (hopefully). However, there is no action taken if that MA-Hello response is missing. The Draft currently says: The R flag MAY be set (R=1); if so, the peer MUST send another message back along the messaging association. This allows a node to test the liveness of the peer. If the latter statement was true, then some action would be taken if such a response is missing. Currently, receiving MA-Hellos (or not) has no effect in the "Connected" state (for R=0), so we really don't care about getting an answer. Probably it makes sense to do the following: Introduce another NULL-message called MA-Hello-Response (with R=0) which must be send as response to an MA-Hello with R=1. We then could start a timer and go to "Death" if the solicited MA-Hello-Response is still missing after that period. Currently, we cannot decide whether we got a response or whether it was just a regularly emitted MA-Hello that arrived; maybe we don't care, because we heard something from the other side, but on the other hand if only our sending direction went down we would not notice. If all of the above doesn't make sense, I would like to remove the R=1 feature for MA-Hellos, because it has no real usefull effect anyway. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Oct 20 12:37:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaxMa-0005Kw-Rz; Fri, 20 Oct 2006 12:36:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaxMa-0005Kr-2c for nsis@ietf.org; Fri, 20 Oct 2006 12:36:52 -0400 Received: from mail-red.research.att.com ([192.20.225.110]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaxMX-0006G0-Qq for nsis@ietf.org; Fri, 20 Oct 2006 12:36:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Date: Fri, 20 Oct 2006 12:36:47 -0400 Message-ID: In-Reply-To: <62D92A9A02BCC845B202323D49A48426E1CEE1@0591-ITS-EXMP02.us.saic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt thread-index: Acbye4IZ7vmeaP4vRWSoYWr8MvZn4AARbEXAABPFuNAAGO1bQAAA14pRADsql8A= From: To: , , X-Spam-Score: 0.2 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: gash@att.com, karagian@cs.utwente.nl, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org For me this is definitely NOT about value-based vs. non-value based, it = is more about the fact that e2e QoS is not the same as, for example, = node-specific performance (e.g., PHBs). We gave this a lot of thought in Y.1541, which gives examples of how = DiffServ PHBs can be used to address certain Y.1541 e2e QoS classes. For = example, if an application requiring interactivity is to be supported, = certain e2e QoS is needed (low delay), which translates into specific = Y.1541 classes, supportable by EF DSCPs. One would thus want an NSIS QoS = protocol to help use nodal behavior to support e2e QoS needs. BTW note that I did not say a thing about bandwidth. (Focusing on only = bandwidth is really missing all of what I thought NSIS was going to do!) Chuck=20 ________________________________________ From: RADHIKA.R.ROY@saic.com [mailto:RADHIKA.R.ROY@saic.com]=20 Sent: Thursday, October 19, 2006 8:25 AM To: john.loughney@nokia.com; Dvorak,Charles A (Chuck); = lars.westberg@ericsson.com Cc: gash@att.com; karagian@cs.utwente.nl; nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Again the same logic of generalization -=A0Mixing "apples" with = "oranges" when "interworking" is concerned! =A0 Is it an isolated stand-alone=A0debate that people will "just" look into = Y.1541 value-based QOS class=A0parameters all by itself? =A0 If it is stand-alone Y.1541 value-based QOS implementations for using = NSIS QOS signaling protocol why a separate stand-alone Y.1541-specific = drat is not written? For example, people can "assume" a Y.1541 = implementation-based QOS policy "somehow" does magic to do so. What is = the problem? =A0 People can "carry" any values of any parameters in NSIS QOS signaling = protocol and, it could be 100s of any so-called QOS classes like Y.1541. = It is NOT a rocket science. =A0 Why then so-called Y.1541 QOS value-based = implementation-specific=A0model is drawn in the same level like that of = non-value-based non-implementation-based DiffServ and RSVP for = interworking? It will NEVER interwork. =A0 Why do they need to be done in the same draft creating a problem of = generalization between apples and oranges? =A0 The issue is interworking of the QSPEC template carry the QOS = parameters: Value-based and Non-Value-based. =A0 Radhika ________________________________________ From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Thu 10/19/2006 7:58 AM To: cdvorak@research.att.com; RADHIKA.R.ROY@saic.com; = lars.westberg@ericsson.com Cc: gash@att.com; karagian@cs.utwente.nl; nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt I've got to agree with Chuck on this.=A0=A0 How Y.1541 fufills QoS = classes is not an NSIS issue.=A0 I think it is clear how to carry them, = but how the domain deploying Y.1541 verifies things are fufilled is = outslide of NSIS. =A0 John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sat Oct 21 00:09:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gb8A2-00070H-HV; Sat, 21 Oct 2006 00:08:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gb89v-0006tU-Ac; Sat, 21 Oct 2006 00:08:31 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gb3NN-0002E5-Mp; Fri, 20 Oct 2006 19:02:05 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gb3CD-0005Ql-Bq; Fri, 20 Oct 2006 18:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 0F483175E8; Fri, 20 Oct 2006 22:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Gb3Bi-00048f-KJ; Fri, 20 Oct 2006 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 20 Oct 2006 18:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-rmd-08.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : RMD-QOSM - The Resource Management in Diffserv QOS Model Author(s) : A. Bader, et al. Filename : draft-ietf-nsis-rmd-08.txt Pages : 92 Date : 2006-10-20 This document describes an NSIS QoS Model for networks that use the Resource Management in Diffserv (RMD) concept. RMD is a technique for adding admission control and preemption function to Differentiated Services (Diffserv) networks. The RMD QoS Model allows devices external to the RMD network to signal reservation requests to edge nodes in the RMD network. The RMD Ingress edge nodes classify the incoming flows into traffic classes and signals resource requests for the corresponding traffic class along the data path to the Egress edge nodes for each flow. Egress nodes reconstitute the original requests and continue forwarding them along the data path towards the final destination. In addition, RMD defines notification functions to indicate overload situations within the domain to the edge nodes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-rmd-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nsis-rmd-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nsis-rmd-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-10-20160718.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-rmd-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-rmd-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-20160718.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --NextPart-- From nsis-bounces@ietf.org Mon Oct 23 03:06:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gbts5-0008J1-L5; Mon, 23 Oct 2006 03:05:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gbts4-0008Gy-4m for nsis@ietf.org; Mon, 23 Oct 2006 03:05:16 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbtmT-00074y-5P for nsis@ietf.org; Mon, 23 Oct 2006 02:59:30 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9N6xQbo010980 for ; Mon, 23 Oct 2006 09:59:28 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Oct 2006 09:59:26 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Oct 2006 09:59:25 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 23 Oct 2006 09:59:26 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Where we stand with the draft-ietf-nsis-qspec draft Thread-Index: Acb2cMiplW5+UcujTsGCzloRBxObRA== From: To: X-OriginalArrivalTime: 23 Oct 2006 06:59:25.0822 (UTC) FILETIME=[C6C531E0:01C6F670] X-Spam-Score: 0.2 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Subject: [NSIS] Where we stand with the draft-ietf-nsis-qspec draft X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org 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=20 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=20 "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 nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 23 03:31:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbuGN-0003SJ-8i; Mon, 23 Oct 2006 03:30:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbuGL-0003S7-6n for nsis@ietf.org; Mon, 23 Oct 2006 03:30:21 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbuGJ-0005Es-N2 for nsis@ietf.org; Mon, 23 Oct 2006 03:30:21 -0400 Received: from sbz-30.cs.helsinki.fi (sbz-30.cs.helsinki.fi [128.214.9.98]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Mon, 23 Oct 2006 10:30:12 +0300 id 000AFDB9.453C6F84.00007856 Date: Mon, 23 Oct 2006 10:30:12 +0300 (EEST) From: Jukka MJ Manner To: john.loughney@nokia.com Subject: Re: [NSIS] Where we stand with the draft-ietf-nsis-qspec draft In-Reply-To: Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org 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 On Mon, 23 Oct 2006, john.loughney@nokia.com wrote: > 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 > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 23 03:45:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbuUF-0003c9-Ui; Mon, 23 Oct 2006 03:44:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbuUF-0003bo-9B for nsis@ietf.org; Mon, 23 Oct 2006 03:44:43 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbuUA-0007z6-IW for nsis@ietf.org; Mon, 23 Oct 2006 03:44:43 -0400 Received: from zeus.cs.utwente.nl (zeus.ewi.utwente.nl [130.89.10.12]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k9N7iYj0016886; Mon, 23 Oct 2006 09:44:34 +0200 (MEST) Received: from janus.ewi.utwente.nl (janus [130.89.10.26]) by zeus.cs.utwente.nl (8.12.10/8.12.10) with ESMTP id k9N7iXL0021784; Mon, 23 Oct 2006 09:44:33 +0200 (MEST) Received: (from nobody@localhost) by janus.ewi.utwente.nl (8.11.7p1+Sun/8.10.2) id k9N7iTG00345; Mon, 23 Oct 2006 09:44:29 +0200 (MEST) Date: Mon, 23 Oct 2006 09:44:29 +0200 (MEST) X-Authentication-Warning: janus.ewi.utwente.nl: nobody set sender to karagian@cs.utwente.nl using -f To: john.loughney@nokia.com, nsis@ietf.org Subject: Re: [NSIS] Where we stand with the draft-ietf-nsis-qspec draft Received: from 84.82.109.231 (auth. user karagian@imap2.cs.utwente.nl) by webmail.cs.utwente.nl with HTTP; Mon, 23 Oct 2006 07:44:29 +0000 X-IlohaMail-Blah: karagian@ewi.utwente.nl X-IlohaMail-Method: mail() [mem] X-IlohaMail-Dummy: moo X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -5.518 () ALL_TRUSTED,AWL,BAYES_00,FVGT_s_OBFU_Q1 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Mon, 23 Oct 2006 09:44:36 +0200 (MEST) X-Spam-Score: 0.1 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org 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 On 10/23/2006, "john.loughney@nokia.com" wrote: >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 >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 23 05:53:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbwUO-0001bH-QC; Mon, 23 Oct 2006 05:53:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbwUN-0001b7-Bp for nsis@ietf.org; Mon, 23 Oct 2006 05:52:59 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbwUH-0002dd-Ml for nsis@ietf.org; Mon, 23 Oct 2006 05:52:59 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k9N9qSBu010827 for ; Mon, 23 Oct 2006 10:52:28 +0100 Received: from [193.118.197.193] ([193.118.197.193]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Oct 2006 10:52:29 +0100 Message-ID: <453C90D7.6040007@roke.co.uk> Date: Mon, 23 Oct 2006 10:52:23 +0100 From: Andrew McDonald User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Nsis (E-mail)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Oct 2006 09:52:29.0047 (UTC) FILETIME=[F3A79870:01C6F688] X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: andrew.mcdonald@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Subject: [NSIS] Re: I-D ACTION:draft-mcdonald-nsis-router-alert-iana-00.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, Following on from previous discussion we had on the topic (going back to the Dallas meeting and before) I wrote a short draft on IANA management of Router Alert Option Values. Currently, the QoS and NAT/FW NSLPs (as suggested by GIST) request allocation of RAO values. However, there isn't an IPv4 registry to manage them. So, if we want to be able to use values other than the default value (i.e. 0 = router shall examine packet), I believe we need to sort out the Router Alert IANA issues. The draft also considers possible ways of aligning the RAO value usage for IPv4 and IPv6. The draft doesn't attempt to discuss when you should/shouldn't use router alert, or should/shouldn't get a new RAO value, though those might be things worth including. Read, comment, tear to shreds, etc Andrew Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : IANA Considerations for the IPv4 and IPv6 Router Alert Option > Author(s) : A. McDonald > Filename : draft-mcdonald-nsis-router-alert-iana-00.txt > Pages : 9 > Date : 2006-10-18 > > This document provides new instructions to IANA on the allocation of > IPv4 and IPv6 Router Alert Option Values. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-mcdonald-nsis-router-alert-iana-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-mcdonald-nsis-router-alert-iana-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-mcdonald-nsis-router-alert-iana-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > ------------------------------------------------------------------------ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 23 06:02:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbwcV-0007Hm-7Z; Mon, 23 Oct 2006 06:01:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbwcT-0007Hg-CK for nsis@ietf.org; Mon, 23 Oct 2006 06:01:21 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbwcR-0004gO-Uf for nsis@ietf.org; Mon, 23 Oct 2006 06:01:21 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9NA1Fdp029875; Mon, 23 Oct 2006 13:01:16 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Oct 2006 13:01:07 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Oct 2006 13:01:07 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Where we stand with the draft-ietf-nsis-qspec draft Date: Mon, 23 Oct 2006 13:01:06 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Where we stand with the draft-ietf-nsis-qspec draft Thread-Index: Acb2d0hY0+xRJMukTjubPUCACzWUawAErwrw From: To: , X-OriginalArrivalTime: 23 Oct 2006 10:01:07.0132 (UTC) FILETIME=[287517C0:01C6F68A] X-Spam-Score: 0.2 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Georgios, >Another proposal for solving the inetroperability issue and=20 >the issue of having too many parameters was to: >* use only one mandatory parameter, i.e., Token Bucket that=20 >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=20 >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=20 >call. If after the deployment phase we conclude that more=20 >mandatory parameters are needed for interoperability then we=20 >could work on an interworking draft. > >I think that there are many of us that would agree with such a=20 >proposal. Do others find this to be a potential solution? John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 23 06:04:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gbwed-0000ot-5P; Mon, 23 Oct 2006 06:03:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gbwec-0000oO-Ey for nsis@ietf.org; Mon, 23 Oct 2006 06:03:34 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gbweb-0005CZ-09 for nsis@ietf.org; Mon, 23 Oct 2006 06:03:34 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9NA3Wjd031772; Mon, 23 Oct 2006 13:03:32 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Oct 2006 13:03:30 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Oct 2006 13:03:31 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Where we stand with the draft-ietf-nsis-qspec draft Date: Mon, 23 Oct 2006 13:03:31 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Where we stand with the draft-ietf-nsis-qspec draft Thread-Index: Acb2dSHbW6FJUiU1TyeohbK1IgNOTwAFTCRw From: To: X-OriginalArrivalTime: 23 Oct 2006 10:03:31.0647 (UTC) FILETIME=[7E9854F0:01C6F68A] X-Spam-Score: 0.2 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jukka, >My proposal _did not_ seek to give up interoperability.=20 >Instead it proposed a way forward, where we separate the=20 >object encoding from interoperability rules. This would allow=20 >making more focused specs, i.e., we have one spec for only=20 >encoding rules, and one that defines how/when/where/why=20 >interoperability can be achieved. > >If one wants to design his own private/internal QOSM, he can=20 >follow the former spec. Only, when a QOSM is meant for a wide=20 >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 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 23 06:07:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gbwi5-00073y-1G; Mon, 23 Oct 2006 06:07:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gbwi3-00071v-Vs for nsis@ietf.org; Mon, 23 Oct 2006 06:07:07 -0400 Received: from emailer.gwdg.de ([134.76.10.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gbwi2-0005wO-Mz for nsis@ietf.org; Mon, 23 Oct 2006 06:07:07 -0400 Received: from s5.ifi.informatik.uni-goettingen.de ([134.76.81.25] helo=[172.22.0.51]) by mailer.gwdg.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1Gbwge-0004AQ-Th; Mon, 23 Oct 2006 12:05:41 +0200 Message-ID: <453C93F1.6020500@cs.uni-goettingen.de> Date: Mon, 23 Oct 2006 12:05:37 +0200 From: Xiaoming Fu Organization: University of Goettingen, Germany User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: john.loughney@nokia.com Subject: Re: [NSIS] Where we stand with the draft-ietf-nsis-qspec draft References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-Id: xfu X-Virus-Scanned: (clean) by exiscan+sophie X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Cc: karagian@cs.utwente.nl, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org john.loughney@nokia.com wrote: > > Do others find this to be a potential solution? Count me in. Xiaoming _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 23 08:26:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gbys4-00071d-Tu; Mon, 23 Oct 2006 08:25:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gbys3-00071Y-U1 for nsis@ietf.org; Mon, 23 Oct 2006 08:25:35 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gbys2-0002F3-Ir for nsis@ietf.org; Mon, 23 Oct 2006 08:25:35 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 23 Oct 2006 05:25:34 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9NCPYZO008024; Mon, 23 Oct 2006 05:25:34 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k9NCPXin029780; Mon, 23 Oct 2006 05:25:33 -0700 (PDT) Received: from [10.32.245.155] (stealth-10-32-245-155.cisco.com [10.32.245.155]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k9NCDELp012758; Mon, 23 Oct 2006 05:13:15 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <74C0CDCF-A84A-4A8A-B729-E7F2A09ED923@cisco.com> Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [NSIS] Where we stand with the draft-ietf-nsis-qspec draft Date: Mon, 23 Oct 2006 08:25:14 -0400 To: X-Mailer: Apple Mail (2.752.2) Authentication-Results: sj-dkim-2.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=2776; t=1161606334; x=1162470334; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:David=20R=20Oran=20 |Subject:Re=3A=20[NSIS]=20Where=20we=20stand=20with=20the=20draft-ietf-nsis-qspec =20draft; X=v=3Dcisco.com=3B=20h=3D8e4FYZit2UY4kAwWnznGuy6WubI=3D; b=w/bZr5Q73NQ1QgRRcL3kkIPO6HAMp8C8AGvN2w7KAsnRBgISOw9NDwS3OYr87pNxaMsrdD+h w4jf0yN7tXZdvQ9VZf2jRIFyI0O6/OopUEZeuBm6YJPcXIA714qrKP1S; X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org On Oct 23, 2006, at 2:59 AM, wrote: > 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. > 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. > 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. If the source can't be described, how can you provide QoS for it? > I'm wondering > if some > sources / deployments may have certain parameters that are relatively > well defined, > but not all are so well defined. > 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. > thanks, > John > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 23 09:53:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc0ER-0004vD-Ay; Mon, 23 Oct 2006 09:52:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc0EN-0004qg-UW for nsis@ietf.org; Mon, 23 Oct 2006 09:52:44 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc0CA-0005zz-12 for nsis@ietf.org; Mon, 23 Oct 2006 09:50:40 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9NDoJft018488; Mon, 23 Oct 2006 16:50:24 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Oct 2006 16:50:24 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Oct 2006 16:50:24 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Where we stand with the draft-ietf-nsis-qspec draft Date: Mon, 23 Oct 2006 16:50:24 +0300 Message-ID: In-Reply-To: <453CC63A.5030206@tm.uka.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Where we stand with the draft-ietf-nsis-qspec draft Thread-Index: Acb2qRTMtqpF/tu8RZ+wCcscgHDEbQAARULg From: To: X-OriginalArrivalTime: 23 Oct 2006 13:50:24.0528 (UTC) FILETIME=[30812100:01C6F6AA] X-Spam-Score: 0.2 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Roland, Thanks for your reply, your comments seem sensible to me. John=20 >-----Original Message----- >From: ext Roland Bless [mailto:bless@tm.uka.de]=20 >Sent: 23 October, 2006 16:40 >To: Loughney John (Nokia-NRC/Helsinki) >Cc: nsis@ietf.org >Subject: Re: [NSIS] Where we stand with the draft-ietf-nsis-qspec draft > >Hi John, > >john.loughney@nokia.com wrote: >> We have had a very large thread on the current=20 >> draft-ietf-nsis-qspec-12.txt draft. >> We don't have a clear consensus, so I'd like to try to summarize the=20 >> discussions. >>=20 >> Several people feel that the current draft contains too many=20 >mandatory=20 >> parameters and mapping some QoS Models to others is mixing=20 >> apples-to-oranges. The > >Yes. I agree with this. > >> feeling >> is that interoperability is hard to achieve and therefore we should=20 >> not try to gain interoperability. Jukka Manner's message on 17th of=20 >> October proposed a way forward. >> http://www1.ietf.org/mail-archive/web/nsis/current/msg06919.html > >No, because there is a better alternative now... > >> However, several (other) people feel that interoperability=20 >is imporant=20 >> and is needed. Giving up on interoperability would not be a good=20 >> thing, and that we are very close to a solution. Dave Oran=20 >proposed a=20 >> mechanism to reach a solution on the 19th October: >> http://www1.ietf.org/mail-archive/web/nsis/current/msg06962.html > >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=20 >> Dave's message above, and the working group can review this,=20 >to see if=20 >> we can gain consensus on this. >> I think it would be sufficient to send some rough text to=20 >the mailing=20 >> 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=20 >> that the source cannot be described a mathematically=20 >complete way, is=20 >> there any value (or does it make any sense at all) in sending an=20 >> incomplete qspec, or potentially "wildcarding" sending some of the=20 >> manditory parameters. I'm wondering if some sources /=20 >deployments may=20 >> have certain parameters that are relatively well defined,=20 >but not all=20 >> are so well defined. > >I find it confusing to have mandatory parameters that are=20 >somehow optional to provide (omitting or wildcarding values...). >IMHO, each QoS model could determine on its own which=20 >(constraint) parameters are relevant to consider during=20 >admission control. > >Regards, > Roland > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 23 09:53:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc0Er-0005SN-JR; Mon, 23 Oct 2006 09:53:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc0Ep-0005IV-P9 for nsis@ietf.org; Mon, 23 Oct 2006 09:53:11 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc02m-0003q0-7U for nsis@ietf.org; Mon, 23 Oct 2006 09:40:49 -0400 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1Gc02g-00016P-39; Mon, 23 Oct 2006 15:40:40 +0200 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1Gc02T-00064S-6G; Mon, 23 Oct 2006 15:40:25 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 9593EA1CD; Mon, 23 Oct 2006 15:40:11 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1Gc02F-0000EV-9f; Mon, 23 Oct 2006 15:40:11 +0200 Message-ID: <453CC63A.5030206@tm.uka.de> Date: Mon, 23 Oct 2006 15:40:10 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: john.loughney@nokia.com Subject: Re: [NSIS] Where we stand with the draft-ietf-nsis-qspec draft References: In-Reply-To: X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.2 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi John, john.loughney@nokia.com wrote: > 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 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. > http://www1.ietf.org/mail-archive/web/nsis/current/msg06919.html No, because there is a better alternative now... > 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 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. > 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. 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 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 23 10:19:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc0dg-0002uB-Ly; Mon, 23 Oct 2006 10:18:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc0de-0002nv-TC for nsis@ietf.org; Mon, 23 Oct 2006 10:18:50 -0400 Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc0da-0003tQ-6D for nsis@ietf.org; Mon, 23 Oct 2006 10:18:50 -0400 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx.mail.saic.com; Mon, 23 Oct 2006 10:18:28 -0400 Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006102310182609732 ; Mon, 23 Oct 2006 10:18:27 -0400 Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Mon, 23 Oct 2006 10:18:26 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426230ECE@0591-ITS-EXMP02.us.saic.com> From: "Roy, Radhika R." To: cdvorak@research.att.com, RADHIKA.R.ROY@saic.com, john.loughney@nokia.com, lars.westberg@ericsson.com Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Date: Mon, 23 Oct 2006 10:18:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) content-class: urn:content-classes:message x-mimeole: Produced By Microsoft Exchange V6.5 x-originalarrivaltime: 23 Oct 2006 14:18:22.0398 (UTC) FILETIME=[1897C5E0:01C6F6AE] Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: gash@att.com, karagian@cs.utwente.nl, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org The whole thing DOES boil down to the value-based system versus the non-value-based system because of the following fact: 1. Why does the so-called Y.1541 implementation-specific specification = use value-based QOS classes that is the fundamental problems of the generic standardization? 2. If the so-called Y.1541-implementation spec wants to be used as generalized QOS model like DiffServ, RSVP, and IntServ, it MUST use for example the spec of IntServ's QOS model like Guaranteed, Controlled, = and Best-Effort service classes without limited itself ONLY to a GIVEN set = of values.=20 That is, it MUST leave the specific values of delay, jitter, and packet = loss to the end users who may use those as they like for the applications = they have in their mind. So, the values of any QOS parameters must NOT be hard-coded in the spec. If QOS parameter values are hard-coded in the = spec it becomes only the implementation spec for a given set of values. Is = it clear? 3. If the so-called Y.1541 spec wants to be generalized like e2e QOS = spec like low delay class, high delay class or very high delay class, it = MUST, like IntSev's Guaranteed Class, Controlled Class, and Best-Effort = Class, define its PROPERTIES. That's all.=20 So, the Y.1541 spec is ONLY good as long as the specific values that = have been defined in the spec. If one does NOT use those specific sets of = values any SINGLE parameter of any QOS parameter, they will NOT be Y.1541 QOS classes.=20 The bottom line is this: Y.1541 QOS classes is ONLY good for the values = of the QOS parameters specified in the spec. Therefore, it is the = value-based IMPLEMENTATION spec, not a generalized standard like low, medium or = high delay e2e QOS classes. Best regards, Radhika PS: It is true that Y.1541 does not specify bandwidth, but it does = specify specific values for delay, jitter, and packet loss. Indirectly, the = delay is also a function of the bandwidth. -----Original Message----- From: cdvorak@research.att.com [mailto:cdvorak@research.att.com]=20 Sent: Friday, October 20, 2006 12:37 PM To: RADHIKA.R.ROY@saic.com; john.loughney@nokia.com; lars.westberg@ericsson.com Cc: gash@att.com; karagian@cs.utwente.nl; nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt For me this is definitely NOT about value-based vs. non-value based, it = is more about the fact that e2e QoS is not the same as, for example, node-specific performance (e.g., PHBs). We gave this a lot of thought in Y.1541, which gives examples of how DiffServ PHBs can be used to address certain Y.1541 e2e QoS classes. = For example, if an application requiring interactivity is to be supported, certain e2e QoS is needed (low delay), which translates into specific = Y.1541 classes, supportable by EF DSCPs. One would thus want an NSIS QoS = protocol to help use nodal behavior to support e2e QoS needs. BTW note that I did not say a thing about bandwidth. (Focusing on only bandwidth is really missing all of what I thought NSIS was going to = do!) Chuck=20 ________________________________________ From: RADHIKA.R.ROY@saic.com [mailto:RADHIKA.R.ROY@saic.com]=20 Sent: Thursday, October 19, 2006 8:25 AM To: john.loughney@nokia.com; Dvorak,Charles A (Chuck); lars.westberg@ericsson.com Cc: gash@att.com; karagian@cs.utwente.nl; nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt Again the same logic of generalization -=A0Mixing "apples" with = "oranges" when "interworking" is concerned! =A0 Is it an isolated stand-alone=A0debate that people will "just" look = into Y.1541 value-based QOS class=A0parameters all by itself? =A0 If it is stand-alone Y.1541 value-based QOS implementations for using = NSIS QOS signaling protocol why a separate stand-alone Y.1541-specific drat = is not written? For example, people can "assume" a Y.1541 = implementation-based QOS policy "somehow" does magic to do so. What is the problem? =A0 People can "carry" any values of any parameters in NSIS QOS signaling protocol and, it could be 100s of any so-called QOS classes like = Y.1541. It is NOT a rocket science. =A0 Why then so-called Y.1541 QOS value-based = implementation-specific=A0model is drawn in the same level like that of non-value-based non-implementation-based DiffServ and RSVP for interworking? It will = NEVER interwork. =A0 Why do they need to be done in the same draft creating a problem of generalization between apples and oranges? =A0 The issue is interworking of the QSPEC template carry the QOS = parameters: Value-based and Non-Value-based. =A0 Radhika ________________________________________ From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Thu 10/19/2006 7:58 AM To: cdvorak@research.att.com; RADHIKA.R.ROY@saic.com; lars.westberg@ericsson.com Cc: gash@att.com; karagian@cs.utwente.nl; nsis@ietf.org Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt I've got to agree with Chuck on this.=A0=A0 How Y.1541 fufills QoS = classes is not an NSIS issue.=A0 I think it is clear how to carry them, but how = the domain deploying Y.1541 verifies things are fufilled is outslide of = NSIS. =A0 John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 23 10:45:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc13F-0001xG-Uu; Mon, 23 Oct 2006 10:45:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc13E-0001wn-K1 for nsis@ietf.org; Mon, 23 Oct 2006 10:45:16 -0400 Received: from amer-mta07.csc.com ([20.137.52.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc12d-00084x-Vp for nsis@ietf.org; Mon, 23 Oct 2006 10:45:16 -0400 Received: from amer-gwdr06.csc.com (amer-gwdr06-1.csc.com [20.137.52.162]) by amer-mta07.csc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id k9NEiZ4n009589 for ; Mon, 23 Oct 2006 10:44:35 -0400 (EDT) In-Reply-To: Subject: Re: [NSIS] Where we stand with the draft-ietf-nsis-qspec draft To: X-Mailer: Lotus Notes 652HF83 November 04, 2004 Message-ID: From: Janet P Gunn Date: Mon, 23 Oct 2006 10:44:33 -0400 X-MIMETrack: Serialize by Router on AMER-GWDR06/SRV/CSC(Release 6.5.3|September 14, 2004) at 10/23/2006 10:44:46 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org 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. -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- To 10/23/2006 02:59 AM cc Subject [NSIS] Where we stand with the draft-ietf-nsis-qspec draft 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 nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 23 15:51:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc5oo-0000kT-9p; Mon, 23 Oct 2006 15:50:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc5oh-0000dd-Jn; Mon, 23 Oct 2006 15:50:35 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc5oR-0002Jy-QU; Mon, 23 Oct 2006 15:50:35 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 03CB026E6B; Mon, 23 Oct 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Gc5o9-0008Nj-S7; Mon, 23 Oct 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 23 Oct 2006 15:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-tunnel-01.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : NSIS Operation Over IP Tunnels Author(s) : C. Shen, et al. Filename : draft-ietf-nsis-tunnel-01.txt Pages : 33 Date : 2006-10-23 This draft presents an NSIS operation over IP tunnel scheme using QoS NSLP as the NSIS signaling application. Both sender-initiated and receiver-initiated NSIS signaling modes are discussed. The scheme creates individual or aggregate tunnel sessions for end-to-end sessions traversing the tunnel. Packets belonging to qualified end- to-end sessions are mapped to corresponding tunnel sessions and assigned special flow IDs to be distinguished from the rest of the tunnel traffic. Tunnel endpoints keep the association of the end-to- end and tunnel session mapping, so that adjustment in one session can be reflected in the other. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-tunnel-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nsis-tunnel-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nsis-tunnel-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-10-23111938.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-tunnel-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-tunnel-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-23111938.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --NextPart-- From nsis-bounces@ietf.org Tue Oct 24 06:17:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcJJY-0002Cy-Iv; Tue, 24 Oct 2006 06:15:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcJJX-00028p-9Q for nsis@ietf.org; Tue, 24 Oct 2006 06:15:19 -0400 Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcJJV-0002Tj-UY for nsis@ietf.org; Tue, 24 Oct 2006 06:15:19 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k9OAFBcC005918 for ; Tue, 24 Oct 2006 12:15:16 +0200 (MEST) From: "Georgios Karagiannis" To: Date: Tue, 24 Oct 2006 12:15:07 +0200 Message-ID: <002001c6f755$4a9ef4d0$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: Acb3VUd09wsf8e9STJaviP40JZ35Cg== X-Spam-Score: 0.096 () AWL X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Tue, 24 Oct 2006 12:15:16 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [NSIS] discussions and out of office X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all >From 25/10 until 1st November I will be out of office and I will have very limited Internet access. This means that I will not be able to actively participate in the QSPEC-1 discussions that probably will start at the end of this week! Best Regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 24 06:21:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcJOD-0006YM-Vs; Tue, 24 Oct 2006 06:20:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcJOC-0006YC-7w for nsis@ietf.org; Tue, 24 Oct 2006 06:20:08 -0400 Received: from smtp2.dei.uc.pt ([193.137.203.231] helo=smtp.dei.uc.pt) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcJOA-00036H-RP for nsis@ietf.org; Tue, 24 Oct 2006 06:20:08 -0400 Received: from [10.3.1.54] (din-cisuc54.dei.uc.pt [10.3.1.54]) (authenticated bits=0) by smtp.dei.uc.pt (8.13.8/8.13.8) with ESMTP id k9OAIqSJ030538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Oct 2006 11:19:10 +0100 Message-ID: <453DF698.5090606@student.dei.uc.pt> Date: Tue, 24 Oct 2006 11:18:48 +0000 From: David Palma User-Agent: Thunderbird 1.5.0.5 (X11/20060915) MIME-Version: 1.0 To: nsis@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-FCTUC-DEI-SIC-MailScanner-Information: Please contact helpdesk@dei.uc.pt for more information X-FCTUC-DEI-SIC-MailScanner: Found to be clean X-FCTUC-DEI-SIC-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-4.399, required 3, autolearn=not spam, ALL_TRUSTED -1.80, BAYES_00 -2.60) X-FCTUC-DEI-SIC-MailScanner-From: palma@student.dei.uc.pt X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: =?ISO-8859-1?Q?Lu=EDs_Cordeiro?= Subject: [NSIS] Receiver Initiated Reservations on QoS NSLP X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, I have a doubt on the QoS NSLP draft. On the receiver initiated reservations it seems that the QUERY message should go downstream, RESERVE upstream and finally a downstream RESPONSE. >From my point of view it would make sense to initiate the process with an upstream QUERY (since GIST supports upstream associations) followed by a downstream RESERVE and upstream RESPONSE. This approach would allow to have clearer state machine for RESERVE and RESPONSE messages since they would be processed as any sender initiated reservation. Besides this the downstream path would always be the same as the data flow path and this could be helpful on scenarios with different upstream and downstream bandwidth. Does this idea make sense? Thank you for your time, Best Regards, David Palma _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 24 08:20:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcLFS-0001VP-6y; Tue, 24 Oct 2006 08:19:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcLFQ-0001VE-RF for nsis@ietf.org; Tue, 24 Oct 2006 08:19:12 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc79T-0004Ws-AL for nsis@ietf.org; Mon, 23 Oct 2006 17:16:07 -0400 Received: from smtp.dei.uc.pt ([193.137.203.228] helo=smtp2.dei.uc.pt) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gc6xm-0007Lm-Ko for nsis@ietf.org; Mon, 23 Oct 2006 17:04:04 -0400 Received: from [10.0.0.2] (bl5-132-185.dsl.telepac.pt [82.154.132.185]) (authenticated bits=0) by smtp2.dei.uc.pt (8.13.8/8.13.8) with ESMTP id k9NL3vEv029274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 23 Oct 2006 22:03:58 +0100 Message-ID: <453D3C53.7080700@student.dei.uc.pt> Date: Mon, 23 Oct 2006 22:04:03 +0000 From: David Palma User-Agent: Thunderbird 1.5.0.5 (X11/20060915) MIME-Version: 1.0 To: nsis@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-FCTUC-DEI-SIC-MailScanner-Information: Please contact helpdesk@dei.uc.pt for more information X-FCTUC-DEI-SIC-MailScanner: Found to be clean X-FCTUC-DEI-SIC-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-4.399, required 3, autolearn=not spam, ALL_TRUSTED -1.80, BAYES_00 -2.60) X-FCTUC-DEI-SIC-MailScanner-From: palma@student.dei.uc.pt X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [NSIS] Receiver Initiated Reservations on QoS NSLP X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, I have a doubt on the QoS NSLP draft. On the receiver initiated reservations it seems that the QUERY message should go downstream, RESERVE upstream and finally a downstream RESPONSE. >From my point of view it would make sense to initiate the process with an upstream QUERY (since GIST supports upstream associations) followed by a downstream RESERVE and upstream RESPONSE. This approach would allow to have clearer state machine for RESERVE and RESPONSE messages since they would be processed as any sender initiated reservation. Besides this the downstream path would always be the same as the data flow path and this could be helpful on scenarios with different upstream and downstream bandwidth. Does this idea make sense? Thank you for your time, Best Regards, David Palma _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 25 08:45:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gci7F-000568-Hi; Wed, 25 Oct 2006 08:44:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gci7E-00055e-Eo for nsis@ietf.org; Wed, 25 Oct 2006 08:44:16 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gci7A-00031A-3O for nsis@ietf.org; Wed, 25 Oct 2006 08:44:16 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 41EEA1BAC4D for ; Wed, 25 Oct 2006 14:44:09 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: nsis From: Martin Stiemerling Date: Wed, 25 Oct 2006 14:44:07 +0200 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [NSIS] NATFW NSLP: Result of the REANCO Voting X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Dear all, The REA Naming Contest (REANCO) has ended. In total, I have received 4 votes. The votes were a) one e) two j) one So proposal e) did make it, i.e., EXT (for playing with the external address and opening firewall holes for external data senders (incoming streams)). You can already find the new name in the submitted draft -13. e) has been proposed by Jukka Manner. Congratulations to Jukka and the beer is ready for you! Thanks, Martin Here is the list of all proposals received as reference: a) Open Internal Path (OIP) message b) Configure Internal Path (CIP) message c) Prepare For Ucreate (PFU) message (where UCREATE is actually now REA) d) Internal Network Configuration (INC) message e) EXT (for playing with the external address and opening firewall holes for external data senders (incoming streams)) f) Open Path Interactive (OPI) message g) Open Interactive Path (OIP) message h) Path Opening Interactive (POI) message i) Interactive Path Opening (IPO) message j) CREATE -> ICREATE (Initiator CREATE); REA -> RCREATE (Responder CREATE) k) CREATE -> SCREATE (Sender CREATE); REA -> RCREATE (Receiver CREATE) _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 25 09:25:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcikZ-00065U-Lw; Wed, 25 Oct 2006 09:24:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcikL-00051X-PJ for nsis@ietf.org; Wed, 25 Oct 2006 09:24:41 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcidU-0002i1-7x for nsis@ietf.org; Wed, 25 Oct 2006 09:17:40 -0400 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1GcidI-00077x-CJ; Wed, 25 Oct 2006 15:17:31 +0200 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1GcidH-00011G-VN; Wed, 25 Oct 2006 15:17:24 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 870B6B4F4; Wed, 25 Oct 2006 15:17:23 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1GcidG-0003Y9-Q5; Wed, 25 Oct 2006 15:17:22 +0200 Message-ID: <453F63E2.4000604@tm.uka.de> Date: Wed, 25 Oct 2006 15:17:22 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: David Palma Subject: Re: [NSIS] Receiver Initiated Reservations on QoS NSLP References: <453DF698.5090606@student.dei.uc.pt> In-Reply-To: <453DF698.5090606@student.dei.uc.pt> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -2.9 (--) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.1 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: nsis@ietf.org, =?ISO-8859-1?Q?Lu=EDs_Cordeiro?= X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi David, David Palma schrieb: > I have a doubt on the QoS NSLP draft. On the receiver initiated > reservations it seems that the QUERY message should go downstream, > RESERVE upstream and finally a downstream RESPONSE. Yep. The QUERY message only serves the purpose of finding the _correct_ path from sender to receiver in downstream direction. This "GIST-fixed" path can then be used to send a RESERVE in upstream direction, ensuring that this RESERVE traverses the correct nodes. >>From my point of view it would make sense to initiate the process with > an upstream QUERY (since GIST supports upstream associations) followed Quote from sec. 5.8.1.3.: You might have missed the "health warning" note that an upstream Query is not really a reliable method to determine the *real* path: In general, it is not possible to determine the hop-by-hop route upstream because of asymmetric routing. However, in particular cases, the upstream peer can be discovered with a high degree of confidence, for example: o The upstream GIST peer is 1 IP hop away, and can be reached by tracing back through the interface on which the flow arrives. o The upstream peer is a border router of a single-homed (stub) network. ... The rationale for this is that the downstream Query is in general a more reliable way to install state, since it directly probes the routing infrastructure along the flow path, whereas use of the upstream Query depends on the correctness of the Querying node's understanding of the topology. > by a downstream RESERVE and upstream RESPONSE. This approach would allow > to have clearer state machine for RESERVE and RESPONSE messages since > they would be processed as any sender initiated reservation. Besides > this the downstream path would always be the same as the data flow path > and this could be helpful on scenarios with different upstream and > downstream bandwidth. > Does this idea make sense? No, but you may find my earlier proposal a little bit more along your lines of thought (namely having the RESERVE always going from sender to receiver, i.e. downstream): http://www1.ietf.org/mail-archive/web/nsis/current/msg05182.html (the diagram was messed up somehow...) or even older (Sep. 2004) http://www1.ietf.org/mail-archive/web/nsis/current/msg04367.html For your convenience I'll repeat it here: ----------------------------------------------------------------------- QNI (receiver) QNE QNE QNR (sender) | RI-RESERVE (direct or bypassing) | |------------------------------------------>| | RESERVE | | RESERVE |<---------- |1) | RESERVE |<-----------| | 2)|<----------------| | | |RESPONSE | | | |---------------->| RESPONSE | | | |----------->| RESPONSE | | | |----------->| 1) RESERVE carries additional an RSN of the RI-RESERVE 2) RESERVE with additional RSN of RI-RESERVE is interpreted as RESPONSE to RI-RESERVE This alternative would simply require a forwarding a RI-RESERVE request from the receiver to the sender and one additional RSN object. It would not require any state installation during this 1st way. The sender would then initiate (or not if local policy forbids it) a normal RESERVE towards the receiver, except that this RESERVE would carry additionally a reference to the RI-RESERVE. When the receiver gets the RESERVE it considers it as response to its RI-RESERVE and sends the normal RESPONSE back. This would also require a 3-way exchange, but no path state installation with a query or some other mechanism beforehand. Furthermore, bi-directional reservations could also be performed (if not in parallel) by piggybacking an RI-RESERVE to a normal RESERVE. One could argue that the RI-RESERVE should rather be sent by some application level signaling protocol. However, in my opinion it would be nice to have such a capability inside the NSLP itself, because it does not depend on the capability of the app level signaling (if there is such at all) to do so... ------------------------------------------------------------------- Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 25 09:47:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcj66-0003aG-Cw; Wed, 25 Oct 2006 09:47:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcj65-0003Zm-4V for nsis@ietf.org; Wed, 25 Oct 2006 09:47:09 -0400 Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gcj61-0000ta-SU for nsis@ietf.org; Wed, 25 Oct 2006 09:47:09 -0400 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx.mail.saic.com; Wed, 25 Oct 2006 09:46:57 -0400 Received: from 0015-ITS-EXBH01.us.saic.com ([10.43.229.18]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006102509465323461 ; Wed, 25 Oct 2006 09:46:55 -0400 Received: from 0591-ITS-EXMP02.us.saic.com ([10.42.81.248]) by 0015-ITS-EXBH01.us.saic.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Oct 2006 09:46:51 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Receiver Initiated Reservations on QoS NSLP Date: Wed, 25 Oct 2006 09:46:37 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426230ED2@0591-ITS-EXMP02.us.saic.com> In-Reply-To: <453F63E2.4000604@tm.uka.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Receiver Initiated Reservations on QoS NSLP Thread-Index: Acb4OSqlA3nIy/EQSrSL9UfiGDNgKAAAReiA From: "Roy, Radhika R." To: "Roland Bless" , "David Palma" X-OriginalArrivalTime: 25 Oct 2006 13:46:51.0270 (UTC) FILETIME=[06380A60:01C6F83C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: nsis@ietf.org, =?iso-8859-1?Q?Lu=EDs_Cordeiro?= X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Ronald: Just a little clarification on your statement, "... the app level = signaling (if there is such at all) to do so..." Yes, the application does have those capabilities if IETF looks into the = beauty and simplicity of the application level QOS signaling. ITU-T's H.323 application does have a standard to use RSVP QOS signaling = messages using guaranteed, controlled, and best-effort QOS classes = DIRECTLY. In the same token, the much more versatile NSIS QOS signaling standard = messages can also be used directly by the applications like H.323 and = SIP. However, SIP/SDP needs a little more works to perform this. If the = NSIS, SIP, and SDP standards would have been under the same WG, this = work of standardization for application-level QOS signaling could be = done more smoothly and in an integrated way. Now all knowledge of QOS signaling from the application layer to the = network layer and below is segmented in different WGs and experts. It = has created a significant problem to solve the QOS signaling problems = either from the end-to-end basis and/or from the application layer to = the lower layers. Best regards, Radhika -----Original Message----- From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On Behalf Of = Roland Bless Sent: Wednesday, October 25, 2006 9:17 AM To: David Palma Cc: nsis@ietf.org; Lu=EDs Cordeiro Subject: Re: [NSIS] Receiver Initiated Reservations on QoS NSLP Hi David, One could argue that the RI-RESERVE should rather be sent by some application level signaling protocol. However, in my opinion it would be nice to have such a capability inside the NSLP itself, because it does not depend on the capability of the app level signaling (if there is such at all) to do so... ------------------------------------------------------------------- Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 25 10:13:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcjUr-0003Ia-9O; Wed, 25 Oct 2006 10:12:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcjUk-0003Cn-Tr for nsis@ietf.org; Wed, 25 Oct 2006 10:12:39 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcjMF-0004Np-Q3 for nsis@ietf.org; Wed, 25 Oct 2006 10:03:56 -0400 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1GcjM4-0005rT-L8; Wed, 25 Oct 2006 16:03:46 +0200 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1GcjM3-0000Gd-Cq; Wed, 25 Oct 2006 16:03:39 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 38359B370; Wed, 25 Oct 2006 16:03:37 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1GcjM0-0003bY-QT; Wed, 25 Oct 2006 16:03:36 +0200 Message-ID: <453F6EB8.8090908@tm.uka.de> Date: Wed, 25 Oct 2006 16:03:36 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: "Roy, Radhika R." Subject: Re: [NSIS] Receiver Initiated Reservations on QoS NSLP References: <62D92A9A02BCC845B202323D49A48426230ED2@0591-ITS-EXMP02.us.saic.com> In-Reply-To: <62D92A9A02BCC845B202323D49A48426230ED2@0591-ITS-EXMP02.us.saic.com> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: -4.2 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: =?ISO-8859-1?Q?Lu=EDs_Cordeiro?= , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, Roy, Radhika R. wrote: > Ronald: no , I'm Roland. > Just a little clarification on your statement, "... the app level > signaling (if there is such at all) to do so..." > > Yes, the application does have those capabilities if IETF looks into > the beauty and simplicity of the application level QOS signaling. Application Level Signaling is rather an end-to-end signaling (e.g. if you consider a direct SIP call for example) than infrastructure signaling. NSIS QoS Signaling is about signaling to the network infrastructure elements because you want network resources. Requesting QoS from the application level only may work, but is limited to the particular application (or its signaling protocol). > ITU-T's H.323 application does have a standard to use RSVP QOS > signaling messages using guaranteed, controlled, and best-effort QOS > classes DIRECTLY. > > In the same token, the much more versatile NSIS QOS signaling > standard messages can also be used directly by the applications like > H.323 and SIP. However, SIP/SDP needs a little more works to perform > this. If the NSIS, SIP, and SDP standards would have been under the > same WG, this work of standardization for application-level QOS > signaling could be done more smoothly and in an integrated way. But using NSIS is more general and modular, because I also want QoS for non-SIP-based applications which is something that A-IMS also wants to achieve (if I understood correctly). So I'm in favor of doing it separately from SIP, because there are so many applications which may do different things than using SIP...(remember innovation is [easier] at the edge). > Now all knowledge of QOS signaling from the application layer to the > network layer and below is segmented in different WGs and experts. It > has created a significant problem to solve the QOS signaling problems > either from the end-to-end basis and/or from the application layer to > the lower layers. QoS mapping is required and not easy, but its solvable... Regards, Roland > -----Original Message----- From: nsis-bounces@ietf.org > [mailto:nsis-bounces@ietf.org] On Behalf Of Roland Bless Sent: > Wednesday, October 25, 2006 9:17 AM To: David Palma Cc: > nsis@ietf.org; Luís Cordeiro Subject: Re: [NSIS] Receiver Initiated > Reservations on QoS NSLP > > Hi David, > > One could argue that the RI-RESERVE should rather be sent by some > application level signaling protocol. However, in my opinion it would > be nice to have such a capability inside the NSLP itself, because it > does not depend on the capability of the app level signaling (if > there is such at all) to do so... > ------------------------------------------------------------------- > Regards, Roland > -- Dr. Roland Bless -- WWW: http://www.tm.uka.de/~bless Institut für Telematik, Universität Karlsruhe (TH), Germany Zirkel 2, D-76128 Karlsruhe -- Geb. 20.20, 3.OG, Raum 358 Tel.: +49 721 608-6413 Fax: +49 721 608-6789 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 25 11:32:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gckjo-0007y3-Ns; Wed, 25 Oct 2006 11:32:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gckjn-0007v8-JQ for nsis@ietf.org; Wed, 25 Oct 2006 11:32:15 -0400 Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gckje-0001GM-N8 for nsis@ietf.org; Wed, 25 Oct 2006 11:32:15 -0400 Received: from 0015-its-ieg01.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx.mail.saic.com; Wed, 25 Oct 2006 11:31:57 -0400 Received: from 0015-ITS-EXBH01.us.saic.com ([10.43.229.18]) by 0015-its-ieg01.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006102511315702926 ; Wed, 25 Oct 2006 11:31:57 -0400 Received: from 0591-ITS-EXMP02.us.saic.com ([10.42.81.248]) by 0015-ITS-EXBH01.us.saic.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Oct 2006 11:31:58 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Receiver Initiated Reservations on QoS NSLP Date: Wed, 25 Oct 2006 11:31:42 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426230ED5@0591-ITS-EXMP02.us.saic.com> In-Reply-To: <453F6EB8.8090908@tm.uka.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Receiver Initiated Reservations on QoS NSLP Thread-Index: Acb4PpHdHmiOrg3VQ+mPSsLQ8jyhfAAAjIDA From: "Roy, Radhika R." To: X-OriginalArrivalTime: 25 Oct 2006 15:31:58.0191 (UTC) FILETIME=[B56FCFF0:01C6F84A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: =?iso-8859-1?Q?Lu=EDs_Cordeiro?= , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Roland: Sorry about misspelling earlier. Inline [RRR]. -----Original Message----- From: bless@tm.uka.de [mailto:bless@tm.uka.de]=20 Sent: Wednesday, October 25, 2006 10:04 AM To: Roy, Radhika R. Cc: David Palma; nsis@ietf.org; Lu=EDs Cordeiro Subject: Re: [NSIS] Receiver Initiated Reservations on QoS NSLP Hi, Roy, Radhika R. wrote: > Ronald: no , I'm Roland. [RRR] See above. > Just a little clarification on your statement, "... the app level > signaling (if there is such at all) to do so..." >=20 > Yes, the application does have those capabilities if IETF looks into > the beauty and simplicity of the application level QOS signaling. Application Level Signaling is rather an end-to-end signaling (e.g. if you consider a direct SIP call for example) than infrastructure signaling. NSIS QoS Signaling is about signaling to the network infrastructure elements because you want network resources. Requesting QoS from the application level only may work, but is limited to the particular application (or its signaling protocol). [RRR] NSIS does have the upper layer that will be used by the = applications. The application layer QOS signaling is the standard = applications like SIP/SDP how to signal NSIS QOS signaling messages to = express theirs needs. There is a little work from standardization = purpose. NSIS may not do this work, but SIP, SIPPING, and MMUSIC WG need = to this work in collaboration with NSIS. > ITU-T's H.323 application does have a standard to use RSVP QOS > signaling messages using guaranteed, controlled, and best-effort QOS > classes DIRECTLY. >=20 > In the same token, the much more versatile NSIS QOS signaling > standard messages can also be used directly by the applications like > H.323 and SIP. However, SIP/SDP needs a little more works to perform > this. If the NSIS, SIP, and SDP standards would have been under the > same WG, this work of standardization for application-level QOS > signaling could be done more smoothly and in an integrated way. But using NSIS is more general and modular, because I also want QoS for non-SIP-based applications which is something that A-IMS also wants to achieve (if I understood correctly).=20 [RRR] Sure, but those applications MUST have standards like SIP/SDP. All = standard applications will have their own application QOS signaling = messages, and these signaling messages must have a standard to use NSIS = signaling messages. (An analogy can be is this: Many networks from 3GPP, = cable, IP, ATM, FR, etc. can use DiffServ code points.) So I'm in favor of doing it separately from SIP, because there are so = many applications which may do different things than using = SIP...(remember innovation is [easier] at the edge). [RRR] It is not about SIP or non-SIP applications. It is about all = applications like SIP/SDP that have been standardized in the IETF. All = applications MUST have standards how to use NSIS signaling messages = using "standard" code points/interfaces/messages DIRECTLY. [RRR] If there are non-IETF standard applications like IMS, CableLabs, = and other, they may do the same (that's not IETF's primary headache). > Now all knowledge of QOS signaling from the application layer to the > network layer and below is segmented in different WGs and experts. It > has created a significant problem to solve the QOS signaling problems > either from the end-to-end basis and/or from the application layer to > the lower layers. QoS mapping is required and not easy, but its solvable... [RRR] It depends what you are looking into. For example, it is easy to = map the application layer QOS signaling messages of a given individual = application to NSIS QOS signaling messages (an analogy is given - = mapping of H.323 signaling messages to RSVP/IntServ signaling messages). [RRR] The above is also true for the lower network QOS when one needs to = map network QOS signaling/model and the NSIS QOS signaling messages = (e.g., DiffServ <-> NSIS, RSVP <-> NSIS, IntServ <-> NSIS, DSTE <-> = NSIS, Y.1541 <-> NSIS, 3GPP <-> NSIS). It is a straight forward to do so = (as can be seen all individual QOSM drafts prepared so far). It is NOT a = rocket science. [RRR] Then what is the problem? The very SERIOUS Problems come when one = needs to do "Interworking" between the different network layer QOS (It = must be noted that there is no need to "interwork" between two different = application layer QOS signaling messages as both ends will use the same = application). [RRR] In intewroking of the network layer QOS, there are couple of = layers where the problems reside. To sort them out, we have to analyze = as follows: [RRR] a. Generic non-value-based non-implementation-specific QOS = signaling schemes: where QOS signaling messages are being standardized. = All we need to map between them and NSIS QOS signaling messages. For = example, IETF's DiffServ, RSVP, and IntServ are the standards which = qualify them. In those cases, the Interworking between these IETF = standard QOS schemes using NSIS signaling messages are straight forward, = and they easily interwork. So, it is not a problem because each of these = protocols is based on the well-defined QOS properties (not hard-coded = some values). [RRR] b. Non-Generic Value-based Implementation-specific QOS signaling = schemes: where only some values of a group of QOS parameters have been = defined. Any violation of any value of any QOS parameter will be treated = as non-compliant. They have SERIOUS problems for INTERWORKING because of = the following: First, they do not have any "QOS signaling messages." = Second, they do NOT define general QOS characteristics based on which = one can understand what properties they have other than some hard-coded = values. Third, they want to use NSIS QOS signaling messages DIRECTLY = using those hard-coded values of group-based QOS parameters as they do = have one. For example, Y.1541, 3GPP/Y.1541 QOSM, and DSTE are of those = categories. More importantly, these value-based implementation-specific = QOS schemes are NOT for standardization. These can be used for ONLY = implementation something like SLA agreements. For example, OSP is = designed to offer Interworking between different value-based = implementations among different implementers. Regards, Roland > -----Original Message----- From: nsis-bounces@ietf.org > [mailto:nsis-bounces@ietf.org] On Behalf Of Roland Bless Sent: > Wednesday, October 25, 2006 9:17 AM To: David Palma Cc: > nsis@ietf.org; Lu=EDs Cordeiro Subject: Re: [NSIS] Receiver Initiated > Reservations on QoS NSLP >=20 > Hi David, >=20 > One could argue that the RI-RESERVE should rather be sent by some=20 > application level signaling protocol. However, in my opinion it would > be nice to have such a capability inside the NSLP itself, because it > does not depend on the capability of the app level signaling (if > there is such at all) to do so...=20 > -------------------------------------------------------------------=20 > Regards, Roland >=20 --=20 Dr. Roland Bless -- WWW: http://www.tm.uka.de/~bless Institut f=FCr Telematik, Universit=E4t Karlsruhe (TH), Germany Zirkel 2, D-76128 Karlsruhe -- Geb. 20.20, 3.OG, Raum 358 Tel.: +49 721 608-6413 Fax: +49 721 608-6789 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Oct 25 16:22:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcpGG-0000JA-Kx; Wed, 25 Oct 2006 16:22:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcolK-0003qf-M5; Wed, 25 Oct 2006 15:50:06 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcolJ-0007q2-14; Wed, 25 Oct 2006 15:50:06 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id DFC6826E3A; Wed, 25 Oct 2006 19:50:04 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GcolI-0004t9-NY; Wed, 25 Oct 2006 15:50:04 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 25 Oct 2006 15:50:04 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-12.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : NSLP for Quality-of-Service Signaling Author(s) : J. Manner, et al. Filename : draft-ietf-nsis-qos-nslp-12.txt Pages : 78 Date : 2006-10-25 This specification describes the NSIS Signaling Layer Protocol (NSLP) for signaling QoS reservations in the Internet. It is in accordance with the framework and requirements developed in NSIS. Together with GIST, it provides functionality similar to RSVP and extends it. The QoS NSLP is independent of the underlying QoS specification or architecture and provides support for different reservation models. It is simplified by the elimination of support for multicast flows. This specification explains the overall protocol approach, design decisions made and provides examples. It specifies object, message formats and processing rules. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-12.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nsis-qos-nslp-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nsis-qos-nslp-12.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-10-25142359.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-qos-nslp-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-qos-nslp-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-25142359.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --NextPart-- From nsis-bounces@ietf.org Wed Oct 25 16:52:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcpj5-0001AS-Cy; Wed, 25 Oct 2006 16:51:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcpET-00071e-Qj; Wed, 25 Oct 2006 16:20:14 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcpE8-0005xV-UL; Wed, 25 Oct 2006 16:20:12 -0400 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1GcozF-0007Qf-3V; Wed, 25 Oct 2006 22:04:29 +0200 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1GcozE-00018s-Mb; Wed, 25 Oct 2006 22:04:28 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 0733DB561; Wed, 25 Oct 2006 22:04:28 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1GcozD-0003q4-Ov; Wed, 25 Oct 2006 22:04:27 +0200 Message-ID: <453FC35E.2070309@tm.uka.de> Date: Wed, 25 Oct 2006 22:04:46 +0200 From: Roland Bless User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8.0.7) Gecko/20060909 Thunderbird/1.5.0.7 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: nsis@ietf.org, nsis-imp@ietf.org X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Score: -2.9 (--) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.1 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Subject: [NSIS] Next NSIS Interop X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, thanks to Luis and his colleagues for hosting the last interop meeting at the University of Coimbra. It was great! However, I guess there are a lot more things to test. So our Intitute likes to offer hosting the next Interop meeting at the University of Karlsruhe, Germany, if there is interest. Karlsruhe is reachable in approx. one hour by train from Frankfurt Airport that is a major hub in Europe. So getting (t)here should be easy. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 26 05:38:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd1gC-0006rT-VD; Thu, 26 Oct 2006 05:37:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd1gB-0006r6-Cd for nsis@ietf.org; Thu, 26 Oct 2006 05:37:39 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd1g9-00005H-UO for nsis@ietf.org; Thu, 26 Oct 2006 05:37:39 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9Q9bZ79005311; Thu, 26 Oct 2006 12:37:35 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Oct 2006 12:37:35 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Oct 2006 12:37:35 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Where we stand with the draft-ietf-nsis-qspec draft Date: Thu, 26 Oct 2006 12:37:34 +0300 Message-ID: In-Reply-To: <74C0CDCF-A84A-4A8A-B729-E7F2A09ED923@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Where we stand with the draft-ietf-nsis-qspec draft Thread-Index: Acb2nsyaU0Gt6F22Rk6PheHTdb0vbQCMdKJw From: To: X-OriginalArrivalTime: 26 Oct 2006 09:37:35.0108 (UTC) FILETIME=[5E109440:01C6F8E2] X-Spam-Score: 0.2 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Dave, >> I have asked Jerry and Dave to make a proposal along the lines of=20 >> Dave's message above, and the working group can review this, to see if=20 >> 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. >> >I just got home Friday night from an around-the-world trip,=20 >and am unburiying. I'll try to sync up with Jerry by mid-week=20 >and see what we can jointly come up with. Since the I-D wondow=20 >is closed, we can just come up with a prposal that can be=20 >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. >> One open question to Dave/Jerry about the proposal is, in the event=20 >> 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=20 >> incomplete qspec, or potentially "wildcarding" sending some of the=20 >> manditory parameters. >If the source can't be described, how can you provide QoS for it? > >> I'm wondering if some >> sources / deployments may have certain parameters that are relatively >> well defined, but not all are so well defined. >> >Maybe something which generated quantum packets... > >Seriously, just like on can always over-provision resources in=20 >order to be able to make QoS "guarantees", one can always=20 >either over- estimate or underestimate one's traffic source=20 >depending on whether you want the system to be optimistic or=20 >pessimistic when making its admission control decision and=20 >resource allocations. I think that could be a solution, how does the wg feel about this?From nsis-bounces@ietf.org Thu Oct 26 05:38:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd1gC-0006rT-VD; Thu, 26 Oct 2006 05:37:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd1gB-0006r6-Cd for nsis@ietf.org; Thu, 26 Oct 2006 05:37:39 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd1g9-00005H-UO for nsis@ietf.org; Thu, 26 Oct 2006 05:37:39 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9Q9bZ79005311; Thu, 26 Oct 2006 12:37:35 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Oct 2006 12:37:35 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Oct 2006 12:37:35 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Where we stand with the draft-ietf-nsis-qspec draft Date: Thu, 26 Oct 2006 12:37:34 +0300 Message-ID: In-Reply-To: <74C0CDCF-A84A-4A8A-B729-E7F2A09ED923@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Where we stand with the draft-ietf-nsis-qspec draft Thread-Index: Acb2nsyaU0Gt6F22Rk6PheHTdb0vbQCMdKJw From: To: X-OriginalArrivalTime: 26 Oct 2006 09:37:35.0108 (UTC) FILETIME=[5E109440:01C6F8E2] X-Spam-Score: 0.2 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Dave, >> I have asked Jerry and Dave to make a proposal along the lines of=20 >> Dave's message above, and the working group can review this, to see if=20 >> 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. >> >I just got home Friday night from an around-the-world trip,=20 >and am unburiying. I'll try to sync up with Jerry by mid-week=20 >and see what we can jointly come up with. Since the I-D wondow=20 >is closed, we can just come up with a prposal that can be=20 >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. >> One open question to Dave/Jerry about the proposal is, in the event=20 >> 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=20 >> incomplete qspec, or potentially "wildcarding" sending some of the=20 >> manditory parameters. >If the source can't be described, how can you provide QoS for it? > >> I'm wondering if some >> sources / deployments may have certain parameters that are relatively >> well defined, but not all are so well defined. >> >Maybe something which generated quantum packets... > >Seriously, just like on can always over-provision resources in=20 >order to be able to make QoS "guarantees", one can always=20 >either over- estimate or underestimate one's traffic source=20 >depending on whether you want the system to be optimistic or=20 >pessimistic when making its admission control decision and=20 >resource allocations. I think that could be a solution, how does the wg feel about this? thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 26 05:38:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd1gD-0006rc-7G; Thu, 26 Oct 2006 05:37:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd1gB-0006rB-Ml for nsis@ietf.org; Thu, 26 Oct 2006 05:37:39 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd1gA-00005K-8O for nsis@ietf.org; Thu, 26 Oct 2006 05:37:39 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9Q9bTLG029241 for ; Thu, 26 Oct 2006 12:37:37 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Oct 2006 12:37:34 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Oct 2006 12:37:34 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 26 Oct 2006 12:37:34 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NSIS Agenda Thread-Index: Acb40GBO2dwCNffpSSOWRH79x+iWyQ== From: To: X-OriginalArrivalTime: 26 Oct 2006 09:37:34.0358 (UTC) FILETIME=[5D9E2360:01C6F8E2] X-Spam-Score: 0.2 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Subject: [NSIS] NSIS Agenda X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, I have prepared a very bare-bones agenda, because we are behind on our deliverables. I don't think we can make any forward progress until we resolve the open issues on GIST, NTLPs and QSPEC. If there are some larger issues that should be addressed, I would be happy to allocate time for discussion of those issues. If there are other charter items that have some burning issues that need to be resolved, we can allocate some time for those as well, but please discuss those on the mailing list first. For new(-ish) work, rather than use meeting time, I suggest we schedule some lunch / bar time to discuss these in more detail with interested parties. thanks, John NSIS Meeting THURSDAY, November 9, 2006 0900-1130 Morning Session I Grande Ballroom A=09 Agenda Bashing charter Update Finalizing GIST - Robert Hancock - update on all IETF LC comments - discussion of open issues Finalizing QoS NSLP - Jukka Manner - Update on latest revision - discussion of any open issues Finalizing QSPEC - Jerry Ash - Update on latest revision - Discussion of Mandatory parameters in the QSPEC and how to achieve some level of QoS model interoperability Finalizing NAT/FW NSLP - Martin Stiemerling - Update on latest revision - discussion of any open issues Remaining time, updates on other charter items _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 26 05:38:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd1gD-0006rc-7G; Thu, 26 Oct 2006 05:37:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd1gB-0006rB-Ml for nsis@ietf.org; Thu, 26 Oct 2006 05:37:39 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd1gA-00005K-8O for nsis@ietf.org; Thu, 26 Oct 2006 05:37:39 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9Q9bTLG029241 for ; Thu, 26 Oct 2006 12:37:37 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Oct 2006 12:37:34 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Oct 2006 12:37:34 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 26 Oct 2006 12:37:34 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NSIS Agenda Thread-Index: Acb40GBO2dwCNffpSSOWRH79x+iWyQ== From: To: X-OriginalArrivalTime: 26 Oct 2006 09:37:34.0358 (UTC) FILETIME=[5D9E2360:01C6F8E2] X-Spam-Score: 0.2 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Subject: [NSIS] NSIS Agenda X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, I have prepared a very bare-bones agenda, because we are behind on our deliverables. I don't think we can make any forward progress until we resolve the open issues on GIST, NTLPs and QSPEC. If there are some larger issues that should be addressed, I would be happy to allocate time for discussion of those issues. If there are other charter items that have some burning issues that need to be resolved, we can allocate some time for those as well, but please discuss those on the mailing list first. For new(-ish) work, rather than use meeting time, I suggest we schedule some lunch / bar time to discuss these in more detail with interested parties. thanks, John NSIS Meeting THURSDAY, November 9, 2006 0900-1130 Morning Session I Grande Ballroom A=09 Agenda Bashing charter Update Finalizing GIST - Robert Hancock - update on all IETF LC comments - discussion of open issues Finalizing QoS NSLP - Jukka Manner - Update on latest revision - discussion of any open issues Finalizing QSPEC - Jerry Ash - Update on latest revision - Discussion of Mandatory parameters in the QSPEC and how to achieve some level of QoS model interoperability Finalizing NAT/FW NSLP - Martin Stiemerling - Update on latest revision - discussion of any open issues Remaining time, updates on other charter items _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 26 07:46:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd3fw-00022m-KJ; Thu, 26 Oct 2006 07:45:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd3ft-00022g-Ig for nsis@ietf.org; Thu, 26 Oct 2006 07:45:29 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd3fo-000550-1C for nsis@ietf.org; Thu, 26 Oct 2006 07:45:29 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 542B51BAC99; Thu, 26 Oct 2006 13:45:21 +0200 (CEST) In-Reply-To: <20061019080205.GA7303@mafr.de> References: <20061018152328.GA3034@mafr.de> <20061019080205.GA7303@mafr.de> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <65F797FF-1C1A-4BC8-AC04-89F9CD32C253@netlab.nec.de> Content-Transfer-Encoding: 7bit From: Martin Stiemerling Subject: Re: [NSIS] Re: NATFW+AUTH_SESSION: Scenarios with multiple authorization tokens Date: Thu, 26 Oct 2006 13:45:20 +0200 To: Matthias Friedrich X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Jukka MJ Manner , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Matthias, Jukka, all, A valid point to ask and I see the need for carrying multiple AUTH_SESSION objects within a single message. Am 19.10.2006 um 10:02 schrieb Matthias Friedrich: > Hi, > > thanks for your reply. Comments inline. > > On Wednesday, 2006-10-18, Jukka MJ Manner wrote: > [...] >> Still, as an overall comment, if you think multiple authentication >> pairs >> should be possible, then we could just allow multiple AUTH_SESSION >> objects >> within a single message. However, how do we define, which entity >> checks >> which token? > > The AUTH_SESSION object contains the ID of an authorizing entity, > so the > NSLP nodes on the path can choose the token from the authorizing > entity > they trust. > > Allowing multiple AUTH_SESSION objects is fine, but I'd suggest to > assign different IDs to each of them. As far as I know, none of > the other NSIS protocols allows multiple objects with the same ID. > This way, it's very easy to store them in arrays or hash maps in an > implementation. I do not see the assignment of multiple NSLP object IDs for AUTH_SESSION objects as a good solution to the problem. The NSLP object ID identifies a type of object and there is only one of type AUTH_SESSION object. It is indeed possible to have multiple instance of one object type in a NSLP message. But until now there hasn't been any need for this. So it is not possible by default but design decision to be made. I.e. it could be allowed to included multiple instances of the AUTH_SESSION object within a single NATFW NSLP message. The entity ID in the object would then be used to figure out which object needs to be used by whom. > > In case only two different tokens should be supported, two IDs > could be > assigned: One for the sender domain and one for the receiver > domain. I'm > not sure if more than two tokens are realistic. The only point is on who is assigning these IDs, avoiding duplicated IDs for different entities. Thanks Martin _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 26 09:11:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd4zg-0005dW-Bi; Thu, 26 Oct 2006 09:10:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd4zf-0005dM-FP for nsis@ietf.org; Thu, 26 Oct 2006 09:09:59 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd4za-0005gM-Fc for nsis@ietf.org; Thu, 26 Oct 2006 09:09:59 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k9QD9jrv027720 for ; Thu, 26 Oct 2006 14:09:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 26 Oct 2006 14:09:45 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: A question on GIST references Thread-Index: Acb40GBO2dwCNffpSSOWRH79x+iWyQALc5fQ From: "Hancock, Robert" To: X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [NSIS] A question on GIST references X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, in reviews of the GIST specification, a few people have questioned whether the framework (RFC4080) and threats (RFC4081) documents should be Informative (as they are now), or Normative. My feeling is that if people understand the GIST specification at a high level, then 4080/4081 will not change how they implement it. However, 4080 (especially) and 4081 do contain useful information about the context within which the protocol is expected to work, and so might be necessary for people to read to get off to the right start when reading the specification. The downside of making them normative (to me) is that as well as useful information, they contain information that is outdated (in terminology if nothing else). They are also Informational and therefore strictly can't be normative references in a Standards Track document (at least according to rfc3967). I suspect that what we really need is a third type of reference, 'Not Normative but still really useful background information', and that is the sort of thing that can be highlighted in the introduction. Alternatively, it costs very little effort to move these references into the Normative section if people think that is appropriate. Any further views appreciated (especially from IETF process experts), robert h. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 26 09:39:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd5S2-00019p-8s; Thu, 26 Oct 2006 09:39:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd5S0-00019k-Nk for nsis@ietf.org; Thu, 26 Oct 2006 09:39:16 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd5Rw-0003X5-7f for nsis@ietf.org; Thu, 26 Oct 2006 09:39:16 -0400 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1Gd5Rh-0004eD-Ev; Thu, 26 Oct 2006 15:38:59 +0200 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1Gd5Rh-0001jj-4L; Thu, 26 Oct 2006 15:38:57 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id A6DF6B5B7; Thu, 26 Oct 2006 15:38:56 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1Gd5Rg-0005bT-4e; Thu, 26 Oct 2006 15:38:56 +0200 Message-ID: <4540BA6F.1080609@tm.uka.de> Date: Thu, 26 Oct 2006 15:38:55 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Jukka MJ Manner , Georgios Karagiannis , Andrew McDonald X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.2 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: "nsis@ietf.org" Subject: [NSIS] QoS NSLP (draft-12) NOTIFY for reduced refreshes X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, though now the ACK flag is gone, there is still this very questionable mechanism: namely sending back a NOTIFY to indicate support for reduced refreshes. Maybe someone can enlighten me with the rationale for this. I don't get the point. IMHO if reduced refreshes are not supported, the QNE will respond with an error message "Full QSPEC required" anyway, so an explicit positive acknowledgment using NOTIFY is NOT NECESSARY. Furthermore, there is not really any good guidance what happens when this NOTIFY is missing (->what timeout?). Sec 5.4.1 says only that if the NOTIFY is missing one must use full refresh messages, but usually one could infer that from getting the corresponding error message (Transient 0x04). I even don't get the point why it would make sense then to keep setting the Q-bit in subsequent requests??? Pleeeaaase provide a little more rationale for this feature! Otherwise I propose to delete that feature (sending NOTIFY back if Q-bit is set), because we have a corresponding error message for this case. Regards, Roland P.S.: this was still on my list because no one answered this IIRC: http://www1.ietf.org/mail-archive/web/nsis/current/msg06128.html -------------------------------------------------------- Now the relevant sections from draft-12: 5.4.4. NOTIFY Messages A special case of synchronous NOTIFY is when the upstream QNE asked to use reduced refresh by setting the appropriate flag in the RESERVE. The QNE receiving such a RESERVE MUST reply with a NOTIFY and a proper INFO_SPEC code whether the QNE agrees to use reduced refresh between the upstream QNE. 3.2.5. Reduced Refreshes .... These reduced refreshes require an explicit acknowledgment to ensure that the RSN reference will be understood. It is up to a QNE that receives a message containing an special flag bit to decide whether it wants to accept reduced refreshes and provide this explicit acknowledgment. It sends a NOTIFY message as answer to the received RESERVE. 5.4.1. If a QNE has not received a NOTIFY confirming the use of reduced refreshes from its downstream peer for a session, the QNE MUST continue to use full refresh messages. It MAY add the Q-bit (Request Reduced Refrehses) in subsequent refresh messages in order to continue asking the downstream QNE to use reduced refrehes. ---------------------------------------------------------------------- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 26 09:57:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd5i8-00014J-U0; Thu, 26 Oct 2006 09:55:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd5hz-0000qy-On for nsis@ietf.org; Thu, 26 Oct 2006 09:55:47 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd5dS-0005yl-NS for nsis@ietf.org; Thu, 26 Oct 2006 09:51:11 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9QDp09U032639; Thu, 26 Oct 2006 16:51:05 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Oct 2006 16:51:05 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Oct 2006 16:51:04 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] A question on GIST references Date: Thu, 26 Oct 2006 16:51:04 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] A question on GIST references Thread-Index: Acb40GBO2dwCNffpSSOWRH79x+iWyQALc5fQAAHd7VA= From: To: , X-OriginalArrivalTime: 26 Oct 2006 13:51:04.0760 (UTC) FILETIME=[C7B94B80:01C6F905] X-Spam-Score: 0.2 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org They should be informational. That's the way things work. That doesn't mean you cannot put something like: 'Not Normative but still really useful background=20 information can be found in RFC4080. John >-----Original Message----- >From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk]=20 >Sent: 26 October, 2006 16:10 >To: nsis@ietf.org >Subject: [NSIS] A question on GIST references > >Hi all, > >in reviews of the GIST specification, a few people have=20 >questioned whether the framework (RFC4080) and threats=20 >(RFC4081) documents should be Informative (as they are now),=20 >or Normative. > >My feeling is that if people understand the GIST specification=20 >at a high level, then 4080/4081 will not change how they=20 >implement it. However, 4080 (especially) and 4081 do contain=20 >useful information about the context within which the protocol=20 >is expected to work, and so might be necessary for people to=20 >read to get off to the right start when reading the specification. > >The downside of making them normative (to me) is that as well=20 >as useful information, they contain information that is=20 >outdated (in terminology if nothing else). They are also=20 >Informational and therefore strictly can't be normative=20 >references in a Standards Track document (at least according=20 >to rfc3967). > >I suspect that what we really need is a third type of=20 >reference, 'Not Normative but still really useful background=20 >information', and that is the sort of thing that can be=20 >highlighted in the introduction. >Alternatively, it costs very little effort to move these=20 >references into the Normative section if people think that is=20 >appropriate. > >Any further views appreciated (especially from IETF process experts), > >robert h. > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 26 10:00:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd5lX-00035I-Pf; Thu, 26 Oct 2006 09:59:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd5iL-00012v-SB for nsis@ietf.org; Thu, 26 Oct 2006 09:56:10 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd5We-0004Xu-D9 for nsis@ietf.org; Thu, 26 Oct 2006 09:44:08 -0400 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1Gd5Wd-0005Uu-EH; Thu, 26 Oct 2006 15:44:03 +0200 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1Gd5Wc-0002TY-Ne; Thu, 26 Oct 2006 15:44:02 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 930C9B5B7; Thu, 26 Oct 2006 15:43:59 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1Gd5WZ-0005cM-9u; Thu, 26 Oct 2006 15:43:59 +0200 Message-ID: <4540BB9E.7070004@tm.uka.de> Date: Thu, 26 Oct 2006 15:43:58 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: "Hancock, Robert" Subject: Re: [NSIS] A question on GIST references References: In-Reply-To: X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.2 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert, Hancock, Robert wrote: > in reviews of the GIST specification, a few people have questioned > whether the framework (RFC4080) and threats (RFC4081) documents should > be Informative (as they are now), or Normative. > > My feeling is that if people understand the GIST specification at a high > level, then 4080/4081 will not change how they implement it. However, > 4080 (especially) and 4081 do contain useful information about the > context within which the protocol is expected to work, and so might be > necessary for people to read to get off to the right start when reading > the specification. I guess that you even can implement it correctly without having read 4080/4081. > The downside of making them normative (to me) is that as well as useful > information, they contain information that is outdated (in terminology > if nothing else). They are also Informational and therefore strictly > can't be normative references in a Standards Track document (at least > according to rfc3967). > > I suspect that what we really need is a third type of reference, 'Not > Normative but still really useful background information', and that is > the sort of thing that can be highlighted in the introduction. As far as I see it that would be a subtype of Informative. > Alternatively, it costs very little effort to move these references into > the Normative section if people think that is appropriate. Besides that fact that Informational RFC cannot be Normative refs, I guess that it would not be appropriate either. Maybe a hint in the introductory text to the references as background info would be enough. > Any further views appreciated (especially from IETF process experts), Cheers, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 26 10:41:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd6Pw-0003H2-QV; Thu, 26 Oct 2006 10:41:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd6Pu-00033n-QP for nsis@ietf.org; Thu, 26 Oct 2006 10:41:10 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd6Pn-0006GG-DL for nsis@ietf.org; Thu, 26 Oct 2006 10:41:10 -0400 Received: from lion.cs.columbia.edu (IDENT:Cd18R4wdz7TzTpC9TgyaMyF3pnE1+9dr@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k9QEcZ6G022829 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 26 Oct 2006 10:40:56 -0400 (EDT) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k9QEcYg7001943 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 26 Oct 2006 10:38:35 -0400 Message-ID: <4540C865.2080309@cs.columbia.edu> Date: Thu, 26 Oct 2006 10:38:29 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Roland Bless Subject: Re: [NSIS] A question on GIST references References: <4540BB9E.7070004@tm.uka.de> In-Reply-To: <4540BB9E.7070004@tm.uka.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, X-Seen-By filter2.cs.columbia.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: nsis@ietf.org, "Hancock, Robert" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org > > I guess that you even can implement it correctly without > having read 4080/4081. That would be my decision criteria. The problem with normative references is the whole downreferences thing - if GIST makes it to DS, all the other references would have to, too, although that clearly can't apply to informationals. Maybe somebody could take a look at recent protocol specs and see if requirements or framework-style documents were cited normatively. My gut feeling is that this makes no sense. Henning _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 26 10:45:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd6TZ-000466-90; Thu, 26 Oct 2006 10:44:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd6TY-000461-Qh for nsis@ietf.org; Thu, 26 Oct 2006 10:44:56 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd6TX-0006uD-CE for nsis@ietf.org; Thu, 26 Oct 2006 10:44:56 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id DBE6C1BAC4D; Thu, 26 Oct 2006 16:44:54 +0200 (CEST) In-Reply-To: <4540BB9E.7070004@tm.uka.de> References: <4540BB9E.7070004@tm.uka.de> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8CD25F6E-A661-4C01-A08A-95ED7C92FC33@netlab.nec.de> Content-Transfer-Encoding: 7bit From: Martin Stiemerling Subject: Re: [NSIS] A question on GIST references Date: Thu, 26 Oct 2006 16:44:53 +0200 To: Roland Bless X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: nsis@ietf.org, "Hancock, Robert" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Am 26.10.2006 um 15:43 schrieb Roland Bless: > Hi Robert, > > Hancock, Robert wrote: >> in reviews of the GIST specification, a few people have questioned >> whether the framework (RFC4080) and threats (RFC4081) documents >> should >> be Informative (as they are now), or Normative. >> >> My feeling is that if people understand the GIST specification at >> a high >> level, then 4080/4081 will not change how they implement it. However, >> 4080 (especially) and 4081 do contain useful information about the >> context within which the protocol is expected to work, and so >> might be >> necessary for people to read to get off to the right start when >> reading >> the specification. > > I guess that you even can implement it correctly without > having read 4080/4081. I see it in the same way. > >> The downside of making them normative (to me) is that as well as >> useful >> information, they contain information that is outdated (in >> terminology >> if nothing else). They are also Informational and therefore strictly >> can't be normative references in a Standards Track document (at least >> according to rfc3967). >> >> I suspect that what we really need is a third type of reference, 'Not >> Normative but still really useful background information', and >> that is >> the sort of thing that can be highlighted in the introduction. > > As far as I see it that would be a subtype of Informative. > >> Alternatively, it costs very little effort to move these >> references into >> the Normative section if people think that is appropriate. > > Besides that fact that Informational RFC cannot be Normative refs, > I guess that it would not be appropriate either. Maybe a hint in the > introductory text to the references as background info would be > enough. Informational RFCs can go into Normative References section, if these Informational RFCs are normative for the I-D. I see 4080/4081 being part of the Informative References, as they can help implementing GIST but it is not necessary to read them. Martin > >> Any further views appreciated (especially from IETF process experts), > > Cheers, > Roland > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 26 10:48:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd6Wn-0005Rw-TE; Thu, 26 Oct 2006 10:48:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd6Wn-0005Ro-1D for nsis@ietf.org; Thu, 26 Oct 2006 10:48:17 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd6Wf-0007SS-5W for nsis@ietf.org; Thu, 26 Oct 2006 10:48:17 -0400 Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Thu, 26 Oct 2006 17:48:02 +0300 id 000AFD06.4540CAA2.00004488 Date: Thu, 26 Oct 2006 17:48:02 +0300 (EEST) From: Jukka MJ Manner To: Roland Bless In-Reply-To: <4540BA6F.1080609@tm.uka.de> Message-ID: References: <4540BA6F.1080609@tm.uka.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: Andrew McDonald , Georgios Karagiannis , "nsis@ietf.org" Subject: [NSIS] Re: QoS NSLP (draft-12) NOTIFY for reduced refreshes X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Roland, If we expect that reduced refreshes would be the default way to refresh reservations, then we could formulate the spec as you say. Thus, a QNE would indicate with the Q-bit that it is going to use the default reduced refreshes, and the upstream QNE should only send a NOTIFY back if it doesn't support the reduced operation. Jukka On Thu, 26 Oct 2006, Roland Bless wrote: > Hi, > > though now the ACK flag is gone, there is still this very questionable > mechanism: namely sending back a NOTIFY to indicate support for reduced > refreshes. Maybe someone can enlighten me with the rationale for this. > I don't get the point. IMHO if reduced refreshes are not supported, > the QNE will respond with an error message "Full QSPEC required" > anyway, so an explicit positive acknowledgment using NOTIFY is > NOT NECESSARY. Furthermore, there is not really any good guidance > what happens when this NOTIFY is missing (->what timeout?). Sec 5.4.1 > says only that if the NOTIFY is missing one must use full refresh > messages, but usually one could infer that from getting the > corresponding error message (Transient 0x04). I even don't get > the point why it would make sense then to keep setting the > Q-bit in subsequent requests??? > > Pleeeaaase provide a little more rationale for this feature! > Otherwise I propose to delete that feature (sending NOTIFY back > if Q-bit is set), because we have a corresponding error message > for this case. > > Regards, > Roland > > P.S.: this was still on my list because no one answered this > IIRC: > http://www1.ietf.org/mail-archive/web/nsis/current/msg06128.html > > -------------------------------------------------------- > Now the relevant sections from draft-12: > > 5.4.4. NOTIFY Messages > A special case of synchronous NOTIFY is when the upstream QNE asked > to use reduced refresh by setting the appropriate flag in the > RESERVE. The QNE receiving such a RESERVE MUST reply with a NOTIFY > and a proper INFO_SPEC code whether the QNE agrees to use reduced > refresh between the upstream QNE. > > > 3.2.5. Reduced Refreshes > .... > > These reduced > refreshes require an explicit acknowledgment to ensure that the RSN > reference will be understood. It is up to a QNE that receives a > message containing an special flag bit to decide whether it wants to > accept reduced refreshes and provide this explicit acknowledgment. It > sends a NOTIFY message as answer to the received RESERVE. > > > 5.4.1. > If a QNE has not received a NOTIFY confirming the use of reduced > refreshes from its downstream peer for a session, the QNE MUST > continue to use full refresh messages. It MAY add the Q-bit (Request > Reduced Refrehses) in subsequent refresh messages in order to > continue asking the downstream QNE to use reduced refrehes. > ---------------------------------------------------------------------- > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 26 11:35:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd7GF-0002wF-GO; Thu, 26 Oct 2006 11:35:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd7GE-0002w9-Dq for nsis@ietf.org; Thu, 26 Oct 2006 11:35:14 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd7G9-000249-VH for nsis@ietf.org; Thu, 26 Oct 2006 11:35:14 -0400 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1Gd7G3-000678-5O; Thu, 26 Oct 2006 17:35:04 +0200 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1Gd7G2-00029p-6U; Thu, 26 Oct 2006 17:35:02 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 5EB6EB5B7; Thu, 26 Oct 2006 17:35:00 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1Gd7G0-0005hT-0d; Thu, 26 Oct 2006 17:35:00 +0200 Message-ID: <4540D5A3.9070801@tm.uka.de> Date: Thu, 26 Oct 2006 17:34:59 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Jukka MJ Manner Subject: Re: [NSIS] Re: QoS NSLP (draft-12) NOTIFY for reduced refreshes References: <4540BA6F.1080609@tm.uka.de> In-Reply-To: X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.2 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Andrew McDonald , Georgios Karagiannis , "nsis@ietf.org" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jukka, Jukka MJ Manner wrote: > If we expect that reduced refreshes would be the default way to refresh > reservations, then we could formulate the spec as you say. Thus, a QNE I always saw it like this: reduced refreshes are mandatory to support. If, for some reason, e.g. hitting a new node, a reduced refresh cannot be supported by a QNE it will simply send back this error message "full QSPEC required" and the upstream QNE must repeat the RESERVE with QSPEC. If this error occurs repeatedly with a node (why should that be the case? Avoiding to store the QSPEC?) for a session the QNE should keep sending full QSPECs instead of reduced ones (maybe someone could give a rationale/example for why reduced refreshes cannot be supported by a node in principle). > would indicate with the Q-bit that it is going to use the default reduced > refreshes, and the upstream QNE should only send a NOTIFY back if it I guess that Q-bit/NOTIFY stuff is intended be a somewhat "hidden negotiation" of a reduced refresh feature. However, I don't need a Q-bit to notice that the sender sent a reduced refresh. A QNE automatically determines that because the QSPEC is missing. > doesn't support the reduced operation. No, no, no. Don't send a NOTIFY back, simply send the error "full QSPEC required" back. Everything we need is already there! Why this strange NOTIFY? I only could imagine some more specific subtype for the full QSPEC required error: - full QSPEC required due to new session establishment - full QSPEC required because reduced refresh not supported (and as said above: what is the scenario for the latter error?) Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 26 13:07:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd8gt-0002hV-AY; Thu, 26 Oct 2006 13:06:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd8gr-0002hQ-OZ for nsis@ietf.org; Thu, 26 Oct 2006 13:06:49 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd8gn-0000RX-93 for nsis@ietf.org; Thu, 26 Oct 2006 13:06:49 -0400 Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Thu, 26 Oct 2006 20:06:42 +0300 id 000AFE0E.4540EB22.000009A7 Date: Thu, 26 Oct 2006 20:06:42 +0300 (EEST) From: Jukka MJ Manner To: Roland Bless Subject: Re: [NSIS] Re: QoS NSLP (draft-12) NOTIFY for reduced refreshes In-Reply-To: <4540D5A3.9070801@tm.uka.de> Message-ID: References: <4540BA6F.1080609@tm.uka.de> <4540D5A3.9070801@tm.uka.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Andrew McDonald , Georgios Karagiannis , "nsis@ietf.org" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, I basically follow your logic. Perhaps Andy or Georgios can comment why a reduced refresh would not be understood? About sending back a NOTIFY: that is how errors are sent. ;) A NOTIFY can include and INFO_SPEC telling about "Full QSPEC required", you can't send back an INFO_SPEC without a message header. :) Jukka On Thu, 26 Oct 2006, Roland Bless wrote: > Hi Jukka, > > Jukka MJ Manner wrote: > > If we expect that reduced refreshes would be the default way to refresh > > reservations, then we could formulate the spec as you say. Thus, a QNE > > I always saw it like this: reduced refreshes are mandatory to support. > If, for some reason, e.g. hitting a new node, a reduced refresh cannot > be supported by a QNE it will simply send back this error message > "full QSPEC required" and the upstream QNE must repeat the RESERVE > with QSPEC. If this error occurs repeatedly with a node (why should > that be the case? Avoiding to store the QSPEC?) for a session > the QNE should keep sending full QSPECs instead of reduced ones > (maybe someone could give a rationale/example for why reduced refreshes > cannot be supported by a node in principle). > > > would indicate with the Q-bit that it is going to use the default reduced > > refreshes, and the upstream QNE should only send a NOTIFY back if it > > I guess that Q-bit/NOTIFY stuff is intended be a somewhat "hidden > negotiation" of a reduced refresh feature. However, I don't > need a Q-bit to notice that the sender sent a reduced refresh. > A QNE automatically determines that because the QSPEC is missing. > > > doesn't support the reduced operation. > > No, no, no. Don't send a NOTIFY back, simply send the > error "full QSPEC required" back. Everything we need is > already there! Why this strange NOTIFY? > I only could imagine some more specific subtype for the > full QSPEC required error: > - full QSPEC required due to new session establishment > - full QSPEC required because reduced refresh not supported > (and as said above: what is the scenario for the latter error?) > > Regards, > Roland > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Oct 26 16:46:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdC6M-0001lk-Fx; Thu, 26 Oct 2006 16:45:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdBMu-0001yr-Sm; Thu, 26 Oct 2006 15:58:24 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdBEu-0007EJ-Rr; Thu, 26 Oct 2006 15:50:09 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id CAD0626E55; Thu, 26 Oct 2006 19:50:08 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GdBEu-0005LX-K6; Thu, 26 Oct 2006 15:50:08 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 26 Oct 2006 15:50:08 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-nslp-natfw-13.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : NAT/Firewall NSIS Signaling Layer Protocol (NSLP) Author(s) : M. Stiemerling, et al. Filename : draft-ietf-nsis-nslp-natfw-13.txt Pages : 101 Date : 2006-10-26 This memo defines the NSIS Signaling Layer Protocol (NSLP) for Network Address Translators (NATs) and firewalls. This NSLP allows hosts to signal on the data path for NATs and firewalls to be configured according to the needs of the application data flows. It enables hosts behind NATs to obtain a public reachable address and hosts behind firewalls to receive data traffic. The overall architecture is given by the framework and requirements defined by the Next Steps in Signaling (NSIS) working group. The network scenarios, the protocol itself, and examples for path-coupled signaling are given in this memo. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-13.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nsis-nslp-natfw-13.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nsis-nslp-natfw-13.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-10-26130023.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-nslp-natfw-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-nslp-natfw-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-26130023.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --NextPart-- From nsis-bounces@ietf.org Fri Oct 27 02:58:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdLej-0000jo-Rd; Fri, 27 Oct 2006 02:57:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdLei-0000ji-Fy for nsis@ietf.org; Fri, 27 Oct 2006 02:57:28 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdLeh-0005C5-7K for nsis@ietf.org; Fri, 27 Oct 2006 02:57:28 -0400 Received: from sbz-30.cs.helsinki.fi (sbz-30.cs.helsinki.fi [128.214.9.98]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Fri, 27 Oct 2006 09:57:24 +0300 id 000AFD47.4541ADD4.00007133 Date: Fri, 27 Oct 2006 09:57:24 +0300 (EEST) From: Jukka MJ Manner To: nsis@ietf.org Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [NSIS] NAT/FW & NATFW_CREDENTIAL X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi NAT/FW authors, The spec mentions a NATFW_CREDENTIAL object but does not say much about it. What for/how/where/when is it used? Is this actually what the AUTH_SESSION proposal is seeking to provide? Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Oct 27 03:17:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdLxb-0008QB-NF; Fri, 27 Oct 2006 03:16:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdLxa-0008Pz-BF for nsis@ietf.org; Fri, 27 Oct 2006 03:16:58 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdLxV-00015C-0c for nsis@ietf.org; Fri, 27 Oct 2006 03:16:58 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 64E901BAC4D; Fri, 27 Oct 2006 09:16:50 +0200 (CEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9B99BAC6-BD85-4B32-83D2-75BF8A3806CF@netlab.nec.de> Content-Transfer-Encoding: 7bit From: Martin Stiemerling Subject: Re: [NSIS] NAT/FW & NATFW_CREDENTIAL Date: Fri, 27 Oct 2006 09:16:47 +0200 To: Jukka MJ Manner X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jukka, The NATFW_CREDENTIAL object has been removed from the spec (-13) in favour of the AUTH_SESSION object. However, I have just seen that at two places it still says NATFW_CREDENTIAL (IANA considerations and Appendix D. "Assigned Numbers for Testing"). I have already fixes this: http://www.stiemerling.org/ietf/nsis/snapshot/ Martin Am 27.10.2006 um 08:57 schrieb Jukka MJ Manner: > > Hi NAT/FW authors, > > The spec mentions a NATFW_CREDENTIAL object but does not say much > about > it. What for/how/where/when is it used? Is this actually what the > AUTH_SESSION proposal is seeking to provide? > > Jukka > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Oct 27 03:19:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdLz3-0000Lk-Jk; Fri, 27 Oct 2006 03:18:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdLz2-0000Lb-5F for nsis@ietf.org; Fri, 27 Oct 2006 03:18:28 -0400 Received: from moutng.kundenserver.de ([212.227.126.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdLz0-0001Tb-OZ for nsis@ietf.org; Fri, 27 Oct 2006 03:18:28 -0400 Received: from [84.163.56.29] (helo=alanis.mafr.de) by mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis), id 0MKwh2-1GdLyy3aMd-0001LN; Fri, 27 Oct 2006 09:18:25 +0200 Received: by alanis.mafr.de (Postfix, from userid 1000) id 3641C5E84CE; Fri, 27 Oct 2006 09:18:04 +0200 (CEST) Date: Fri, 27 Oct 2006 09:18:04 +0200 From: Matthias Friedrich To: nsis@ietf.org Subject: Re: [NSIS] NAT/FW & NATFW_CREDENTIAL Message-ID: <20061027071803.GA8677@mafr.de> Mail-Followup-To: nsis@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 X-Provags-ID: kundenserver.de abuse@kundenserver.de login:b369618fd1a3462119ba5a921f6f235b X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org On Friday, 2006-10-27, Jukka MJ Manner wrote: > The spec mentions a NATFW_CREDENTIAL object but does not say much about > it. What for/how/where/when is it used? Is this actually what the > AUTH_SESSION proposal is seeking to provide? That reminds me: Although the NATFW_CREDENTIAL has been removed from draft revision 13 (posted today), it is still referenced two times in the spec. Regards, Matthias _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Oct 27 03:24:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdM3n-0005q5-Gl; Fri, 27 Oct 2006 03:23:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdM3m-0005px-Du for nsis@ietf.org; Fri, 27 Oct 2006 03:23:22 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdM3i-00035P-SL for nsis@ietf.org; Fri, 27 Oct 2006 03:23:22 -0400 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1GdM3Y-0004O1-9A; Fri, 27 Oct 2006 09:23:11 +0200 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1GdM3X-0000kQ-UE; Fri, 27 Oct 2006 09:23:07 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 74FD7B505; Fri, 27 Oct 2006 09:23:07 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1GdM3X-0006wd-2o; Fri, 27 Oct 2006 09:23:07 +0200 Message-ID: <4541B3DA.3030801@tm.uka.de> Date: Fri, 27 Oct 2006 09:23:06 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Jukka MJ Manner Subject: Re: [NSIS] Re: QoS NSLP (draft-12) NOTIFY for reduced refreshes References: <4540BA6F.1080609@tm.uka.de> <4540D5A3.9070801@tm.uka.de> In-Reply-To: X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.2 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Andrew McDonald , Georgios Karagiannis , "nsis@ietf.org" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jukka, Jukka MJ Manner wrote: > I basically follow your logic. Perhaps Andy or Georgios can comment why a > reduced refresh would not be understood? Good. > About sending back a NOTIFY: that is how errors are sent. ;) A NOTIFY can > include and INFO_SPEC telling about "Full QSPEC required", you can't send > back an INFO_SPEC without a message header. :) And I thought it must be a RESPONSE with an INFO_SPEC. That would be the more natural way to indicate an error (NOTIFY is usually asynchronous whereas failed RESERVES or QUERIES should generate a RESPONSE containing an error description in the INFO_SPEC). Regards, Roland > Jukka > > On Thu, 26 Oct 2006, Roland Bless wrote: > >> Hi Jukka, >> >> Jukka MJ Manner wrote: >>> If we expect that reduced refreshes would be the default way to refresh >>> reservations, then we could formulate the spec as you say. Thus, a QNE >> I always saw it like this: reduced refreshes are mandatory to support. >> If, for some reason, e.g. hitting a new node, a reduced refresh cannot >> be supported by a QNE it will simply send back this error message >> "full QSPEC required" and the upstream QNE must repeat the RESERVE >> with QSPEC. If this error occurs repeatedly with a node (why should >> that be the case? Avoiding to store the QSPEC?) for a session >> the QNE should keep sending full QSPECs instead of reduced ones >> (maybe someone could give a rationale/example for why reduced refreshes >> cannot be supported by a node in principle). >> >>> would indicate with the Q-bit that it is going to use the default reduced >>> refreshes, and the upstream QNE should only send a NOTIFY back if it >> I guess that Q-bit/NOTIFY stuff is intended be a somewhat "hidden >> negotiation" of a reduced refresh feature. However, I don't >> need a Q-bit to notice that the sender sent a reduced refresh. >> A QNE automatically determines that because the QSPEC is missing. >> >>> doesn't support the reduced operation. >> No, no, no. Don't send a NOTIFY back, simply send the >> error "full QSPEC required" back. Everything we need is >> already there! Why this strange NOTIFY? >> I only could imagine some more specific subtype for the >> full QSPEC required error: >> - full QSPEC required due to new session establishment >> - full QSPEC required because reduced refresh not supported >> (and as said above: what is the scenario for the latter error?) _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Oct 27 04:24:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdN0M-0005IZ-Ig; Fri, 27 Oct 2006 04:23:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdN0L-0005IP-FH for nsis@ietf.org; Fri, 27 Oct 2006 04:23:53 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdN0K-0008ER-4S for nsis@ietf.org; Fri, 27 Oct 2006 04:23:53 -0400 Received: from sbz-30.cs.helsinki.fi (sbz-30.cs.helsinki.fi [128.214.9.98]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Fri, 27 Oct 2006 11:23:51 +0300 id 000AFD31.4541C217.00000C98 Date: Fri, 27 Oct 2006 11:23:51 +0300 (EEST) From: Jukka MJ Manner To: Martin Stiemerling Subject: Re: [NSIS] NATFW NSLP: Result of the REANCO Voting In-Reply-To: Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Obviously, I'm very happy with the result. The contest was hard, but fair, and I want to thank my fellow competitors for the challenge. The team did a fantastic job, obviously. This is a great achievement for years of hard work. :P Jukka On Wed, 25 Oct 2006, Martin Stiemerling wrote: > Dear all, > > The REA Naming Contest (REANCO) has ended. In total, I have received 4 votes. > The votes were > > a) one > e) two > j) one > > So proposal e) did make it, i.e., EXT (for playing with the external address > and opening firewall > holes for external data senders (incoming streams)). You can already find the > new name in the submitted draft -13. > > e) has been proposed by Jukka Manner. > > Congratulations to Jukka and the beer is ready for you! > > Thanks, > > Martin > > > Here is the list of all proposals received as reference: > > a) Open Internal Path (OIP) message > b) Configure Internal Path (CIP) message > c) Prepare For Ucreate (PFU) message (where UCREATE is actually now REA) > d) Internal Network Configuration (INC) message > e) EXT (for playing with the external address and opening firewall > holes for external data senders (incoming streams)) > f) Open Path Interactive (OPI) message > g) Open Interactive Path (OIP) message > h) Path Opening Interactive (POI) message > i) Interactive Path Opening (IPO) message > j) CREATE -> ICREATE (Initiator CREATE); REA -> RCREATE (Responder > CREATE) > k) CREATE -> SCREATE (Sender CREATE); REA -> RCREATE (Receiver CREATE) > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Oct 27 06:47:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdPEd-0005el-Qi; Fri, 27 Oct 2006 06:46:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdPEc-0005ef-94 for nsis@ietf.org; Fri, 27 Oct 2006 06:46:46 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdPEa-0008Vp-Pu for nsis@ietf.org; Fri, 27 Oct 2006 06:46:46 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k9RAkOsw009153; Fri, 27 Oct 2006 11:46:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] GIST issue - PATH MTU v4/v6 Date: Fri, 27 Oct 2006 11:46:24 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] GIST issue - PATH MTU v4/v6 Thread-Index: AcbzlUevLAnThmOwTgmxjUT3woZifwGH9Rig From: "Hancock, Robert" To: "Roland Bless" X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi, i've updated both the issue and the resolution with a note that the limit applies to both v4 and v6. cheers, robert h. > -----Original Message----- > From: Roland Bless [mailto:bless@tm.uka.de]=20 > Sent: 19 October 2006 16:42 > To: Hancock, Robert > Cc: nsis@ietf.org > Subject: Re: [NSIS] GIST issue - PATH MTU v4/v6 >=20 >=20 > Hi Robert, >=20 > Robert Hancock wrote: > > if you are interested in MTU issues, you might in any case like to=20 > > check the revised text at=20 > > http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue124 > > (this is following up Lar's DISCUSS comments). > >=20 > > on the v4/v6 question, i'd rather not distinguish between the two: > >=20 > > - i don't know how it would cope with some transition=20 > mechanisms (you=20 > > could still get fragmentation) >=20 > Hmm, this might be a problem... >=20 > > - we know 512 is fine for v4 or v6 (if it isn't we are in trouble) >=20 > Yep. However, it would be good to also state this explicitly > so that v6 implementations follow the same max size as with=20 > v4, e.g. "...value 512 bytes as a default (also for IPv6). " > > - if you know you are in a homogeneous v6 network, you know=20 > the larger=20 > > PMTU anyway as 1280 so that case is covered in the new text. >=20 > Regards, > Roland >=20 >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Oct 27 07:01:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdPRn-0003od-8K; Fri, 27 Oct 2006 07:00:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdPRl-0003jE-TV for nsis@ietf.org; Fri, 27 Oct 2006 07:00:21 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdPRh-0002ms-II for nsis@ietf.org; Fri, 27 Oct 2006 07:00:21 -0400 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1GdPRf-00078G-4y; Fri, 27 Oct 2006 13:00:16 +0200 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1GdPRe-0000Fi-G8; Fri, 27 Oct 2006 13:00:14 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 5308DB581; Fri, 27 Oct 2006 13:00:13 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1GdPRd-00075Q-35; Fri, 27 Oct 2006 13:00:13 +0200 Message-ID: <4541E6BC.3020307@tm.uka.de> Date: Fri, 27 Oct 2006 13:00:12 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: "Hancock, Robert" Subject: Re: [NSIS] GIST issue - PATH MTU v4/v6 References: In-Reply-To: X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.2 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: "nsis@ietf.org" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert, Hancock, Robert wrote: > i've updated both the issue and the resolution with a note that > the limit applies to both v4 and v6. Ok, that's fine for me. Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Oct 27 08:16:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdQcO-0008TN-UJ; Fri, 27 Oct 2006 08:15:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdQcN-0008T6-MU for nsis@ietf.org; Fri, 27 Oct 2006 08:15:23 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdQcJ-0002NF-1e for nsis@ietf.org; Fri, 27 Oct 2006 08:15:23 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 828671BAC4D for ; Fri, 27 Oct 2006 14:15:18 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v752.2) References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Martin Stiemerling Date: Fri, 27 Oct 2006 14:15:16 +0200 To: nsis X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.2 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Subject: [NSIS] Fwd: Update to Internet-Draft and RFC Boilerplate X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org FYI, in the case you haven't seen it anyway. Martin Anfang der weitergeleiteten E-Mail: > Von: IETF Chair > Datum: 27. Oktober 2006 03:19:59 MESZ > An: IETF Announcement list > Betreff: Update to Internet-Draft and RFC Boilerplate > > A small update to BCP 78 was recently approved by the IESG as > RFC 4748, to update the boilerplate (i.e., standard legal text) in > RFCs and Internet-Drafts to recognize the IETF Trust as a rights > holder, instead of ISOC. > > The actual boilerplate changes are given below this message. > > Starting as soon as reasonably possible, all authors of Internet- > Drafts > are requested to use the new boilerplate. The RFC Editor will in > any case > be inserting it in all RFCs issued from 2006-11-01. (The rights > held by > ISOC in older RFCs will be administratively transferred to the IETF > Trust.) > > The public ID Nits checker already accepts I-Ds with old or new > boilerplate. > The Secretariat has started accepting I-Ds with old or new boilerplate > > XML2RFC version 1.32 will generate the new boilerplate. > Users of I-D templates are requested to update them appropriately. > > http://www.ietf.org/ID-Checklist.html and > http://www.ietf.org/ietf/1id-guidelines.html are being updated. > > Starting December, the public ID Nits checker will issue warnings for > old boilerplate. > > Starting February 2007, the Secretariat will refuse > the old boilerplate in Internet-Drafts. > > We are sorry for the inconvenience, but this change cannot > be avoided. > > IETF Chair > IETF Secretariat > TOOLS Team > > -------- > > Copyright Notice (required for all IETF Documents) > > (Normally placed at the end of the IETF Document.) > > NOTE: by convention, the first line of the copyright statement > is usually placed near the beginning of each document. This must > also be updated. > > OLD > "Copyright (C) The Internet Society (year). > > This document is subject to the rights, licenses and > restrictions > contained in BCP 78, and except as set forth therein, the > authors > retain all their rights. > > NEW > "Copyright (C) The IETF Trust (year). > > This document is subject to the rights, licenses and > restrictions > contained in BCP 78, and except as set forth therein, the > authors > retain all their rights. > > > Disclaimer (required in all IETF Documents) > > (Normally placed at the end of the IETF Document after the > copyright > notice.) > > > OLD > "This document and the information contained herein are provided > on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE > REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND > THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, > EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY > THAT > THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY > RIGHTS OR > ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A > PARTICULAR PURPOSE." > > > NEW > "This document and the information contained herein are provided > on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE > REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, > THE > IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL > WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY > WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT > INFRINGE > ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR > FITNESS > FOR A PARTICULAR PURPOSE." > > Exceptions > > In MIB modules, PIB modules and similar material commonly > extracted from IETF Documents, except for material that is being > placed under IANA maintenance, the following abbreviated notice > shall be included in the body of the material that will be > extracted in lieu of the notices otherwise required by > Section 5: > > OLD > "Copyright (C) The Internet Society . This version of > this MIB module is part of RFC XXXX; see the RFC itself for > full legal notices." > > NEW > "Copyright (C) The IETF Trust . This version of > this MIB module is part of RFC XXXX; see the RFC itself for > full legal notices." > > When the MIB or PIB module is the initial version of a module > that > is to be maintained by the IANA, the following abbreviated > notice > shall be included: > > OLD > "Copyright (C) The Internet Society . The initial > version of this MIB module was published in RFC XXXX; for > full > legal notices see the RFC itself. Supplementary information > may be available at: > http://www.ietf.org/copyrights/ianamib.html." > > NEW > "Copyright (C) The IETF Trust . The initial > version of this MIB module was published in RFC XXXX; for > full > legal notices see the RFC itself. Supplementary information > may be available at: > http://www.ietf.org/copyrights/ianamib.html." > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Oct 27 10:15:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdSTf-0000Hl-6f; Fri, 27 Oct 2006 10:14:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdSTd-0000Em-QW for nsis@ietf.org; Fri, 27 Oct 2006 10:14:29 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdSTa-00017z-93 for nsis@ietf.org; Fri, 27 Oct 2006 10:14:29 -0400 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1GdSTT-0003zL-Le; Fri, 27 Oct 2006 16:14:21 +0200 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1GdSTT-00042M-Au; Fri, 27 Oct 2006 16:14:19 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id B53ABB57F; Fri, 27 Oct 2006 16:14:18 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1GdSTS-0007NN-Em; Fri, 27 Oct 2006 16:14:18 +0200 Message-ID: <45421439.6070204@tm.uka.de> Date: Fri, 27 Oct 2006 16:14:17 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Andrew McDonald Subject: Re: [NSIS] Re: I-D ACTION:draft-mcdonald-nsis-router-alert-iana-00.txt References: <453C90D7.6040007@roke.co.uk> In-Reply-To: <453C90D7.6040007@roke.co.uk> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.2 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: "Nsis \(E-mail\)" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Andrew, Andrew McDonald wrote: > Following on from previous discussion we had on the topic (going back to > the Dallas meeting and before) I wrote a short draft on IANA management > of Router Alert Option Values. > > Currently, the QoS and NAT/FW NSLPs (as suggested by GIST) request > allocation of RAO values. However, there isn't an IPv4 registry to > manage them. So, if we want to be able to use values other than the > default value (i.e. 0 = router shall examine packet), I believe we need > to sort out the Router Alert IANA issues. > > The draft also considers possible ways of aligning the RAO value usage > for IPv4 and IPv6. The draft doesn't attempt to discuss when you > should/shouldn't use router alert, or should/shouldn't get a new RAO > value, though those might be things worth including. > > Read, comment, tear to shreds, etc Great that you wrote that down. Now it's clear where the problems are. I guess that we probably need more feedback, esp. from vendors and operators, about the current deployment of these RAO values. If not they are currently not really in wide use, then reassignment may not be a big problem. Otherwise we must try tro preserve some backwards compatability. So bringing the draft to the attention of a wider community should be considered IMHO. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 30 05:03:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeTys-0005ru-6P; Mon, 30 Oct 2006 05:02:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeTyd-0005ka-PC for nsis@ietf.org; Mon, 30 Oct 2006 05:02:43 -0500 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeTxP-0007Qp-37 for nsis@ietf.org; Mon, 30 Oct 2006 05:01:28 -0500 Received: from S4DE8PSAAGT.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Mon, 30 Oct 2006 10:52:38 +0100 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by S4DE8PSAAGT.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Oct 2006 10:52:38 +0100 Content-class: urn:content-classes:message Subject: RE: [NSIS] Proposal to move the QSPEC work forward MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 30 Oct 2006 10:52:37 +0100 Message-Id: <6439282641581441A36F7F6F83ED2ED2CBF8FF@S4DE8PSAAFQ.mitte.t-com.de> X-MimeOLE: Produced By Microsoft Exchange V6.5 in-reply-to: <25A762D7-AB90-44B6-8A0D-98F9AFCB225D@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Proposal to move the QSPEC work forward Thread-Index: AcbzlS5Rk73nWpv0RvyeZF/mOb3E1gIcL9JQ From: "Geib, Ruediger" To: X-OriginalArrivalTime: 30 Oct 2006 09:52:38.0342 (UTC) FILETIME=[22162660:01C6FC09] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Dave, My question was about admission control in environments=20 where statistical multiplexing is not possible.=20 |If you have a VBR flow with short term bursts (which can exceed peak =20 |over small time scales) the burst size in the traffic description =20 |tells you how much burst buffering you have to set aside to=20 |avoid drops. That means you must set aside a buffer space of number of=20 VBR sources * burst size to avoid losses (assume purely VBR sources).=20 Additionally you'd control the sum of the peak rates. I so far expected the burst size to define the maximimum burst=20 at a defined rate, not at an undefined one - so thanks for=20 your explanation. The 4 parameters proposed by you make sense then (assuming that most=20 reservations pass also a network sections where multiplexing is=20 applied). Regards, Rudiger =20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 30 07:12:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeW05-0003wE-Sd; Mon, 30 Oct 2006 07:12:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeW04-0003w2-2M for nsis@ietf.org; Mon, 30 Oct 2006 07:12:20 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeW02-00032I-Mc for nsis@ietf.org; Mon, 30 Oct 2006 07:12:20 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 30 Oct 2006 04:12:18 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9UCCHZj014498; Mon, 30 Oct 2006 04:12:17 -0800 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k9UCCHOV029826; Mon, 30 Oct 2006 04:12:17 -0800 (PST) Received: from [10.67.119.139] (rtp-vpn4-215.cisco.com [10.82.208.215]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k9UBxXxb010797; Mon, 30 Oct 2006 03:59:33 -0800 In-Reply-To: <6439282641581441A36F7F6F83ED2ED2CBF8FF@S4DE8PSAAFQ.mitte.t-com.de> References: <6439282641581441A36F7F6F83ED2ED2CBF8FF@S4DE8PSAAFQ.mitte.t-com.de> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <47235017-4D71-41B1-A9B4-CCF15A58F48F@cisco.com> Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [NSIS] Proposal to move the QSPEC work forward Date: Mon, 30 Oct 2006 07:12:05 -0500 To: "Geib, Ruediger" X-Mailer: Apple Mail (2.752.2) Authentication-Results: sj-dkim-5.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=1829; t=1162210338; x=1163074338; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:David=20R=20Oran=20 |Subject:Re=3A=20[NSIS]=20Proposal=20to=20move=20the=20QSPEC=20work=20forward; X=v=3Dcisco.com=3B=20h=3DnjGkRzfeaTz56ILMnMysXHoWo1Y=3D; b=GharvlYD2h5H4ZUD0QNeoFTZnzX/KJCmRXmjdX1qRtLBkAoILIyqExYdq5iTXRBznywaHeD4 RFugz3so5rU1MHHE6ntsecjtrFEI+maJcgKV69XBwpEDSArz1eRevIoA; X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org On Oct 30, 2006, at 4:52 AM, Geib, Ruediger wrote: > Dave, > > My question was about admission control in environments > where statistical multiplexing is not possible. > OK. > |If you have a VBR flow with short term bursts (which can exceed peak > |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 > |tells you how much burst buffering you have to set aside to > |avoid drops. > correct, but this is not directly related to the peak rate, it's related to the short-term packet generation process. > That means you must set aside a buffer space of number of > 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. > 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. > Correct. > The 4 parameters proposed by you make sense then (assuming that most > reservations pass also a network sections where multiplexing is > applied). > 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. > Regards, > > Rudiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Oct 30 07:48:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeWYT-0003QB-I7; Mon, 30 Oct 2006 07:47:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeWYM-0003Q0-80 for nsis@ietf.org; Mon, 30 Oct 2006 07:47:46 -0500 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeWYK-0008Bn-RV for nsis@ietf.org; Mon, 30 Oct 2006 07:47:46 -0500 Received: from S4DE8PSAAGT.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Mon, 30 Oct 2006 13:47:43 +0100 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by S4DE8PSAAGT.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Oct 2006 13:47:43 +0100 Content-class: urn:content-classes:message Subject: RE: [NSIS] Proposal to move the QSPEC work forward MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 30 Oct 2006 13:47:42 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-Id: <6439282641581441A36F7F6F83ED2ED2CBF90B@S4DE8PSAAFQ.mitte.t-com.de> in-reply-to: <47235017-4D71-41B1-A9B4-CCF15A58F48F@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Proposal to move the QSPEC work forward Thread-Index: Acb8Hc4hQe42iWo2R+m+pznF5x50sAAADuxw From: "Geib, Ruediger" To: X-OriginalArrivalTime: 30 Oct 2006 12:47:43.0327 (UTC) FILETIME=[978BA6F0:01C6FC21] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Dave, ummm, I've quoted your first response to my mail below. When you=20 are asking "did you mean", the addressed "you" is Dave Oran.=20 D> |If you have a VBR flow with short term bursts (which can=20 |> |exceed peak over small time scales) D|By definition, a "peak" rate is a rate you never exceed...did you =20 |mean "which can exceed average rate...over small time scales" So far I also thought that the peak rate is never exceeded. You=20 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.=20 The buffer should be dimensioned to avoid losses by random=20 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 =20 |fundamentals of dealing with such kinds of traffic optimally. Admission Control for On-Off sources with a session context (RSVP,=20 NSIS or any other) may be performed by peak rate reservation if=20 multiplexing is impossible. =20 If difficult here means, that the "average rate" of a flow can't be calculated for admission control in environments allowing=20 multiplexing gains, because the average rate is unknown prior=20 to the call, then measurement based admission control may=20 offer a solution. An example may be a phone conversation with=20 silence suppression.=20 Regards, Rudiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 31 10:19:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GevNb-0005m5-3i; Tue, 31 Oct 2006 10:18:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GevNY-0005kg-S3 for nsis@ietf.org; Tue, 31 Oct 2006 10:18:17 -0500 Received: from tart.dcs.qmul.ac.uk ([138.37.95.139] helo=mail.dcs.qmul.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GevNT-0005yH-Ac for nsis@ietf.org; Tue, 31 Oct 2006 10:18:16 -0500 Received: from hst138-37-90-32.dcs.qmul.ac.uk ([138.37.90.32] helo=[127.0.0.1]) by mail.dcs.qmul.ac.uk with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.62) (envelope-from ) id 1GevNP-00022O-3C; Tue, 31 Oct 2006 15:18:07 +0000 Message-ID: <45476930.3020304@dcs.qmul.ac.uk> Date: Tue, 31 Oct 2006 15:18:08 +0000 From: Jian Zhang Organization: Queen Mary, Univ. of London User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: nsis@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCS-Auth-User: jianzhang X-DCS-Whoson-User: jianzhang X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: edmundo@dei.uc.pt, karagian@cs.utwente.nl, mendes@docomolab-euro.com Subject: [NSIS] The version 3 of the InterDomain-QOSM Draft: the NSIS QOS Model to Fulfill the E2E QoS Control in the ITU-T RACF Functional Architecture X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jian.zhang@dcs.qmul.ac.uk List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Dear all, Please kindly read the version 3 of the InterDomain-QOSM Draft: our effort to define a NSIS QOS Model to fulfill the E2E QoS control in the ITU-T RACF functional architecture, which has been submitted to the NSIS WG for discussion at the coming IETF meeting. And if you have any questions or suggestions about this draft, we would like to answer or discuss with you in this mailing list. The abstract of this draft is attached below and the link which holds the whole contents of the draft is also provided below. Cheers, Jian Zhang Dept. of Computer Science Queen Mary, Univ. of London --------------------------------------- Abstract This document has three goals. First of all, it presents our analysis of how to use the NSIS signaling (inter-domain QOSM and intra-domain QOSM) to fulfill the QoS control in accord with the ITU-T RACF functional architecture. For this goal, we discuss how the ITU-T RACF entities in the ITU-T RACF functional architecture can be mapped to the NSIS entities and how the RACF reference points can be implemented by using the NSIS protocol suites and QOSMs. Secondly, we aim at specifying an NSIS Inter-domain QOSM for E2E QoS control across heterogeneous IP networks and applying this Inter-domain QOSM to the e2e QoS control in the ITU-T RACF functional architecture based on the above ITU-T RACF analysis. The detailed description of the NSIS Inter-domain QOSM are given and the e2e QoS control scenarios in the ITU-T RACF architecture (including RACF Push and Pull resource control modes), which will be covered by the NSIS Inter-domain QOSM are described and implemented. Thirdly, we specify and implement those QSPECs that will be used by the Inter-domain QOSM for the e2e QoS control in the ITU-T RACF architecture. The link is http://ietfreport.isoc.org/ids/draft-zhang-nsis-interdomain-qosm-03.txt . _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 31 12:20:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GexGs-00061v-Nq; Tue, 31 Oct 2006 12:19:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GexGq-0005po-Ox for nsis@ietf.org; Tue, 31 Oct 2006 12:19:28 -0500 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GexGn-0004l7-8v for nsis@ietf.org; Tue, 31 Oct 2006 12:19:28 -0500 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k9VHIxZV001515; Tue, 31 Oct 2006 17:18:59 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 31 Oct 2006 17:18:59 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MA-Hello request/response processing (was: RE: GIST MA Keep-alive/Liveliness) Thread-Index: Acb0Vz+v10mgyEfXQKGS9tCKWoif9QItoalQ From: "Hancock, Robert" To: "Roland Bless" X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: nsis@ietf.org Subject: [NSIS] MA-Hello request/response processing (was: RE: GIST MA Keep-alive/Liveliness) X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi roland, Some good questions. I think the facility is useful (see below) and so we need to keep it, but a small protocol change is=20 needed to make it work properly. I've implemented a version of this change for the next version of the draft, but since it is a protocol change, other people might like to review it as well. [snipped stuff that will be answered in another thread] >=20 > Another one: > Currently, requesting a reply to an MA-Hello has > the effect of getting an MA-Hello back (hopefully). > However, there is no action taken if that MA-Hello > response is missing. The Draft currently says: >=20 > The R flag MAY be set > (R=3D1); if so, the peer MUST send another message back along the > messaging association. This allows a node to test the liveness of > the peer. >=20 > If the latter statement was true, then some action would be=20 > taken if such a response is missing. Currently, receiving=20 > MA-Hellos (or not) has no effect in the "Connected" state=20 > (for R=3D0), so we really don't care about getting an answer.=20 > Probably it makes sense to do the following: Introduce=20 > another NULL-message called MA-Hello-Response (with R=3D0)=20 > which must be send as response to an MA-Hello with R=3D1. We=20 > then could start a timer and go to "Death" if the solicited=20 > MA-Hello-Response is still missing after that period.=20 Basically I think that since it is up to the originating node to decide whether to make such a liveness test, we don't need to be totally prescriptive about how to go about it. After all, a conformant node can just decide never to do such a test in the first place. What I think does need to be stated is that you can use the MA-Hello to test liveness and Die if the test fails. Text is added in 6.4 to say just that. > Currently, we cannot decide whether we got a response or=20 > whether it was just a regularly emitted MA-Hello that=20 > arrived; maybe we don't care, because we heard something from=20 > the other side, but on the other hand if only our sending=20 > direction went down we would not notice.=20 This is the crucial point. I've proposed adding a Hello-ID to the MA-Hello message. It is set to a non-zero value in request (R=3D1) messages, and echoed in any reply; otherwise it is set to zero. Note that replies must have R=3D0. No-one ever has to generate R=3D1 messages, but if you get one you=20 have to send a response with R=3D0 including the Hello-ID. (I think this meets the matching requirement safely.) > If all of the above=20 > doesn't make sense, I would like to remove the R=3D1 feature=20 > for MA-Hellos, because it has no real usefull effect anyway. I think of it as a diagnostic. You don't have to invoke it, but it is useful to define normatively how peers will respond to it. At the moment, it's a simple way to check that the GIST layer at the peer is still functioning without having to send some made-up data (which might interact with an=20 NSLP). It might even be used mainly by user tools (a GIST ping). It can also be used to test the whether outstanding=20 messages have been delivered to the other end of an MA, which can be useful in some circumstances. The currently proposed text is in the issue tracker at http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue157 cheers, robert h. >=20 > Regards, > Roland >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 31 12:36:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GexWQ-0006Li-3J; Tue, 31 Oct 2006 12:35:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GexWO-0006Ld-8K for nsis@ietf.org; Tue, 31 Oct 2006 12:35:32 -0500 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GexWK-0002Db-HC for nsis@ietf.org; Tue, 31 Oct 2006 12:35:32 -0500 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k9VHZCuH004970; Tue, 31 Oct 2006 17:35:12 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] GIST issue on MA-Hold-Time Date: Tue, 31 Oct 2006 17:35:12 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] GIST issue on MA-Hold-Time Thread-Index: AcbxOczk+P0mrC8TS9OHL/zVWOo4nwL2EGmw From: "Hancock, Robert" To: "Roland Bless" X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Cc: nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Roland, there have been questions about exactly when and how to send the confirm, and when and how to include the hold time value. The details and proposals for how to fix them are in the=20 tracker at=20 http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue156 you might like to take a look. Some more detailed comments in line below. r. > -----Original Message----- > From: Roland Bless [mailto:bless@tm.uka.de]=20 > Sent: 16 October 2006 16:43 > To: Hancock, Robert > Cc: nsis > Subject: Re: [NSIS] GIST issue on MA-Hold-Time >=20 >=20 > Hi Robert and all, >=20 > Hancock, Robert wrote: > > An issue has been raised on MA-Hold-Time negotiation. It is in > > the tracker as issue #131 > >=20 > (http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue131) > > and the summary text is included below. > > =20 > > This is a solicitation for input, especially from the=20 > implementors, on=20 > > this matter. In the absence of input, my preference would=20 > be to leave=20 > > to spec unchanged, but if people feel that this level of=20 > flexibility=20 > > is necessary please speak up and say so. It would be very=20 > good to see=20 > > change/no change comments either way. >=20 > I'm not really sure whether it's indeed required to have an=20 > own MA-Hold-Time per protocol. On the one hand the=20 > negotiation is already complex enough, on the other hand it=20 > would be more consistent to provide it per proposal.=20 > Currently, I would vote for no change. At the moment I have done nothing. >=20 > However, I have more issues that came up with the=20 > MA-Hold-Time during the interop test: > * What does an MA-Hold-Time of 0 mean (keep open forever)? Reserved. Added text to say this. (This and the next point are actually covered under a different issue, = http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue131) > * Should very small values, e.g., below one or several seconds > be always ignored and forced to be set to a predefined lower bound? > (In order to avoid a flooding with MA-Hellos) I am not sure how to do this in an interoperable way without=20 quite a bit of extra complexity (some more message rounds). I'd prefer just to emphasise that it's silly to use small values. Any text suggestions? > * The MA-Hold-Time must be repeated in the first Confirm message > due to the need for having this value available even if late > state installation is used. > =3D> What should be done if the MA-Hold-Time is missing? > Sending back an Object-Type error with mandatory object missing is > probably the right thing to do. Done. > Furthermore, the specification in 5.1 of the Confirm message > is confusing in this respect and should be clarified. > Confirm =3D Common-Header > Message-Routing-Information > Session-Identification > Network-Layer-Information > [ Responder-Cookie > [ Stack-Proposal > [ Stack-Configuration-Data ] ] ] > [ NSLP-Data ] > While the example in fig.4 sheds more lighty on how it is > intended, one would think that Stack-Proposal _and_ SCD > of the Responder are repeated in the Confirm (so I guess > nesting with brackets must be fixed). Therefore, > clarification is needed that only the R-Node SP is repeated > (w/o R-Node SCD) > and the Q-Node SCD with MA-Hold-Time is mandatory in the > very first Confirm.=20 I think that the ABNF is correct here; the real problem is that ABNF is not a good syntax for handling 'conditionally mandatory' information elements. More discussion is in the issue tracker. Also, I don't really want to qualify which SP is included=20 (since this makes the ABNF harder to validate). Hopefully the new text before the ABNF in 5.1 makes this clearer. > Thus, also the MAY on top of p. 30 > (sec 4.4.1) should be a MUST. Done. Cheers, robert h. >=20 > Regards, > Roland >=20 > > [Following Routing Area Directorate comments from Adrian Farrel] > >=20 > > At the moment, the MA-Hold-Time in a proposal applies to=20 > all possible=20 > > configurations of the messaging association. There is no way to=20 > > indicate that (for example) one would prefer 30 seconds for=20 > TCP, but=20 > > 120 seconds for TLS/SCTP. > >=20 > > In principle, different hold time possibilities could be=20 > indicated in=20 > > the Query, but this would require some changes in the=20 > Stack-Proposal=20 > > or Stack-Configuration-Data objects. The SCD syntax does=20 > not allow one=20 > > to specify a > > value which applies to a whole proposal, only to a MA-protocol in a > > proposal; > > the SP syntax does not allow one to specify MA-Hold-Time at all. One > > option > > would be to tag the MA-Hold-Time value in the SCD so that=20 > there was a > > single > > value (tagged 0) possibly overridden by alternative values for > > particular > > proposals (rather like we do for the other protocol=20 > options). The SCD > > would get > > another count field in the header, and we could steal a=20 > byte from the > > MA-Hold-Time field for the tag. > >=20 > > However, it is not clear whether the value of this sophistication=20 > > outweighs the cost. The policy for choosing an MA-Hold-Time=20 > presumably=20 > > is a tradeoff between 3 > > variables: > > a) the extent to which an MA is being used or is going to be used > > b) the cost of keeping the MA open (in stored protocol=20 > state inside the > > protocols that make up the MA itself) > > c) the cost of re-setting up the MA if it is needed again > > Of these, (a) is totally independent of the protocol=20 > configuration, (b) > > is > > weakly dependent on it, and (c) is definitely dependent on=20 > it. But the > > strength > > of the dependence is not that great. If you just chose the largest > > hold-time > > value for all possible MA configurations and used that as the single > > value in > > the negotiation, the net affect would not be much different=20 > from what > > could be > > achieved with a more granular mechanism. > >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > >=20 >=20 >=20 > --=20 > Dr. Roland Bless -- WWW: http://www.tm.uka.de/~bless > Institut f=FCr Telematik, Universit=E4t Karlsruhe (TH), Germany=20 > Zirkel 2, D-76128 Karlsruhe -- Geb. 20.20, 3.OG, Raum 358 > Tel.: +49 721 608-6413 Fax: +49 721 608-6789 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Oct 31 13:01:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GexuT-0005Oq-RL; Tue, 31 Oct 2006 13:00:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GexuR-0005Fy-Ly for nsis@ietf.org; Tue, 31 Oct 2006 13:00:23 -0500 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GexrT-0007hj-8O for nsis@ietf.org; Tue, 31 Oct 2006 12:57:20 -0500 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k9VHtxlh009451; Tue, 31 Oct 2006 17:55:59 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 31 Oct 2006 17:55:59 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: GIST MA Keep-alive/Liveliness Thread-Index: Acb0UYIiU9gSkMJzTbuuO+si9N9HdQIwy/Iw From: "Hancock, Robert" To: "Roland Bless" X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: nsis@ietf.org Subject: [NSIS] RE: GIST MA Keep-alive/Liveliness X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Roland, I think the basic problem here is that the state machine is over prescriptive about the Connected -> Idle transition. The intention has always been Connected: I want it; I don't care if my peer wants it, but I will send MA-Hellos if necessary to stop my peer from dropping it Idle: I no longer want it, but so long as my peer keeps=20 sending me MA-Hellos I will not drop it So the distinction between Connected and Idle is one of whether I want the MA or not, and that has to be mainly a question of local policy. Indeed, that is what the text in 4.4.3 says. The current 6.4 implies that this transition is purely timer driven, which then raises all sorts of extra questions about what if the timer-driven transitions do something stupid (like put the MA into a state where it may be torn down even though there are=20 still NSLP states using it). Therefore, my proposed resolution is to be open that the Connected -> Idle transition is triggered by policy, and that the policy may be timer driven but could also (clearly) take anything else into account. In particular, the NoActivity timer disappears, and there is just a tg_MAIdle event. I think that should answer most of the questions below. It does so at the cost of providing some more implementation freedom; however, I think that freedom was always necessary anyway (and I don't believe the change affects interoperability). The discussion and proposed text is in the tracker at http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue131 cheers & happy reading ;-) robert h. > -----Original Message----- > From: Roland Bless [mailto:bless@tm.uka.de]=20 > Sent: 20 October 2006 15:10 > To: Hancock, Robert > Cc: nsis@ietf.org > Subject: GIST MA Keep-alive/Liveliness >=20 >=20 > Hi Robert, >=20 > After trying to understand the exact semantics of the=20 > mechanism described in section 6.4 I found it somewhat=20 > confusing with all the different timers (NoActivity/NoHello)=20 > and trying to match what should be actually achieved by the=20 > state machine in Fig. 8. I guess that this needs more=20 > motivation and clarification. Some statements are confusing=20 > and IMHO a short paragraph about the overall goals of this=20 > concept is missing. What are we trying to achieve with this=20 > mechanism? Is it just a keep-alive or is it failure=20 > detection, or both? However, just in order to keep the=20 > connection open after the last message was sent or received,=20 > MA-Hellos are not necessary (see below). >=20 > Let me try to summarize: > Each peer has an MA-Hold-Time which is exchanged at session=20 > setup. So I would expect that the other side keeps the=20 > connection at least until this period has passed after the=20 > last message was exchanged. Thus if I want to keep the=20 > connection beyond the other side's MA-Hold-Time but have=20 > nothing else to send, I should sent an MA-Hello to the other=20 > side. So far so good, that is pretty clear. >=20 > Now the situation is like this: > Instead of using the maximum of both hold-times and then > both going to death, the peer with an internal NoActivity > timer period greater than the other peers MA-Hold-Time > has to send MA-Hellos to the other peer in order to keep > the connection open. Thus, the real internal timeout policy > is actually determined by the NoActivity timer period > (and which must be >=3D own-MA-Hold-Time (=3DNoHello Timer=20 > period)). Let's say we choose NoHello=3DNoActivity=3Down-MA-Hold-Time. > Then each side will keep sending MA-Hellos until the=20 > own-MA-Hold-Time expired. Then both go to IDLE and after a=20 > further NoHello timeout to death. Thus each side will really=20 > close down after NoActivity+own-MA-Hold-Time (so this is the=20 > _real_ MA-Hold-Time). >=20 > So now the questions (maybe I'm puzzled, because both > functions are mixed together right now): > 1.) if we only want to keep the connection open, it > would probably be sufficient to use the minimum > proposed MA-Hold-Time as timeout without sending > any MA-Hellos around. If the connection broke due > to a failure of the peer, this would have been > probably noticed and indicated by the transport > layer. If not, we need a liveliness test. >=20 > 2.) if this is meant to be also a liveliness check > mechanism, I would appreciate more reasoning > for having a NoActivity timeout which may be different > than NoHello. The statement: > "The period of this timer is implementation-specific but > is likely to be related to the period of the NoHello timer." > is too fuzzy. Why isn't NoActivity=3D=3DNoHello reasonable? > If not we probably should rename MA-Hold-Time and NoActivity... > The current use of MA-Hold-Time in the initial handshake > is more or less the notification when the > MA-Hellos should be send and not how long the > connection is really available. This is confusing... >=20 > However, I'm missing a rationale and a clear description > of the objectives that this should achieve. >=20 > One more thing: > A default time of 30s for an MA-Hold-Time would probably=20 > require to send refreshing RESERVEs by QoS NSLP before that=20 > time in order to avoid close down and re-setup of the connection. >=20 > Regards, > Roland >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis