From nsis-bounces@ietf.org Mon Sep 04 06:09:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKBNn-0004qX-1n; Mon, 04 Sep 2006 06:08:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKBNk-0004qE-5e; Mon, 04 Sep 2006 06:08:44 -0400 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKBNc-0002Ke-VJ; Mon, 04 Sep 2006 06:08:44 -0400 Received: from i2kc07-ukbr.domain1.systemhost.net ([193.113.197.14]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Sep 2006 11:08:35 +0100 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by i2kc07-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 4 Sep 2006 11:08:34 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 4 Sep 2006 11:08:33 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5A2CC6D@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN (Pre-Congestion Notification) draft charter Thread-Index: AcbQAYi9xsMdnywQQdS0KTufbV8hRgAAEQDw From: To: , , , X-OriginalArrivalTime: 04 Sep 2006 10:08:34.0335 (UTC) FILETIME=[14C51AF0:01C6D00A] X-Spam-Score: 0.5 (/) X-Scan-Signature: 3adba28c47054ea827843deea22a7215 Cc: Subject: [NSIS] FW: [PCN] PCN (Pre-Congestion Notification) draft charter X-BeenThere: nsis@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="===============0768464239==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0768464239== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6D00A.1463B16D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6D00A.1463B16D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Copy for info, as think this PCN (pre-congestion notification) work is relevant to your WG. =20 Please send replies to the PCN mailing list, pcn@ietf.org - you can subscribe at http://www1.ietf.org/mailman/listinfo/pcn =20 thanks.=20 -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: 04 September 2006 10:07 To: pcn@ietf.org Subject: [PCN] PCN (Pre-Congestion Notification) draft charter =20 We are hoping to organize a BOF on PCN (pre-congestion notification) at the next IETF. Some of us have now put together a first draft of a Charter - below. We'd very much appreciate your comments and suggestions - for instance: is the scope right? Is the range of deployment models ok? Is it a reasonable set of milestones and are the timescales ok? =20 We're now working on a Problem Statement draft.=20 =20 Thanks. =20 =20 PCN Draft Charter (Pre-Congestion Notification) =20 The PCN BOF (WG) will tackle the problem of how to provide scalable, resilient admission control and strong QoS assurance while using packet marking techniques. Current attempts to deliver QoS using only packet marking (e.g. DiffServ) are limited in the level of QoS assurance that can be provided without substantial over-provisioning. To improve the QoS assurance, PCN will add flow admission control and flow pre-emption. In normal circumstances admission control should protect the QoS of previously admitted flows. In times of heavy congestion (for example caused by route changes due to link or router failure) pre-emption of some flows should preserve the QoS of remaining flows. =20 The initial scope of the BOF (WG) is the use of PCN within a single DiffServ region. The overall approach will be based on a separation of functionality between the interior routers and edge nodes of the DiffServ region. Interior routers mark packet headers when their traffic is above a certain level, as an early warning of incipient congestion ("pre-congestion"); this builds on concepts from RFC 3168 "The Addition of Explicit Congestion Notification to IP". Edge nodes of the DiffServ Region monitor the markings and that information is used to make flow admission control and pre-emption decisions. The decisions could be made by the edge nodes or by a centralised system (which is informed of the edge nodes' measurements).=20 =20 The WG will address the following specific problems and develop standards track solutions to them: * When should an interior router mark a packet (i.e. at what traffic level) in order to give early warning of its own congestion? * How should such a mark be encoded in a packet (in the ECN and/or DSCP fields)? * How should these markings (at packet granularity) be converted into admission control and flow pre-emption decisions (at flow granularity)? =20 To support this, the WG will work on the following Informational documents: * a Problem Statement, to describe the problems the group is tackling and the assumptions made * at least two deployment models, initially to help focus the problem statement and later to check that the solutions being developed satisfy the deployment scenario. Possible deployment models may be:=20 o IntServ over DiffServ (RFC2998): the DiffServ region is PCN-enabled and its edge nodes decide about admission and flow pre-emption o SIP-controlled PCN: routers within the DiffServ region are PCN-capable and trusted SIP endpoints (gateway or host) perform admission and flow pre-emption =20 o Pseudowire: PCN may be used as a congestion avoidance mechanism for end-user deployed pseudowires (collaborate with the PWE3 WG) * a generic analysis of the signalling extensions required to support PCN. Note that extensions/enhancements to specific signalling protocols (e.g. RSVP, NSIS, SIP) will not be done in the PCN WG. * at least one example solution implementing the framework and its performance evaluation (e.g. simulation results), to provide evidence of the viability of the proposed standard in the proposed deployment models * an analysis of the tradeoffs of different encoding possibilities (e.g. ECN and DCSP marking) =20 The initial scope of the WG will restrict the problem space in the following ways: * By assuming the PCN-enabled Internet Region is a controlled environment, i.e. all the interior routers and edge nodes of the region run PCN and trust each other * By assuming there are many flows on any bottleneck link in the PCN-enabled region=20 * By focusing on the QoS assurance required by real time applications generating inelastic traffic like voice and video requiring low delay, jitter and packet loss, i.e. as defined by the Controlled Load Service [RFC2211].=20 =20 Subsequent re-chartering may investigate solutions for when some of these restrictions are not in place.=20 =20 Topics out of scope for the WG include a general investigation of admission control mechanisms. =20 The WG will draw on the substantial prior academic and IETF work on measurement-based admission control.=20 =20 Milestones Nov 2006 initial Problem statement Nov 2006 initial deployment models March 2007 initial router marking behaviour (including encoding) March 2007 initial flow admission control and pre-emption mechanism (including edge node measurements) March/July 2007 submit Problem statement March/July 2007 submit deployment models Nov 2007 submit router marking behaviour Nov 2007/Mar 2008 submit flow admission control and pre-emption mechanism Nov 2007 initial signalling analysis Mar 2008 re-charter or close =20 =20 Philip Eardley Networks Researcher BT Group=20 =20 Phone: +44 (0)1473 645938 Fax : +44 (0)1473 640929 Email: philip.eardley@bt.com =20 BT MeetMe: +44 (0)870 241 2994=20 Passcode: 16851189# =20 BT Group plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England and Wales no. 4190816 This electronic message contains information from BT Group plc which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. Activity and use of the BT Group plc E-mail system is monitored to secure its effective operation and for other lawful business purposes. Communications using this system will also be monitored and may be recorded to secure effective operation and for other lawful business purposes.=20 =20 ------_=_NextPart_001_01C6D00A.1463B16D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Copy for info, as think this = PCN (pre-congestion notification) work is relevant to your WG.

 

Please send replies to the PCN = mailing list, pcn@ietf.org  - you can = subscribe at

http://www1.ietf.org/m= ailman/listinfo/pcn

 

thanks.

-----Original Message-----
From: = philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: 04 September 2006 10:07
To: pcn@ietf.org
Subject: [PCN] PCN = (Pre-Congestion Notification) draft charter

 

We are hoping to organize a BOF on PCN = (pre-congestion notification) at the next IETF. Some of us have now put together a first = draft of a Charter - below. We’d very much appreciate your comments and suggestions – for instance: is the scope right? Is the range of = deployment models ok? Is it a reasonable set of milestones and are the timescales = ok?

 

We’re now working on a Problem Statement draft. =

 

Thanks.

 

 

PCN Draft Charter (Pre-Congestion = Notification)

 

The PCN BOF (WG) will tackle the problem of = how to provide scalable, resilient admission control and strong QoS assurance = while using packet marking techniques. Current attempts to deliver QoS using = only packet marking (e.g. DiffServ) are limited in the level of QoS assurance = that can be provided without substantial over-provisioning. To improve the = QoS assurance, PCN will add flow admission control and flow pre-emption. In = normal circumstances admission control should protect the QoS of previously = admitted flows. In times of heavy congestion (for example caused by route changes = due to link or router failure) pre-emption of some flows should preserve the = QoS of remaining flows.

 

The initial scope of the BOF (WG) is the use = of PCN within a single DiffServ region. The overall approach will be based on a separation of functionality between the interior routers and edge nodes = of the DiffServ region. Interior routers mark packet headers when their traffic = is above a certain level, as an early warning of incipient congestion (“pre-congestion”); this builds on concepts from RFC 3168 = "The Addition of Explicit Congestion Notification to IP". Edge nodes of = the DiffServ Region monitor the markings and that information is used to = make flow admission control and pre-emption decisions. The decisions could be made = by the edge nodes or by a centralised system (which is informed of the edge nodes’ measurements).

 

The WG will address the following specific = problems and develop standards track solutions to them:

·           =           When should an interior router mark a packet = (i.e. at what traffic level) in order to give early warning of its own = congestion?

·           =           How should such a mark be encoded in a packet = (in the ECN and/or DSCP fields)?

·           =           How should these markings (at packet = granularity) be converted into admission control and flow pre-emption decisions (at flow granularity)?

 

To support this, the WG will work on the = following Informational documents:

·           =           a Problem Statement, to describe the problems = the group is tackling and the assumptions made

·           =           at least two deployment models, initially to = help focus the problem statement and later to check that the solutions being developed satisfy the deployment scenario. Possible deployment models = may be:

o        IntServ over DiffServ (RFC2998): the DiffServ = region is PCN-enabled and its edge nodes decide about admission and flow = pre-emption

o        SIP-controlled PCN: routers within the = DiffServ region are PCN-capable and trusted SIP endpoints (gateway or host) = perform admission and flow pre-emption  

o        Pseudowire: PCN may be used as a congestion avoidance mechanism for end-user deployed pseudowires (collaborate with = the PWE3 WG)

·           =            a generic analysis of the signalling extensions required to support PCN. Note that extensions/enhancements to specific signalling protocols (e.g. RSVP, NSIS, SIP) will not be done in = the PCN WG.

·           =           at least one example solution implementing = the framework and its performance evaluation (e.g. simulation results), to = provide evidence of the viability of the proposed standard in the proposed = deployment models

·           =           an analysis of the tradeoffs of different = encoding possibilities (e.g. ECN and DCSP marking)

 

The initial scope of the WG will restrict the problem space in the following ways:

·           =           By assuming the PCN-enabled Internet Region = is a controlled environment, i.e. all the interior routers and edge nodes of = the region run PCN and trust each other

·           =           By assuming there are many flows on any = bottleneck link in the PCN-enabled region

·           =           By focusing on the QoS assurance required by = real time applications generating inelastic traffic like voice and video = requiring low delay, jitter and packet loss, i.e. as defined by the Controlled = Load  Service = [RFC2211].

 

Subsequent re-chartering may investigate = solutions for when some of these restrictions are not in place.

 

Topics out of scope for the WG include a = general investigation of admission control mechanisms.

 

The WG will draw on the substantial prior = academic and IETF work on measurement-based admission control.

 

Milestones

Nov 2006          initial Problem = statement

Nov 2006          initial deployment = models

March 2007  =       initial router marking behaviour (including encoding)

March 2007  =       initial flow admission control and pre-emption mechanism (including edge = node measurements)

March/July 2007   submit Problem = statement

March/July 2007   submit deployment = models

Nov 2007          submit router marking = behaviour

Nov 2007/Mar 2008 submit flow admission = control and pre-emption mechanism

Nov 2007          initial signalling = analysis

Mar 2008          re-charter or close

 

 

= Philip Eardley

Networks Researcher

BT Group

 

Phone:        =       +44 (0)1473 645938

Fax :                 +44 (0)1473 = 640929

Email:        =        philip.eardley@bt.com

BT MeetMe:      +44 (0)870 241 = 2994

Passcode:       &nb= sp; 16851189#

 

BT Group plc
Registered office: 81 = Newgate Street = London EC1A 7AJ
Registered in = England and Wales no. 4190816   This electronic message contains = information from BT Group plc which may be privileged or confidential. The = information is intended to be for the use of the individual(s) or entity named above. = If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. = If you have received this electronic message in error, please notify us by = telephone or email (to the numbers or address above) immediately. Activity and use = of the BT Group plc E-mail system is monitored to secure its effective = operation and for other lawful business purposes. Communications using this system = will also be monitored and may be recorded to secure effective operation and for = other lawful business purposes.

 

=00 ------_=_NextPart_001_01C6D00A.1463B16D-- --===============0768464239== 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 --===============0768464239==-- From nsis-bounces@ietf.org Wed Sep 06 06:09:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKuKc-0006Vh-11; Wed, 06 Sep 2006 06:08:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKuKZ-0006VZ-Rz; Wed, 06 Sep 2006 06:08:27 -0400 Received: from mail.dcu.ie ([136.206.1.5] helo=hawk.dcu.ie) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKuKX-0008R6-HL; Wed, 06 Sep 2006 06:08:27 -0400 Received: from zoing (136.206.225.89) by hawk.dcu.ie (7.2.075) id 44D10F8B002C6093; Wed, 6 Sep 2006 11:08:16 +0100 From: =?iso-8859-1?Q?Lu=EDs_Cordeiro?= To: , Date: Wed, 6 Sep 2006 11:08:22 +0100 Message-ID: <016101c6d19c$62b0dfe0$59e1ce88@zoing> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcbRnGJmSBCpSVdgSLioZvWWUzrtNQ== X-Spam-Score: 0.1 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: Subject: [NSIS] NSIS Interoperability Meeting X-BeenThere: nsis@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="===============0947279212==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0947279212== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0162_01C6D1A4.C47547E0" This is a multi-part message in MIME format. ------=_NextPart_000_0162_01C6D1A4.C47547E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, =20 As discussed in the last IETF meeting, I would like to propose a NSIS Interoperability Event in Coimbra, Portugal. I propose the following two days: 12 and 13 of October. If you think more time is needed please = inform me. =20 Please provide me your availability until 12 of September so we can have time to arrange everything. =20 BR, Lu=EDs Cordeiro ------=_NextPart_000_0162_01C6D1A4.C47547E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,

 

As discussed in the last IETF meeting, I would = like to propose a NSIS Interoperability Event in Coimbra, Portugal. I propose the following two days: 12 and 13 of October. If you think = more time is needed please inform me.

 

Please provide me your availability until 12 = of September so we can have time to arrange everything.

 

BR,

Lu=EDs Cordeiro

------=_NextPart_000_0162_01C6D1A4.C47547E0-- --===============0947279212== 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 --===============0947279212==-- From nsis-bounces@ietf.org Fri Sep 08 08:50:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLfnm-0003FT-7s; Fri, 08 Sep 2006 08:49:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLfnk-0003CO-GQ; Fri, 08 Sep 2006 08:49:44 -0400 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLfnj-0007iQ-7b; Fri, 08 Sep 2006 08:49:44 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1GLfnX-0003rz-RW; Fri, 08 Sep 2006 14:49:38 +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 CFB568701; Fri, 8 Sep 2006 14:49:30 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1GLfnW-0005gA-DZ; Fri, 08 Sep 2006 14:49:30 +0200 Message-ID: <450166D9.1010409@tm.uka.de> Date: Fri, 08 Sep 2006 14:49:29 +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: =?ISO-8859-1?Q?Lu=EDs_Cordeiro?= References: <016101c6d19c$62b0dfe0$59e1ce88@zoing> In-Reply-To: <016101c6d19c$62b0dfe0$59e1ce88@zoing> X-Enigmail-Version: 0.94.0.0 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: d6b246023072368de71562c0ab503126 Cc: nsis-imp@ietf.org, nsis@ietf.org Subject: [NSIS] Re: [Nsis-imp] NSIS Interoperability Meeting X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.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 Luis, Luís Cordeiro schrieb: > As discussed in the last IETF meeting, I would like to propose a NSIS > Interoperability Event in Coimbra, Portugal. I propose the following two > days: 12 and 13 of October. If you think more time is needed please inform > me. > That could work for us. > Please provide me your availability until 12 of September so we can have > time to arrange everything. I'll try to do so. Best regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Sep 08 09:44:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLgdg-0008Aq-8h; Fri, 08 Sep 2006 09:43:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLgdf-0008Al-57 for nsis@ietf.org; Fri, 08 Sep 2006 09:43:23 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLgdU-0006RT-ML for nsis@ietf.org; Fri, 08 Sep 2006 09:43:23 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D77BD4F00EA for ; Fri, 8 Sep 2006 15:43:05 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Sep 2006 15:43:05 +0200 Received: from [153.88.14.32] ([153.88.14.32]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Sep 2006 15:43:04 +0200 Message-ID: <45017369.9030502@ericsson.com> Date: Fri, 08 Sep 2006 15:43:05 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: NSIS Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Sep 2006 13:43:04.0899 (UTC) FILETIME=[B5E05130:01C6D34C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [NSIS] Volunteers to be IANA expert reviewer for 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 Hi, GIST (draft-ietf-nsis-ntlp) specifies some IANA managed registries where the policy is expert review. The expert will review any registration requests in those registries (and value ranges) that are under this policy to ensure that requests are following the rules for these registries and are sensible. It important that the expert reviewer can perform these requests in a timely manner. For more information on the role of IANA designated experts, see RFC 2434. So if you have the necessary skills for this role and are interested in volunteering please send me an email before the 25th of September. 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 Sep 11 04:16:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMgwc-0007O9-Fz; Mon, 11 Sep 2006 04:15:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMgwa-0007MC-Dr for nsis@ietf.org; Mon, 11 Sep 2006 04:15:04 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMgwZ-0004W2-0M for nsis@ietf.org; Mon, 11 Sep 2006 04:15:04 -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.7) with ESMTP id k8B8Ev83020163 for ; Mon, 11 Sep 2006 11:14:59 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Sep 2006 11:14:35 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Sep 2006 11:14: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 Date: Mon, 11 Sep 2006 11:14:33 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: QoS NSLP update Thread-Index: AcbVdoPVs2kbDn3gRYCPuFo0LeDT1AAA8bHA From: To: X-OriginalArrivalTime: 11 Sep 2006 08:14:35.0200 (UTC) FILETIME=[51382C00:01C6D57A] X-Spam-Score: 0.2 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [NSIS] QoS NSLP update X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.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 are 6 open issues on the NSIS QoS NSLP. We need to resolve these. If we don't have any comments by Friday, I will ask Jukka to update the document and will send the document to the IESG. thanks, John Open issues are found here: http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-qos-nslp-issues/ _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Sep 11 06:57:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMjT0-00009q-Kn; Mon, 11 Sep 2006 06:56:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMjSz-00008R-7d for nsis@ietf.org; Mon, 11 Sep 2006 06:56:41 -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 1GMjSv-0006PN-SB for nsis@ietf.org; Mon, 11 Sep 2006 06:56:41 -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, 11 Sep 2006 13:56:32 +0300 id 0008D14F.450540E0.000075C6 Date: Mon, 11 Sep 2006 13:56:31 +0300 (EEST) From: Jukka MJ Manner To: nsis@ietf.org Subject: Re: [NSIS] QoS NSLP update 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: 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 Hi all, Basically we are only missing a few clarifications here and there, and a re-write of the IANA Considerations section. Then we are done. My current version "12-pre2", and a diff can be found at: http://www.cs.helsinki.fi/u/jmanner/qos-nslp/ The two major changes done were the new so-called Proxy Mode, and the QoS NSLP now provides a bit to tell whether all nodes on the path supported the reservation, or not, e.g., some nodes might have been totally NSIS unaware. Jukka On Mon, 11 Sep 2006 john.loughney@nokia.com wrote: > Hi all, > > There are 6 open issues on the NSIS QoS NSLP. We need to resolve these. > If we don't have any comments by Friday, I will ask Jukka to update the > document and will send the document to the IESG. > > thanks, > John > > Open issues are found here: > > http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-qos-nslp-issues/ > > _______________________________________________ > 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 Sep 12 08:49:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GN7gs-0004TD-W6; Tue, 12 Sep 2006 08:48:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GN7gs-0004T8-3J for nsis@ietf.org; Tue, 12 Sep 2006 08:48:38 -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 1GN7gq-00005o-Lm for nsis@ietf.org; Tue, 12 Sep 2006 08:48:38 -0400 Received: from Bea (87-196-87-251.net.novis.pt [87.196.87.251]) by smtp2.dei.uc.pt (8.13.6/8.13.6) with ESMTP id k8CCmOAS021865 for ; Tue, 12 Sep 2006 13:48:24 +0100 From: "Marilia Curado" To: Date: Tue, 12 Sep 2006 13:48:01 +0100 Organization: University of Coimbra Message-ID: <00bc01c6d669$b1e01280$6602a8c0@Bea> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcbWaZrv3qXioeU/TvaeDstMamB4MA== 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=-0.553, required 3, BAYES_00 -2.60, RCVD_IN_SORBS_DUL 2.05) X-FCTUC-DEI-SIC-MailScanner-From: marilia@dei.uc.pt X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [NSIS] NSIS Interoperability Meeting in Coimbra X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: marilia@dei.uc.pt List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Dear all, As expressed by the message Luis Cordeiro sent in the beginning of September, we are organizing a NSIS Interoperability Event in Coimbra, Portugal on the 12 and 13 of October. If you are interested in participating, please send me your confirmation until 15 of September. Please contact me for any details about the Interop, since Luis Cordeiro will be on vacations until the end of September. Looking forward to welcome you in Coimbra, Marilia Curado _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Sep 14 09:56:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNrhC-0001R8-Dq; Thu, 14 Sep 2006 09:56:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNrhA-0001R3-Tq for nsis@ietf.org; Thu, 14 Sep 2006 09:56:00 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNrh0-0001Kc-DV for nsis@ietf.org; Thu, 14 Sep 2006 09:56:00 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A48218E0002; Thu, 14 Sep 2006 15:54:38 +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, 14 Sep 2006 15:54:38 +0200 Received: from esealmw116.eemea.ericsson.se ([153.88.200.7]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Sep 2006 15:54: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: RE: [NSIS] NSIS Interoperability Meeting in Coimbra Date: Thu, 14 Sep 2006 15:54:37 +0200 Message-ID: In-Reply-To: <00bc01c6d669$b1e01280$6602a8c0@Bea> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] NSIS Interoperability Meeting in Coimbra Thread-Index: AcbWaZrv3qXioeU/TvaeDstMamB4MABm0fUg From: =?iso-8859-1?Q?Ferenc_Pint=E9r_=28IJ/ETH=29?= To: X-OriginalArrivalTime: 14 Sep 2006 13:54:38.0020 (UTC) FILETIME=[517CB040:01C6D805] X-Brightmail-Tracker: AAAAAA== 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 all, We are interested in interop testing our QoS-NSLP implementation, the date is ok. Ferenc Pint=E9r -----Original Message----- From: Marilia Curado [mailto:marilia@dei.uc.pt]=20 Sent: Tuesday, September 12, 2006 2:48 PM To: nsis@ietf.org Subject: [NSIS] NSIS Interoperability Meeting in Coimbra Dear all, As expressed by the message Luis Cordeiro sent in the beginning of = September, we are organizing a NSIS Interoperability Event in Coimbra, = Portugal on the 12 and 13 of October. If you are interested in participating, please send me your confirmation = until 15 of September. Please contact me for any details about the = Interop, since Luis Cordeiro will be on vacations until the end of = September. Looking forward to welcome you in Coimbra, Marilia Curado =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 Fri Sep 15 09:05:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GODNJ-0002lo-AB; Fri, 15 Sep 2006 09:04:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GODNH-0002lg-81 for nsis@ietf.org; Fri, 15 Sep 2006 09:04:55 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GODNG-0002E1-Ff for nsis@ietf.org; Fri, 15 Sep 2006 09:04:55 -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 k8FD4ro6019862; Fri, 15 Sep 2006 16:04:53 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Sep 2006 16:04:53 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Sep 2006 16:04:53 +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: Fri, 15 Sep 2006 16:04:53 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Lars Eggert: DISCUSS and COMMENT: draft-ietf-nsis-ntlp Thread-Index: AcbWYkEJ2uY5e1g0QhuauV7a79ZpvgCZSBJg From: To: , X-OriginalArrivalTime: 15 Sep 2006 13:04:53.0431 (UTC) FILETIME=[88F24C70:01C6D8C7] X-Spam-Score: 0.2 (/) X-Scan-Signature: 8d89ee9312a95de8ee48d1c94511f1bb Cc: Subject: [NSIS] Lars Eggert: DISCUSS and COMMENT: draft-ietf-nsis-ntlp X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Here's a DISCUSS and comment from Lars about GIST. Robert is traveling, but it would be good to discuss this in the WG to find out ways to address=20 his DISCUSS. John=20 >-----Original Message----- >From: ext Lars Eggert [mailto:lars.eggert@netlab.nec.de]=20 >Sent: 12 September, 2006 14:54 >To: iesg@ietf.org >Cc: nsis-chairs@tools.ietf.org; robert.hancock@roke.co.uk;=20 >hgs+nsis@cs.columbia.edu >Subject: DISCUSS and COMMENT: draft-ietf-nsis-ntlp=20 > >Discuss: > DISCUSS: For anything sent over UDP, i.e., D- and Q-mode, it must be > made clear that messages must have payloads smaller than the PMTU > (minus headers) or 512 bytes if the PMTU is unknown, to avoid > fragmentation. (Section 5.4.1 and 5.8.1.2 do so, but other=20 >sections do > not.) Because some messages MUST be transmitted in D- or Q-mode, are > such messages guaranteed to be less than this limit in all cases? > Furthermore, a suitable rate control mechanism for the use with UDP > must also be described. The token bucket in section 5.3.3 is > insufficient, see below. > > >Section 3.5., paragraph 8: >> o Messages with the same SID that are to be delivered reliably >> between the same GIST peers are delivered in order. > > DISCUSS: If messages with the same SID go over different messaging > associations, there is a possibility that they reach the peer out-of > order, even if each messaging association guarantees in-order > delivery. I don't see this case addressed in the document. > > >Section 2., paragraph 4: >> The basic rate-control requirements for D-mode traffic are >> deliberately minimal. A single rate limiter applies to=20 >all traffic, >> for all interfaces and message types. It applies to=20 >retransmissions >> as well as new messages, although an implementation MAY choose to >> prioritise one over the other. Rate-control applies only=20 >to locally >> generated D-mode messages, not to messages which are=20 >being forwarded. >> When the rate limiter is in effect, D-mode messages MUST be queued >> until transmission is re-enabled, or an error condition MAY be >> indicated back to local signaling applications. The rate limiting >> mechanism is implementation-defined, but it is RECOMMENDED that a >> token bucket limiter as described in [31] be used. The=20 >token bucket >> MUST be sized to ensure that a node cannot saturate the=20 >network with >> D-mode traffic, for example when re-probing the network=20 >for multiple >> flows after a route change. A suitable approach is to=20 >restrict the >> token bucket parameters so that the mean output rate is a small >> fraction, such as 5%, of the node's lowest-speed interface. > > DISCUSS: "Node cannot saturate the network" is a very weak statement > when it comes to congestion control, because it does not take > concurrent traffic into account. Furthermore, bandwidth=20 >limits of, for > example, "5% of the node's lowest-speed interface" also=20 >don't have the > desired effect. Consider a router with only Gigabit Ethernet > interfaces. By the definition above, it'd be allowed to send=20 >at a rate > of 50Mb/s. If one of those links connects to a layer-2 switch that > connects to the next router using 10Mb/s Ethernet, those 50Mb/s will > overload the link. A similar case exists when a non-NSIS router is > located between two NSIS routers. Even worse, fixed rate=20 >limits do not > take concurrent network traffic along the link/path into account. > Along a fully loaded link/path, adding 5% traffic can significantly > impact concurrent flows. What an appropriate mechanism could be > deserves some more discussion. There are several options, such as > limiting each MA to a single outstanding D-mode request, which limits > the additional traffic to be proportional to the number of MAs/flows, > or more complex schemes if that is too limiting (AIMD, etc.) > >Comment: >COMMENT: > > Nit: Mixes US and British English (e.g., signalling vs. signaling, > etc.) - pick one. > > >Section 3.1., paragraph 7: >> Figure 2: Protocol Stacks for Signaling Transport > > Nit: TLS doesn't currently operate over DCCP, and there are some > issues with operating over some variants of SCTP. > > > >Section 3., paragraph 0: >> a messaging association. The Query is encapsulated in a UDP >> datagram and injected into the network, addressed towards the >> flow destination and with an IP Router Alert Option (RAO) >> included. > > Some IP options force packets onto a router's slow path, which may > contribute to resource exhaustion. I assume that the authors have > verified that Router Alert Options are safe to use in this regard? > > >Section 4., paragraph 0: >> 4. The Query passes through the network towards the flow=20 >receiver, >> and is seen by each router in turn. GIST-unaware routers will >> not recognise the RAO value and will forward the message >> unchanged; GIST-aware routers which do not support the NSLP in >> question will also forward the message basically unchanged, >> although they may need to process more of the message=20 >to decide >> this. > > Many middleboxes drop packets with IP options (Alberto Medina, Mark > Allman, Sally Floyd. Measuring the Evolution of Transport=20 >Protocols in > the Internet. ACM Computer Communication Review, 35(2), April 2005.) > Although I assume that this will mostly occur on the first or last > couple of hops, this can still interfere with end-to-end NSIS > operation. > > >Section 4.1.2., paragraph 2: >> Reliability: This attribute may be 'true' or 'false'. =20 >When 'true', >> messages MUST be delivered to the signaling application in the >> peer exactly once or not at all; > > "Once or not at all" isn't exactly the typically definition of > reliability. Is there a better term for what is meant here? > > >Section 4.1.2., paragraph 3: >> TCP is considered in Section 5.7.2. Messages with the=20 >same SID to >> the same peer MUST be delivered in order. > > ...unless they are not delivered at all. > > >Section 4.1.2., paragraph 4: >> When 'false', a message >> may be delivered, once, several times or not at all,=20 >with no error >> indications in any case. > > What about reordering when "false" - are duplicates of a message > allowed to arrive after later messages have arrived? > > >Section 4.1.2., paragraph 6: >> intermediate nodes. An NSLP may also indicate that=20 >reverse path >> routing state will not be needed for this flow, to inhibit the >> node requesting its downstream peer to create it. > > s/may/MAY/ > > >Section 4.3.2., paragraph 1: >> prevent looping, MUST be checked and decremented immediately the >> message has been received. Further processing depends on the=20 >> message > > Nit: s/immediately the/immediately after the/ > > >Section 5.2.2., paragraph 10: >> The setting and interpretation of the IP-TTL field=20 >depends on the >> message direction (upstream/downstream as determined=20 >from the MRI >> as described above) and encapsulation. > > Routers may decrement the IP TTL by more than than 1, and there is no > requirement that routers use the same decrement value on all > interfaces. Is this mechanism robust under these conditions? > > >Section 5.3.3., paragraph 2: >> Query messages which do not receive Responses MAY be=20 >retransmitted; >> retransmissions MUST use a binary exponential backoff. =20 >The initial >> timer value is T1, which the backoff process can increase up to a >> maximum value of T2 seconds. The default value for T1 is=20 >500 ms. T1 >> is an estimate of the round-trip time between the querying and >> responding nodes. Elements MAY use smaller values of T1 if it is >> known that the Query should be answered within the local=20 >network. T1 >> MAY be chosen larger, and this is RECOMMENDED if it is known in >> advance (such as on high latency access links) that the round-trip >> time is larger. The default value of T2 is 64*T1. > > 500ms seems short. TCP uses T1=3D3sec for SYN retransmissions and DNS > uses T1=3D5sec. (However, I think SIP uses 500ms, too?) > > > >Section 2., paragraph 2: >> It can be seen that all of these transport protocol options can be >> supported by the basic GIST message format already=20 >presented. GIST >> messages requiring fragmentation must be carried using a reliable >> transport protocol, TCP or SCTP. This specification=20 >defines only the >> use of TCP, but other possibilities could be included without >> additional work on message formatting. > > This paragraph should be moved to 5.1 or even earlier, as it is not > specific to C-mode. It would also be good to discuss in more detail > what "require fragmentation" means, i.e., GIST message > path MTU (or > 512 bytes, if path MTU is unknown). Additionally, because some > messages MUST be carried in D- or Q-mode - is it guaranteed=20 >that their > payloads are always less than 512 bytes? > > Also, s/must/MUST/. > > >Section 5.4.2., paragraph 0: >> 5.4.2. Encapsulation Format > > Move up, section is not specific to C-mode. Section 5.4 should > probably be restructured after these changes. > > >Section 5.7.1., paragraph 1: >> A key attribute of GIST is that it is flexible in its=20 >ability to use >> existing transport and security protocols. Different transport >> protocols may have performance attributes appropriate to different >> environments; different security protocols may fit=20 >appropriately with >> different authentication infrastructures. > > All protocols defined in the subsections of this section are for > C-mode - what about D-mode? > > >Section 5.8.1.3., paragraph 0: >> 5.8.1.3. Upstream Q-mode Encapsulation > > No restriction on message size. See DISCUSS. > > >Section 6.2., paragraph 20: >> Rule 4: > > Nit: Pseudocode not indented. > > >Section 7.2., paragraph 0: >> 7.2. NAT Traversal > > Are any GIST-aware NATs in existence? It seems that this section is > mostly about a hypothetical mechanism. > > >Section 7.3., paragraph 0: >> 7.3. Interaction with IP Tunnelling > > This subsection doesn't really belong under "Advanced Protocol > Features." > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Sep 15 09:06:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GODO2-00030w-Lr; Fri, 15 Sep 2006 09:05:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GODO1-00030B-Ml for nsis@ietf.org; Fri, 15 Sep 2006 09:05:41 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GODO0-0002Go-6Y for nsis@ietf.org; Fri, 15 Sep 2006 09:05:41 -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 k8FD5caf020058; Fri, 15 Sep 2006 16:05:39 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Sep 2006 16:05:38 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Sep 2006 16:05:38 +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: Fri, 15 Sep 2006 16:05:38 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Sam Hartman: DISCUSS: draft-ietf-nsis-ntlp Thread-Index: AcbXbmAykOl5ZavCSNqBsukQ2MLSpwBWTCuA From: To: , X-OriginalArrivalTime: 15 Sep 2006 13:05:38.0914 (UTC) FILETIME=[A40E7420:01C6D8C7] X-Spam-Score: 0.2 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: Subject: [NSIS] Sam Hartman: DISCUSS: draft-ietf-nsis-ntlp X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Here's a DISCUSS and Sam about GIST. Robert is traveling, but it would be good to discuss this in the WG to find out ways to address=20 his DISCUSS. John=20 >-----Original Message----- >From: ext Sam Hartman [mailto:hartmans-ietf@mit.edu]=20 >Sent: 13 September, 2006 22:53 >To: iesg@ietf.org >Cc: nsis-chairs@tools.ietf.org; robert.hancock@roke.co.uk;=20 >hgs+nsis@cs.columbia.edu >Subject: DISCUSS: draft-ietf-nsis-ntlp=20 > >Discuss: >First, thanks for a well written protocol writeup. While I'm=20 >bringing up serious concerns, I think that we'll be able to=20 >address them and move forward relatively quickly. > > >How does GIST deal with lost response packets in the case=20 >where there are multiple responders. The discussion in=20 >section 5.3.3 presents an argument that a node will get at=20 >least one query response. However, it seems that there could=20 >be multiple GIST nodes wishing to participate in signaling=20 >between the querying node and the destination of the data flow=20 >(assuming path-coupled MRM). >How will you know if there was a GIST peer who wanted to set=20 >up routing state but whose response was lost? > >GIST raises significant architectural concerns about the=20 >end-to-end service model of the Internet. In particular there=20 >are multiple cases having to do with q-mode encapsulation=20 >where GIST nodes consume, generate and modify packets that are=20 >neither sourced nor destined for them. The advice in section=20 >7.2 goes against the requirements of section 7 of=20 >draft-ietf-behave-nat-udp (an approved BCP). Even so, I think=20 >it is necessary for GIST to do these things but I think we=20 >need to be very careful about the interactions with other=20 >things deployed on the Internet. We also want to discourage=20 >general applications of this form and I think it critical that=20 >we establish architectural requirements so that future=20 >proposals work with GIST. I don't think it necessary to block=20 >GIST on that architectural work. > >I propose that: > >1) A section of the GIST document be added clearly indicating=20 >when a GIST implementation can modify a packet not targeted=20 >for itself and when it is expected to intercept such packets. =20 >That is currently scattered too much throughout the document. =20 >Specific care should be given to cases where a GIST node will=20 >not forward traffic for which it would normally act as a=20 >router. In particular, I think it would be harmful if traffic=20 >that happened to be on the GIST UDP port were discarded if it=20 >clearly had no relation to GIST. > > >2) Discuss interactions with AH and other mechanisms that=20 >might be added (especially by intermediate routers) that could=20 >cause problems when packets are modified. > > >3) Explicitly call out this document's divergence from=20 >draft-ietf-behave-nat-udp. > >4) Send a more general architectural question to the community and IAB. > > >Would it be possible to add a MAC (message integrity code)=20 >based on a negotiated secret to D-mode packets using an=20 >extensibility mechanism? >If so, how would this be done? I don't think we need require=20 >this now, but I do think we need to make sure that if=20 >modification of D-mode packets becomes a problem we have a=20 >solution we can specify. > > >The discussion of TLS needs to describe what names=20 >certificates need to use. > >Section 8.3 claims that authenticated peers can be trusted not=20 >to claim they are on-path when they are off-path. =20 >Authentication is not the same as authorization. The=20 >discussion of when this assumption is reasonable needs to be=20 >significantly expanded. > > >There does not seem to be a discussion of extensibility in the=20 >main body of the document. > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Sep 15 09:19:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GODam-0007IM-EX; Fri, 15 Sep 2006 09:18:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GODal-0007IH-4l for nsis@ietf.org; Fri, 15 Sep 2006 09:18:51 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GODai-0004Pd-Lo for nsis@ietf.org; Fri, 15 Sep 2006 09:18:51 -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 k8FDIlDf006294; Fri, 15 Sep 2006 16:18:47 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Sep 2006 16:18:47 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Sep 2006 16:18:47 +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: Fri, 15 Sep 2006 16:18:47 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Jari Arkko: DISCUSS: draft-ietf-nsis-ntlp Thread-Index: AcbX/fExuHHMLXAORYaLzCEVreXavwAydECAAABrnfA= From: To: , X-OriginalArrivalTime: 15 Sep 2006 13:18:47.0535 (UTC) FILETIME=[7A1C77F0:01C6D8C9] X-Spam-Score: 0.2 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Subject: [NSIS] Jari Arkko: DISCUSS: draft-ietf-nsis-ntlp X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Here's a DISCUSS from Jari about GIST. Robert is traveling, but it would be good to discuss this in the WG to find out ways to address his DISCUSS. John=20 >-----Original Message----- >From: ext Jari Arkko [mailto:jari.arkko@piuha.net] >Sent: 14 September, 2006 16:01 >To: iesg@ietf.org >Cc: nsis-chairs@tools.ietf.org; robert.hancock@roke.co.uk; >hgs+nsis@cs.columbia.edu >Subject: DISCUSS: draft-ietf-nsis-ntlp > >Discuss: >> Legacy NATs: GIST messages will generally pass through NATs, but >> unless the NAT is GIST-aware, any addressing data carried in the >> payload will not be handled correctly. There is a dual problem of >> whether the GIST peers either side of the boundary can work out >> how to address each other, and whether they can work out what >> translation to apply to the signaling packet payloads. The >> fundamental problem is that GIST messages contain three or four >> interdependent addresses which all have to be consistently >> translated, and existing generic NAT traversal techniques such as >> STUN [23] or TURN [24] can process only two. Appropriate >> behaviour for a GIST-aware NAT is discussed in Section 7.2. >... >> GIST messages must carry packet addressing and higher layer >> information as payload data in order to define the flow signalled >> for. (This applies to all GIST messages, regardless of >how they are >> encapsulated or which direction they are travelling in.) At an >> addressing boundary the data flow packets will have their headers >> translated; if the signaling payloads are not translated >> consistently, the signaling messages will refer to incorrect (and >> probably meaningless) flows after passing through the boundary. In >> addition, GIST handshake messages carry additional addressing >> information about the GIST nodes themselves, and this must also be >> processed appropriately when traversing a NAT. > >I do not understand all the implications of running GIST over a=20 >non-modified NAT. If the implications are benign, please explain why=20 >that is the case. If they are serious, the protocol should fail=20 >gracefully upon detecting a NAT. Without additional information I worry >that the design is brittle enough that it may cause harm to the=20 >senders, receivers, GIST nodes, or worse, outsiders when a GIST unaware >NAT causes the address information to become invalid. > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Sep 15 11:23:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOFWE-0004KG-Cm; Fri, 15 Sep 2006 11:22:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOFWC-0004Gb-IM for nsis@ietf.org; Fri, 15 Sep 2006 11:22:16 -0400 Received: from natklopstock.rzone.de ([81.169.145.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOFWB-0001Fl-6K for nsis@ietf.org; Fri, 15 Sep 2006 11:22:16 -0400 Received: from [192.168.178.200] (p5484C51F.dip0.t-ipconnect.de [84.132.197.31]) (authenticated bits=0) by post.webmailer.de (8.13.6/8.13.6) with ESMTP id k8FFMDPM010936 for ; Fri, 15 Sep 2006 17:22:13 +0200 (MEST) Message-ID: <450AC541.4040206@cs.uni-goettingen.de> Date: Fri, 15 Sep 2006 17:22:41 +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: nsis@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [NSIS] Questions on QoS NSLP 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, I have a few questions on the QoS NSLP draft. A RESPONSE is sent to a QUERY containing an RII object. The INFO object is mandatory. Which value does it contain, when no error situation occured? A refresh along the path contains a RII object. When do I send refreshes peer to peer and when refreshes along the path? Are only refreshes with a RII object answered by a RESPONSE? When no reservation state is installed at a QNE, does it make sense to process a RESERVE with set T-Flag and forward it? A RESPONSE usually contains a RII object that the quering node does not forward it further along the path. A NOTIFY which is sent in response of a RESERVE with set Q-Flag could be sent further along the path by the quering node, if the QNI didn't request reduced refreshes but a QNE did. Would a RESPONSE make sense here? Bernd _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Sep 15 12:07:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOGCl-0000Ii-D2; Fri, 15 Sep 2006 12:06:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOGCj-0000IY-SX for nsis@ietf.org; Fri, 15 Sep 2006 12:06:13 -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 1GOGCh-000592-DX for nsis@ietf.org; Fri, 15 Sep 2006 12:06:13 -0400 Received: from [10.3.1.136] (din-cisuc136.dei.uc.pt [10.3.1.136]) (authenticated bits=0) by smtp.dei.uc.pt (8.13.6/8.13.6) with ESMTP id k8FG5hER031782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Sep 2006 17:05:52 +0100 Message-ID: <450ACF45.6010108@student.dei.uc.pt> Date: Fri, 15 Sep 2006 17:05:25 +0100 From: David Palma User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernd Schloer Subject: Re: [NSIS] Questions on QoS NSLP draft References: <450AC541.4040206@cs.uni-goettingen.de> In-Reply-To: <450AC541.4040206@cs.uni-goettingen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: 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 Hi Bernd et al. Please see in line. Bernd Schloer wrote: > Hi, > > I have a few questions on the QoS NSLP draft. > > A RESPONSE is sent to a QUERY containing an RII object. The INFO > object is mandatory. Which value does it contain, when no error > situation occured? Maybe a QoS Specific error code. > > A refresh along the path contains a RII object. When do I send > refreshes peer to peer and when refreshes along the path? Are only > refreshes with a RII object answered by a RESPONSE? In the introduction we see: "...The design of QoS NSLP is conceptually similar to RSVP, RFC 2205 [RFC2205], and uses soft-state peer-to-peer refresh messages as the primary state management mechanism (i.e., state installation/refresh is performed between pairs of adjacent NSLP nodes, rather than in an end-to-end fashion along the complete signaling path)..." and in section 4.3.4 we can read: "...This peer-to-peer refreshing (as opposed to the QNI initiating a refresh which travels all the way to the QNR) allows QNEs to choose refresh intervals..." With this I mean that peer to peer refreshing is much more useful and I don't see where should we use refreshes along the path. About the second question I would say yes. > > When no reservation state is installed at a QNE, does it make > sense to process a RESERVE with set T-Flag and forward it? I think so because this might happen due to some re-routing and we still want to tear down the old branches. > > A RESPONSE usually contains a RII object that the quering node > does not forward it further along the path. A NOTIFY which is > sent in response of a RESERVE with set Q-Flag could be sent > further along the path by the quering node, if the QNI didn't > request reduced refreshes but a QNE did. Would a RESPONSE make > sense here? > I think that the NOTIFY message should be sent only to the immediate upstream peer, much like the RESPONSE sent to the ACK flag on the last version of the draft. With this we only answer the upstream node that really asked for the reduced refresh. Regards, David Palma > Bernd > > _______________________________________________ > 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 Sep 15 12:11:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOGHa-0001pY-54; Fri, 15 Sep 2006 12:11:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOGHY-0001o8-8I for nsis@ietf.org; Fri, 15 Sep 2006 12:11:12 -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 1GOGHV-0005cs-Tz for nsis@ietf.org; Fri, 15 Sep 2006 12:11:12 -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; Fri, 15 Sep 2006 19:11:00 +0300 id 0008D116.450AD094.00006B4D Date: Fri, 15 Sep 2006 19:11:00 +0300 (EEST) From: Jukka MJ Manner To: Bernd Schloer Subject: Re: [NSIS] Questions on QoS NSLP draft In-Reply-To: <450AC541.4040206@cs.uni-goettingen.de> Message-ID: References: <450AC541.4040206@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: 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, some answers below. Jukka On Fri, 15 Sep 2006, Bernd Schloer wrote: > Hi, > > I have a few questions on the QoS NSLP draft. > > A RESPONSE is sent to a QUERY containing an RII object. The INFO > object is mandatory. Which value does it contain, when no error > situation occured? Section 5.1.3.6: Class 0x02, error code 0x01 > > A refresh along the path contains a RII object. When do I send > refreshes peer to peer and when refreshes along the path? Are only > refreshes with a RII object answered by a RESPONSE? RII is only used in special cases when you might want a refreshto go all the way, the default refresh is p2p. > > When no reservation state is installed at a QNE, does it make > sense to process a RESERVE with set T-Flag and forward it? Say your router rebooted, and lost the state. Just after reboot, it gets a tear for a session it was supposed to have. Thus, it should just forward the message further downstrea, otherwise the reservations will not be removed on other nodes downstream. > > A RESPONSE usually contains a RII object that the quering node > does not forward it further along the path. A NOTIFY which is > sent in response of a RESERVE with set Q-Flag could be sent > further along the path by the quering node, if the QNI didn't > request reduced refreshes but a QNE did. Would a RESPONSE make > sense here? The NOTIFY includes an INFO_SPEC that tells the result of the request. It should be sent to the immediate peer from where the RESERVE came, which does not forward it further. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Sep 15 22:10:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOPcF-0004Pc-ID; Fri, 15 Sep 2006 22:09:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOPcE-0004Nu-Sd for nsis@ietf.org; Fri, 15 Sep 2006 22:09:10 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOPcD-0002iX-LB for nsis@ietf.org; Fri, 15 Sep 2006 22:09:10 -0400 Received: from [192.168.0.41] (pool-141-153-175-20.mad.east.verizon.net [141.153.175.20]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k8G28xGl029540 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Fri, 15 Sep 2006 22:09:08 -0400 (EDT) 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: Henning Schulzrinne Subject: Re: [NSIS] Lars Eggert: DISCUSS and COMMENT: draft-ietf-nsis-ntlp Date: Fri, 15 Sep 2006 22:08:53 -0400 To: "" X-Mailer: Apple Mail (2.752.2) X-PerlMx-Spam: Gauge=XXII, Probability=22%, X-Seen-By filter1.cs.columbia.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: lars.eggert@netlab.nec.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 >> DISCUSS: "Node cannot saturate the network" is a very weak statement >> when it comes to congestion control, because it does not take >> concurrent traffic into account. Furthermore, bandwidth >> limits of, for >> example, "5% of the node's lowest-speed interface" also >> don't have the >> desired effect. Consider a router with only Gigabit Ethernet >> interfaces. By the definition above, it'd be allowed to send >> at a rate >> of 50Mb/s. If one of those links connects to a layer-2 switch that >> connects to the next router using 10Mb/s Ethernet, those 50Mb/s will >> overload the link. A similar case exists when a non-NSIS router is >> located between two NSIS routers. Even worse, fixed rate >> limits do not >> take concurrent network traffic along the link/path into account. >> Along a fully loaded link/path, adding 5% traffic can significantly >> impact concurrent flows. What an appropriate mechanism could be >> deserves some more discussion. There are several options, such as >> limiting each MA to a single outstanding D-mode request, which >> limits >> the additional traffic to be proportional to the number of MAs/ >> flows, >> or more complex schemes if that is too limiting (AIMD, etc.) >> The problem with the 'single outstanding D-mode' is that this is likely extremely conservative, given that the sender won't necessarily know where the next hop terminates, so all of these messages could easily traverse different first and/or second hops. AIMD has the same problem, since the destination path to the next hop is unknown and feedback won't arrive until it is too late. You'll only be sending one message in D-mode, usually, so there's nothing to ramp up. I will note that GIST isn't any more congesting than, say, DNS - generally, one end-to-end transaction per application start (ignoring local caching). It would be pretty difficult to rate-control DNS for that same reason. Henning _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Sep 17 23:19:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP9e6-0001SN-Ts; Sun, 17 Sep 2006 23:18:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP9e5-0001Rc-QK for nsis@ietf.org; Sun, 17 Sep 2006 23:18:09 -0400 Received: from py-out-1112.google.com ([64.233.166.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GP9e4-0000Ei-J1 for nsis@ietf.org; Sun, 17 Sep 2006 23:18:09 -0400 Received: by py-out-1112.google.com with SMTP id e30so4072143pya for ; Sun, 17 Sep 2006 20:18:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=KtPJs+XbyTXyrB9DWRkXFWHBW5Tg+ID1jLll9S+JqF5beL0ufUalKO8zMOCtKlPXJgE1UGQZuu78s3DoHsnxrQsTdeGy51YyID4sVTEPpnewSpSchgRdsa143HkAEPdKT4wvCWXESBvnqofoS0tw/zP48D/oJ4+huWZ9NvJJ2lk= Received: by 10.65.250.11 with SMTP id c11mr12041201qbs; Sun, 17 Sep 2006 20:18:05 -0700 (PDT) Received: by 10.65.194.20 with HTTP; Sun, 17 Sep 2006 20:18:05 -0700 (PDT) Message-ID: <5a26be460609172018i75b6ee05kd90dac29404102d2@mail.gmail.com> Date: Mon, 18 Sep 2006 11:18:05 +0800 From: "=?GB2312?B?sfOx8831?=" To: nsis@ietf.org MIME-Version: 1.0 X-Spam-Score: 1.0 (+) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Subject: [NSIS] question about routing in NTLP X-BeenThere: nsis@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="===============1607305841==" Errors-To: nsis-bounces@ietf.org --===============1607305841== Content-Type: multipart/alternative; boundary="----=_Part_271711_3578203.1158549485861" ------=_Part_271711_3578203.1158549485861 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all ! I have some questions about routing in NTLP. As we know there are two major functions in NTLP: (1) Routing. (2) Transport. I have read the implementation code of nsis-0.4.0. And I know that the function of "Transport" is implementd by the GistMAEntry class, which uses the socket classes provided in ../library/socket. however, I have been very confused on the "Routing" function. I don't know how it is being realized. And I realized there are many library files in ..\library\libxorp. Further more, I don't understand this words " Incoming messages are fetched from the socket by callbacks called by XORP(socket_events.cpp) ". What is the role of XORP as it here? how does XORP and GIST work together? I am looking forward someone can reply to my questions. Thank u very much! Bestwishes! Sky Wang 2006-9-18 -- journey ------=_Part_271711_3578203.1158549485861 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi all !
 
I have some questions about routing in NTLP. As we know  there are two major functions in NTLP: (1) Routing. (2) Transport.
 
I have read the implementation code of nsis-0.4.0. And I know that the function of "Transport" is implementd by the GistMAEntry class, which uses the socket classes provided in ../library/socket.
 
however, I have been very confused on the "Routing" function. I don't know how it is being realized. And I realized there are many library files in ..\library\libxorp. Further more, I don't understand this words " Incoming messages are fetched from the socket by callbacks called by XORP(socket_events.cpp) ". What is the role of XORP as it here? how does XORP and GIST work together?
 
I am looking forward someone can reply to my questions. Thank u very much!
 
Bestwishes!
 
Sky Wang
2006-9-18



 


-- 
journey ------=_Part_271711_3578203.1158549485861-- --===============1607305841== 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 --===============1607305841==-- From nsis-bounces@ietf.org Mon Sep 18 02:35:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPCi3-00033j-T2; Mon, 18 Sep 2006 02:34:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPCi3-00033e-2q for nsis@ietf.org; Mon, 18 Sep 2006 02:34:27 -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 1GPCi1-0001nD-Dk for nsis@ietf.org; Mon, 18 Sep 2006 02:34:27 -0400 Received: from win2003.dickmann2003.home (p548A6576.dip.t-dialin.net [84.138.101.118]) by www.difra-computer.de (Postfix) with ESMTP id F35DA3E4082 for ; Mon, 18 Sep 2006 08:32:56 +0200 (CEST) Subject: RE: [NSIS] question about routing in NTLP MIME-Version: 1.0 Date: Mon, 18 Sep 2006 08:21:42 +0200 Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] question about routing in NTLP Thread-Index: Acba0JW46l23iMpLRG+0sAAzawgdCwAGs1sg From: "Christian Dickmann" To: =?iso-2022-jp?B?GyRCSUxJTDImGyhC?= , X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d9ae72af46718088458d214998cc683 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="===============1745273607==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============1745273607== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6DAEA.B567FDA0" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C6DAEA.B567FDA0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Hi, your question is not related to the specification of GIST/NSIS. Instead, you refer to the NSIS implementation of the University of Goettingen. Therefore, you should use a different mailing list as instructed in the README file of the implementation. Please see http://user.informatik.uni-goettingen.de/~nsis/help.html for the correct mailing list. I will be happy to help you there. Thank you for your interest. Christian Dickmann ________________________________ From: $BILIL2&(J [mailto:binbinwang118@gmail.com] Sent: Monday, September 18, 2006 5:18 AM To: nsis@ietf.org Subject: [NSIS] question about routing in NTLP Hi all ! I have some questions about routing in NTLP. As we know there are two major functions in NTLP: (1) Routing. (2) Transport. I have read the implementation code of nsis-0.4.0. And I know that the function of "Transport" is implementd by the GistMAEntry class, which uses the socket classes provided in ../library/socket. however, I have been very confused on the "Routing" function. I don't know how it is being realized. And I realized there are many library files in ..\library\libxorp. Further more, I don't understand this words " Incoming messages are fetched from the socket by callbacks called by XORP(socket_events.cpp) ". What is the role of XORP as it here? how does XORP and GIST work together? I am looking forward someone can reply to my questions. Thank u very much! Bestwishes! Sky Wang 2006-9-18 -- journey ------_=_NextPart_001_01C6DAEA.B567FDA0 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit

Hi,

 

your question is not related to the specification of GIST/NSIS. Instead, you refer to the

NSIS implementation of the University of Goettingen. Therefore, you should use a different

mailing list as instructed in the README file of the implementation.

 

Please see http://user.informatik.uni-goettingen.de/~nsis/help.html

for the correct mailing list. I will be happy to help you there.

 

Thank you for your interest.

 

Christian Dickmann

 

From: $BILIL2&(J [mailto:binbinwang118@gmail.com]
Sent: Monday, September 18, 2006 5:18 AM
To: nsis@ietf.org
Subject: [NSIS] question about routing in NTLP

 

Hi all !

 

I have some questions about routing in NTLP. As we know  there are two major functions in NTLP: (1) Routing. (2) Transport.

 

I have read the implementation code of nsis-0.4.0. And I know that the function of "Transport" is implementd by the GistMAEntry class, which uses the socket classes provided in ../library/socket.

 

however, I have been very confused on the "Routing" function. I don't know how it is being realized. And I realized there are many library files in ..\library\libxorp. Further more, I don't understand this words " Incoming messages are fetched from the socket by callbacks called by XORP(socket_events.cpp) ". What is the role of XORP as it here? how does XORP and GIST work together?

 

I am looking forward someone can reply to my questions. Thank u very much!

 

Bestwishes!

 

Sky Wang

2006-9-18




 



-- 
journey

------_=_NextPart_001_01C6DAEA.B567FDA0-- --===============1745273607== 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 --===============1745273607==-- From nsis-bounces@ietf.org Mon Sep 18 03:18:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPDNt-0001LP-1R; Mon, 18 Sep 2006 03:17:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPDNr-0001Kh-Co for nsis@ietf.org; Mon, 18 Sep 2006 03:17:39 -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 1GPDCG-0007f1-6v for nsis@ietf.org; Mon, 18 Sep 2006 03:05:41 -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, 18 Sep 2006 10:05:31 +0300 id 0007CE89.450E453B.00000282 Date: Mon, 18 Sep 2006 10:05:31 +0300 (EEST) From: Jukka MJ Manner To: "=?GB2312?B?sfOx8831?=" Subject: Re: [NSIS] question about routing in NTLP In-Reply-To: <5a26be460609172018i75b6ee05kd90dac29404102d2@mail.gmail.com> Message-ID: References: <5a26be460609172018i75b6ee05kd90dac29404102d2@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable 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, You should point your question to the NSIS Implementation mailist list.=20 This nsis@ietf.org list is for discussions about the standardization=20 work on the protocol suite, not about specific implementations. https://www1.ietf.org/mailman/listinfo/nsis-imp Jukka On Mon, 18 Sep 2006, ???=F3=CD=F5 wrote: > Hi all ! >=20 > I have some questions about routing in NTLP. As we know there are two ma= jor > functions in NTLP: (1) Routing. (2) Transport. >=20 > I have read the implementation code of nsis-0.4.0. And I know that the > function of "Transport" is implementd by the GistMAEntry class, which use= s > the socket classes provided in ../library/socket. >=20 > however, I have been very confused on the "Routing" function. I don't kno= w > how it is being realized. And I realized there are many library files in > ..\library\libxorp. Further more, I don't understand this words " Incomin= g > messages are fetched from the socket by callbacks called by > XORP(socket_events.cpp) ". What is the role of XORP as it here? how does > XORP and GIST work together? >=20 > I am looking forward someone can reply to my questions. Thank u very much= ! >=20 > Bestwishes! >=20 > Sky Wang > 2006-9-18 >=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 Sep 18 08:22:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPI84-00059b-Jn; Mon, 18 Sep 2006 08:21:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPI81-00050O-CT for nsis@ietf.org; Mon, 18 Sep 2006 08:21:37 -0400 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPI21-00010v-2b for nsis@ietf.org; Mon, 18 Sep 2006 08:15:28 -0400 Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k8ICFNm6009955; Mon, 18 Sep 2006 14:15:23 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k8ICFK0B014261; Mon, 18 Sep 2006 14:15:23 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Sep 2006 14:15:21 +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] Jari Arkko: DISCUSS: draft-ietf-nsis-ntlp Date: Mon, 18 Sep 2006 14:15:20 +0200 Message-ID: <69D2C30BFA177E4DB3E6C93A94C87F1FBD96BF@MCHP7IEA.ww002.siemens.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Jari Arkko: DISCUSS: draft-ietf-nsis-ntlp Thread-Index: AcbX/fExuHHMLXAORYaLzCEVreXavwAydECAAABrnfAAlH+kQA== From: "Pashalidis, Andreas" To: , , X-OriginalArrivalTime: 18 Sep 2006 12:15:21.0875 (UTC) FILETIME=[1D001630:01C6DB1C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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 Hello, In response to the message below I would like to point out that the ID http://tools.ietf.org/wg/nsis/draft-pashalidis-nsis-gist-legacynats-00.t xt=20 addresses (at least some of) the issues that are raised in that message. That is, the ID contains a description of how GIST nodes can discover the existence of legacy NAT(s) and how to cope with them.=20 Best Regards, Andreas -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 Sent: Freitag, 15. September 2006 15:19 To: jari.arkko@piuha.net; nsis@ietf.org Subject: [NSIS] Jari Arkko: DISCUSS: draft-ietf-nsis-ntlp=20 Here's a DISCUSS from Jari about GIST. Robert is traveling, but it would be good to discuss this in the WG to find out ways to address his DISCUSS. John=20 >-----Original Message----- >From: ext Jari Arkko [mailto:jari.arkko@piuha.net] >Sent: 14 September, 2006 16:01 >To: iesg@ietf.org >Cc: nsis-chairs@tools.ietf.org; robert.hancock@roke.co.uk; >hgs+nsis@cs.columbia.edu >Subject: DISCUSS: draft-ietf-nsis-ntlp > >Discuss: >> Legacy NATs: GIST messages will generally pass through NATs, but >> unless the NAT is GIST-aware, any addressing data carried in the >> payload will not be handled correctly. There is a dual problem of >> whether the GIST peers either side of the boundary can work out >> how to address each other, and whether they can work out what >> translation to apply to the signaling packet payloads. The >> fundamental problem is that GIST messages contain three or four >> interdependent addresses which all have to be consistently >> translated, and existing generic NAT traversal techniques such as >> STUN [23] or TURN [24] can process only two. Appropriate >> behaviour for a GIST-aware NAT is discussed in Section 7.2. >... >> GIST messages must carry packet addressing and higher layer >> information as payload data in order to define the flow signalled >> for. (This applies to all GIST messages, regardless of >how they are >> encapsulated or which direction they are travelling in.) At an >> addressing boundary the data flow packets will have their headers >> translated; if the signaling payloads are not translated >> consistently, the signaling messages will refer to incorrect (and >> probably meaningless) flows after passing through the boundary. In >> addition, GIST handshake messages carry additional addressing >> information about the GIST nodes themselves, and this must also be >> processed appropriately when traversing a NAT. > >I do not understand all the implications of running GIST over a=20 >non-modified NAT. If the implications are benign, please explain why=20 >that is the case. If they are serious, the protocol should fail=20 >gracefully upon detecting a NAT. Without additional information I worry >that the design is brittle enough that it may cause harm to the=20 >senders, receivers, GIST nodes, or worse, outsiders when a GIST unaware >NAT causes the address information to become invalid. > > > _______________________________________________ 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 Sep 18 12:29:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPLzR-0007xb-NA; Mon, 18 Sep 2006 12:29:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPLzR-0007wk-7v for nsis@ietf.org; Mon, 18 Sep 2006 12:29:01 -0400 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPLzP-0007IP-PU for nsis@ietf.org; Mon, 18 Sep 2006 12:29:01 -0400 Received: from localhost (localhost.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 3A87020031EF; Mon, 18 Sep 2006 18:29:26 +0200 (CEST) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26237-05; Mon, 18 Sep 2006 18:29:26 +0200 (CEST) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id DAAE920031E0; Mon, 18 Sep 2006 18:29:25 +0200 (CEST) Received: from n-eggert.office ([10.1.1.112]) by mx1.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Sep 2006 18:28:58 +0200 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n-eggert.office (Postfix) with ESMTP id 644E521F6EA; Mon, 18 Sep 2006 18:28:58 +0200 (CEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Jabber-Id: lars.eggert@jabber.netlab.nec.de Message-Id: From: Lars Eggert Subject: Re: [NSIS] Lars Eggert: DISCUSS and COMMENT: draft-ietf-nsis-ntlp Date: Mon, 18 Sep 2006 18:28:55 +0200 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 18 Sep 2006 16:28:58.0560 (UTC) FILETIME=[8AD9F400:01C6DB3F] X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 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="===============1220958076==" Errors-To: nsis-bounces@ietf.org --===============1220958076== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2--98889994; protocol="application/pkcs7-signature" --Apple-Mail-2--98889994 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, On Sep 16, 2006, at 4:08, Henning Schulzrinne wrote: > The problem with the 'single outstanding D-mode' is that this is > likely extremely conservative, given that the sender won't > necessarily know where the next hop terminates, so all of these > messages could easily traverse different first and/or second hops. right - I only included the "single outstanding D-mode" case as one possible solution. > AIMD has the same problem, since the destination path to the next > hop is unknown and feedback won't arrive until it is too late. > You'll only be sending one message in D-mode, usually, so there's > nothing to ramp up. It may be true that usually there is only one D-mode message, but the document doesn't currently place any such restriction on D-mode. If it said "send only the query in Q-mode, use C-mode for everything else that follows", that'd be significantly better. My concern is based on the document not placing any restrictions on how frequently D-mode messages can be sent and how large they can be. > I will note that GIST isn't any more congesting than, say, DNS - > generally, one end-to-end transaction per application start > (ignoring local caching). It would be pretty difficult to rate- > control DNS for that same reason. Agreed, but see above. Lars -- Lars Eggert NEC Network Laboratories --Apple-Mail-2--98889994 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKZDCCAwEw ggJqoAMCAQICEBCR/semQl5bz/x3jtiU02YwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDgxNjA5MTU0NloXDTA3MDgxNjA5MTU0 NlowYDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAL/+LXyqufw8ApYnCU24cnZ/H9S7ro4zZYeCqcyFqhwJpTcM8/yX 6Ms+16d2EtIceQS8Bas3GAUR+xfq0QI5dt8uIKM1Uy4trk8AAO0dh23+QTLw7toloArVngGIhUhC OTpVRR1bYfJTwPVpSAY43mbGhSGhwiu5035yKdYJezNWOXmuIO+lvXcD36hc5cU6AzRJkj0LYaFd WHjbfwzGmT7MO60p/7hT+aTv5xvTl/mcwslvm+KhKmJjoMYfSOF99xvuJE/rB7Ho3g6wDoeB2Tip 44Qq8CPmOHtCXzh/tF/bYo+OHStkPTzgPfOuNDMxa0/gAPEyELNL0Eh1/hC2TeMCAwEAAaM2MDQw JAYDVR0RBB0wG4EZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTAMBgNVHRMBAf8EAjAAMA0GCSqG SIb3DQEBBQUAA4GBAHdaTI5TM5wV+LG2WW+CMEmxEyNhaRu3oca9T31HjbfHzvhVJe2fzKt1xBSo +hhCg0qKVFuE7yKxDH975Csq9jVvJJj3oL29RQjPnc3CgQqlMFJKHdJgterPQ+ZiCp05S9rbMhRl 1zxB/x+GvnDFHsXu19gA2dlynrdWN/G1BVWJMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBU b3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSsw KQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAw MFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7s vc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV 84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGR MBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUu Y29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCk HjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oL LswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoL gnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHT HUb/XV9lTzCCBBgwggOBoAMCAQICAQAwDQYJKoZIhvcNAQEFBQAwgb8xCzAJBgNVBAYTAkRFMRww GgYDVQQIFBNCYWRlbi1Xw3VlcnR0ZW1iZXJnMRMwEQYDVQQHEwpIZWlkZWxiZXJnMRcwFQYDVQQK Ew5ORUMgRXVyb3BlIEx0ZDEdMBsGA1UECxMUTmV0d29yayBMYWJvcmF0b3JpZXMxGzAZBgNVBAMT EmtvYmUubmV0bGFiLm5lYy5kZTEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5l Yy5kZTAeFw0wNDA2MTgxMTUzMDhaFw0wOTA2MTcxMTUzMDhaMIG/MQswCQYDVQQGEwJERTEcMBoG A1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVyZzETMBEGA1UEBxMKSGVpZGVsYmVyZzEXMBUGA1UEChMO TkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsTFE5ldHdvcmsgTGFib3JhdG9yaWVzMRswGQYDVQQDExJr b2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMu ZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALQ5DCwTzpGu3RmzQY4KxiaQak/BwIW9Wk6K Mg+/V0aiWvlrz7uFdICBGVTKhyWr3F+GxRPCVTWqS9VEPf9A59DI9TFCS3FtraSx+w8ApQei8idb J0Lqu8tTz2O1gYR2dELID5wQH9dxIANt3bP39crgDZzGYxCJilcimFhADEgHAgMBAAGjggEgMIIB HDAdBgNVHQ4EFgQU6Hsv16oYecCFsl07g9gtjPEJo00wgewGA1UdIwSB5DCB4YAU6Hsv16oYecCF sl07g9gtjPEJo02hgcWkgcIwgb8xCzAJBgNVBAYTAkRFMRwwGgYDVQQIFBNCYWRlbi1Xw3VlcnR0 ZW1iZXJnMRMwEQYDVQQHEwpIZWlkZWxiZXJnMRcwFQYDVQQKEw5ORUMgRXVyb3BlIEx0ZDEdMBsG A1UECxMUTmV0d29yayBMYWJvcmF0b3JpZXMxGzAZBgNVBAMTEmtvYmUubmV0bGFiLm5lYy5kZTEo MCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZYIBADAMBgNVHRMEBTADAQH/ MA0GCSqGSIb3DQEBBQUAA4GBAJfoil3cAX3cUPMFrDdlW9DPMK/+QY8EHPOsnefm77h5CmmY6J+G 5Ydl9vyHxL76Opyg8cZWOOU/k9oVv7AvQ1GmIFqVFyWKQPfEhj+EWjEnUAcI7QDN8XER+U7XRvj6 yYysFgm2Tl30QCGvmESCgYIztCKMG2cLBkEosj2kWBbXMYIDsjCCA64CAQEwdjBiMQswCQYDVQQG EwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBCR/semQl5bz/x3jtiU02YwCQYFKw4D AhoFAKCCAhEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwOTE4 MTYyODU2WjAjBgkqhkiG9w0BCQQxFgQUGpYdJsU3Do8Z/QRqxKdnWLJpNjIwgdYGCSsGAQQBgjcQ BDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcxEzAR BgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExROZXR3 b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZIhvcN AQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsqhkiG9w0BCRACCzGByKCBxTCB vzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhl aWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9y YXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJz LmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUABIIBAFSdDx93QfBiZYjF2MMG TSmWliAtg/FjZVFHbs77/oLEVao8PPbEv+tDW/NKE381J1m+vXh3hPBMa49hPOod8M2+EXTSizqe F6hD0z0GqRef6vpK9VynGmiz+th1/38TWsz2fNPabJsjCDtz0ehszMcUihpcGyEG5yKeS7HKAGiE RIrRiJW6ovLFrQqJoblSrXlfE4KwYZH4s1A30loZ98UfcUF/13wORi8uNnTifO31jvoZXvdO+4bI 5bIIkZW39qvIAiYIH+HA49dF3ej1twTM/wmJQ7Sf9xip/QyT98Iaqig0zNuORvWyFECNdTClIRbH 7oLh/VBmU8yV2K3m/j8AAAAAAAA= --Apple-Mail-2--98889994-- --===============1220958076== 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 --===============1220958076==-- From nsis-bounces@ietf.org Mon Sep 18 12:44:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPMDM-0006dy-Qm; Mon, 18 Sep 2006 12:43:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPMDM-0006ds-1M for nsis@ietf.org; Mon, 18 Sep 2006 12:43:24 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPMDJ-0000i1-Qe for nsis@ietf.org; Mon, 18 Sep 2006 12:43:24 -0400 Received: from lion.cs.columbia.edu (IDENT:GWtp+63X64bIOb/+ELb38eEZ5HoHxzY+@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k8IGhIGb022348 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 18 Sep 2006 12:43:18 -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 k8IGhHg7002318 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 18 Sep 2006 12:43:17 -0400 Message-ID: <450ECCA0.60203@cs.columbia.edu> Date: Mon, 18 Sep 2006 12:43:12 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Lars Eggert Subject: Re: [NSIS] Lars Eggert: DISCUSS and COMMENT: draft-ietf-nsis-ntlp References: In-Reply-To: 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: 68c8cc8a64a9d0402e43b8eee9fc4199 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 > > It may be true that usually there is only one D-mode message, but the > document doesn't currently place any such restriction on D-mode. If it > said "send only the query in Q-mode, use C-mode for everything else that > follows", that'd be significantly better. My concern is based on the > document not placing any restrictions on how frequently D-mode messages > can be sent and how large they can be. Given that the major point of NSIS is to avoid re-inventing TCP, maybe the best solution would indeed be to call out this restriction, i.e., that D-mode SHOULD only be used once (and after route changes). _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Sep 18 16:03:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPPKh-0003WD-Lj; Mon, 18 Sep 2006 16:03:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPMXv-0007Sg-Rj for nsis@ietf.org; Mon, 18 Sep 2006 13:04:39 -0400 Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPMPo-0003C1-Iw for nsis@ietf.org; Mon, 18 Sep 2006 12:56:17 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id B5387E0127; Mon, 18 Sep 2006 12:56:16 -0400 (EDT) From: Sam Hartman To: References: Date: Mon, 18 Sep 2006 12:56:16 -0400 In-Reply-To: (john loughney's message of "Fri, 15 Sep 2006 16:05:38 +0300") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-Mailman-Approved-At: Mon, 18 Sep 2006 16:03:11 -0400 Cc: nsis@ietf.org Subject: [NSIS] Re: Sam Hartman: DISCUSS: draft-ietf-nsis-ntlp X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.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" == writes: John> Here's a DISCUSS and Sam about GIST. Robert is traveling, John> but it would be good to discuss this in the WG to find out John> ways to address his DISCUSS. A few additional comments on the discuss. First, I've been told that many of my architectural questions about changing IP packets as they traverse the network are handled in the NSIS framework. That's on my reading list probably for late this week. Second, I realize that the situation for multiple responses is more complicated than I thought. It turns out that what happens to the original query falls off a disconnect between section 4.3.1 and 4.4.1 Section 4.3.1 tells us that we're going to 4.4.1 if we are a GIST peer that actually wants to become involved in the signaling. We know from 3.7 that the query packet we received will be forwarded and will make its way to the end node. However 4.4.1 does not discuss this forwarding. Who does the response go to? Is the MRI updated to point to us, or is the MRI left unchanged so that all responses go to the querying node? It turns out this is important to understand my comment about multiple responses. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Sep 19 10:36:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPghX-000300-F9; Tue, 19 Sep 2006 10:35:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPghV-0002zY-FA; Tue, 19 Sep 2006 10:35:53 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPghK-0002jm-VD; Tue, 19 Sep 2006 10:35:53 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2E7188E0001; Tue, 19 Sep 2006 16:35:40 +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, 19 Sep 2006 16:35:39 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Sep 2006 16:35:38 +0200 Message-ID: <4510003A.8080505@ericsson.com> Date: Tue, 19 Sep 2006 16:35:38 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: NSIS , TSV Area Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Sep 2006 14:35:38.0473 (UTC) FILETIME=[E018C590:01C6DBF8] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: John Loughney Subject: [NSIS] Looking for Volunteer to chair the NSIS WG X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.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 needs support in chairing the NSIS WG. http://www.ietf.org/html.charters/nsis-charter.html Therefore we are looking for volunteers interested in be a co-chair with John. The WG is currently trying to finish up a number of documents. So the major part of the work is to help ensure that issues are closed, updates made timely, sufficient review is performed and help progress the documents through the publication process. Please note that the position is commitment that takes a number of hours every week and the need for participating in the IETF meetings when the WG is meeting. So please ensure that you have support for that commitment before volunteering. If you are interested please send a response to me and John and include the following information: - Name - Affiliation - Major accomplishments and official positions within IETF. Please note that there are no requirement to had held any previous WG chair position etc. Please send your response at the latest the 2nd of October. cheers Magnus Westerlund TSV AD _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Sep 19 19:55:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPpQ4-0005RG-8m; Tue, 19 Sep 2006 19:54:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPpQ3-0005RB-FR for nsis@ietf.org; Tue, 19 Sep 2006 19:54:27 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPpPz-0001Kw-Ps for nsis@ietf.org; Tue, 19 Sep 2006 19:54:27 -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 k8JNsG0R031589; Wed, 20 Sep 2006 00:54:16 +0100 Received: from ac78840 ([193.118.192.66]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Sep 2006 00:54:15 +0100 From: "Robert Hancock" To: "'Sam Hartman'" , Subject: multiple responses to a Query (was: RE: [NSIS] Re: Sam Hartman: DISCUSS: draft-ietf-nsis-ntlp) Date: Wed, 20 Sep 2006 09:54:11 +1000 Message-ID: <000001c6dc46$e97c0b80$6500000a@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: 19 Sep 2006 23:54:16.0216 (UTC) FILETIME=[EA3A7980:01C6DC46] 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: 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 Sam, I'll try to address this multiple responses issue specifically, and come back to the rest of the discuss in another mail. The situation here should be relatively simple, but it's possible that the current text has misleading aspects. The basic concept is that each Query gets one Response. The Response gets sent to the node that sent the Query (the node address comes from the NLI object in the Query message); the two nodes, Querying and Responding, are the two ends of a single GIST hop. Along an end-to-end path, there will likely be multiple GIST hops; for each of them, there is a Query/Response exchange which is local to that hop. The MRI is not changed along the path. GIST is basically ignorant of the fact that there are multiple hops chained together in this way; linking up the hops to provide an end-to-end signalling exchange is carried out at the signalling application level (e.g. the forwarding referred to in section 3.7 step 5 is done at that level) - a single Query itself does not travel end to end. Each hop is initiated by signalling application on the node trying to send a message; GIST then carries out a local Query/ Response to get to the next node. Most of the details of the process are in section 4.3. The complications arise from the rules about when a node decides that it is going to be the other end of a hop, i.e. when it decides to send a Response to an intercepted Query. There are 3 cases: - node is completely uninterested; the Query is forwarded (4.3.4) - the signalling application inspects the Query payload but the node decides not to become the end of a hop; the Query is forwarded (4.3.2 case 2) - the signalling application inspects the Query payload and decides to peer; a Response is sent (4.3.2 case 1; 4.4.1 then describes the details of how the peering process continues) (There are subtleties in the case of error conditions, but the fundamental behaviour above is preserved.) Is this explanation going in the right direction to address your concern? Or have I misunderstood it? cheers, Robert H. ps. responses may be delayed by travelling > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > Sent: 19 September 2006 02:56 > To: john.loughney@nokia.com > Cc: nsis@ietf.org > Subject: [NSIS] Re: Sam Hartman: DISCUSS: draft-ietf-nsis-ntlp > > > >>>>> "John" == writes: > > John> Here's a DISCUSS and Sam about GIST. Robert is traveling, > John> but it would be good to discuss this in the WG to find out > John> ways to address his DISCUSS. > > > A few additional comments on the discuss. > > First, I've been told that many of my architectural questions about > changing IP packets as they traverse the network are handled in the > NSIS framework. That's on my reading list probably for late this > week. > > > Second, I realize that the situation for multiple responses > is more complicated than I thought. > > It turns out that what happens to the original query falls off a > disconnect between section 4.3.1 and 4.4.1 Section 4.3.1 tells us that > we're going to 4.4.1 if we are a GIST peer that actually wants to > become involved in the signaling. > > We know from 3.7 that the query packet we received will be forwarded > and will make its way to the end node. > > However 4.4.1 does not discuss this forwarding. Who does the response > go to? Is the MRI updated to point to us, or is the MRI left > unchanged so that all responses go to the querying node? > > It turns out this is important to understand my comment about multiple > responses. > > _______________________________________________ > 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 Sep 19 21:58:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPrLI-0001Wf-Vy; Tue, 19 Sep 2006 21:57:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPrLH-0001WR-8i for nsis@ietf.org; Tue, 19 Sep 2006 21:57:39 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPrLE-0002Zl-Q3 for nsis@ietf.org; Tue, 19 Sep 2006 21:57:39 -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 k8K1v3xG017276; Wed, 20 Sep 2006 02:57:08 +0100 Received: from ac78840 ([193.118.192.66]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Sep 2006 02:57:03 +0100 From: "Robert Hancock" To: "'Henning Schulzrinne'" , "'Lars Eggert'" Subject: RE: [NSIS] Lars Eggert: DISCUSS and COMMENT: draft-ietf-nsis-ntlp Date: Wed, 20 Sep 2006 11:56:58 +1000 Message-ID: <003e01c6dc58$1083e570$6500000a@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: <450ECCA0.60203@cs.columbia.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Importance: Normal X-OriginalArrivalTime: 20 Sep 2006 01:57:04.0122 (UTC) FILETIME=[11D7B5A0:01C6DC58] 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: 41c17b4b16d1eedaa8395c26e9a251c4 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 Henning, Lars, all, > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: 19 September 2006 02:43 > To: Lars Eggert > Cc: ; nsis@ietf.org > Subject: Re: [NSIS] Lars Eggert: DISCUSS and COMMENT: > draft-ietf-nsis-ntlp > > > > > > It may be true that usually there is only one D-mode > message, but the > > document doesn't currently place any such restriction on > D-mode. If it > > said "send only the query in Q-mode, use C-mode for > everything else that > > follows", that'd be significantly better. My concern is > based on the > > document not placing any restrictions on how frequently > D-mode messages > > can be sent and how large they can be. > > Given that the major point of NSIS is to avoid re-inventing > TCP, maybe > the best solution would indeed be to call out this restriction, i.e., > that D-mode SHOULD only be used once (and after route changes). Is this the seed of a solution? I know there will be people who want to use D-mode more extensively; however, they want to do so in environments where they can engineer capacity for the signalling traffic (don't know if that is worth adding as a rider to the SHOULD). In terms of the other ideas that have come up in previous mails, I still find it very hard to work out how an adaptive scheme could work for the Query/Response traffic, since, as Henning says, there is nothing on which to build up any information about the congestion state of the network. Restricting the number of outstanding D mode messages opens up a trivial DoS attack (signal for a flow whose endpoint silently eats Query messages; the Querying node will have to time out waiting for answers). I still think it is necessary to consider some kind of rate control discussion for the route change/peer failure case. These events could trigger a GIST node to Query for all its flows, and that has to be capped in some way. The current text sizes the token bucket on router interface capacity; #sessions is another possibility (in fact, the original proposal). They are all equally non-bulletproof, albeit in different ways. Or do people want the token bucket stuff out altogether? cheers, r. > > > _______________________________________________ > 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 Sep 19 22:55:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPsE9-0003E7-IE; Tue, 19 Sep 2006 22:54:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPsE8-0003Dv-WF for nsis@ietf.org; Tue, 19 Sep 2006 22:54:21 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPsE6-0005uM-MM for nsis@ietf.org; Tue, 19 Sep 2006 22:54:20 -0400 Received: from [192.168.0.41] (pool-141-153-175-20.mad.east.verizon.net [141.153.175.20]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k8K2sFGl026193 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Tue, 19 Sep 2006 22:54:16 -0400 (EDT) In-Reply-To: <003e01c6dc58$1083e570$6500000a@comm.ad.roke.co.uk> References: <003e01c6dc58$1083e570$6500000a@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: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [NSIS] Lars Eggert: DISCUSS and COMMENT: draft-ietf-nsis-ntlp Date: Tue, 19 Sep 2006 22:54:07 -0400 To: "Robert Hancock" X-Mailer: Apple Mail (2.752.2) X-PerlMx-Spam: Gauge=XXII, Probability=22%, X-Seen-By filter1.cs.columbia.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: 'Lars Eggert' , 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 >> Given that the major point of NSIS is to avoid re-inventing >> TCP, maybe >> the best solution would indeed be to call out this restriction, i.e., >> that D-mode SHOULD only be used once (and after route changes). > > Is this the seed of a solution? > > I know there will be people who want to use D-mode more > extensively; however, they want to do so in environments > where they can engineer capacity for the signalling > traffic (don't know if that is worth adding as a rider > to the SHOULD). > Stating exceptions ("known network capacity") is certainly helpful. > In terms of the other ideas that have come up in previous > mails, I still find it very hard to work out how an > adaptive scheme could work for the Query/Response traffic, > since, as Henning says, there is nothing on which to build > up any information about the congestion state of the > network. Restricting the number of outstanding D mode messages > opens up a trivial DoS attack (signal for a flow whose > endpoint silently eats Query messages; the Querying node > will have to time out waiting for answers). > > I still think it is necessary to consider some kind of > rate control discussion for the route change/peer failure > case. These events could trigger a GIST node to Query for > all its flows, and that has to be capped in some way. The > current text sizes the token bucket on router interface > capacity; #sessions is another possibility (in fact, the > original proposal). They are all equally non-bulletproof, > albeit in different ways. Or do people want the token bucket > stuff out altogether? I think this mostly offers the illusion of safety, while adding more "tweak" parameters that cause unpleasant surprises when they are set wrong, but forgotten. (Suddenly, voice calls fail after re-routes because somebody didn't update the parameter after upgrading the T1 to an OC-12.) Also, fixed ratios and such can't take into account that reservation messages may have different importance in different networks. If I run a corporate network where voice is most important, I will want the reservation messages to go through pronto, even if they temporarily reduce the web bandwidth. Adding buckets and the like also introduces strange failure modes, if messages are queued or dropped, causing upstream retransmissions or duplicate messages as the queue empties. There's probably a reasonable limit per-flow for resource reservation, such as not sending more than the bandwidth you'd like to reserve, but even that's complicated (over what time horizon?) and doesn't help much if message-triggering events are synchronized. One piece of useful advice we can and should give, I think, is to tell people to space error-induced re-attempts N seconds (where N is some reasonable number, such as 5), rather than trying to grab bandwidth, say, by continuously sending messages. Personally, I see it has highly implausible that any well-behaved NSIS application would cause problems, compared to other non-rate- controlled streams such as UDP games and audio. Not-so-well-behaved NSIS, like any other such application, won't give a [bleep] about fancy algorithms. > > cheers, > > r. > >> >> >> _______________________________________________ >> 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 Sep 20 02:19:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPvPY-0004UH-B2; Wed, 20 Sep 2006 02:18:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPvPW-0004U3-U3 for nsis@ietf.org; Wed, 20 Sep 2006 02:18:18 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPvPT-0006O2-2F for nsis@ietf.org; Wed, 20 Sep 2006 02:18:18 -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 k8K6I29s015876; Wed, 20 Sep 2006 07:18:02 +0100 Received: from ac78840 ([193.118.192.66]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Sep 2006 07:18:01 +0100 From: "Robert Hancock" To: , , Subject: RE: [NSIS] Jari Arkko: DISCUSS: draft-ietf-nsis-ntlp Date: Wed, 20 Sep 2006 16:17:58 +1000 Message-ID: <005901c6dc7c$86e4e100$6500000a@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: 20 Sep 2006 06:18:02.0485 (UTC) FILETIME=[86F44A50:01C6DC7C] 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: 3fbd9b434023f8abfcb1532abaec7a21 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 Jari, all, I think there is probably an issue here which can be fixed. A little background: during the development of the spec, we have steadfastly avoided trying to address the problem of getting NSIS to work through legacy NATs. That's at least partly because it seems like a nearly impossible problem, and also a major activity even to analyse all the cases (although Andreas' draft is a very promising approach). However, there has been a baby/bathwater effect, in that we don't talk about how to 'fail safely' when we encounter a legacy NAT. Actually I think the protocol can already be implemented to do this, but the relevant guidance is not explicit. Here is how I always assumed it would be done, taking the path coupled MRM (actually the hardest one) as an example: ================================================================= case 1: querying node on the internal side of the NAT Here, the initial Query is sent from the flow source address, but the NLI will contain the Querying node address. Both will be 'private' (internal side) addresses, and usually they will be different (S=0 in the common header). The IP source address will be translated but not the NLI. The consequence is that the Response will be sent to a meaningless internal address and probably not even make it out of the node in the first place. It certainly won't make it back to the Querying node. There are then two subcases: a) retransmitted Queries also have S=0. None will get replies. Eventually the Querying node will give up and believe it is the last GIST node on the path - which is essentially correct behaviour. b) some retransmitted Queries have S=1, so the Querying node address is used as the signalling source address (this is what the spec says SHOULD happen). Now the Responding node will be able to compare the NLI and IP source and see they are different where they should be the same. At this point it should send an error; a good possibility is code 9 subcode 4 (untranslated object), although maybe a dedicated error would be better. the Error will be routable towards the NAT since it now has a valid destination address. there are then two further subcases: i) the NAT is unable to forward the message (note that the IP source address of the incoming message does not match the IP destination of the outgoing one, so some types of NAT will I guess discard it). Same as case (a) above. ii) the NAT is able to forward the message. The Querying node will receive the error and give up immediately, so it is the same result as case (a) but more prompt. case 2: querying node on the external side of the NAT here, I am not sure how much detail to go into, since the processing depends so much on how the NAT has been configured. But basically, if the Query gets through, the Response can be correctly routed back through the NAT relatively easily. However, the S flag will always be set on the Response and the Querying node will detect that a NAT has been traversed and can give up again. ======================================================== This is not the whole story (there are several corner cases). However, it would strike me as a reasonable approach. If we cannot get the messages correctly through the NAT, the only solution is to give up, which the above procedures do fairly rapidly. More generally, rather than 'give up', the solution could be 'invoke some legacy NAT traversal mechanism' but I think that would best be defined in separate documents. Note also that if the MRI doesn't include addressing information, it is actually possible to operate perfectly through a legacy NAT following the above procedures, and that could also be made more explicit. Should text along these lines be included in the draft? Is more functionality required than this minimal level? cheers, robert h. > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: 15 September 2006 23:19 > To: jari.arkko@piuha.net; nsis@ietf.org > Subject: [NSIS] Jari Arkko: DISCUSS: draft-ietf-nsis-ntlp > > > Here's a DISCUSS from Jari about GIST. Robert is traveling, but it > would be good to discuss this in the WG to find out ways to > address his > DISCUSS. > > John > > >-----Original Message----- > >From: ext Jari Arkko [mailto:jari.arkko@piuha.net] > >Sent: 14 September, 2006 16:01 > >To: iesg@ietf.org > >Cc: nsis-chairs@tools.ietf.org; robert.hancock@roke.co.uk; > >hgs+nsis@cs.columbia.edu > >Subject: DISCUSS: draft-ietf-nsis-ntlp > > > >Discuss: > >> Legacy NATs: GIST messages will generally pass through NATs, but > >> unless the NAT is GIST-aware, any addressing data carried in the > >> payload will not be handled correctly. There is a dual > problem of > >> whether the GIST peers either side of the boundary can work out > >> how to address each other, and whether they can work out what > >> translation to apply to the signaling packet payloads. The > >> fundamental problem is that GIST messages contain three or four > >> interdependent addresses which all have to be consistently > >> translated, and existing generic NAT traversal techniques such as > >> STUN [23] or TURN [24] can process only two. Appropriate > >> behaviour for a GIST-aware NAT is discussed in Section 7.2. > >... > >> GIST messages must carry packet addressing and higher layer > >> information as payload data in order to define the flow signalled > >> for. (This applies to all GIST messages, regardless of > >how they are > >> encapsulated or which direction they are travelling in.) At an > >> addressing boundary the data flow packets will have their headers > >> translated; if the signaling payloads are not translated > >> consistently, the signaling messages will refer to incorrect (and > >> probably meaningless) flows after passing through the > boundary. In > >> addition, GIST handshake messages carry additional addressing > >> information about the GIST nodes themselves, and this > must also be > >> processed appropriately when traversing a NAT. > > > >I do not understand all the implications of running GIST over a > >non-modified NAT. If the implications are benign, please explain why > >that is the case. If they are serious, the protocol should fail > >gracefully upon detecting a NAT. Without additional > information I worry > > >that the design is brittle enough that it may cause harm to the > >senders, receivers, GIST nodes, or worse, outsiders when a > GIST unaware > > >NAT causes the address information to become invalid. > > > > > > > > _______________________________________________ > 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 Sep 20 04:10:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPx9S-0006oV-OK; Wed, 20 Sep 2006 04:09:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPx9S-0006oQ-B9 for nsis@ietf.org; Wed, 20 Sep 2006 04:09:50 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPx9Q-0006Bd-Qn for nsis@ietf.org; Wed, 20 Sep 2006 04:09:50 -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 k8K89U5p012074; Wed, 20 Sep 2006 10:09:42 +0200 (MEST) From: "Georgios Karagiannis" To: "'Robert Hancock'" , "'Henning Schulzrinne'" , "'Lars Eggert'" Subject: RE: [NSIS] Lars Eggert: DISCUSS and COMMENT: draft-ietf-nsis-ntlp Date: Wed, 20 Sep 2006 10:09:27 +0200 Message-ID: <000801c6dc8c$1db82f60$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: AcbcWHVPkF6R0BeqRiGLDaFTuqx7DwAM0ijg In-Reply-To: <003e01c6dc58$1083e570$6500000a@comm.ad.roke.co.uk> X-Spam-Score: -5.64 () 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]); Wed, 20 Sep 2006 10:09:44 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 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 Robert and Henning Regarding the D-mode, yes we are using it extensively in the RMD-QOSM, which is applied in environments where we can engineer the capacity of the signaling traffic. Best Regards, Georgios -----Original Message----- From: Robert Hancock [mailto:robert.hancock@roke.co.uk] Sent: woensdag 20 september 2006 3:57 To: 'Henning Schulzrinne'; 'Lars Eggert' Cc: john.loughney@nokia.com; nsis@ietf.org Subject: RE: [NSIS] Lars Eggert: DISCUSS and COMMENT: draft-ietf-nsis-ntlp Henning, Lars, all, > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: 19 September 2006 02:43 > To: Lars Eggert > Cc: ; nsis@ietf.org > Subject: Re: [NSIS] Lars Eggert: DISCUSS and COMMENT: > draft-ietf-nsis-ntlp > > > > > > It may be true that usually there is only one D-mode > message, but the > > document doesn't currently place any such restriction on > D-mode. If it > > said "send only the query in Q-mode, use C-mode for > everything else that > > follows", that'd be significantly better. My concern is > based on the > > document not placing any restrictions on how frequently > D-mode messages > > can be sent and how large they can be. > > Given that the major point of NSIS is to avoid re-inventing TCP, maybe > the best solution would indeed be to call out this restriction, i.e., > that D-mode SHOULD only be used once (and after route changes). Is this the seed of a solution? I know there will be people who want to use D-mode more extensively; however, they want to do so in environments where they can engineer capacity for the signalling traffic (don't know if that is worth adding as a rider to the SHOULD). In terms of the other ideas that have come up in previous mails, I still find it very hard to work out how an adaptive scheme could work for the Query/Response traffic, since, as Henning says, there is nothing on which to build up any information about the congestion state of the network. Restricting the number of outstanding D mode messages opens up a trivial DoS attack (signal for a flow whose endpoint silently eats Query messages; the Querying node will have to time out waiting for answers). I still think it is necessary to consider some kind of rate control discussion for the route change/peer failure case. These events could trigger a GIST node to Query for all its flows, and that has to be capped in some way. The current text sizes the token bucket on router interface capacity; #sessions is another possibility (in fact, the original proposal). They are all equally non-bulletproof, albeit in different ways. Or do people want the token bucket stuff out altogether? cheers, r. > > > _______________________________________________ > 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 Sep 20 08:23:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ16i-0007NW-V2; Wed, 20 Sep 2006 08:23:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ10G-00007D-Cf for nsis@ietf.org; Wed, 20 Sep 2006 08:16:36 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ10F-0005Ot-2M for nsis@ietf.org; Wed, 20 Sep 2006 08:16:36 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 96B6389865; Wed, 20 Sep 2006 15:16:31 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 59E7C8980A; Wed, 20 Sep 2006 15:16:31 +0300 (EEST) Message-ID: <4511310F.1040104@piuha.net> Date: Wed, 20 Sep 2006 15:16:15 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060725) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Hancock Subject: Re: [NSIS] Jari Arkko: DISCUSS: draft-ietf-nsis-ntlp References: <005901c6dc7c$86e4e100$6500000a@comm.ad.roke.co.uk> In-Reply-To: <005901c6dc7c$86e4e100$6500000a@comm.ad.roke.co.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-Mailman-Approved-At: Wed, 20 Sep 2006 08:23:16 -0400 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 Robert Hancock wrote: >If we >cannot get the messages correctly through the NAT, the only >solution is to give up, which the above procedures do >fairly rapidly. More generally, rather than 'give up', >the solution could be 'invoke some legacy NAT traversal >mechanism' but I think that would best be defined in separate >documents. > Agreed -- I certainly do not require you to design the NAT traversal so that this would actually WORK. All that is needed from my perspective is the ability fail gracefully and without causing damage to others. But I have a question about your procedure. Does it allow the response to be sent to the by-mistake-not-translated address? I think it would be better if you didn't do that, and actually detected when translation has occurred. --Jari _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Sep 20 08:55:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ1au-0005AR-N1; Wed, 20 Sep 2006 08:54:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ1au-0005AM-4A for nsis@ietf.org; Wed, 20 Sep 2006 08:54:28 -0400 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ1as-0002Jd-J9 for nsis@ietf.org; Wed, 20 Sep 2006 08:54:28 -0400 Received: from localhost (localhost.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 6AC1A200C977; Wed, 20 Sep 2006 14:54:53 +0200 (CEST) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05361-06; Wed, 20 Sep 2006 14:54:53 +0200 (CEST) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 46A0D20031E0; Wed, 20 Sep 2006 14:54:53 +0200 (CEST) Received: from n-eggert.office ([10.1.1.112]) by mx1.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Sep 2006 14:54:25 +0200 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n-eggert.office (Postfix) with ESMTP id 69499226153; Wed, 20 Sep 2006 14:54:25 +0200 (CEST) In-Reply-To: <003e01c6dc58$1083e570$6500000a@comm.ad.roke.co.uk> References: <003e01c6dc58$1083e570$6500000a@comm.ad.roke.co.uk> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 (Normal) Jabber-Id: lars.eggert@jabber.netlab.nec.de Message-Id: <8DBF8F25-1B31-45D6-973E-5C727E4095C0@netlab.nec.de> From: Lars Eggert Subject: Re: [NSIS] Lars Eggert: DISCUSS and COMMENT: draft-ietf-nsis-ntlp Date: Wed, 20 Sep 2006 14:54:23 +0200 To: Robert Hancock X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 20 Sep 2006 12:54:25.0936 (UTC) FILETIME=[E6FEE900:01C6DCB3] X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: john.loughney@nokia.com, nsis@ietf.org, 'Henning Schulzrinne' X-BeenThere: nsis@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="===============1976687898==" Errors-To: nsis-bounces@ietf.org --===============1976687898== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-11-61037879; protocol="application/pkcs7-signature" --Apple-Mail-11-61037879 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, On Sep 20, 2006, at 3:56, Robert Hancock wrote: >> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >> >> Given that the major point of NSIS is to avoid re-inventing >> TCP, maybe >> the best solution would indeed be to call out this restriction, i.e., >> that D-mode SHOULD only be used once (and after route changes). > > Is this the seed of a solution? I'd be happy with this approach. > I know there will be people who want to use D-mode more > extensively; however, they want to do so in environments > where they can engineer capacity for the signalling > traffic (don't know if that is worth adding as a rider > to the SHOULD). Adding a recommendation that more extensive use of D-mode (than the above) SHOULD only be considered together with provisioned capacity for signaling seems like a good idea. > In terms of the other ideas that have come up in previous > mails, I still find it very hard to work out how an > adaptive scheme could work for the Query/Response traffic, > since, as Henning says, there is nothing on which to build > up any information about the congestion state of the > network. Restricting the number of outstanding D mode messages > opens up a trivial DoS attack (signal for a flow whose > endpoint silently eats Query messages; the Querying node > will have to time out waiting for answers). Is that attack actually possible? There isn't any verification of whether a packet comes from a valid source? > I still think it is necessary to consider some kind of > rate control discussion for the route change/peer failure > case. These events could trigger a GIST node to Query for > all its flows, and that has to be capped in some way. The > current text sizes the token bucket on router interface > capacity; #sessions is another possibility (in fact, the > original proposal). They are all equally non-bulletproof, > albeit in different ways. Or do people want the token bucket > stuff out altogether? I don't see how the token buffer could be made to work based on interface capacity. Could you elaborate a bit on the original proposal that was based on the number of sessions? Thanks, Lars -- Lars Eggert NEC Network Laboratories --Apple-Mail-11-61037879 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKZDCCAwEw ggJqoAMCAQICEBCR/semQl5bz/x3jtiU02YwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDgxNjA5MTU0NloXDTA3MDgxNjA5MTU0 NlowYDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAL/+LXyqufw8ApYnCU24cnZ/H9S7ro4zZYeCqcyFqhwJpTcM8/yX 6Ms+16d2EtIceQS8Bas3GAUR+xfq0QI5dt8uIKM1Uy4trk8AAO0dh23+QTLw7toloArVngGIhUhC OTpVRR1bYfJTwPVpSAY43mbGhSGhwiu5035yKdYJezNWOXmuIO+lvXcD36hc5cU6AzRJkj0LYaFd WHjbfwzGmT7MO60p/7hT+aTv5xvTl/mcwslvm+KhKmJjoMYfSOF99xvuJE/rB7Ho3g6wDoeB2Tip 44Qq8CPmOHtCXzh/tF/bYo+OHStkPTzgPfOuNDMxa0/gAPEyELNL0Eh1/hC2TeMCAwEAAaM2MDQw JAYDVR0RBB0wG4EZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTAMBgNVHRMBAf8EAjAAMA0GCSqG SIb3DQEBBQUAA4GBAHdaTI5TM5wV+LG2WW+CMEmxEyNhaRu3oca9T31HjbfHzvhVJe2fzKt1xBSo +hhCg0qKVFuE7yKxDH975Csq9jVvJJj3oL29RQjPnc3CgQqlMFJKHdJgterPQ+ZiCp05S9rbMhRl 1zxB/x+GvnDFHsXu19gA2dlynrdWN/G1BVWJMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBU b3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSsw KQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAw MFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7s vc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV 84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGR MBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUu Y29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCk HjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oL LswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoL gnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHT HUb/XV9lTzCCBBgwggOBoAMCAQICAQAwDQYJKoZIhvcNAQEFBQAwgb8xCzAJBgNVBAYTAkRFMRww GgYDVQQIFBNCYWRlbi1Xw3VlcnR0ZW1iZXJnMRMwEQYDVQQHEwpIZWlkZWxiZXJnMRcwFQYDVQQK Ew5ORUMgRXVyb3BlIEx0ZDEdMBsGA1UECxMUTmV0d29yayBMYWJvcmF0b3JpZXMxGzAZBgNVBAMT EmtvYmUubmV0bGFiLm5lYy5kZTEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5l Yy5kZTAeFw0wNDA2MTgxMTUzMDhaFw0wOTA2MTcxMTUzMDhaMIG/MQswCQYDVQQGEwJERTEcMBoG A1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVyZzETMBEGA1UEBxMKSGVpZGVsYmVyZzEXMBUGA1UEChMO TkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsTFE5ldHdvcmsgTGFib3JhdG9yaWVzMRswGQYDVQQDExJr b2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMu ZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALQ5DCwTzpGu3RmzQY4KxiaQak/BwIW9Wk6K Mg+/V0aiWvlrz7uFdICBGVTKhyWr3F+GxRPCVTWqS9VEPf9A59DI9TFCS3FtraSx+w8ApQei8idb J0Lqu8tTz2O1gYR2dELID5wQH9dxIANt3bP39crgDZzGYxCJilcimFhADEgHAgMBAAGjggEgMIIB HDAdBgNVHQ4EFgQU6Hsv16oYecCFsl07g9gtjPEJo00wgewGA1UdIwSB5DCB4YAU6Hsv16oYecCF sl07g9gtjPEJo02hgcWkgcIwgb8xCzAJBgNVBAYTAkRFMRwwGgYDVQQIFBNCYWRlbi1Xw3VlcnR0 ZW1iZXJnMRMwEQYDVQQHEwpIZWlkZWxiZXJnMRcwFQYDVQQKEw5ORUMgRXVyb3BlIEx0ZDEdMBsG A1UECxMUTmV0d29yayBMYWJvcmF0b3JpZXMxGzAZBgNVBAMTEmtvYmUubmV0bGFiLm5lYy5kZTEo MCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZYIBADAMBgNVHRMEBTADAQH/ MA0GCSqGSIb3DQEBBQUAA4GBAJfoil3cAX3cUPMFrDdlW9DPMK/+QY8EHPOsnefm77h5CmmY6J+G 5Ydl9vyHxL76Opyg8cZWOOU/k9oVv7AvQ1GmIFqVFyWKQPfEhj+EWjEnUAcI7QDN8XER+U7XRvj6 yYysFgm2Tl30QCGvmESCgYIztCKMG2cLBkEosj2kWBbXMYIDsjCCA64CAQEwdjBiMQswCQYDVQQG EwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBCR/semQl5bz/x3jtiU02YwCQYFKw4D AhoFAKCCAhEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwOTIw MTI1NDI0WjAjBgkqhkiG9w0BCQQxFgQUEFfOO1hvfWOCpNCNr1HL4B0GYAswgdYGCSsGAQQBgjcQ BDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcxEzAR BgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExROZXR3 b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZIhvcN AQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsqhkiG9w0BCRACCzGByKCBxTCB vzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhl aWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9y YXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJz LmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUABIIBALh6ja+y+JJ7IZgb7/ix n3Nex8NfmkdVcFazWdpGyk2BM0v0Jxp/6XRdFuXv5f57kK1Z/7TRVRXgiXeRHSF6wjIXaoJrReTF AY23c97a4KLZZbwzDDuBv5dMa1saSplaJG14i8TEp/VWmoaD1VMz8hlaqTbtJQwIwFzKBkd33STM tgRaTOUme467OVWuSLUOWEWhR5LUKBiQOzPW4RD+qm1zuGsJ5jSe+tfPfC2PVmvvHh/1ioTSZdIz dzQp7bs/brtx3DaHr1MHn9DxjRqE5cP7dK6YYZ/MdaE5ORLnDS+92+LmzP6uD1tgseIMeQlGdiZH Ly9HrhmLD3Cdr4lLFa8AAAAAAAA= --Apple-Mail-11-61037879-- --===============1976687898== 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 --===============1976687898==-- From nsis-bounces@ietf.org Wed Sep 20 09:21:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ202-0007iA-GP; Wed, 20 Sep 2006 09:20:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ200-0007i5-Un for nsis@ietf.org; Wed, 20 Sep 2006 09:20:24 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ1zx-00058O-7R for nsis@ietf.org; Wed, 20 Sep 2006 09:20:24 -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 k8KDJvwF029206; Wed, 20 Sep 2006 14:19:57 +0100 Received: from ac78840 ([193.118.192.66]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Sep 2006 14:19:57 +0100 From: "Robert Hancock" To: "'Jari Arkko'" Subject: RE: [NSIS] Jari Arkko: DISCUSS: draft-ietf-nsis-ntlp Date: Wed, 20 Sep 2006 23:19:58 +1000 Message-ID: <004101c6dcb7$7a7d0f60$6500000a@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: <4511310F.1040104@piuha.net> Importance: Normal X-OriginalArrivalTime: 20 Sep 2006 13:19:57.0493 (UTC) FILETIME=[77DFF650:01C6DCB7] 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: 538aad3a3c4f01d8b6a6477ca4248793 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 jari, > Robert Hancock wrote: > > >If we > >cannot get the messages correctly through the NAT, the only > >solution is to give up, which the above procedures do > >fairly rapidly. More generally, rather than 'give up', > >the solution could be 'invoke some legacy NAT traversal > >mechanism' but I think that would best be defined in separate > >documents. > > > Agreed -- I certainly do not require you to design the NAT > traversal so that this would actually WORK. All that is > needed from my perspective is the ability fail gracefully > and without causing damage to others. > > But I have a question about your procedure. Does it allow > the response to be sent to the by-mistake-not-translated > address? I think it would be better if you didn't do that, and > actually detected when translation has occurred. > > --Jari it depends on what's in your armoury of NAT detection mechanisms. if the only method is comparison between header addresses and addresses in the payload, then the answer is "sometimes". what you need to do is find something in the payload which should match either the source or destination address. the NLI is guaranteed to match the source address if S=1 which is nearly guaranteed to be true for some Queries and all Responses. the only other addressing field is the MRI, which might or might not be useful depending on the routing method; there would be quite a lot of different cases to specify even given the current two MRMs, and i'm pretty sure some would fail (and we don't know what the future will bring in this area). if we really want guaranteed NAT detection, i think the only reasonably simple way to do it is to include a full copy of the header in the payload. Even then we have to accept that some messages will get sent that may not arrive, because we have no way to know if the Error (which is useful) will actually get back through the NAT. this seems to me like a rather narrow tradeoff: the cost is not that great, but neither is the benefit. i'm not sure how to make that call. cheers, r. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Sep 20 09:36:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ2Eu-0001a6-RC; Wed, 20 Sep 2006 09:35:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ2Et-0001Xy-8a for nsis@ietf.org; Wed, 20 Sep 2006 09:35:47 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ2Er-00072B-CU for nsis@ietf.org; Wed, 20 Sep 2006 09:35:47 -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 k8KDZ3Z5032291; Wed, 20 Sep 2006 14:35:03 +0100 Received: from ac78840 ([193.118.192.66]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Sep 2006 14:35:02 +0100 From: "Robert Hancock" To: "'Lars Eggert'" Subject: RE: [NSIS] Lars Eggert: DISCUSS and COMMENT: draft-ietf-nsis-ntlp Date: Wed, 20 Sep 2006 23:35:01 +1000 Message-ID: <004401c6dcb9$97105bd0$6500000a@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: <8DBF8F25-1B31-45D6-973E-5C727E4095C0@netlab.nec.de> Importance: Normal X-OriginalArrivalTime: 20 Sep 2006 13:35:03.0342 (UTC) FILETIME=[93CD8CE0:01C6DCB9] 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: 6e922792024732fb1bb6f346e63517e4 Cc: john.loughney@nokia.com, nsis@ietf.org, 'Henning Schulzrinne' X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.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, > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@netlab.nec.de] > Sent: 20 September 2006 22:54 > To: Robert Hancock > Cc: 'Henning Schulzrinne'; john.loughney@nokia.com; nsis@ietf.org > Subject: Re: [NSIS] Lars Eggert: DISCUSS and COMMENT: > draft-ietf-nsis-ntlp > > > Hi, > > On Sep 20, 2006, at 3:56, Robert Hancock wrote: > >> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > >> > >> Given that the major point of NSIS is to avoid re-inventing > >> TCP, maybe > >> the best solution would indeed be to call out this > restriction, i.e., > >> that D-mode SHOULD only be used once (and after route changes). > > > > Is this the seed of a solution? > > I'd be happy with this approach. awesome, to coin a phrase :-) > > > I know there will be people who want to use D-mode more > > extensively; however, they want to do so in environments > > where they can engineer capacity for the signalling > > traffic (don't know if that is worth adding as a rider > > to the SHOULD). > > Adding a recommendation that more extensive use of D-mode (than the > above) SHOULD only be considered together with provisioned capacity > for signaling seems like a good idea. OK (and the people who want it would be happy too). > > > In terms of the other ideas that have come up in previous > > mails, I still find it very hard to work out how an > > adaptive scheme could work for the Query/Response traffic, > > since, as Henning says, there is nothing on which to build > > up any information about the congestion state of the > > network. Restricting the number of outstanding D mode messages > > opens up a trivial DoS attack (signal for a flow whose > > endpoint silently eats Query messages; the Querying node > > will have to time out waiting for answers). > > Is that attack actually possible? There isn't any verification of > whether a packet comes from a valid source? I refer you to the SAVA bof (it's basically the same problem). We can filter some out but not everything. But in any case, that question is moot: the signalling could come from an entirely valid source - it's the destination that isn't valid. A simple approach would be to signal for a flow into a paranoid corporate network (i.e. valid address space) which never emitted any outgoing diagnostics. > > > I still think it is necessary to consider some kind of > > rate control discussion for the route change/peer failure > > case. These events could trigger a GIST node to Query for > > all its flows, and that has to be capped in some way. The > > current text sizes the token bucket on router interface > > capacity; #sessions is another possibility (in fact, the > > original proposal). They are all equally non-bulletproof, > > albeit in different ways. Or do people want the token bucket > > stuff out altogether? > > I don't see how the token buffer could be made to work based on > interface capacity. Could you elaborate a bit on the original > proposal that was based on the number of sessions? it didn't get much more elaborate than that (we were discussing http://www3.ietf.org/proceedings/06jul/slides/nsis-10/sld7.htm in the session and the interface rate approach came up as an alternative). you would size the bucket on the number of established sessions and the session refresh time being used plus a bit of headroom. but this is still not robust (for example, a routing change which puts flows onto a lower capacity link would still be a problem). cheers, robert h. > > Thanks, > Lars > -- > Lars Eggert NEC Network > Laboratories > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Sep 20 10:02:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ2dk-0004ZM-SW; Wed, 20 Sep 2006 10:01:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ2dj-0004ZH-I3 for nsis@ietf.org; Wed, 20 Sep 2006 10:01:27 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ2dg-0001Xm-Nm for nsis@ietf.org; Wed, 20 Sep 2006 10:01:27 -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 k8KE109B005172; Wed, 20 Sep 2006 15:01:00 +0100 Received: from ac78840 ([193.118.192.66]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Sep 2006 15:00:59 +0100 From: "Robert Hancock" To: , , Subject: RE: [NSIS] Lars Eggert: DISCUSS and COMMENT: draft-ietf-nsis-ntlp Date: Thu, 21 Sep 2006 00:01:02 +1000 Message-ID: <005101c6dcbd$37d76330$6500000a@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: Importance: Normal X-OriginalArrivalTime: 20 Sep 2006 14:00:59.0915 (UTC) FILETIME=[3397BDB0:01C6DCBD] 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: 55503977758b6a5197d8a2b5141eae86 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, lars, all, some comments on the comments and discuss (not including the rate control issue): > >From: ext Lars Eggert [mailto:lars.eggert@netlab.nec.de] > > > >Discuss: > > DISCUSS: For anything sent over UDP, i.e., D- and Q-mode, > it must be > > made clear that messages must have payloads smaller than the PMTU > > (minus headers) or 512 bytes if the PMTU is unknown, to avoid > > fragmentation. (Section 5.4.1 and 5.8.1.2 do so, but other > >sections do > > not.) Because some messages MUST be transmitted in D- or > Q-mode, are > > such messages guaranteed to be less than this limit in all cases? on the MTU front: fair point. Probably the note in 5.8.1.2 should really be in 5.3 (where it applies to all cases of D mode). See below on actual message sizes. > > > > > >Section 3.5., paragraph 8: > >> o Messages with the same SID that are to be delivered reliably > >> between the same GIST peers are delivered in order. > > > > DISCUSS: If messages with the same SID go over different messaging > > associations, there is a possibility that they reach the > peer out-of > > order, even if each messaging association guarantees in-order > > delivery. I don't see this case addressed in the document. > > it's not addressed explicitly; the simple solution is not to distribute messages for the same SID over multiple associations. if (for some reason) you need to create a new association while an existing one is active, you can either close the existing one gracefully (4.4.3) or use a MA-Hello request/response to flush the connection. do you want this highlighted more? [snip] > > > >Comment: > >COMMENT: > > > > Nit: Mixes US and British English (e.g., signalling vs. signaling, > > etc.) - pick one. signalling it is then ;-) > > > > > >Section 3.1., paragraph 7: > >> Figure 2: Protocol Stacks for Signaling Transport > > > > Nit: TLS doesn't currently operate over DCCP, and there are some > > issues with operating over some variants of SCTP. > > true; the diagram is supposed to be indicating the general structure rather than precisely the detailed stacks that can be used. Maybe add a note that not all protocol combinations are possible and the allowed ones are in 5.7? > > > > > >Section 3., paragraph 0: > >> a messaging association. The Query is encapsulated in a UDP > >> datagram and injected into the network, addressed > towards the > >> flow destination and with an IP Router Alert Option (RAO) > >> included. > > > > Some IP options force packets onto a router's slow path, which may > > contribute to resource exhaustion. I assume that the authors have > > verified that Router Alert Options are safe to use in this regard? its difficult to be definitive. however, we do believe while not all routers can handle the RAO in their fast path, at least some can, and that from that point of view it is the safest way to mark packets for interception which also allows a subset of the marked packets to be pulled out of the fast path for interception (which is basically a requirement for the multi-application support). Further discussion of the RAO is in the extensibility document. Basically, the path- coupling mandate of NSIS requires packet interception, and the RAO appears to have the optimum design for that. > > > > > >Section 4., paragraph 0: > >> 4. The Query passes through the network towards the flow > >receiver, > >> and is seen by each router in turn. GIST-unaware > routers will > >> not recognise the RAO value and will forward the message > >> unchanged; GIST-aware routers which do not support > the NSLP in > >> question will also forward the message basically unchanged, > >> although they may need to process more of the message > >to decide > >> this. > > > > Many middleboxes drop packets with IP options (Alberto Medina, Mark > > Allman, Sally Floyd. Measuring the Evolution of Transport > >Protocols in > > the Internet. ACM Computer Communication Review, 35(2), > April 2005.) > > Although I assume that this will mostly occur on the first or last > > couple of hops, this can still interfere with end-to-end NSIS > > operation. true. one approach would be to allow a Querying node to fall back to encapsulating without the RAO if the first message(s) fail. However, this would interact with other fallback processing (source address setting, relevant to the NAT discovery case) and would also make the interception more complex. > > > > > >Section 4.1.2., paragraph 2: > >> Reliability: This attribute may be 'true' or 'false'. > >When 'true', > >> messages MUST be delivered to the signaling > application in the > >> peer exactly once or not at all; > > > > "Once or not at all" isn't exactly the typically definition of > > reliability. Is there a better term for what is meant here? I believe this is the same semantic that TCP provides (once you take into account error conditions). I can't offer a better term. > > > > > >Section 4.1.2., paragraph 3: > >> TCP is considered in Section 5.7.2. Messages with the > >same SID to > >> the same peer MUST be delivered in order. > > > > ...unless they are not delivered at all. True. > > > > > >Section 4.1.2., paragraph 4: > >> When 'false', a message > >> may be delivered, once, several times or not at all, > >with no error > >> indications in any case. > > > > What about reordering when "false" - are duplicates of a message > > allowed to arrive after later messages have arrived? Yes. Basically, if 'false', GIST does no better than the underlying Internet, which can do what you say. > > > > > >Section 4.1.2., paragraph 6: > >> intermediate nodes. An NSLP may also indicate that > >reverse path > >> routing state will not be needed for this flow, to > inhibit the > >> node requesting its downstream peer to create it. > > > > s/may/MAY/ I believe not. This document is not intended to specify NSLP behaviour normatively, so I think 2119 language would be inappropriate. > > > > > >Section 4.3.2., paragraph 1: > >> prevent looping, MUST be checked and decremented immediately the > >> message has been received. Further processing depends on the > >> message > > > > Nit: s/immediately the/immediately after the/ OK. > > > > > >Section 5.2.2., paragraph 10: > >> The setting and interpretation of the IP-TTL field > >depends on the > >> message direction (upstream/downstream as determined > >from the MRI > >> as described above) and encapsulation. > > > > Routers may decrement the IP TTL by more than than 1, and > there is no > > requirement that routers use the same decrement value on all > > interfaces. Is this mechanism robust under these conditions? > > I think so. The mechanism is only measuring/reporting IP TTL change to compare it to the IP TTL change that normal data packets would see. So, given that the Query is being routed like a normal data packet (including through the same interfaces), I don't see a problem. > > > >Section 5.3.3., paragraph 2: > >> Query messages which do not receive Responses MAY be > >retransmitted; > >> retransmissions MUST use a binary exponential backoff. > >The initial > >> timer value is T1, which the backoff process can > increase up to a > >> maximum value of T2 seconds. The default value for T1 is > >500 ms. T1 > >> is an estimate of the round-trip time between the querying and > >> responding nodes. Elements MAY use smaller values of > T1 if it is > >> known that the Query should be answered within the local > >network. T1 > >> MAY be chosen larger, and this is RECOMMENDED if it is known in > >> advance (such as on high latency access links) that the > round-trip > >> time is larger. The default value of T2 is 64*T1. > > > > 500ms seems short. TCP uses T1=3sec for SYN retransmissions and DNS > > uses T1=5sec. (However, I think SIP uses 500ms, too?) > > Yes, and that was the origin of the value here. The response is supposed to be lightweight to generate, and it is important that T1 is not too large since it is the basis for the time taken to detect some critical failures (last node, node behind a NAT, etc.) > > > > > >Section 2., paragraph 2: > >> It can be seen that all of these transport protocol > options can be > >> supported by the basic GIST message format already > >presented. GIST > >> messages requiring fragmentation must be carried using > a reliable > >> transport protocol, TCP or SCTP. This specification > >defines only the > >> use of TCP, but other possibilities could be included without > >> additional work on message formatting. > > > > This paragraph should be moved to 5.1 or even earlier, as it is not > > specific to C-mode. I don't follow. The paragraph is entirely about C mode (since only in this mode can these protocols be used). > > It would also be good to discuss in more detail > > what "require fragmentation" means, i.e., > > GIST message > path MTU (or > > 512 bytes, if path MTU is unknown). We can say that. > > Additionally, because some > > messages MUST be carried in D- or Q-mode - is it guaranteed > > that their payloads are always less than 512 bytes? In theory no, because things like the cookies and peer identity are variable length strings. But I just did a quick count, and with a worst case for the other fields (e.g. using v6 addresses, and a couple of possible stack proposals) adds up to about 150 bytes. So I think we are safe. > > > > Also, s/must/MUST/. OK. > > > > > >Section 5.4.2., paragraph 0: > >> 5.4.2. Encapsulation Format > > > > Move up, section is not specific to C-mode. Section 5.4 should > > probably be restructured after these changes. Again, this is about C mode (see above). > > > > > >Section 5.7.1., paragraph 1: > >> A key attribute of GIST is that it is flexible in its > >ability to use > >> existing transport and security protocols. Different transport > >> protocols may have performance attributes appropriate > to different > >> environments; different security protocols may fit > >appropriately with > >> different authentication infrastructures. > > > > All protocols defined in the subsections of this section are for > > C-mode - what about D-mode? D mode only uses UDP+nothing. No flexibility is intended; if you wanted to negotiate another protocol, one would do so with the C-mode mechanisms. It is probably worth saying this explicitly. > > > > > >Section 5.8.1.3., paragraph 0: > >> 5.8.1.3. Upstream Q-mode Encapsulation > > > > No restriction on message size. See DISCUSS. Noted. > > > > > >Section 6.2., paragraph 20: > >> Rule 4: > > > > Nit: Pseudocode not indented. Indentation not needed (rule 4 contains six steps at the same nesting level; the ifs are genuine 1-liners). > > > > > >Section 7.2., paragraph 0: > >> 7.2. NAT Traversal > > > > Are any GIST-aware NATs in existence? It seems that this section is > > mostly about a hypothetical mechanism. Hmm. It would seem that any discussion of special treatment required for NAT traversal for a new protocol is *bound* to be hypothetical while that spec is being written. What are you suggesting to be done with the section? (BTW the mechanisms in this section have been implemented in GIST nodes and NATs, although they are not as yet widely deployed.) > > > > > >Section 7.3., paragraph 0: > >> 7.3. Interaction with IP Tunnelling > > > > This subsection doesn't really belong under "Advanced Protocol > > Features." Yes, it turned out to be less advanced than we expected. Are you suggesting it to be moved earlier? From the point of view of the document structure I'd prefer to leave it where it is - it isn't needed to understand the earlier sections, which are already pretty long. 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 Wed Sep 20 10:28:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ32x-0005uQ-Vz; Wed, 20 Sep 2006 10:27:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ32w-0005uH-EN for nsis@ietf.org; Wed, 20 Sep 2006 10:27:30 -0400 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ32t-0005wv-OU for nsis@ietf.org; Wed, 20 Sep 2006 10:27:30 -0400 Received: from localhost (localhost.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 67B0E200C982; Wed, 20 Sep 2006 16:27:54 +0200 (CEST) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07587-08; Wed, 20 Sep 2006 16:27:54 +0200 (CEST) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 44B8C200C981; Wed, 20 Sep 2006 16:27:54 +0200 (CEST) Received: from n-eggert.office ([10.1.1.112]) by mx1.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Sep 2006 16:27:26 +0200 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n-eggert.office (Postfix) with ESMTP id 6BE6422637B; Wed, 20 Sep 2006 16:27:26 +0200 (CEST) In-Reply-To: <005101c6dcbd$37d76330$6500000a@comm.ad.roke.co.uk> References: <005101c6dcbd$37d76330$6500000a@comm.ad.roke.co.uk> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 (Normal) Jabber-Id: lars.eggert@jabber.netlab.nec.de Message-Id: From: Lars Eggert Subject: Re: [NSIS] Lars Eggert: DISCUSS and COMMENT: draft-ietf-nsis-ntlp Date: Wed, 20 Sep 2006 16:27:23 +0200 To: Robert Hancock X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 20 Sep 2006 14:27:26.0891 (UTC) FILETIME=[E5810FB0:01C6DCC0] X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 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: , Content-Type: multipart/mixed; boundary="===============0719107708==" Errors-To: nsis-bounces@ietf.org --===============0719107708== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-17-66617851; protocol="application/pkcs7-signature" --Apple-Mail-17-66617851 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, below, I've cut all the stuff I agree with in your original email. On Sep 20, 2006, at 16:01, Robert Hancock wrote: >>> Section 3.5., paragraph 8: >>>> o Messages with the same SID that are to be delivered reliably >>>> between the same GIST peers are delivered in order. >>> >>> DISCUSS: If messages with the same SID go over different messaging >>> associations, there is a possibility that they reach the >> peer out-of >>> order, even if each messaging association guarantees in-order >>> delivery. I don't see this case addressed in the document. >>> > > it's not addressed explicitly; the simple solution is not to > distribute messages for the same SID over multiple associations. > if (for some reason) you need to create a new association while > an existing one is active, you can either close the existing one > gracefully (4.4.3) or use a MA-Hello request/response to flush > the connection. do you want this highlighted more? I asume "this" is that only a single MA MUST be used for messages for the same SID? Then yes, please. >>> Some IP options force packets onto a router's slow path, which may >>> contribute to resource exhaustion. I assume that the authors have >>> verified that Router Alert Options are safe to use in this regard? > > its difficult to be definitive. however, we do believe while not all > routers can handle the RAO in their fast path, at least some can, > and that from that point of view it is the safest way to mark packets > for interception which also allows a subset of the marked packets to > be pulled out of the fast path for interception (which is basically > a requirement for the multi-application support). Further discussion > of the RAO is in the extensibility document. Basically, the path- > coupling mandate of NSIS requires packet interception, and the RAO > appears to have the optimum design for that. We should involve the RTG/INT ADs here. We just had a discussion in the IESG on a similar mechanism that used IP options, where the stance was basically that everything that forces stuff on the slow- path is almost a DoS on the router CPU. >>> Many middleboxes drop packets with IP options (Alberto Medina, Mark >>> Allman, Sally Floyd. Measuring the Evolution of Transport >>> Protocols in >>> the Internet. ACM Computer Communication Review, 35(2), >> April 2005.) >>> Although I assume that this will mostly occur on the first or last >>> couple of hops, this can still interfere with end-to-end NSIS >>> operation. > > true. one approach would be to allow a Querying node to fall back to > encapsulating without the RAO if the first message(s) fail. However, > this would interact with other fallback processing (source address > setting, relevant to the NAT discovery case) and would also make the > interception more complex. Encapsulation would also alleviate the possible concerns due to use of an IP option for the previous comment, so this might be something that needs some investigation. >>> Additionally, because some >>> messages MUST be carried in D- or Q-mode - is it guaranteed >>> that their payloads are always less than 512 bytes? > > In theory no, because things like the cookies and peer identity > are variable length strings. But I just did a quick count, and > with a worst case for the other fields (e.g. using v6 addresses, > and a couple of possible stack proposals) adds up to about 150 > bytes. So I think we are safe. Since you were going to add MTU-related text anyway, it may be good to point out that if payloads grow past the MTU, C-mode SHOULD be used if possible. >>> Section 5.4.2., paragraph 0: >>>> 5.4.2. Encapsulation Format >>> >>> Move up, section is not specific to C-mode. Section 5.4 should >>> probably be restructured after these changes. > > Again, this is about C mode (see above). But not only about C-mode - D-mode uses the same encapsulation format, no? (Similar to the prior comment, which should be located in the D-mode section, because it recommends to not use D-mode in a specific case.) >>> Section 7.3., paragraph 0: >>>> 7.3. Interaction with IP Tunnelling >>> >>> This subsection doesn't really belong under "Advanced Protocol >>> Features." > > Yes, it turned out to be less advanced than we expected. > Are you suggesting it to be moved earlier? From the point > of view of the document structure I'd prefer to leave it > where it is - it isn't needed to understand the earlier > sections, which are already pretty long. Maybe just change the title of section 7? Lars -- Lars Eggert NEC Network Laboratories --Apple-Mail-17-66617851 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKZDCCAwEw ggJqoAMCAQICEBCR/semQl5bz/x3jtiU02YwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDgxNjA5MTU0NloXDTA3MDgxNjA5MTU0 NlowYDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAL/+LXyqufw8ApYnCU24cnZ/H9S7ro4zZYeCqcyFqhwJpTcM8/yX 6Ms+16d2EtIceQS8Bas3GAUR+xfq0QI5dt8uIKM1Uy4trk8AAO0dh23+QTLw7toloArVngGIhUhC OTpVRR1bYfJTwPVpSAY43mbGhSGhwiu5035yKdYJezNWOXmuIO+lvXcD36hc5cU6AzRJkj0LYaFd WHjbfwzGmT7MO60p/7hT+aTv5xvTl/mcwslvm+KhKmJjoMYfSOF99xvuJE/rB7Ho3g6wDoeB2Tip 44Qq8CPmOHtCXzh/tF/bYo+OHStkPTzgPfOuNDMxa0/gAPEyELNL0Eh1/hC2TeMCAwEAAaM2MDQw JAYDVR0RBB0wG4EZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTAMBgNVHRMBAf8EAjAAMA0GCSqG SIb3DQEBBQUAA4GBAHdaTI5TM5wV+LG2WW+CMEmxEyNhaRu3oca9T31HjbfHzvhVJe2fzKt1xBSo +hhCg0qKVFuE7yKxDH975Csq9jVvJJj3oL29RQjPnc3CgQqlMFJKHdJgterPQ+ZiCp05S9rbMhRl 1zxB/x+GvnDFHsXu19gA2dlynrdWN/G1BVWJMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBU b3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSsw KQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAw MFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7s vc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV 84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGR MBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUu Y29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCk HjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oL LswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoL gnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHT HUb/XV9lTzCCBBgwggOBoAMCAQICAQAwDQYJKoZIhvcNAQEFBQAwgb8xCzAJBgNVBAYTAkRFMRww GgYDVQQIFBNCYWRlbi1Xw3VlcnR0ZW1iZXJnMRMwEQYDVQQHEwpIZWlkZWxiZXJnMRcwFQYDVQQK Ew5ORUMgRXVyb3BlIEx0ZDEdMBsGA1UECxMUTmV0d29yayBMYWJvcmF0b3JpZXMxGzAZBgNVBAMT EmtvYmUubmV0bGFiLm5lYy5kZTEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5l Yy5kZTAeFw0wNDA2MTgxMTUzMDhaFw0wOTA2MTcxMTUzMDhaMIG/MQswCQYDVQQGEwJERTEcMBoG A1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVyZzETMBEGA1UEBxMKSGVpZGVsYmVyZzEXMBUGA1UEChMO TkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsTFE5ldHdvcmsgTGFib3JhdG9yaWVzMRswGQYDVQQDExJr b2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMu ZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALQ5DCwTzpGu3RmzQY4KxiaQak/BwIW9Wk6K Mg+/V0aiWvlrz7uFdICBGVTKhyWr3F+GxRPCVTWqS9VEPf9A59DI9TFCS3FtraSx+w8ApQei8idb J0Lqu8tTz2O1gYR2dELID5wQH9dxIANt3bP39crgDZzGYxCJilcimFhADEgHAgMBAAGjggEgMIIB HDAdBgNVHQ4EFgQU6Hsv16oYecCFsl07g9gtjPEJo00wgewGA1UdIwSB5DCB4YAU6Hsv16oYecCF sl07g9gtjPEJo02hgcWkgcIwgb8xCzAJBgNVBAYTAkRFMRwwGgYDVQQIFBNCYWRlbi1Xw3VlcnR0 ZW1iZXJnMRMwEQYDVQQHEwpIZWlkZWxiZXJnMRcwFQYDVQQKEw5ORUMgRXVyb3BlIEx0ZDEdMBsG A1UECxMUTmV0d29yayBMYWJvcmF0b3JpZXMxGzAZBgNVBAMTEmtvYmUubmV0bGFiLm5lYy5kZTEo MCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZYIBADAMBgNVHRMEBTADAQH/ MA0GCSqGSIb3DQEBBQUAA4GBAJfoil3cAX3cUPMFrDdlW9DPMK/+QY8EHPOsnefm77h5CmmY6J+G 5Ydl9vyHxL76Opyg8cZWOOU/k9oVv7AvQ1GmIFqVFyWKQPfEhj+EWjEnUAcI7QDN8XER+U7XRvj6 yYysFgm2Tl30QCGvmESCgYIztCKMG2cLBkEosj2kWBbXMYIDsjCCA64CAQEwdjBiMQswCQYDVQQG EwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBCR/semQl5bz/x3jtiU02YwCQYFKw4D AhoFAKCCAhEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwOTIw MTQyNzI0WjAjBgkqhkiG9w0BCQQxFgQUUZy3pj+mrngRmT4J2QyXrjtofNAwgdYGCSsGAQQBgjcQ BDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcxEzAR BgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExROZXR3 b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZIhvcN AQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsqhkiG9w0BCRACCzGByKCBxTCB vzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhl aWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9y YXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJz LmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUABIIBABsk+4yL77Jq1wXkhirJ EY4Zc1jldraE8yuycX1xAflBfffi/YYQf2DF2I0HvzGYutRBNaFBDNx4C9Cy/gsY8s2/5hx7/8lm lfhxYeoVs+Y7Ru743e19WRb3Tzs2HGm1msE2SSBzxU744wWGu42bBZPgj4xChQpYEhtltA7BP8oz EIDlMgNx4JIIRU/15yZEDSOvHPEEpmg0aLui0f7QGBtfMLb9uRDecA47rYCWmy0EqucHtbxL2Plv oUBxMHJwvXupLEXaJCyVY3cahuQQ4CxAaRwL9A3GBp+3aSzFdm6xubZRt1hb6kTzwjhKfjZo9fWZ xCKVwmUFJA0AUdIm27AAAAAAAAA= --Apple-Mail-17-66617851-- --===============0719107708== 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 --===============0719107708==-- From nsis-bounces@ietf.org Wed Sep 20 11:28:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ3zN-0002IJ-JF; Wed, 20 Sep 2006 11:27:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ3zM-0002Dk-K4 for nsis@ietf.org; Wed, 20 Sep 2006 11:27:52 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ3zL-0007E8-BE for nsis@ietf.org; Wed, 20 Sep 2006 11:27:52 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 28612E0129; Wed, 20 Sep 2006 11:27:54 -0400 (EDT) From: Sam Hartman To: "Robert Hancock" References: <000001c6dc46$e97c0b80$6500000a@comm.ad.roke.co.uk> Date: Wed, 20 Sep 2006 11:27:54 -0400 In-Reply-To: <000001c6dc46$e97c0b80$6500000a@comm.ad.roke.co.uk> (Robert Hancock's message of "Wed, 20 Sep 2006 09:54:11 +1000") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: john.loughney@nokia.com, nsis@ietf.org Subject: [NSIS] Re: multiple responses to a Query X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.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" == Robert Hancock writes: Robert> Hi Sam, I'll try to address this multiple responses issue Robert> specifically, and come back to the rest of the discuss in Robert> another mail. The situation here should be relatively Robert> simple, but it's possible that the current text has Robert> misleading aspects. Robert> The basic concept is that each Query gets one Robert> Response. The Response gets sent to the node that sent the Robert> Query (the node address comes from the NLI object in the Robert> Query message); the two nodes, Querying and Responding, Robert> are the two ends of a single GIST hop. Along an end-to-end Robert> path, there will likely be multiple GIST hops; for each of Robert> them, there is a Query/Response exchange which is local to Robert> that hop. The MRI is not changed along the path. Sorry, I meant NLI not MRI. I found nothing in the text of section 3 or early section 4 that clearly states this. I think for example updating 3.7 to include two nodes that want to be interested in the signal flow would help handle some of these issues. Robert> GIST is basically ignorant of the fact that there are Robert> multiple hops chained together in this way; linking up the Robert> hops to provide an end-to-end signalling exchange is Robert> carried out at the signalling application level (e.g. the Robert> forwarding referred to in section 3.7 step 5 is done at Robert> that level) - a single Query itself does not travel end to Robert> end. Each hop is initiated by signalling application on Robert> the node trying to send a message; GIST then carries out a Robert> local Query/ Response to get to the next node. This seems like it is discussed nowhere. It also makes 5 in 3.7 very misleading, because that behavior is dependent on the signaling application. I assumed throughout my entire reading of the document that such forwarding was an invarient of GIST. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Sep 20 11:43:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ4DQ-0002NX-L0; Wed, 20 Sep 2006 11:42:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ4DP-0002NR-5R for nsis@ietf.org; Wed, 20 Sep 2006 11:42:23 -0400 Received: from natklopstock.rzone.de ([81.169.145.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ4DN-0001NC-P0 for nsis@ietf.org; Wed, 20 Sep 2006 11:42:23 -0400 Received: from [192.168.178.200] (p5484C49D.dip0.t-ipconnect.de [84.132.196.157]) (authenticated bits=0) by post.webmailer.de (8.13.6/8.13.6) with ESMTP id k8KFg96m026596 for ; Wed, 20 Sep 2006 17:42:10 +0200 (MEST) Message-ID: <4511615D.8090206@cs.uni-goettingen.de> Date: Wed, 20 Sep 2006 17:42:21 +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: nsis@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [NSIS] Questions on QSPEC draft-11 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.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, the Parameter has a variable length (1 or 5 Bytes). >From my point of view it would be better to seperate Bandwidth and Token Bucket. It's easier to implement and the objects can be identified by the ID. Parameter has a length of 3 Bytes, but 4 integers are listed below the header. What do the values 0..7 in the field of stand for? Is there a value for Best Effort or high priority? of : higher values represent higher priority. Is there a fixed value for Best Effort? , do here also higher values represent higher priority? Any values for best effort? If I want to distinguish between 3 priority levels (best effort, normal and high priority) where are the limits for each level in , and ? Bernd _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Sep 20 18:48:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQArJ-0008Mv-L4; Wed, 20 Sep 2006 18:48:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQArI-0008Md-Ny for nsis@ietf.org; Wed, 20 Sep 2006 18:48:00 -0400 Received: from mail146.messagelabs.com ([216.82.245.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GQArE-0000Mj-DX for nsis@ietf.org; Wed, 20 Sep 2006 18:48:00 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-10.tower-146.messagelabs.com!1158792475!2381848!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 4960 invoked from network); 20 Sep 2006 22:47:55 -0000 Received: from unknown (HELO attrh9i.attrh.att.com) (134.24.146.4) by server-10.tower-146.messagelabs.com with SMTP; 20 Sep 2006 22:47:55 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh9i.attrh.att.com (8.13.7/8.13.7) with ESMTP id k8KMgFle009835; Wed, 20 Sep 2006 18:42:16 -0400 (EDT) Received: from occlust03evs1.ugd.att.com (ocst05.ugd.att.com [135.38.164.10]) by attrh9i.attrh.att.com (8.13.7/8.13.7) with ESMTP id k8KMgBYJ009815; Wed, 20 Sep 2006 18:42:11 -0400 (EDT) Received: from kcclust06evs1.ugd.att.com ([135.38.164.89]) by occlust03evs1.ugd.att.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 20 Sep 2006 17:47:50 -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] Questions on QSPEC draft-11 Date: Wed, 20 Sep 2006 17:47:49 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7D53@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <4511615D.8090206@cs.uni-goettingen.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Questions on QSPEC draft-11 thread-index: Acbcy+JUc12BApW4RQG6+IirVgXLvQAIHvYg From: "Ash, Gerald R \(Jerry\), ALABS" To: "Bernd Schloer" , X-OriginalArrivalTime: 20 Sep 2006 22:47:50.0197 (UTC) FILETIME=[CCC9FE50:01C6DD06] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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 Bernd, See below.=20 > -----Original Message----- > From: Bernd Schloer [mailto:bschloer@cs.uni-goettingen.de]=20 > Sent: Wednesday, September 20, 2006 11:42 AM > To: nsis@ietf.org > Subject: [NSIS] Questions on QSPEC draft-11 >=20 > Hi, >=20 > the Parameter has a variable length (1 or 5 Bytes). > >From my point of view it would be better to separate Bandwidth > and Token Bucket. It's easier to implement and the objects > can be identified by the ID. We had the same suggestion from Christian Dickmann is his post at http://www1.ietf.org/mail-archive/web/nsis/current/msg06658.html. It looks like a good change to make. =20 > Parameter has a length of 3 Bytes, but 4 integers > are listed below the header. Good catch. =20 > What do the values 0..7 in the field of > stand for? Is there a value for Best Effort or high > priority? These values would be defined within the DSTE context; there is no fixed mapping, see RFC 4124 http://www.ietf.org/rfc/rfc4124.txt?number=3D4124. =20 > of : higher values represent higher > priority. Is there a fixed value for Best Effort? No, these take on relative values. See the normative RFC 3181 http://www.ietf.org/rfc/rfc3181.txt?number=3D3181. =20 > , do here also higher values represent higher > priority? Any values for best effort? No, these take on relative values. See the normative RFC 3181 http://www.ietf.org/rfc/rfc3181.txt?number=3D3181. =20 > If I want to distinguish between 3 priority levels (best effort, > normal and high priority) where are the limits for each level > in , and ? Not sure I understand the question. As above, there is no fixed mapping for any of these parameters. See the normative RFCs for details, e.g., as stated in RFC 4124 http://www.ietf.org/rfc/rfc4124.txt?number=3D4124 for DSTE: "DSTE LSRs MUST allow configuration of a TE-Class mapping whereby the Class-Type and preemption level are configured for each of (up to) 8 TE-Classes... A TE-class consists of i. a Class-Type and ii. a preemption priority allowed for that Class-Type. This means that an LSP transporting a Traffic Trunk from that Class-Type can use that preemption priority as the setup priority, the holding priority, or both." Thanks, Jerry =20 >=20 > Bernd >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Sep 20 21:46:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQDdj-0003o4-Df; Wed, 20 Sep 2006 21:46:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQDdh-0003no-Rp for nsis@ietf.org; Wed, 20 Sep 2006 21:46:09 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQDdb-0005LR-6t for nsis@ietf.org; Wed, 20 Sep 2006 21:46:09 -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 k8L1jmuT026278; Thu, 21 Sep 2006 02:45:52 +0100 Received: from ac78840 ([193.118.192.66]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Sep 2006 02:45:48 +0100 From: "Robert Hancock" To: "'Sam Hartman'" Date: Thu, 21 Sep 2006 11:45:45 +1000 Message-ID: <007c01c6dd1f$a985f110$6500000a@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: 21 Sep 2006 01:45:48.0782 (UTC) FILETIME=[A9B8C0E0:01C6DD1F] 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: f60d0f7806b0c40781eee6b9cd0b2135 Cc: nsis@ietf.org Subject: [NSIS] RE: multiple responses to a Query X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.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 sam, Basically I'll apologise now that the text has led you astray in this way. I think the question now is how and where to clarify the text to avoid other people falling into the same trap. One possibility would be to make a normative reference to the framework (rfc4080) and highlight it as required reading. For example, section 3.2.2 of RFC4080 covers exactly this point (i think fairly unambiguously). On the other hand, it is just more text for the implementor to read. Do you think that extending 3.7 of the GIST spec itself to cover who takes responsibility for what for the multi-hop aspects would be enough? cheers & thanks for your patience, robert h. > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > Sent: 21 September 2006 01:28 > To: Robert Hancock > Cc: john.loughney@nokia.com; nsis@ietf.org > Subject: Re: multiple responses to a Query > > > >>>>> "Robert" == Robert Hancock writes: > > Robert> Hi Sam, I'll try to address this multiple responses issue > Robert> specifically, and come back to the rest of the discuss in > Robert> another mail. The situation here should be relatively > Robert> simple, but it's possible that the current text has > Robert> misleading aspects. > > Robert> The basic concept is that each Query gets one > Robert> Response. The Response gets sent to the node that sent the > Robert> Query (the node address comes from the NLI object in the > Robert> Query message); the two nodes, Querying and Responding, > Robert> are the two ends of a single GIST hop. Along an end-to-end > Robert> path, there will likely be multiple GIST hops; for each of > Robert> them, there is a Query/Response exchange which is local to > Robert> that hop. The MRI is not changed along the path. > > Sorry, I meant NLI not MRI. > > I found nothing in the text of section 3 or early section 4 that > clearly states this. I think for example updating 3.7 to include two > nodes that want to be interested in the signal flow would help handle > some of these issues. > > Robert> GIST is basically ignorant of the fact that there are > Robert> multiple hops chained together in this way; linking up the > Robert> hops to provide an end-to-end signalling exchange is > Robert> carried out at the signalling application level (e.g. the > Robert> forwarding referred to in section 3.7 step 5 is done at > Robert> that level) - a single Query itself does not travel end to > Robert> end. Each hop is initiated by signalling application on > Robert> the node trying to send a message; GIST then carries out a > Robert> local Query/ Response to get to the next node. > > This seems like it is discussed nowhere. It also makes 5 in 3.7 very > misleading, because that behavior is dependent on the signaling > application. I assumed throughout my entire reading of the document > that such forwarding was an invarient of GIST. > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Sep 20 22:33:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQEN1-0004bo-Hi; Wed, 20 Sep 2006 22:32:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQEN0-0004aY-4z for nsis@ietf.org; Wed, 20 Sep 2006 22:32:58 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQEMw-0004Jn-Ec for nsis@ietf.org; Wed, 20 Sep 2006 22:32:58 -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 k8L2WcA6032638; Thu, 21 Sep 2006 03:32:42 +0100 Received: from ac78840 ([193.118.192.66]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Sep 2006 03:32:37 +0100 From: "Robert Hancock" To: "'Lars Eggert'" Subject: RE: [NSIS] Lars Eggert: DISCUSS and COMMENT: draft-ietf-nsis-ntlp Date: Thu, 21 Sep 2006 12:32:34 +1000 Message-ID: <00a901c6dd26$33829750$6500000a@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: 21 Sep 2006 02:32:38.0160 (UTC) FILETIME=[343DD100:01C6DD26] 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: 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: , Errors-To: nsis-bounces@ietf.org hi, inline: > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@netlab.nec.de] > Sent: 21 September 2006 00:27 > To: Robert Hancock > Cc: john.loughney@nokia.com; nsis@ietf.org > Subject: Re: [NSIS] Lars Eggert: DISCUSS and COMMENT: > draft-ietf-nsis-ntlp > > > Hi, > > below, I've cut all the stuff I agree with in your original email. > > On Sep 20, 2006, at 16:01, Robert Hancock wrote: > >>> Section 3.5., paragraph 8: > >>>> o Messages with the same SID that are to be > delivered reliably > >>>> between the same GIST peers are delivered in order. > >>> > >>> DISCUSS: If messages with the same SID go over different > messaging > >>> associations, there is a possibility that they reach the > >> peer out-of > >>> order, even if each messaging association guarantees in-order > >>> delivery. I don't see this case addressed in the document. > >>> > > > > it's not addressed explicitly; the simple solution is not to > > distribute messages for the same SID over multiple associations. > > if (for some reason) you need to create a new association while > > an existing one is active, you can either close the existing one > > gracefully (4.4.3) or use a MA-Hello request/response to flush > > the connection. do you want this highlighted more? > > I asume "this" is that only a single MA MUST be used for > messages for > the same SID? Then yes, please. we'll add something to cover the topic. > > >>> Some IP options force packets onto a router's slow path, > which may > >>> contribute to resource exhaustion. I assume that the authors have > >>> verified that Router Alert Options are safe to use in > this regard? > > > > its difficult to be definitive. however, we do believe while not all > > routers can handle the RAO in their fast path, at least some can, > > and that from that point of view it is the safest way to > mark packets > > for interception which also allows a subset of the marked packets to > > be pulled out of the fast path for interception (which is basically > > a requirement for the multi-application support). Further discussion > > of the RAO is in the extensibility document. Basically, the path- > > coupling mandate of NSIS requires packet interception, and the RAO > > appears to have the optimum design for that. > > We should involve the RTG/INT ADs here. We just had a discussion in > the IESG on a similar mechanism that used IP options, where the > stance was basically that everything that forces stuff on the slow- > path is almost a DoS on the router CPU. I think one needs to be careful here. Since we are talking about signalling to control the router, all the signalling that is relevant to the router will almost certainly cause an impact on the router CPU. The best we can do is to minimise the impact of signalling traffic which is not relevant to the router in question. Given that we're mandated to use packet interception for path coupling following the basic RVSP model, this means that we need - something in the packet that marks it as a potential signalling packet - something in the packet that the router can check efficiently to see if the packet can be ignored I believe the RAO is a fairly precise match for this requirement. There is more discussion of this in section 3.4 of http://tools.ietf.org/wg/nsis/draft-loughney-nsis-ext-02.txt (that text originally came from the GIST spec). Side note: interception techniques have been a topic since the start of NSIS. It was one of the biggest discussion points during the NTLP early review (search for 'interception' at http://www3.ietf.org/proceedings/04mar/235.htm; Dave and Fred are Oran and Baker respectively). The point made there is that, if you are a bad person and want to DoS the router, there are easier ways than RAO, if you can find out a router IP address. If you are not a bad person, you want to make sure that the marked packets are as small as possible percentage of the overall traffic, and C-mode enables that (and the RAO design allows rapid filtering of whatever is marked). I don't believe that the ecn-alternates use of options is strictly comparable. ecn-alternates (and similar mechanisms) require a read-write operation on the option field, rather than a filter comparison. Also, I assume it would apply to a much larger proportion of the total traffic than we are expecting here. > > >>> Many middleboxes drop packets with IP options (Alberto > Medina, Mark > >>> Allman, Sally Floyd. Measuring the Evolution of Transport > >>> Protocols in > >>> the Internet. ACM Computer Communication Review, 35(2), > >> April 2005.) > >>> Although I assume that this will mostly occur on the > first or last > >>> couple of hops, this can still interfere with end-to-end NSIS > >>> operation. > > > > true. one approach would be to allow a Querying node to fall back to > > encapsulating without the RAO if the first message(s) fail. However, > > this would interact with other fallback processing (source address > > setting, relevant to the NAT discovery case) and would also make the > > interception more complex. > > Encapsulation would also alleviate the possible concerns due to use > of an IP option for the previous comment, so this might be something > that needs some investigation. I am not clear on this. Note that encapsulation without using the RAO may make packets less likely to be dropped (solves one problem), but it makes the interception process harder because it requires 5-tuple analysis (in fact, for v6 it would require complete header chain analysis), so it makes the previous problem even worse). So there is a tradeoff to be made. > > >>> Additionally, because some > >>> messages MUST be carried in D- or Q-mode - is it guaranteed > >>> that their payloads are always less than 512 bytes? > > > > In theory no, because things like the cookies and peer identity > > are variable length strings. But I just did a quick count, and > > with a worst case for the other fields (e.g. using v6 addresses, > > and a couple of possible stack proposals) adds up to about 150 > > bytes. So I think we are safe. > > Since you were going to add MTU-related text anyway, it may be good > to point out that if payloads grow past the MTU, C-mode SHOULD be > used if possible. OK. > > >>> Section 5.4.2., paragraph 0: > >>>> 5.4.2. Encapsulation Format > >>> > >>> Move up, section is not specific to C-mode. Section 5.4 should > >>> probably be restructured after these changes. > > > > Again, this is about C mode (see above). > > But not only about C-mode - D-mode uses the same encapsulation > format, no? (Similar to the prior comment, which should be > located in > the D-mode section, because it recommends to not use D-mode in a > specific case.) Similar, but not the same. The same diagram for D mode would - remove the security encpsulation annotation - allow only a single GIST message - have an optional RAO included (for Q-mode) - have several different possible addresses in the IP header (for Q-mode) - allow only UDP as a transport In retrospect, I might be tempted to remove 5.4.2 or at least figure 5 altogether, since it it actually technically wrong for the TCP case anyway (although in practice this seems to have caused no confusion!) > > >>> Section 7.3., paragraph 0: > >>>> 7.3. Interaction with IP Tunnelling > >>> > >>> This subsection doesn't really belong under "Advanced Protocol > >>> Features." > > > > Yes, it turned out to be less advanced than we expected. > > Are you suggesting it to be moved earlier? From the point > > of view of the document structure I'd prefer to leave it > > where it is - it isn't needed to understand the earlier > > sections, which are already pretty long. > > Maybe just change the title of section 7? 'Additional'? cheers, r. > > Lars > -- > Lars Eggert NEC Network > Laboratories > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Sep 21 11:46:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQQjb-0007WQ-37; Thu, 21 Sep 2006 11:45:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQQja-0007WG-A1 for nsis@ietf.org; Thu, 21 Sep 2006 11:45:06 -0400 Received: from natklopstock.rzone.de ([81.169.145.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQQjV-0005sn-Rr for nsis@ietf.org; Thu, 21 Sep 2006 11:45:06 -0400 Received: from [192.168.178.200] (p5484BBD7.dip0.t-ipconnect.de [84.132.187.215]) (authenticated bits=0) by post.webmailer.de (8.13.6/8.13.6) with ESMTP id k8LFiWIc004740; Thu, 21 Sep 2006 17:44:32 +0200 (MEST) Message-ID: <4512B36A.3060801@cs.uni-goettingen.de> Date: Thu, 21 Sep 2006 17:44:42 +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: "Ash, Gerald R (Jerry), ALABS" Subject: Re: [NSIS] Questions on QSPEC draft-11 References: <9473683187ADC049A855ED2DA739ABCA0DDC7D53@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC7D53@KCCLUST06EVS1.ugd.att.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 Jerry, thanks for your answer. I was hoping there were fixed values. I think the best is to handle , and as normal priority, ignoring that higher values represent higher priority, when processing with a QOSM CLS. Bernd >>If I want to distinguish between 3 priority levels (best effort, >>normal and high priority) where are the limits for each level >>in , and ? > > > Not sure I understand the question. As above, there is no fixed mapping > for any of these parameters. > > See the normative RFCs for details, e.g., as stated in RFC 4124 > http://www.ietf.org/rfc/rfc4124.txt?number=4124 for DSTE: > "DSTE LSRs MUST allow configuration of a TE-Class mapping whereby the > Class-Type and preemption level are configured for each of (up to) 8 > TE-Classes... A TE-class consists of i. a Class-Type and ii. a > preemption priority allowed for that Class-Type. This means that an LSP > transporting a Traffic Trunk from that Class-Type can use that > preemption priority as the setup priority, the holding priority, or > both." _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Sep 22 05:26:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQhHy-0004G2-6g; Fri, 22 Sep 2006 05:25:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQhHx-0004Fx-Ej for nsis@ietf.org; Fri, 22 Sep 2006 05:25:41 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQhHw-0005xX-0x for nsis@ietf.org; Fri, 22 Sep 2006 05:25:41 -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 k8M9PLMM029759; Fri, 22 Sep 2006 11:25:35 +0200 (MEST) From: "Georgios Karagiannis" To: "'Ash, Gerald R \(Jerry\), ALABS'" , "'Kappler, Cornelia'" , "=?iso-8859-1?Q?'Attila_B=E1der_=28IJ/ETH=29'?=" Date: Fri, 22 Sep 2006 11:25:17 +0200 Message-ID: <000001c6de29$09feb270$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC7D36@KCCLUST06EVS1.ugd.att.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: Aca/6wl1mien3kJ5R0u2kXlkJtiCmAIP4e+wAAWS8CAAAoy9AAOH1HuAACvc7DAAAM4ZkAAAThngAA7rUXAAHft90AAEopLQAABi+9AAAL3FQAAAyKRQAAATFzAANAFP4ACdR8LQACcVEaAAAinnwACTWb4A X-Spam-Score: -5.541 () 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]); Fri, 22 Sep 2006 11:25:36 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: nsis@ietf.org Subject: [NSIS] Recommendation on QSpec-1 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 Hi Jerry, Cornelia and Attila I have made an exercise and tried to apply and use the QPSEC-1 (mandatory) and QSPEC-2 (optional) parameters into the RMD-QOSM. Please note that in my opinion one might get the same conclusions if another edge-to-edge QOSM will be used, e.g., the future PCN QOSM. My conclusions are as follows: 1) and parameters should be QSPEC-1 paramteres, but then a QNI MUST include both. A QNE that receives both these parameters must: * either strictly interpret at least one of the parameters. In this case the "R" flag and "Q" flags MUST not be set. * or remap one of the parameters into another parameter (e.g. into In this case the remapped parameter (e.g., has to set the flag. The flag should also be set. 2) The parameter influences the way of how the data packets should be treated within an edge-to-edge domain. In this way the solutions that can be provided by RMD-QOSM in situations of e.g., severe congestion are limited. Note that this also will influence a solution such as PCN in case of solving the preemption issue. My recommendation is to ignore this parameter when it has to be used in such edge-to-edge domains. This means that this parameter should be * either a QSPEC-2 parameter * or a QSPEC-1 parameter that is able to be ignored in edge-to-edge domains, without that the flags "R" and "Q" flags are set. In the last case the QOSM description should emphasize that this parameter is ignored. 3) : as already mentioned in the last version of the QSPEC template draft such a parameter cannot be mandatory, because in several countries preemption of sessions in favour of others is not allowed. Thus this parameter, should either be a QSPEC-2 parameter or a QSPEC-1 that could be in some cases ignored. Further, I would again recommend that all the parameters, MUST be included by a QNI, then a QNE that receives these parameters could: * either strictly interpret at least one of the parameters. In this case the "R" flag and "Q" flags MUST not be set. * or remap one of the parameters into another parameter In this case the remapped parameter has to set the flag. The flag should also be set. 4) : this parameter can be a QSPEC-1 parameter, but a QNI MUST include all parameters, i.e., , and . Then a QNE that receives these parameters could: * either strictly interpret at least one of the parameters. In this case the "R" flag and "Q" flags MUST not be set. * or remap one of the parameters into another parameter, e.g., "DSCP" => "PHB ID code" In this case the remapped parameter, e.g., has to set the flag. The flag should also be set. Best Regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sat Sep 23 08:34:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GR6hD-00010G-7S; Sat, 23 Sep 2006 08:33:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GR6hB-00010B-BE for nsis@ietf.org; Sat, 23 Sep 2006 08:33:25 -0400 Received: from mail146.messagelabs.com ([216.82.245.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GR6h4-0008K7-UI for nsis@ietf.org; Sat, 23 Sep 2006 08:33:25 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-14.tower-146.messagelabs.com!1159014797!2764906!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 16793 invoked from network); 23 Sep 2006 12:33:18 -0000 Received: from unknown (HELO attrh9i.attrh.att.com) (134.24.146.4) by server-14.tower-146.messagelabs.com with SMTP; 23 Sep 2006 12:33:18 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh9i.attrh.att.com (8.13.7/8.13.7) with ESMTP id k8NCRZCx013178; Sat, 23 Sep 2006 08:27:36 -0400 (EDT) Received: from ocpf01.ugd.att.com (ocpf01.ugd.att.com [135.38.164.26]) by attrh9i.attrh.att.com (8.13.7/8.13.7) with ESMTP id k8NCRXnT013161; Sat, 23 Sep 2006 08:27:34 -0400 (EDT) Received: from kcclust06evs1.ugd.att.com ([135.38.164.89]) by ocpf01.ugd.att.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 23 Sep 2006 07:33: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sat, 23 Sep 2006 07:33:12 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7D6E@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <000001c6de29$09feb270$4c0d5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Recommendation on QSpec-1 parameters thread-index: Aca/6wl1mien3kJ5R0u2kXlkJtiCmAIP4e+wAAWS8CAAAoy9AAOH1HuAACvc7DAAAM4ZkAAAThngAA7rUXAAHft90AAEopLQAABi+9AAAL3FQAAAyKRQAAATFzAANAFP4ACdR8LQACcVEaAAAinnwACTWb4AADh5INA= From: "Ash, Gerald R \(Jerry\), ALABS" To: "Georgios Karagiannis" X-OriginalArrivalTime: 23 Sep 2006 12:33:14.0403 (UTC) FILETIME=[70579F30:01C6DF0C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: "Ash, Gerald R \(Jerry\), ALABS" , nsis@ietf.org Subject: [NSIS] RE: Recommendation on QSpec-1 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 Georgios, See below.=20 > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 > Sent: Friday, September 22, 2006 5:25 AM > To: Ash, Gerald R (Jerry), ALABS; 'Kappler, Cornelia';=20 > 'Attila B=E1der (IJ/ETH)' > Cc: nsis@ietf.org > Subject: Recommendation on QSpec-1 parameters >=20 > Hi Jerry, Cornelia and Attila >=20 > I have made an exercise and tried to apply and use the =20 > QSPEC-1 (mandatory) and QSPEC-2 (optional) parameters into the=20 > RMD-QOSM. Please note that in my opinion one might get the=20 > same conclusions if > another edge-to-edge QOSM will be used, e.g., the future PCN QOSM. >=20 > My conclusions are as follows: >=20 > 1) and parameters should be QSPEC-1=20 > parameters, but then=20 > a QNI MUST include both. A QNE that receives both these=20 > parameters must: >=20 > * either strictly interpret at least one of the=20 > parameters. In this case > the "R" flag and "Q" flags MUST not be set. >=20 > * or remap one of the parameters into another parameter=20 > (e.g. into > In this case the remapped parameter (e.g., > has to set the flag. The flag should also be set. Always sending both and makes no sense to me. = The QNI sends either/or based on its QOSM. A QNE can either strictly = interpret or remap whichever parameter is sent. > 2) The parameter influences the way of how the=20 > data packets should be treated within an edge-to-edge domain. > In this way the solutions that can be provided by RMD-QOSM in=20 > situations of=20 > e.g., severe congestion are limited. Note that this also will=20 > influence a solution=20 > such as PCN in case of solving the preemption issue. > My recommendation is to ignore this parameter when it has to=20 > be used in > such edge-to-edge domains. This means that this parameter should be=20 > * either a QSPEC-2 parameter=20 > * or a QSPEC-1 parameter that is able to be ignored=20 > in edge-to-edge domains, without that the flags "R" and=20 > "Q" flags are set.=20 > In the last case the QOSM description should emphasize that > this parameter is ignored.=20 You haven't explained why the QSPEC-1 parameters cannot be strictly = interpreted or remapped. Anyway, there is essentially no support to = ignore QSPEC-1 parameters. > 3) : as already mentioned in the last version of the QSPEC > template draft > such a parameter cannot be mandatory, because in several countries > preemption of > sessions in favour of others is not allowed. Thus this=20 > parameter, should either be=20 > a QSPEC-2 parameter or a QSPEC-1 that could be in some=20 > cases ignored. Preemption is used with RSVP without problem, NSIS introduces nothing = new in that regard. However, if such an issue of 'illegality' arises = for use of preemption, perhaps a specific error code could be introduced = to address that specific issue, but I see no need for that at this = point. > Further, I would again recommend that all the =20 > parameters, MUST be included=20 > by a QNI, then a QNE that receives these parameters could: > * either strictly interpret at least one of the=20 > parameters. In this case > the "R" flag and "Q" flags MUST not be set. >=20 > * or remap one of the parameters into another parameter=20 > In this case the remapped parameter > has to set the flag. The flag should also be set. The various cases of sending parameters are described in = Section 7.2.4 of the QSPEC draft = http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-11.txt. There are = some instances where all or some of the parameters are sent, but it = makes no sense to always send all parameters. The QNI sends = parameters based on its QOSM. A QNE can either strictly interpret or = remap whichever parameter(s) are sent. =20 > 4) : this parameter can be a QSPEC-1 parameter,=20 > but a QNI MUST include=20 > all parameters, i.e., , Type> and=20 > . Then a QNE that receives these=20 > parameters could: > * either strictly interpret at least one of the=20 > parameters. In this case the "R"=20 > flag and "Q" flags MUST not be set. >=20 > * or remap one of the parameters into another parameter,=20 > e.g., "DSCP" =3D> "PHB ID code" > In this case the remapped parameter, e.g., > has to set the flag. The flag should also be set. As stated in Section 7.2.3 of the QSPEC draft = http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-11.txt: " =3D The above notation means that either , , or sub-parameters MAY be populated in the parameter. Normally only one of these sub-parameters is populated in . If more than one sub-parameter is populated, the QOSM specification document MUST give procedures for processing multiple sub-parameters." IMO this is the correct approach, it makes no sense to always send all = parameters. The QNI sends parameters based on its QOSM. A = QNE can either strictly interpret or remap whichever parameter(s) are = sent. Thanks, Jerry >=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 Sun Sep 24 02:46:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRNkH-0008UI-RG; Sun, 24 Sep 2006 02:45:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRNkG-0008UA-KD for nsis@ietf.org; Sun, 24 Sep 2006 02:45:44 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRNkG-0003ng-0F for nsis@ietf.org; Sun, 24 Sep 2006 02:45:44 -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 k8O6jWeq028622; Sun, 24 Sep 2006 09:45:32 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 24 Sep 2006 09:45:32 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 24 Sep 2006 09:45: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] RE: Recommendation on QSpec-1 parameters Date: Sun, 24 Sep 2006 09:45:31 +0300 Message-ID: In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC7D6E@KCCLUST06EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] RE: Recommendation on QSpec-1 parameters Thread-Index: Aca/6wl1mien3kJ5R0u2kXlkJtiCmAIP4e+wAAWS8CAAAoy9AAOH1HuAACvc7DAAAM4ZkAAAThngAA7rUXAAHft90AAEopLQAABi+9AAAL3FQAAAyKRQAAATFzAANAFP4ACdR8LQACcVEaAAAinnwACTWb4AADh5INAAJ8YrUA== From: To: , X-OriginalArrivalTime: 24 Sep 2006 06:45:32.0223 (UTC) FILETIME=[07ED54F0:01C6DFA5] X-Spam-Score: 0.2 (/) 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 all, It might be good to get some other people to comment on this mailing = list, to get some others' opinions on this thread. John=20 >-----Original Message----- >From: ext Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com]=20 >Sent: 23 September, 2006 15:33 >To: Georgios Karagiannis >Cc: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org >Subject: [NSIS] RE: Recommendation on QSpec-1 parameters > >Georgios, > >See below.=20 > >> -----Original Message----- >> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >> Sent: Friday, September 22, 2006 5:25 AM >> To: Ash, Gerald R (Jerry), ALABS; 'Kappler, Cornelia'; 'Attila = B=E1der=20 >> (IJ/ETH)' >> Cc: nsis@ietf.org >> Subject: Recommendation on QSpec-1 parameters >>=20 >> Hi Jerry, Cornelia and Attila >>=20 >> I have made an exercise and tried to apply and use the >> QSPEC-1 (mandatory) and QSPEC-2 (optional) parameters into the=20 >> RMD-QOSM. Please note that in my opinion one might get the same=20 >> conclusions if another edge-to-edge QOSM will be used, e.g., the=20 >> future PCN QOSM. >>=20 >> My conclusions are as follows: >>=20 >> 1) and parameters should be QSPEC-1=20 >> parameters, but then a QNI MUST include both. A QNE that=20 >receives both=20 >> these parameters must: >>=20 >> * either strictly interpret at least one of the=20 >> parameters. In this case >> the "R" flag and "Q" flags MUST not be set. >>=20 >> * or remap one of the parameters into another parameter=20 >> (e.g. into >> In this case the remapped parameter (e.g., >> has to set the flag. The flag should also be set. > >Always sending both and makes no=20 >sense to me. The QNI sends either/or based on its QOSM. A=20 >QNE can either strictly interpret or remap whichever parameter is sent. > >> 2) The parameter influences the way of=20 >how the data=20 >> packets should be treated within an edge-to-edge domain. >> In this way the solutions that can be provided by RMD-QOSM in=20 >> situations of e.g., severe congestion are limited. Note that=20 >this also=20 >> will influence a solution such as PCN in case of solving the=20 >> preemption issue. >> My recommendation is to ignore this parameter when it has to be used=20 >> in such edge-to-edge domains. This means that this parameter=20 >should be >> * either a QSPEC-2 parameter=20 >> * or a QSPEC-1 parameter that is able to be ignored=20 >> in edge-to-edge domains, without that the flags "R" and=20 >> "Q" flags are set.=20 >> In the last case the QOSM description should emphasize that >> this parameter is ignored.=20 > >You haven't explained why the QSPEC-1 parameters cannot be=20 >strictly interpreted or remapped. Anyway, there is=20 >essentially no support to ignore QSPEC-1 parameters. > >> 3) : as already mentioned in the last version of the QSPEC=20 >> template draft >> such a parameter cannot be mandatory, because in several countries=20 >> preemption of >> sessions in favour of others is not allowed. Thus this parameter,=20 >> should either be >> a QSPEC-2 parameter or a QSPEC-1 that could be in some cases=20 >> ignored. > >Preemption is used with RSVP without problem, NSIS introduces=20 >nothing new in that regard. However, if such an issue of=20 >'illegality' arises for use of preemption, perhaps a specific=20 >error code could be introduced to address that specific issue,=20 >but I see no need for that at this point. > >> Further, I would again recommend that all the =20 >parameters,=20 >> MUST be included >> by a QNI, then a QNE that receives these parameters could: >> * either strictly interpret at least one of the=20 >> parameters. In this case >> the "R" flag and "Q" flags MUST not be set. >>=20 >> * or remap one of the parameters into another parameter=20 >> In this case the remapped parameter >> has to set the flag. The flag should also be set. > >The various cases of sending parameters are=20 >described in Section 7.2.4 of the QSPEC draft=20 >http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-11.txt. =20 >There are some instances where all or some of the parameters=20 >are sent, but it makes no sense to always send all parameters.=20 > The QNI sends parameters based on its QOSM. A QNE=20 >can either strictly interpret or remap whichever parameter(s) are sent. > =20 >> 4) : this parameter can be a QSPEC-1 parameter, but a QNI=20 >> MUST include >> all parameters, i.e., , > Type> and >> . Then a QNE that receives these parameters=20 >> could: >> * either strictly interpret at least one of the=20 >> parameters. In this case the "R"=20 >> flag and "Q" flags MUST not be set. >>=20 >> * or remap one of the parameters into another parameter,=20 >> e.g., "DSCP" =3D> "PHB ID code" >> In this case the remapped parameter, e.g., >> has to set the flag. The flag should also be set. > >As stated in Section 7.2.3 of the QSPEC draft=20 >http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-11.txt: >" =3D > The above notation means that either , , > or sub-parameters MAY be populated in the Class> parameter. Normally only one of these sub-parameters is > populated in . If more than one sub-parameter is > populated, the QOSM specification document MUST give procedures for > processing multiple sub-parameters." > >IMO this is the correct approach, it makes no sense to always=20 >send all parameters. The QNI sends parameters=20 >based on its QOSM. A QNE can either strictly interpret or=20 >remap whichever parameter(s) are sent. > >Thanks, >Jerry > >>=20 >> Best Regards, >> Georgios >>=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 Sun Sep 24 07:56:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRSac-0000Qi-If; Sun, 24 Sep 2006 07:56:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRSab-0000Qa-V4 for nsis@ietf.org; Sun, 24 Sep 2006 07:56:05 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRSaa-0007CZ-GP for nsis@ietf.org; Sun, 24 Sep 2006 07:56:05 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 24 Sep 2006 04:56:04 -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 k8OBu3Av025383; Sun, 24 Sep 2006 04:56:03 -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 k8OBu3Yp019140; Sun, 24 Sep 2006 04:56:03 -0700 (PDT) Received: from [10.32.245.156] (stealth-10-32-245-156.cisco.com [10.32.245.156]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k8OBjVRr019031; Sun, 24 Sep 2006 04:45:31 -0700 In-Reply-To: <007c01c6dd1f$a985f110$6500000a@comm.ad.roke.co.uk> References: <007c01c6dd1f$a985f110$6500000a@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: Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [NSIS] RE: multiple responses to a Query Date: Sun, 24 Sep 2006 07:55:59 -0400 To: Robert Hancock 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=4075; t=1159098963; x=1159962963; 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]=20RE=3A=20multiple=20responses=20to=20a=20Query; X=v=3Dcisco.com=3B=20h=3DUpQMZBGrE4Snm0TDZqY1l4IZ2rI=3D; b=F/na8PAozHmLaFS12jMGHAEvntIVbwRqA54bE1sCI/PDPnjuZI0MsjHfXDHfi1H4XynAf2Js Ld0tMoC3yBswkmV91lLT3Ye+WLvLqeg8VMBFesMXn/COD/loOZrXjR5F; X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: 'Sam Hartman' , 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 Sep 20, 2006, at 9:45 PM, Robert Hancock wrote: > hi sam, > > Basically I'll apologise now that the text has led you astray in > this way. > > I think the question now is how and where to clarify the text to > avoid other people falling into the same trap. > > One possibility would be to make a normative reference to the > framework (rfc4080) and highlight it as required reading. For > example, section 3.2.2 of RFC4080 covers exactly this point (i think > fairly unambiguously). On the other hand, it is just more text for > the implementor to read. Do you think that extending 3.7 of the > GIST spec itself to cover who takes responsibility for what for > the multi-hop aspects would be enough? > This of course begs the question of whether the end-to-end transactional state machine should or should not be common for the different signaling applications. As everyone on this list knows, I've been on the other side of this question (I wouldn't call it a debate because I was roundly defeated by the WG consensus) on this and the associated issues of common end- to-end features among the signaling applications. I simply can't resist posting, because I am undeterred in my conviction that the design is at least suboptimal, and possibly flawed. If there's no stomach to wind back and revisit these issues, I'll crawl back into my cave. Dave. > cheers & thanks for your patience, > > robert h. > >> -----Original Message----- >> From: Sam Hartman [mailto:hartmans-ietf@mit.edu] >> Sent: 21 September 2006 01:28 >> To: Robert Hancock >> Cc: john.loughney@nokia.com; nsis@ietf.org >> Subject: Re: multiple responses to a Query >> >> >>>>>>> "Robert" == Robert Hancock writes: >> >> Robert> Hi Sam, I'll try to address this multiple responses issue >> Robert> specifically, and come back to the rest of the discuss in >> Robert> another mail. The situation here should be relatively >> Robert> simple, but it's possible that the current text has >> Robert> misleading aspects. >> >> Robert> The basic concept is that each Query gets one >> Robert> Response. The Response gets sent to the node that sent >> the >> Robert> Query (the node address comes from the NLI object in the >> Robert> Query message); the two nodes, Querying and Responding, >> Robert> are the two ends of a single GIST hop. Along an end-to- >> end >> Robert> path, there will likely be multiple GIST hops; for >> each of >> Robert> them, there is a Query/Response exchange which is >> local to >> Robert> that hop. The MRI is not changed along the path. >> >> Sorry, I meant NLI not MRI. >> >> I found nothing in the text of section 3 or early section 4 that >> clearly states this. I think for example updating 3.7 to include two >> nodes that want to be interested in the signal flow would help handle >> some of these issues. >> >> Robert> GIST is basically ignorant of the fact that there are >> Robert> multiple hops chained together in this way; linking up >> the >> Robert> hops to provide an end-to-end signalling exchange is >> Robert> carried out at the signalling application level (e.g. the >> Robert> forwarding referred to in section 3.7 step 5 is done at >> Robert> that level) - a single Query itself does not travel >> end to >> Robert> end. Each hop is initiated by signalling application on >> Robert> the node trying to send a message; GIST then carries >> out a >> Robert> local Query/ Response to get to the next node. >> >> This seems like it is discussed nowhere. It also makes 5 in 3.7 very >> misleading, because that behavior is dependent on the signaling >> application. I assumed throughout my entire reading of the document >> that such forwarding was an invarient of GIST. >> > > > _______________________________________________ > 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 Sep 24 08:38:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRTEJ-000755-BW; Sun, 24 Sep 2006 08:37:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRTEI-000750-P2 for nsis@ietf.org; Sun, 24 Sep 2006 08:37:06 -0400 Received: from natblert.rzone.de ([81.169.145.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRTEH-0004io-9T for nsis@ietf.org; Sun, 24 Sep 2006 08:37:06 -0400 Received: from [192.168.178.200] (p5484860B.dip0.t-ipconnect.de [84.132.134.11]) (authenticated bits=0) by post.webmailer.de (8.13.6/8.13.6) with ESMTP id k8OCabNJ013202; Sun, 24 Sep 2006 14:36:38 +0200 (MEST) Message-ID: <45167BD7.6050409@cs.uni-goettingen.de> Date: Sun, 24 Sep 2006 14:36:39 +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: Georgios Karagiannis Subject: Re: [NSIS] Recommendation on QSpec-1 parameters References: <000001c6de29$09feb270$4c0d5982@dynamic.ewi.utwente.nl> In-Reply-To: <000001c6de29$09feb270$4c0d5982@dynamic.ewi.utwente.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.8 (+) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: "'Ash, Gerald R \(Jerry\), ALABS'" , =?ISO-8859-1?Q?=22=27Attila_B=E1der_=28IJ/ETH=29=27=22?= , 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 Georgios and all, what are the solutions for RMD-QOSM for ? For the behaviour of the Traffic Conditioner for out-of-profile traffic for the CLS-QOSM I thought of: 0: drop, some or all packets are discarded 1: shape, some or all packets are delayed 2: remark, reclassification to BE 3: no metering or policing, ... In countries where preemption is not allowed, high priority could be degraded to normal priority. This still allows to differentiate between best effort traffic and normal priority. When a QNI must include , and , which values should be taken, when the QNI can't provide them? As Jerry pointed out some days ago, there's no fixed mapping for , . If both, and have to be included by a QNI then one parameter is enough: . A QOSM which needs , can interpret it as bandwidth. Is there a need to define this mapping or can this be up to the implementation? Bernd Georgios Karagiannis wrote: > Hi Jerry, Cornelia and Attila > > I have made an exercise and tried to apply and use the > QPSEC-1 (mandatory) and QSPEC-2 (optional) parameters into the > RMD-QOSM. Please note that in my opinion one might get the same conclusions > if > another edge-to-edge QOSM will be used, e.g., the future PCN QOSM. > > > My conclusions are as follows: > > 1) and parameters should be QSPEC-1 paramteres, > but then > a QNI MUST include both. A QNE that receives both these parameters must: > > * either strictly interpret at least one of the parameters. In this case > the "R" > flag and "Q" flags MUST not be set. > > * or remap one of the parameters into another parameter (e.g. Bucket> into > In this case the remapped parameter (e.g., > has to set the flag. The flag should also be set. > > > > 2) The parameter influences the way of how the > data packets should be treated within an edge-to-edge domain. > In this way the solutions that can be provided by RMD-QOSM in situations of > e.g., severe congestion are limited. Note that this also will influence a > solution > such as PCN in case of solving the preemption issue. > My recommendation is to ignore this parameter when it has to be used in > such edge-to-edge domains. This means that this parameter should be > * either a QSPEC-2 parameter > * or a QSPEC-1 parameter that is able to be ignored > in edge-to-edge domains, without that the flags "R" and "Q" flags are > set. > In the last case the QOSM description should emphasize that > this parameter is ignored. > > > 3) : as already mentioned in the last version of the QSPEC > template draft > such a parameter cannot be mandatory, because in several countries > preemption of > sessions in favour of others is not allowed. Thus this parameter, should > either be > a QSPEC-2 parameter or a QSPEC-1 that could be in some cases ignored. > Further, I would again recommend that all the parameters, MUST > be included > by a QNI, then a QNE that receives these parameters could: > * either strictly interpret at least one of the parameters. In this case > the "R" > flag and "Q" flags MUST not be set. > > * or remap one of the parameters into another parameter > In this case the remapped parameter > has to set the flag. The flag should also be set. > > 4) : this parameter can be a QSPEC-1 parameter, but a QNI MUST > include > all parameters, i.e., , and > . Then a QNE that receives these parameters could: > * either strictly interpret at least one of the parameters. In this case > the "R" > flag and "Q" flags MUST not be set. > > * or remap one of the parameters into another parameter, e.g., "DSCP" => > "PHB ID code" > In this case the remapped parameter, e.g., > has to set the flag. The flag should also be set. > > 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 Sun Sep 24 10:35:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRV41-0008Td-Mc; Sun, 24 Sep 2006 10:34:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRV40-0008TV-IJ for nsis@ietf.org; Sun, 24 Sep 2006 10:34:36 -0400 Received: from [2001:610:1908:1000:204:23ff:feb5:7e66] (helo=smtp.utwente.nl) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRV3z-0005UK-1B for nsis@ietf.org; Sun, 24 Sep 2006 10:34:36 -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 k8OEYPkO026113 for ; Sun, 24 Sep 2006 16:34:25 +0200 Date: Sun, 24 Sep 2006 16:34:25 +0200 From: Ruud Klaver X-Mailer: The Bat! (v1.52) Organization: Universiteit Twente X-Priority: 3 (Normal) Message-ID: <3612277578.20060924163425@student.utwente.nl> To: nsis@ietf.org Subject: Re[2]: [NSIS] Questions on QoS NSLP draft In-Reply-To: References: <450AC541.4040206@cs.uni-goettingen.de> 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: d6b246023072368de71562c0ab503126 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 Hello, Friday, September 15, 2006, 18:11:00, you wrote: >> When no reservation state is installed at a QNE, does it make >> sense to process a RESERVE with set T-Flag and forward it? > Say your router rebooted, and lost the state. Just after reboot, it gets a > tear for a session it was supposed to have. Thus, it should just forward > the message further downstrea, otherwise the reservations will not be > removed on other nodes downstream. In this case what should the RSN be in the tearing RESERVE that is passed on to the downstream peer? -- 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 Sun Sep 24 11:05:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRVXR-0002lx-33; Sun, 24 Sep 2006 11:05:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRVXP-0002ls-Pk for nsis@ietf.org; Sun, 24 Sep 2006 11:04:59 -0400 Received: from natklopstock.rzone.de ([81.169.145.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRVXO-0007v7-Do for nsis@ietf.org; Sun, 24 Sep 2006 11:04:59 -0400 Received: from [192.168.178.200] (p5484860B.dip0.t-ipconnect.de [84.132.134.11]) (authenticated bits=0) by post.webmailer.de (8.13.6/8.13.6) with ESMTP id k8OF4id4023716; Sun, 24 Sep 2006 17:04:45 +0200 (MEST) Message-ID: <45169E8E.9090409@cs.uni-goettingen.de> Date: Sun, 24 Sep 2006 17:04:46 +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: Ruud Klaver Subject: Re: [NSIS] Questions on QoS NSLP draft References: <450AC541.4040206@cs.uni-goettingen.de> <3612277578.20060924163425@student.utwente.nl> In-Reply-To: <3612277578.20060924163425@student.utwente.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 Dear Ruud Klaver, section 5.3.1 says if the Epoch Identifier is different to the stored one then the reservation has to be seen as an update. The stored RSN and Epoch Identifier need to be exchanged to the received ones. In case the router rebooted the RSN can be e.g. 0 and the QNE has to store it as RSN from the upstream peer. Bernd Ruud Klaver wrote: > Hello, > > Friday, September 15, 2006, 18:11:00, you wrote: > > >>>When no reservation state is installed at a QNE, does it make >>>sense to process a RESERVE with set T-Flag and forward it? > > >>Say your router rebooted, and lost the state. Just after reboot, it gets a >>tear for a session it was supposed to have. Thus, it should just forward >>the message further downstrea, otherwise the reservations will not be >>removed on other nodes downstream. > > > In this case what should the RSN be in the tearing RESERVE that is > passed on to the downstream peer? > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Sep 25 06:35:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRnnL-0007Xu-Nx; Mon, 25 Sep 2006 06:34:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRnnK-0007Xo-Hq for nsis@ietf.org; Mon, 25 Sep 2006 06:34:38 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRnnJ-0004hf-OE for nsis@ietf.org; Mon, 25 Sep 2006 06:34: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 k8PAXugG008091; Mon, 25 Sep 2006 12:34:10 +0200 (MEST) From: "Georgios Karagiannis" To: "'Bernd Schloer'" Subject: RE: [NSIS] Recommendation on QSpec-1 parameters Date: Mon, 25 Sep 2006 12:33:52 +0200 Message-ID: <001501c6e08e$20c13a70$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <45167BD7.6050409@cs.uni-goettingen.de> Thread-Index: Acbf1oEvLb7ijzoCSxOvKgsuUEVhMwAqJNRQ X-Spam-Score: -5.599 () ALL_TRUSTED,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, 25 Sep 2006 12:34:13 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 Cc: "'Ash, Gerald R \(Jerry\), ALABS'" , "'Kappler, Cornelia'" , nsis@ietf.org, =?iso-8859-1?Q?'=22'Attila_B=E1der_=28IJ/ETH=29'=22'?= X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.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 * Regarding the , the RMD QNEs should be able to=20 choose the most efficient way for excess treatment in order to=20 for example, solve severe congestion situations. If this parameter is mandatory, this will mean that the=20 end QNI will dictate what kind of excess treatment should be used=20 by each QNE in the RMD domain. This will limit the way of how the=20 severe congestion is solved. Note that in a severe congestion situation, typically most packets=20 will be dropped! However, if the is mandatory=20 and the end QNI dictates that the packets should be remarked=20 and not dropped, then all the nodes that are under severe congestion=20 will keep the congestion and the network will very quickly collapse. * Regarding and , if both are included in the=20 or then a QNE can choose the one of the = two parameters. A problem may arise from the fact that the QNI will not know which of = the one is=20 used by the QNEs. One solution of this problem can be solved in the following way: If a QNI is willing to use the parameter as mandatory, = then=20 the QNI must include the parameter as QSPEC-1 parameter = and=20 it must also inlcude the parameter as QSPEC-2 parameter. If a QNE cannot use the , then it will use the optional=20 parameter and will set the "R" and "Q" flags associated with = the parameter. When is chosen as QSPEC-1 parameter, then is chosen as=20 QSPEC-2 parameter. A similar method of remapping as described above can = be followed. Note that in this case the way of how the remapping of one QSPEC-1 = parameter value into another=20 value is specified by the QNI.=20 * Regarding , the mentioned solution regarding the=20 remapping from high to normal by appling a degradation of high priority=20 to normal priority, maybe can help, but the main problem that I have is=20 the fact that all four parameters are mandatory and for=20 a QOSM that uses one of the four parameters, it is difficult=20 to remap one of the parameters into another one. If a QNI includes all 4 parameters, then a QNE=20 can choose the one that it needs! Note that a QNI should be able=20 to fill all 4 QSPEC-1 parameters. This is the same situation = as the situation=20 that a QNE should be able to process all QSPEC-1 parameters. A problem may arise from the fact that the QNI will not know which of = the one is=20 used by the QNEs. One solution of this problem can be solved in the following way: Make only one of the four parameters QSPEC-1 parameter.=20 The QNI must include all the other three parameters as=20 QSPEC-2 parameters. The way of how the remapping is done is similar to the explanation that = I give above regarding and parameters. * The problem with the QoS class parameters is that it is very difficult = to remap One of the QoS class parameters into another parameter. In my previous e-mails=20 I emphasized that each of the QoS class parameters are usefull in some setting and useless=20 in other settings. In order to make the parameter always = usefull We can do that by requiring that the QNI must include all three QoS = class parameters, then a QNE can choose the one that it needs. Note that a QNI should be = able=20 to fill all 3 QSPEC-1 parameters. This is the same situation = as the situation=20 that a QNE should be able to process all QSPEC-1 parameters. Best regards, Georgios -----Original Message----- From: Bernd Schloer [mailto:bschloer@cs.uni-goettingen.de]=20 Sent: zondag 24 september 2006 14:37 To: Georgios Karagiannis Cc: 'Ash, Gerald R (Jerry), ALABS'; "'Attila B=E1der (IJ/ETH)'"; nsis@ietf.org; 'Kappler,Cornelia' Subject: Re: [NSIS] Recommendation on QSpec-1 parameters Hi Georgios and all, what are the solutions for RMD-QOSM for ? For the behaviour of the Traffic Conditioner for out-of-profile traffic = for the CLS-QOSM I thought of: 0: drop, some or all packets are discarded 1: shape, some or all packets are delayed 2: remark, reclassification to BE 3: no metering or policing, ... In countries where preemption is not allowed, high priority could be degraded to normal priority. This still allows to differentiate between = best effort traffic and normal priority. When a QNI must include , and , which values should be taken, when the QNI can't = provide them? As Jerry pointed out some days ago, there's no fixed mapping for = , . If both, and have to be included by a QNI = then one parameter is enough: . A QOSM which needs , = can interpret it as bandwidth. Is there a need to define this mapping or can this be up to the implementation? Bernd Georgios Karagiannis wrote: > Hi Jerry, Cornelia and Attila >=20 > I have made an exercise and tried to apply and use the > QPSEC-1 (mandatory) and QSPEC-2 (optional) parameters into the=20 > RMD-QOSM. Please note that in my opinion one might get the same=20 > conclusions if another edge-to-edge QOSM will be used, e.g., the=20 > future PCN QOSM. >=20 >=20 > My conclusions are as follows: >=20 > 1) and parameters should be QSPEC-1=20 > paramteres, but then a QNI MUST include both. A QNE that receives both = > these parameters must: >=20 > * either strictly interpret at least one of the parameters. In this = > case the "R" > flag and "Q" flags MUST not be set. >=20 > * or remap one of the parameters into another parameter (e.g.=20 > Bucket> into > In this case the remapped parameter (e.g., > has to set the flag. The flag should also be set. >=20 >=20 >=20 > 2) The parameter influences the way of how the data = > packets should be treated within an edge-to-edge domain. > In this way the solutions that can be provided by RMD-QOSM in=20 > situations of e.g., severe congestion are limited. Note that this also = > will influence a solution such as PCN in case of solving the=20 > preemption issue. > My recommendation is to ignore this parameter when it has to be used=20 > in such edge-to-edge domains. This means that this parameter should be > * either a QSPEC-2 parameter=20 > * or a QSPEC-1 parameter that is able to be ignored=20 > in edge-to-edge domains, without that the flags "R" and "Q" flags=20 > are set. > In the last case the QOSM description should emphasize that > this parameter is ignored.=20 >=20 >=20 > 3) : as already mentioned in the last version of the QSPEC=20 > template draft > such a parameter cannot be mandatory, because in several countries=20 > preemption of > sessions in favour of others is not allowed. Thus this parameter,=20 > should either be > a QSPEC-2 parameter or a QSPEC-1 that could be in some cases = ignored. > Further, I would again recommend that all the parameters, = > MUST be included > by a QNI, then a QNE that receives these parameters could: > * either strictly interpret at least one of the parameters. In this = > case the "R" > flag and "Q" flags MUST not be set. >=20 > * or remap one of the parameters into another parameter=20 > In this case the remapped parameter > has to set the flag. The flag should also be set. > =20 > 4) : this parameter can be a QSPEC-1 parameter, but a QNI=20 > MUST include > all parameters, i.e., , = and=20 > . Then a QNE that receives these parameters = could: > * either strictly interpret at least one of the parameters. In this = > case the "R" > flag and "Q" flags MUST not be set. >=20 > * or remap one of the parameters into another parameter, e.g.,=20 > "DSCP" =3D> "PHB ID code" > In this case the remapped parameter, e.g., > has to set the flag. The flag should also be set. >=20 > Best Regards, > Georgios >=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 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Sep 25 07:53:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRp17-00062K-0b; Mon, 25 Sep 2006 07:52:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRp15-00062D-VZ for nsis@ietf.org; Mon, 25 Sep 2006 07:52:56 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRp12-0007C5-Ab for nsis@ietf.org; Mon, 25 Sep 2006 07:52:55 -0400 Received: from mail1.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id k8PBqirs020116; Mon, 25 Sep 2006 13:52:44 +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 k8PBqeLS001059; Mon, 25 Sep 2006 13:52:44 +0200 Received: from blns00fa.ww002.siemens.net ([147.54.45.102]) by mchp7wta.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Sep 2006 13:52:41 +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 Date: Mon, 25 Sep 2006 13:52:41 +0200 Message-ID: In-Reply-To: <000001c6de29$09feb270$4c0d5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Recommendation on QSpec-1 parameters Thread-Index: Aca/6wl1mien3kJ5R0u2kXlkJtiCmAIP4e+wAAWS8CAAAoy9AAOH1HuAACvc7DAAAM4ZkAAAThngAA7rUXAAHft90AAEopLQAABi+9AAAL3FQAAAyKRQAAATFzAANAFP4ACdR8LQACcVEaAAAinnwACTWb4AAJ0ZMbA= From: "Kappler, Cornelia" To: "Georgios Karagiannis" , "Ash, Gerald R \(Jerry\), ALABS" , =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= X-OriginalArrivalTime: 25 Sep 2006 11:52:41.0992 (UTC) FILETIME=[1B56A880:01C6E099] X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: nsis@ietf.org Subject: [NSIS] AW: Recommendation on QSpec-1 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 Hi Georgios,=20 essentially you would include always all parameters into the QSPEC. The = goal of the QSPEC exercise was however right the contrary: gain = interoperability by allowing (may be unprecise) "x-interpretation" of = parameters. So I think your proposal is - while entirely possible - not = in the spirit of the draft. There are other possibilities if you make = slight compromises (regarding (i) the exact interpretation of QNI = parameters and (ii) what a QNE must be able to do (note in the RMD case = these are just the stateful edge QNEs!))=20 Cornelia=20 > -----Urspr=FCngliche Nachricht----- > Von: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 > Gesendet: Freitag, 22. September 2006 11:25 > An: 'Ash, Gerald R (Jerry), ALABS'; Kappler, Cornelia;=20 > 'Attila B=E1der (IJ/ETH)' > Cc: nsis@ietf.org > Betreff: Recommendation on QSpec-1 parameters >=20 > Hi Jerry, Cornelia and Attila >=20 > I have made an exercise and tried to apply and use the =20 > QPSEC-1 (mandatory) and QSPEC-2 (optional) parameters into the=20 > RMD-QOSM. Please note that in my opinion one might get the=20 > same conclusions > if > another edge-to-edge QOSM will be used, e.g., the future PCN QOSM. >=20 >=20 > My conclusions are as follows: >=20 > 1) and parameters should be QSPEC-1=20 > paramteres, > but then=20 > a QNI MUST include both. A QNE that receives both these=20 > parameters must: >=20 > * either strictly interpret at least one of the=20 > parameters. In this case > the "R"=20 > flag and "Q" flags MUST not be set. >=20 > * or remap one of the parameters into another parameter=20 > (e.g. Bucket> into > In this case the remapped parameter (e.g., > has to set the flag. The flag should also be set. >=20 >=20 >=20 > 2) The parameter influences the way of how the=20 > data packets should be treated within an edge-to-edge domain. > In this way the solutions that can be provided by RMD-QOSM in=20 > situations of=20 > e.g., severe congestion are limited. Note that this also will=20 > influence a > solution=20 > such as PCN in case of solving the preemption issue. > My recommendation is to ignore this parameter when it has to=20 > be used in > such edge-to-edge domains. This means that this parameter should be=20 > * either a QSPEC-2 parameter=20 > * or a QSPEC-1 parameter that is able to be ignored=20 > in edge-to-edge domains, without that the flags "R" and=20 > "Q" flags are > set.=20 > In the last case the QOSM description should emphasize that > this parameter is ignored.=20 >=20 >=20 > 3) : as already mentioned in the last version of the QSPEC > template draft > such a parameter cannot be mandatory, because in several countries > preemption of > sessions in favour of others is not allowed. Thus this=20 > parameter, should > either be=20 > a QSPEC-2 parameter or a QSPEC-1 that could be in some=20 > cases ignored. > Further, I would again recommend that all the =20 > parameters, MUST > be included=20 > by a QNI, then a QNE that receives these parameters could: > * either strictly interpret at least one of the=20 > parameters. In this case > the "R"=20 > flag and "Q" flags MUST not be set. >=20 > * or remap one of the parameters into another parameter=20 > In this case the remapped parameter > has to set the flag. The flag should also be set. > =20 > 4) : this parameter can be a QSPEC-1 parameter,=20 > but a QNI MUST > include=20 > all parameters, i.e., , Type> and=20 > . Then a QNE that receives these=20 > parameters could: > * either strictly interpret at least one of the=20 > parameters. In this case > the "R"=20 > flag and "Q" flags MUST not be set. >=20 > * or remap one of the parameters into another parameter,=20 > e.g., "DSCP" =3D> > "PHB ID code" > In this case the remapped parameter, e.g., > has to set the flag. The flag should also be set. >=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 Mon Sep 25 09:42:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRqi2-0002WA-IO; Mon, 25 Sep 2006 09:41:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRqi0-0002Vy-Vf for nsis@ietf.org; Mon, 25 Sep 2006 09:41:20 -0400 Received: from nz-out-0102.google.com ([64.233.162.192]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRqhy-0000ly-ON for nsis@ietf.org; Mon, 25 Sep 2006 09:41:20 -0400 Received: by nz-out-0102.google.com with SMTP id q3so485039nzb for ; Mon, 25 Sep 2006 06:41:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=sLGIAAvvPD4YpuI4+h+gEiJeaXZV3XYHw1Un2xQDlB4TWCZ3dLIVls7phonOT2HfWa4RyBDw+11o08vi1LWuBMqlmPt3lidPQNdJjo3gVdjdGfS6n/rkSK41pIcmcYPVZhYWP9v6sLS1idsgPmx8WgmkAScNiZWpBDl0abfE668= Received: by 10.65.15.17 with SMTP id s17mr4275808qbi; Mon, 25 Sep 2006 06:41:17 -0700 (PDT) Received: by 10.65.194.20 with HTTP; Mon, 25 Sep 2006 06:41:17 -0700 (PDT) Message-ID: <5a26be460609250641w293139e6wc47cc0cc0ad76cc4@mail.gmail.com> Date: Mon, 25 Sep 2006 21:41:17 +0800 From: "=?GB2312?B?sfOx8831?=" To: nsis@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.6 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Subject: [NSIS] question about nsis qos routing X-BeenThere: nsis@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="===============1121442092==" Errors-To: nsis-bounces@ietf.org --===============1121442092== Content-Type: multipart/alternative; boundary="----=_Part_21826_33333561.1159191677868" ------=_Part_21826_33333561.1159191677868 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all, I have a question about nsis qos routing. There are two nodes (Assuming node A and node B) in a computer communication network. I want to set up a qos routing between node A and node B, then send the real data. As we know, there are probably several qos routings between node A and node B. My question is that: Before I send the real data, how nsis qos signaling finds the optimum routing amoung these probably routings and sets up the optimum qos routing? Bestwishes! skywang 2006-9-25 -- journey binbinwang118@gmail.com ------=_Part_21826_33333561.1159191677868 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi all,
 
I have a question about nsis qos routing. There are two nodes (Assuming node A and node B) in a computer communication network. I want to set up a qos routing between node A and node B, then send the real data.
 
As we know, there are probably several qos routings between node A and node B. My question is that: Before I send the real data, how nsis qos signaling finds the optimum routing amoung these probably routings  and sets up the optimum qos routing?
 
Bestwishes!
 
skywang
2006-9-25
 


--
journey
------=_Part_21826_33333561.1159191677868-- --===============1121442092== 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 --===============1121442092==-- From nsis-bounces@ietf.org Mon Sep 25 09:57:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRqxY-0001bo-2a; Mon, 25 Sep 2006 09:57:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRqxW-0001ZE-Hf for nsis@ietf.org; Mon, 25 Sep 2006 09:57:22 -0400 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRqxS-0003pF-VI for nsis@ietf.org; Mon, 25 Sep 2006 09:57:22 -0400 Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k8PDvGOl016495; Mon, 25 Sep 2006 15:57:17 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k8PDvFq1020191; Mon, 25 Sep 2006 15:57:16 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Sep 2006 15:57:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: AW: [NSIS] question about nsis qos routing Date: Mon, 25 Sep 2006 15:56:42 +0200 Message-ID: In-Reply-To: <5a26be460609250641w293139e6wc47cc0cc0ad76cc4@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] question about nsis qos routing Thread-Index: AcbgqZtlSdB8nSHfRAmbzsj19KKF9gAAK0SA From: "Tschofenig, Hannes" To: =?iso-2022-jp?B?GyRCSUxJTDImGyhC?= , X-OriginalArrivalTime: 25 Sep 2006 13:57:16.0150 (UTC) FILETIME=[8248A960:01C6E0AA] X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 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="===============0868939050==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0868939050== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6E0AA.711CAF66" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6E0AA.711CAF66 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit NSIS does not provide QoS routing functionality. Ciao Hannes ________________________________ Von: $BILIL2&(J [mailto:binbinwang118@gmail.com] Gesendet: Montag, 25. September 2006 15:41 An: nsis@ietf.org Betreff: [NSIS] question about nsis qos routing Hi all, I have a question about nsis qos routing. There are two nodes (Assuming node A and node B) in a computer communication network. I want to set up a qos routing between node A and node B, then send the real data. As we know, there are probably several qos routings between node A and node B. My question is that: Before I send the real data, how nsis qos signaling finds the optimum routing amoung these probably routings and sets up the optimum qos routing? Bestwishes! skywang 2006-9-25 -- journey binbinwang118@gmail.com ------_=_NextPart_001_01C6E0AA.711CAF66 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit
NSIS does not provide QoS routing functionality.
 
Ciao
Hannes
 

Von: $BILIL2&(B [mailto:binbinwang118@gmail.com]
Gesendet: Montag, 25. September 2006 15:41
An: nsis@ietf.org
Betreff: [NSIS] question about nsis qos routing

Hi all,
 
I have a question about nsis qos routing. There are two nodes (Assuming node A and node B) in a computer communication network. I want to set up a qos routing between node A and node B, then send the real data.
 
As we know, there are probably several qos routings between node A and node B. My question is that: Before I send the real data, how nsis qos signaling finds the optimum routing amoung these probably routings  and sets up the optimum qos routing?
 
Bestwishes!
 
skywang
2006-9-25
 


--
journey
------_=_NextPart_001_01C6E0AA.711CAF66-- --===============0868939050== 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 --===============0868939050==-- From nsis-bounces@ietf.org Mon Sep 25 10:19:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRrIX-0003vE-GS; Mon, 25 Sep 2006 10:19:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRrIW-0003rm-8U for nsis@ietf.org; Mon, 25 Sep 2006 10:19:04 -0400 Received: from amer-mta07.csc.com ([20.137.52.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRrIV-0008V6-0q for nsis@ietf.org; Mon, 25 Sep 2006 10:19:04 -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 k8PEIdHL021190; Mon, 25 Sep 2006 10:18:39 -0400 (EDT) In-Reply-To: <001501c6e08e$20c13a70$4c0d5982@dynamic.ewi.utwente.nl> Subject: RE: [NSIS] Recommendation on QSpec-1 parameters To: "Georgios Karagiannis" X-Mailer: Lotus Notes 652HF83 November 04, 2004 Message-ID: From: Janet P Gunn Date: Mon, 25 Sep 2006 10:18:36 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 6.5.3|September 14, 2004) at 09/25/2006 10:17:30 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: "'Ash, Gerald R \(Jerry\), ALABS'" , "'Kappler, Cornelia'" , nsis@ietf.org, "\"'\"'Attila =?ISO-8859-1?Q?B=E1der?= \(IJ/ETH\)'\"'\"" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.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 Karagiannis" wrote on 09/25/2006 06:33:52 AM: > Hi Bernd ... > > > * Regarding , the mentioned solution regarding the > remapping from high to normal by appling a degradation of high priority > to normal priority, maybe can help, but the main problem that I have is > the fact that all four parameters are mandatory and for > a QOSM that uses one of the four parameters, it is difficult > to remap one of the parameters into another one. > > If a QNI includes all 4 parameters, then a QNE > can choose the one that it needs! Note that a QNI should be able > to fill all 4 QSPEC-1 parameters. This is the same situation as > the situation > that a QNE should be able to process all QSPEC-1 parameters. > A problem may arise from the fact that the QNI will not know which of the > one is > used by the QNEs. > One solution of this problem can be solved in the following way: > Make only one of the four parameters QSPEC-1 parameter. > The QNI must include all the other three parameters as > QSPEC-2 parameters. > The way of how the remapping is done is similar to the explanation that I > give above > regarding and parameters. > > It is my understanding that the priority parameters should not by regarded as 4 independent parameters, but rather as two parameter-pairs: The & Parameters must either both be present, or neither. You can have without , but you can only have if you also have , with the value " 2 - high priority flow". Janet _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Sep 25 11:00:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRrw4-0002eD-Fv; Mon, 25 Sep 2006 10:59:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRrw1-0002Ry-8a for nsis@ietf.org; Mon, 25 Sep 2006 10:59:53 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRrvj-0005tG-SF for nsis@ietf.org; Mon, 25 Sep 2006 10: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 k8PExAnU029033; Mon, 25 Sep 2006 16:59:22 +0200 (MEST) From: "Georgios Karagiannis" To: "'Janet P Gunn'" Subject: RE: [NSIS] Recommendation on QSpec-1 parameters Date: Mon, 25 Sep 2006 16:59:07 +0200 Message-ID: <001901c6e0b3$2e631110$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: Thread-Index: Acbgra/ME7c0sADvQpKU7ohWTZMh7gABQu8Q X-Spam-Score: -5.199 () ALL_TRUSTED,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]); Mon, 25 Sep 2006 16:59:28 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: "'Ash, Gerald R \(Jerry\), ALABS'" , =?iso-8859-1?Q?'=22'=22'Attila_B=E1der_=28IJ/ETH=29'=22'=22'?= , 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 You are right, but my point was to emphasize that the=20 QNI should include all 4 parameters, then a QNE can choose=20 the one (or the ones) that it needs! Note that a QNI should be able to=20 fill all 4 QSPEC-1 parameters. This is the same situation as the situation that a QNE should be able to process all QSPEC-1 parameters. =20 Best regards, Georgios -----Original Message----- From: Janet P Gunn [mailto:jgunn6@csc.com]=20 Sent: maandag 25 september 2006 16:19 To: Georgios Karagiannis Cc: 'Ash, Gerald R (Jerry), ALABS'; 'Kappler,Cornelia'; nsis@ietf.org; "'"'Attila B=E1der (IJ/ETH)'"'" Subject: RE: [NSIS] Recommendation on QSpec-1 parameters "Georgios Karagiannis" wrote on 09/25/2006 06:33:52 AM: > Hi Bernd ... > > > * Regarding , the mentioned solution regarding the remapping = > from high to normal by appling a degradation of high priority to=20 > normal priority, maybe can help, but the main problem that I have is=20 > the fact that all four parameters are mandatory and for a=20 > QOSM that uses one of the four parameters, it is difficult=20 > to remap one of the parameters into another one. > > If a QNI includes all 4 parameters, then a QNE can choose=20 > the one that it needs! Note that a QNI should be able to fill all 4=20 > QSPEC-1 parameters. This is the same situation as > the situation > that a QNE should be able to process all QSPEC-1 parameters. > A problem may arise from the fact that the QNI will not know which of=20 > the one is used by the QNEs. > One solution of this problem can be solved in the following way: > Make only one of the four parameters QSPEC-1 parameter. > The QNI must include all the other three parameters as > QSPEC-2 parameters. > The way of how the remapping is done is similar to the explanation=20 > that I give above regarding and =20 > parameters. > > It is my understanding that the priority parameters should not by = regarded as 4 independent parameters, but rather as two parameter-pairs: The & Parameters must either = both be present, or neither. You can have without , but you can = only have if you also have , with the = value " 2 - high priority flow". Janet _______________________________________________ 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 Sep 25 11:23:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRsIR-0003tO-QF; Mon, 25 Sep 2006 11:23:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRsIQ-0003t6-F9 for nsis@ietf.org; Mon, 25 Sep 2006 11:23:02 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRsIP-0006Fy-S0 for nsis@ietf.org; Mon, 25 Sep 2006 11:23: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 k8PFMUIC001661; Mon, 25 Sep 2006 17:22:34 +0200 (MEST) From: "Georgios Karagiannis" To: "'Kappler, Cornelia'" , "'Ash, Gerald R \(Jerry\), ALABS'" , "=?iso-8859-1?Q?'Attila_B=E1der_=28IJ/ETH=29'?=" Subject: RE: [NSIS] AW: Recommendation on QSpec-1 parameters Date: Mon, 25 Sep 2006 17:22:27 +0200 Message-ID: <001b01c6e0b6$6c413400$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: Thread-Index: Aca/6wl1mien3kJ5R0u2kXlkJtiCmAIP4e+wAAWS8CAAAoy9AAOH1HuAACvc7DAAAM4ZkAAAThngAA7rUXAAHft90AAEopLQAABi+9AAAL3FQAAAyKRQAAATFzAANAFP4ACdR8LQACcVEaAAAinnwACTWb4AAJ0ZMbAABsNIEA== X-Spam-Score: -5.599 () ALL_TRUSTED,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, 25 Sep 2006 17:22:37 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: f60fbf3dbcaca652b6d10036f0630412 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 problems that I have found with these parameters are: 1) Not all QSPEC-1 parameters are necessary to provide the = interoperability. For example, the QNE must support each parameter even if that = parameter causes a collapse in the network performance, e.g., .=20 2) There are 4 sets of QSPEC-1 parameters: , , = . Each of these sets includes more than one parameter, e.g., includes the , and parameters. However,=20 in the current version of QSpec template, a QNI must include at least = one of the parameters. Thus, for example, consider that a QNI includes = either a a or a . Based on the current = QSpec template specification=20 a diffserv based QNE must be able to interpret a = and a =20 even if it cannot do that! Please note that I do not think that it is possible=20 to remap a or a parameter into a = PHB class=20 parameter. Below you can find a copy of the e-mail that I have sent this morning = that describes these issues=20 in a more detailed way: --------------------- * Regarding the , the RMD QNEs should be able to = choose the most efficient way for excess treatment in order to for example, = solve severe congestion situations. If this parameter is mandatory, this will mean that the end QNI will = dictate what kind of excess treatment should be used by each QNE in the RMD = domain. This will limit the way of how the severe congestion is solved. Note that in a severe congestion situation, typically most packets will = be dropped! However, if the is mandatory and the end QNI dictates that the packets should be remarked and not dropped, then all = the nodes that are under severe congestion will keep the congestion and the network will very quickly collapse. * Regarding and , if both are included in the = or then a QNE can choose the one of the two parameters. A problem may arise from the fact that the QNI will not know which of = the one is used by the QNEs. One solution of this problem can be solved in the following way: If a QNI is willing to use the parameter as mandatory, = then the QNI must include the parameter as QSPEC-1 parameter = and it must also inlcude the parameter as QSPEC-2 parameter. If a QNE cannot use the , then it will use the optional parameter and will set the "R" and "Q" flags associated with = the parameter. When is chosen as QSPEC-1 parameter, then is chosen as QSPEC-2 parameter. A similar method of remapping as described above can = be followed. Note that in this case the way of how the remapping of one QSPEC-1 = parameter value into another value is specified by the QNI.=20 * Regarding , the mentioned solution regarding the remapping = from high to normal by appling a degradation of high priority to normal = priority, maybe can help, but the main problem that I have is the fact that all = four parameters are mandatory and for a QOSM that uses one of the = four parameters, it is difficult to remap one of the parameters into another one. If a QNI includes all 4 parameters, then a QNE can choose the = one that it needs! Note that a QNI should be able to fill all 4 QSPEC-1 parameters. This is the same situation as the situation that = a QNE should be able to process all QSPEC-1 parameters. A problem may arise from the fact that the QNI will not know which of = the one is used by the QNEs. One solution of this problem can be solved in the following way: Make only one of the four parameters QSPEC-1 parameter.=20 The QNI must include all the other three parameters as QSPEC-2 parameters. The way of how the remapping is done is similar to the explanation that = I give above regarding and parameters. * The problem with the QoS class parameters is that it is very difficult = to remap One of the QoS class parameters into another parameter. In my = previous e-mails I emphasized that each of the QoS class parameters are usefull = in some setting and useless in other settings. In order to make the parameter always usefull We can do that by requiring that the QNI must include all three QoS class parameters, then a QNE can choose the one = that it needs. Note that a QNI should be able to fill all 3 QSPEC-1 parameters. This is the same situation as the situation that a QNE = should be able to process all QSPEC-1 parameters. ---------------------------------- Best Regards, Georgios -----Original Message----- From: Kappler, Cornelia [mailto:cornelia.kappler@siemens.com]=20 Sent: maandag 25 september 2006 13:53 To: Georgios Karagiannis; Ash, Gerald R (Jerry), ALABS; Attila B=E1der (IJ/ETH) Cc: nsis@ietf.org Subject: [NSIS] AW: Recommendation on QSpec-1 parameters Hi Georgios,=20 essentially you would include always all parameters into the QSPEC. The = goal of the QSPEC exercise was however right the contrary: gain = interoperability by allowing (may be unprecise) "x-interpretation" of parameters. So I = think your proposal is - while entirely possible - not in the spirit of the = draft. There are other possibilities if you make slight compromises (regarding = (i) the exact interpretation of QNI parameters and (ii) what a QNE must be = able to do (note in the RMD case these are just the stateful edge QNEs!))=20 Cornelia=20 > -----Urspr=FCngliche Nachricht----- > Von: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > Gesendet: Freitag, 22. September 2006 11:25 > An: 'Ash, Gerald R (Jerry), ALABS'; Kappler, Cornelia; 'Attila B=E1der = > (IJ/ETH)' > Cc: nsis@ietf.org > Betreff: Recommendation on QSpec-1 parameters >=20 > Hi Jerry, Cornelia and Attila >=20 > I have made an exercise and tried to apply and use the > QPSEC-1 (mandatory) and QSPEC-2 (optional) parameters into the=20 > RMD-QOSM. Please note that in my opinion one might get the same=20 > conclusions if another edge-to-edge QOSM will be used, e.g., the=20 > future PCN QOSM. >=20 >=20 > My conclusions are as follows: >=20 > 1) and parameters should be QSPEC-1=20 > paramteres, > but then=20 > a QNI MUST include both. A QNE that receives both these=20 > parameters must: >=20 > * either strictly interpret at least one of the=20 > parameters. In this case > the "R"=20 > flag and "Q" flags MUST not be set. >=20 > * or remap one of the parameters into another parameter=20 > (e.g. Bucket> into > In this case the remapped parameter (e.g., > has to set the flag. The flag should also be set. >=20 >=20 >=20 > 2) The parameter influences the way of how the=20 > data packets should be treated within an edge-to-edge domain. > In this way the solutions that can be provided by RMD-QOSM in=20 > situations of=20 > e.g., severe congestion are limited. Note that this also will=20 > influence a > solution=20 > such as PCN in case of solving the preemption issue. > My recommendation is to ignore this parameter when it has to=20 > be used in > such edge-to-edge domains. This means that this parameter should be=20 > * either a QSPEC-2 parameter=20 > * or a QSPEC-1 parameter that is able to be ignored=20 > in edge-to-edge domains, without that the flags "R" and=20 > "Q" flags are > set.=20 > In the last case the QOSM description should emphasize that > this parameter is ignored.=20 >=20 >=20 > 3) : as already mentioned in the last version of the QSPEC > template draft > such a parameter cannot be mandatory, because in several countries > preemption of > sessions in favour of others is not allowed. Thus this=20 > parameter, should > either be=20 > a QSPEC-2 parameter or a QSPEC-1 that could be in some=20 > cases ignored. > Further, I would again recommend that all the =20 > parameters, MUST > be included=20 > by a QNI, then a QNE that receives these parameters could: > * either strictly interpret at least one of the=20 > parameters. In this case > the "R"=20 > flag and "Q" flags MUST not be set. >=20 > * or remap one of the parameters into another parameter=20 > In this case the remapped parameter > has to set the flag. The flag should also be set. > =20 > 4) : this parameter can be a QSPEC-1 parameter,=20 > but a QNI MUST > include=20 > all parameters, i.e., , Type> and=20 > . Then a QNE that receives these=20 > parameters could: > * either strictly interpret at least one of the=20 > parameters. In this case > the "R"=20 > flag and "Q" flags MUST not be set. >=20 > * or remap one of the parameters into another parameter,=20 > e.g., "DSCP" =3D> > "PHB ID code" > In this case the remapped parameter, e.g., > has to set the flag. The flag should also be set. >=20 > Best Regards, > Georgios >=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 Sep 25 21:08:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS1Ps-0003Z3-BA; Mon, 25 Sep 2006 21:07:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS1Pr-0003Yy-E5 for nsis@ietf.org; Mon, 25 Sep 2006 21:07:19 -0400 Received: from nz-out-0102.google.com ([64.233.162.206]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GS1Pp-00087m-PF for nsis@ietf.org; Mon, 25 Sep 2006 21:07:19 -0400 Received: by nz-out-0102.google.com with SMTP id q3so617418nzb for ; Mon, 25 Sep 2006 18:07:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Hn3pefUZP99XhGV6L/G6vA8S3FL0w+/rlrejqaCde1q8ziVWMoc5qeE22kXEWKSHBTdHzQ1ni3llrKDhqzBjAnv4YhCSzRCYgNvRLVB/n7GOIuMVB+mLgOD/U/JBNTIM5Q9Vmyiux2xkA0TWt/z0r/9v40l1XD6VWHjJb50soWY= Received: by 10.65.84.6 with SMTP id m6mr231802qbl; Mon, 25 Sep 2006 18:07:17 -0700 (PDT) Received: by 10.65.194.20 with HTTP; Mon, 25 Sep 2006 18:07:17 -0700 (PDT) Message-ID: <5a26be460609251807x411128c4jd918f3c97ccd22f0@mail.gmail.com> Date: Tue, 26 Sep 2006 09:07:17 +0800 From: "=?GB2312?B?sfOx8831?=" To: "Tschofenig, Hannes" Subject: Re: [NSIS] question about nsis qos routing In-Reply-To: MIME-Version: 1.0 References: <5a26be460609250641w293139e6wc47cc0cc0ad76cc4@mail.gmail.com> X-Spam-Score: 0.6 (/) 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: , Content-Type: multipart/mixed; boundary="===============1967997199==" Errors-To: nsis-bounces@ietf.org --===============1967997199== Content-Type: multipart/alternative; boundary="----=_Part_32442_33326536.1159232837248" ------=_Part_32442_33326536.1159232837248 Content-Type: text/plain; charset=GB2312; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline SGkgSGFubmVzLAoKR2xhZCB0byByZWNlaXZlIHVyIG1haWwhIFRoYW5rIHUgdmVyeSBtdWNoOi0p CgpXaGV0aGVyIEkgY2FuIHVuZGVyc3RhbmQgbGlrZSB0aGlzOiB0aGUgUW9TIHJvdXRpbmcgZnVu Y3Rpb25hbGl0eSBpcyBkb3duIGJ5CklQIGxheWVyLiBBbmQgd2Uga25vdyB0aGUgbnNpcyBpcyBt YWlubHkgb24gcGF0aC1jb3VwbGVkIHNpZ25hbGluZy4KVGhlcmVmb3IsIGlmIEkgd2FudCB0byBz ZXQgdXAgYSBRb1Mgcm91dGluZyBiZXR3ZWVuIG5vZGUgQSBhbmQgbm9kZSBCLCB0aGVuCnNlbmQg cmVhbCBkYXRhLiB0aGVyZSBhcmUgdGhyZWUgc3RlcHMsCnN0ZXAgMSwgdGhlIElQIGxheWVyIHNl dCB1cCBhIFFvUyByb3V0aW5nIGJldHdlZW4gbm9kZSBBIGFuZCBub2RlIEIuCnN0ZXAgMiwgdGhl IFFvUyBOU0xQLCB0b2dldGhlciB3aXRoIEdJU1QsIGl0IGVzdGFibGlzaGVzIGFuZCBtYWludGFp bnMgc3RhdGUKYXQgbm9kZXMgYWxvbmcgdGhlIHBhdGggd2hpY2ggSVAgbGF5ZXIgc2V0IHVwLgpz dGVwIDMsIHNlbmQgcmVhbCBkYXRhIGFsb25nIHRoZSBwYXRoLgoKQmVzdHdpc2hlcyEKCnNreXdh bmcKMjAwNi05LTI2CgoyMDA2LzkvMjUsIFRzY2hvZmVuaWcsIEhhbm5lcyA8aGFubmVzLnRzY2hv ZmVuaWdAc2llbWVucy5jb20+Ogo+Cj4gIE5TSVMgZG9lcyBub3QgcHJvdmlkZSBRb1Mgcm91dGlu ZyBmdW5jdGlvbmFsaXR5Lgo+Cj4gQ2lhbwo+IEhhbm5lcwo+Cj4KPiAgLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tCj4gKlZvbjoqILHzsfPN9SBbbWFpbHRvOmJpbmJpbndhbmcxMThAZ21h aWwuY29tXQo+ICpHZXNlbmRldDoqIE1vbnRhZywgMjUuIFNlcHRlbWJlciAyMDA2IDE1OjQxCj4g KkFuOiogbnNpc0BpZXRmLm9yZwo+ICpCZXRyZWZmOiogW05TSVNdIHF1ZXN0aW9uIGFib3V0IG5z aXMgcW9zIHJvdXRpbmcKPgo+Cj4gIEhpIGFsbCwKPgo+IEkgaGF2ZSBhIHF1ZXN0aW9uIGFib3V0 IG5zaXMgcW9zIHJvdXRpbmcuIFRoZXJlIGFyZSB0d28gbm9kZXMgKEFzc3VtaW5nCj4gbm9kZSBB IGFuZCBub2RlIEIpIGluIGEgY29tcHV0ZXIgY29tbXVuaWNhdGlvbiBuZXR3b3JrLiBJIHdhbnQg dG8gc2V0IHVwIGEKPiBxb3Mgcm91dGluZyBiZXR3ZWVuIG5vZGUgQSBhbmQgbm9kZSBCLCB0aGVu IHNlbmQgdGhlIHJlYWwgZGF0YS4KPgo+IEFzIHdlIGtub3csIHRoZXJlIGFyZSBwcm9iYWJseSBz ZXZlcmFsIHFvcyByb3V0aW5ncyBiZXR3ZWVuIG5vZGUgQSBhbmQKPiBub2RlIEIuIE15IHF1ZXN0 aW9uIGlzIHRoYXQ6IEJlZm9yZSBJIHNlbmQgdGhlIHJlYWwgZGF0YSwgaG93IG5zaXMgcW9zCj4g c2lnbmFsaW5nIGZpbmRzIHRoZSBvcHRpbXVtIHJvdXRpbmcgYW1vdW5nIHRoZXNlIHByb2JhYmx5 IHJvdXRpbmdzICBhbmQgc2V0cwo+IHVwIHRoZSBvcHRpbXVtIHFvcyByb3V0aW5nPwo+Cj4gQmVz dHdpc2hlcyEKPgo+IHNreXdhbmcKPiAyMDA2LTktMjUKPiAgPGJpbmJpbndhbmcxMThAZ21haWwu Y29tPgo+Cj4KPiAtLQo+IGpvdXJuZXkKPiBiaW5iaW53YW5nMTE4QGdtYWlsLmNvbQo+Cj4KCgot LSAKKmkqbWVtbypjZSogam91cm5leQo= ------=_Part_32442_33326536.1159232837248 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: base64 Content-Disposition: inline PGRpdj5IaSBIYW5uZXMsPC9kaXY+CjxkaXY+Jm5ic3A7PC9kaXY+CjxkaXY+R2xhZCB0byByZWNl aXZlIHVyIG1haWwhIFRoYW5rIHUgdmVyeSBtdWNoOi0pIDwvZGl2Pgo8ZGl2PiZuYnNwOzwvZGl2 Pgo8ZGl2PldoZXRoZXIgSSBjYW4gdW5kZXJzdGFuZCBsaWtlIHRoaXM6IHRoZSBRb1Mgcm91dGlu ZyBmdW5jdGlvbmFsaXR5IGlzIGRvd24gYnkgSVAgbGF5ZXIuJm5ic3A7QW5kIHdlIGtub3cgdGhl IG5zaXMgaXMgbWFpbmx5IG9uIHBhdGgtY291cGxlZCBzaWduYWxpbmcuIFRoZXJlZm9yLCBpZiBJ IHdhbnQgdG8gc2V0IHVwJm5ic3A7YSBRb1Mgcm91dGluZyBiZXR3ZWVuIG5vZGUgQSBhbmQgbm9k ZSBCLCB0aGVuIHNlbmQgcmVhbCBkYXRhLiB0aGVyZSBhcmUgdGhyZWUgc3RlcHMsCjwvZGl2Pgo8 ZGl2PnN0ZXAgMSwgdGhlIElQIGxheWVyIHNldCB1cCBhIFFvUyByb3V0aW5nIGJldHdlZW4gbm9k ZSBBIGFuZCBub2RlIEIuPC9kaXY+CjxkaXY+c3RlcCAyLCB0aGUgUW9TIE5TTFAsIHRvZ2V0aGVy IHdpdGggR0lTVCwgaXQgZXN0YWJsaXNoZXMgYW5kIG1haW50YWlucyBzdGF0ZSBhdCBub2RlcyZu YnNwO2Fsb25nIHRoZSBwYXRoIHdoaWNoIElQIGxheWVyIHNldCB1cC4mbmJzcDs8L2Rpdj4KPGRp dj5zdGVwIDMsIHNlbmQgcmVhbCBkYXRhIGFsb25nIHRoZSBwYXRoLjxicj4mbmJzcDs8L2Rpdj4K PGRpdj5CZXN0d2lzaGVzITwvZGl2Pgo8ZGl2PiZuYnNwOzwvZGl2Pgo8ZGl2PnNreXdhbmc8L2Rp dj4KPGRpdj4yMDA2LTktMjY8YnI+Jm5ic3A7PC9kaXY+CjxkaXY+PHNwYW4gY2xhc3M9ImdtYWls X3F1b3RlIj4yMDA2LzkvMjUsIFRzY2hvZmVuaWcsIEhhbm5lcyAmbHQ7PGEgaHJlZj0ibWFpbHRv Omhhbm5lcy50c2Nob2ZlbmlnQHNpZW1lbnMuY29tIj5oYW5uZXMudHNjaG9mZW5pZ0BzaWVtZW5z LmNvbTwvYT4mZ3Q7Ojwvc3Bhbj4KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHls ZT0iUEFERElORy1MRUZUOiAxZXg7IE1BUkdJTjogMHB4IDBweCAwcHggMC44ZXg7IEJPUkRFUi1M RUZUOiAjY2NjIDFweCBzb2xpZCI+CjxkaXY+CjxkaXYgZGlyPSJsdHIiIGFsaWduPSJsZWZ0Ij48 Zm9udCBmYWNlPSJBcmlhbCIgY29sb3I9IiMwMDAwZmYiIHNpemU9IjIiPjxzcGFuPk5TSVMgZG9l cyBub3QgcHJvdmlkZSBRb1Mgcm91dGluZyBmdW5jdGlvbmFsaXR5LiA8L3NwYW4+PC9mb250Pjwv ZGl2Pgo8ZGl2IGRpcj0ibHRyIiBhbGlnbj0ibGVmdCI+PGZvbnQgZmFjZT0iQXJpYWwiIGNvbG9y PSIjMDAwMGZmIiBzaXplPSIyIj48c3Bhbj48L3NwYW4+PC9mb250PiZuYnNwOzwvZGl2Pgo8ZGl2 IGRpcj0ibHRyIiBhbGlnbj0ibGVmdCI+PGZvbnQgZmFjZT0iQXJpYWwiIGNvbG9yPSIjMDAwMGZm IiBzaXplPSIyIj48c3Bhbj5DaWFvPC9zcGFuPjwvZm9udD48L2Rpdj4KPGRpdiBkaXI9Imx0ciIg YWxpZ249ImxlZnQiPjxmb250IGZhY2U9IkFyaWFsIiBjb2xvcj0iIzAwMDBmZiIgc2l6ZT0iMiI+ PHNwYW4+SGFubmVzPC9zcGFuPjwvZm9udD48L2Rpdj4KPGRpdiBkaXI9Imx0ciIgYWxpZ249Imxl ZnQiPjxmb250IGZhY2U9IkFyaWFsIiBjb2xvcj0iIzAwMDBmZiIgc2l6ZT0iMiI+PHNwYW4+PC9z cGFuPjwvZm9udD4mbmJzcDs8L2Rpdj48Zm9udCBmYWNlPSJBcmlhbCIgY29sb3I9IiMwMDAwZmYi IHNpemU9IjIiPjwvZm9udD48YnI+CjxibG9ja3F1b3RlIGRpcj0ibHRyIiBzdHlsZT0iUEFERElO Ry1MRUZUOiA1cHg7IE1BUkdJTi1MRUZUOiA1cHg7IEJPUkRFUi1MRUZUOiAjMDAwMGZmIDJweCBz b2xpZDsgTUFSR0lOLVJJR0hUOiAwcHgiPgo8ZGl2IGxhbmc9ImRlIiBkaXI9Imx0ciIgYWxpZ249 ImxlZnQiPgo8aHI+Cjxmb250IGZhY2U9IlRhaG9tYSIgc2l6ZT0iMiI+PGI+Vm9uOjwvYj4gsfOx 8831IFttYWlsdG86PGEgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3cs ZXZlbnQsdGhpcykiIGhyZWY9Im1haWx0bzpiaW5iaW53YW5nMTE4QGdtYWlsLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPmJpbmJpbndhbmcxMThAZ21haWwuY29tPC9hPl0gPGJyPjxiPkdlc2VuZGV0Ojwv Yj4gTW9udGFnLCAyNS4gU2VwdGVtYmVyIDIwMDYgMTU6NDEKPGJyPjxiPkFuOjwvYj4gPGEgb25j bGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiIGhyZWY9 Im1haWx0bzpuc2lzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bnNpc0BpZXRmLm9yZzwvYT48 YnI+PGI+QmV0cmVmZjo8L2I+IFtOU0lTXSBxdWVzdGlvbiBhYm91dCBuc2lzIHFvcyByb3V0aW5n PGJyPjwvZm9udD48YnI+Jm5ic3A7PC9kaXY+CjxkaXY+PHNwYW4gY2xhc3M9ImUiIGlkPSJxXzEw ZGU1NDNmMjU5MmUwNmNfMSI+CjxkaXY+PC9kaXY+CjxkaXY+SGkgYWxsLDwvZGl2Pgo8ZGl2PiZu YnNwOzwvZGl2Pgo8ZGl2PkkgaGF2ZSBhIHF1ZXN0aW9uIGFib3V0IG5zaXMgcW9zIHJvdXRpbmcu IFRoZXJlIGFyZSB0d28gbm9kZXMgKEFzc3VtaW5nIG5vZGUgQSBhbmQgbm9kZSBCKSBpbiBhIGNv bXB1dGVyIGNvbW11bmljYXRpb24gbmV0d29yay4gSSB3YW50IHRvIHNldCB1cCBhIHFvcyByb3V0 aW5nIGJldHdlZW4gbm9kZSBBIGFuZCBub2RlIEIsIHRoZW4gc2VuZCB0aGUmbmJzcDtyZWFsIGRh dGEuIDwvZGl2PgoKPGRpdj4mbmJzcDs8L2Rpdj4KPGRpdj5BcyB3ZSBrbm93LCB0aGVyZSBhcmUg cHJvYmFibHkgc2V2ZXJhbCBxb3Mgcm91dGluZ3MgYmV0d2VlbiBub2RlIEEgYW5kIG5vZGUgQi4g TXkgcXVlc3Rpb24gaXMgdGhhdDogQmVmb3JlIEkgc2VuZCB0aGUgcmVhbCBkYXRhLCBob3cgbnNp cyBxb3Mgc2lnbmFsaW5nIGZpbmRzIHRoZSBvcHRpbXVtIHJvdXRpbmcgYW1vdW5nIHRoZXNlIHBy b2JhYmx5IHJvdXRpbmdzJm5ic3A7IGFuZCBzZXRzIHVwIHRoZSBvcHRpbXVtIHFvcyByb3V0aW5n PyAKPC9kaXY+CjxkaXY+Jm5ic3A7PC9kaXY+CjxkaXY+QmVzdHdpc2hlcyE8L2Rpdj4KPGRpdj4m bmJzcDs8L2Rpdj4KPGRpdj5za3l3YW5nPC9kaXY+CjxkaXY+MjAwNi05LTI1PC9kaXY+CjxkaXY+ PGEgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhpcyki IGhyZWY9Im1haWx0bzpiaW5iaW53YW5nMTE4QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjwv YT4mbmJzcDs8L2Rpdj4KPGRpdj48YnIgY2xlYXI9ImFsbCI+PGJyPi0tIDxicj5qb3VybmV5IDwv ZGl2Pgo8ZGl2PjxhIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2 ZW50LHRoaXMpIiBocmVmPSJtYWlsdG86YmluYmlud2FuZzExOEBnbWFpbC5jb20iIHRhcmdldD0i X2JsYW5rIj5iaW5iaW53YW5nMTE4QGdtYWlsLmNvbTwvYT48L2Rpdj48L3NwYW4+PC9kaXY+PC9i bG9ja3F1b3RlPjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48YnI+PGJyIGNsZWFyPSJhbGwiPgo8 YnI+LS0gPGJyPippKm1lbW8qY2UqIGpvdXJuZXkgCg== ------=_Part_32442_33326536.1159232837248-- --===============1967997199== 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 --===============1967997199==-- From nsis-bounces@ietf.org Tue Sep 26 06:56:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSAbv-0007ac-Ic; Tue, 26 Sep 2006 06:56:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSAbu-0007Zp-RE for nsis@ietf.org; Tue, 26 Sep 2006 06:56:22 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GSAbt-0004Gt-D7 for nsis@ietf.org; Tue, 26 Sep 2006 06:56:22 -0400 Received: (qmail invoked by alias); 26 Sep 2006 10:56:20 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp042) with SMTP; 26 Sep 2006 12:56:20 +0200 X-Authenticated: #29516787 Message-ID: <4519074F.5050502@gmx.net> Date: Tue, 26 Sep 2006 12:56:15 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: =?GB2312?B?sfOx8831?= Subject: Re: [NSIS] question about nsis qos routing References: <5a26be460609250641w293139e6wc47cc0cc0ad76cc4@mail.gmail.com> <5a26be460609251807x411128c4jd918f3c97ccd22f0@mail.gmail.com> In-Reply-To: <5a26be460609251807x411128c4jd918f3c97ccd22f0@mail.gmail.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: nsis@ietf.org, "Tschofenig, Hannes" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.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 ±ó±óÍő schrieb: > Hi Hannes, > > Glad to receive ur mail! Thank u very much:-) > > Whether I can understand like this: the QoS routing functionality is > down by IP layer. About which QoS routing proposal are you talking when you say that QoS routing functionality is provided by the IP layer? And we know the nsis is mainly on path-coupled > signaling. True. Therefor, if I want to set up a QoS routing between node A > and node B, then send real data. What you might really want todo with NSIS is to create a QoS reservation along a path between the data sender (node A) and the data receiver (node B). there are three steps, > step 1, the IP layer set up a QoS routing between node A and node B. You need to reference the QoS routing proposal in order to give this sentence some meaning. > step 2, the QoS NSLP, together with GIST, it establishes and maintains > state at nodes along the path which IP layer set up. The state is allocated at nodes that are discovered by the GIST discovery procedure. > step 3, send real data along the path. Ciao Hannes > > Bestwishes! > > skywang > 2006-9-26 > > 2006/9/25, Tschofenig, Hannes >: > > NSIS does not provide QoS routing functionality. > > Ciao > Hannes > > > ------------------------------------------------------------------------ > *Von:* ±ó±óÍő [mailto:binbinwang118@gmail.com > ] > *Gesendet:* Montag, 25. September 2006 15:41 > *An:* nsis@ietf.org > *Betreff:* [NSIS] question about nsis qos routing > > > Hi all, > > I have a question about nsis qos routing. There are two nodes > (Assuming node A and node B) in a computer communication > network. I want to set up a qos routing between node A and node > B, then send the real data. > > As we know, there are probably several qos routings between node > A and node B. My question is that: Before I send the real data, > how nsis qos signaling finds the optimum routing amoung these > probably routings and sets up the optimum qos routing? > > Bestwishes! > > skywang > 2006-9-25 > > > > -- > journey > binbinwang118@gmail.com > > > > > -- > *i*memo*ce* journey > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Sep 26 08:11:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSBly-0005z1-1x; Tue, 26 Sep 2006 08:10:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSBlx-0005wb-5P for nsis@ietf.org; Tue, 26 Sep 2006 08:10:49 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSBlu-0004BO-92 for nsis@ietf.org; Tue, 26 Sep 2006 08:10:49 -0400 Received: from mail1.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id k8QCARD8025297; Tue, 26 Sep 2006 14:10: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 k8QCARvQ012276; Tue, 26 Sep 2006 14:10: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, 26 Sep 2006 14:10: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] AW: Recommendation on QSpec-1 parameters Date: Tue, 26 Sep 2006 14:10:26 +0200 Message-ID: In-Reply-To: <001b01c6e0b6$6c413400$4c0d5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] AW: Recommendation on QSpec-1 parameters Thread-Index: Aca/6wl1mien3kJ5R0u2kXlkJtiCmAIP4e+wAAWS8CAAAoy9AAOH1HuAACvc7DAAAM4ZkAAAThngAA7rUXAAHft90AAEopLQAABi+9AAAL3FQAAAyKRQAAATFzAANAFP4ACdR8LQACcVEaAAAinnwACTWb4AAJ0ZMbAABsNIEAAsBDoQ From: "Kappler, Cornelia" To: "Georgios Karagiannis" , "Ash, Gerald R \(Jerry\), ALABS" , =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= X-OriginalArrivalTime: 26 Sep 2006 12:10:26.0869 (UTC) FILETIME=[C077BE50:01C6E164] X-Spam-Score: 0.0 (/) X-Scan-Signature: fcb459c204557d9509ce9c1b55d771f1 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 Re (1): "cause collapse in network performance": I assume this is something you = think might happen rather than the result of a measurement? For sure the = inclusion of every mandatory parameter is a trade off between = performance and interoperabilty. And my impression is "rough consensus" = in the WG is including Excess Treatment (since we dont have any = measurements) [reading your more detailed email attached my impression is you worry = particularly about a QNE being forced to remark rather than drop. So may = be this is a problem with this particular value of Excess Treatment?] Re (2): a) As you know, the QNI does NOT need to include every parameter = (ceterum censeo...!?!?!?!) (Nor a QNI must be able to fill all three = priority parameters. A QNI only fills those parameters it cares about) b) Doubtlessly there is no perfect mapping between the individual = parameters. But then the goal of QoS NSLP is interoperability. And this = is only possible when allowing an (imperfect) mapping. Cornelia > -----Urspr=FCngliche Nachricht----- > Von: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 > Gesendet: Montag, 25. September 2006 17:22 > An: Kappler, Cornelia; 'Ash, Gerald R (Jerry), ALABS';=20 > 'Attila B=E1der (IJ/ETH)' > Cc: nsis@ietf.org > Betreff: RE: [NSIS] AW: Recommendation on QSpec-1 parameters >=20 > Hi Cornelia >=20 > The problems that I have found with these parameters are: >=20 > 1) Not all QSPEC-1 parameters are necessary to provide the=20 > interoperability. > For example, the QNE must support each parameter even if=20 > that parameter > causes a collapse in > the network performance, e.g., .=20 >=20 > 2) There are 4 sets of QSPEC-1 parameters: ,=20 > , Treatment> > . Each of these sets includes more than one=20 > parameter, e.g., > > includes the , and > parameters. However,=20 > in the current version of QSpec template, a QNI must=20 > include at least one >=20 > of the parameters. Thus, for example, consider that a QNI=20 > includes either > a > a or a . Based on the=20 > current QSpec > template specification=20 > a diffserv based QNE must be able to interpret a class type> and a > =20 > even if it cannot do that! Please note that I do not think=20 > that it is > possible=20 > to remap a or a =20 > parameter into a PHB > class=20 > parameter. >=20 >=20 > Below you can find a copy of the e-mail that I have sent this=20 > morning that > describes these issues=20 > in a more detailed way: >=20 > --------------------- >=20 >=20 > * Regarding the , the RMD QNEs should be=20 > able to choose > the most efficient way for excess treatment in order to for=20 > example, solve > severe congestion situations. > If this parameter is mandatory, this will mean that the end=20 > QNI will dictate > what kind of excess treatment should be used by each QNE in=20 > the RMD domain. > This will limit the way of how the severe congestion is solved. >=20 > Note that in a severe congestion situation, typically most=20 > packets will be > dropped! However, if the is mandatory and=20 > the end QNI > dictates that the packets should be remarked and not dropped,=20 > then all the > nodes that are under severe congestion will keep the=20 > congestion and the > network will very quickly collapse. >=20 >=20 > * Regarding and , if both are=20 > included in the desired> or then a QNE can choose the one of the two > parameters. >=20 > A problem may arise from the fact that the QNI will not know=20 > which of the > one is used by the QNEs. > One solution of this problem can be solved in the following way: > If a QNI is willing to use the parameter as=20 > mandatory, then > the QNI must include the parameter as QSPEC-1=20 > parameter and > it must also inlcude the parameter as QSPEC-2 parameter. > If a QNE cannot use the , then it will use the optional > parameter and will set the "R" and "Q" flags=20 > associated with the > parameter. > When is chosen as QSPEC-1 parameter, then Bucket> is > chosen as > QSPEC-2 parameter. A similar method of remapping as described=20 > above can be > followed. > Note that in this case the way of how the remapping of one=20 > QSPEC-1 parameter > value into another value is specified by the QNI.=20 >=20 >=20 > * Regarding , the mentioned solution regarding the=20 > remapping from > high to normal by appling a degradation of high priority to=20 > normal priority, > maybe can help, but the main problem that I have is the fact=20 > that all four > parameters are mandatory and for a QOSM that uses=20 > one of the four > parameters, it is difficult to remap one of the > parameters into another one. >=20 > If a QNI includes all 4 parameters, then a QNE can=20 > choose the one > that it needs! Note that a QNI should be able to fill all 4 QSPEC-1 > parameters. This is the same situation as the=20 > situation that a > QNE should be able to process all QSPEC-1 parameters. > A problem may arise from the fact that the QNI will not know=20 > which of the > one is used by the QNEs. > One solution of this problem can be solved in the following way: > Make only one of the four parameters QSPEC-1 parameter.=20 > The QNI must include all the other three parameters as > QSPEC-2 parameters. > The way of how the remapping is done is similar to the=20 > explanation that I > give above regarding and parameters. >=20 >=20 > * The problem with the QoS class parameters is that it is=20 > very difficult to > remap One of the QoS class parameters into another parameter.=20 > In my previous > e-mails I emphasized that each of the QoS class parameters=20 > are usefull in > some setting and useless in other settings. In order to make=20 > the > parameter always usefull We can do that by requiring that the QNI must > include all three QoS class parameters, then a QNE can choose=20 > the one that > it needs. Note that a QNI should be able to fill all 3=20 > QSPEC-1 > parameters. This is the same situation as the situation that=20 > a QNE should be > able to process all QSPEC-1 parameters. >=20 > ---------------------------------- >=20 > Best Regards, > Georgios >=20 > -----Original Message----- > From: Kappler, Cornelia [mailto:cornelia.kappler@siemens.com]=20 > Sent: maandag 25 september 2006 13:53 > To: Georgios Karagiannis; Ash, Gerald R (Jerry), ALABS; Attila B=E1der > (IJ/ETH) > Cc: nsis@ietf.org > Subject: [NSIS] AW: Recommendation on QSpec-1 parameters >=20 > Hi Georgios,=20 >=20 > essentially you would include always all parameters into the=20 > QSPEC. The goal > of the QSPEC exercise was however right the contrary: gain=20 > interoperability > by allowing (may be unprecise) "x-interpretation" of=20 > parameters. So I think > your proposal is - while entirely possible - not in the=20 > spirit of the draft. > There are other possibilities if you make slight compromises=20 > (regarding (i) > the exact interpretation of QNI parameters and (ii) what a=20 > QNE must be able > to do (note in the RMD case these are just the stateful edge QNEs!))=20 >=20 > Cornelia=20 >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > Gesendet: Freitag, 22. September 2006 11:25 > > An: 'Ash, Gerald R (Jerry), ALABS'; Kappler, Cornelia;=20 > 'Attila B=E1der=20 > > (IJ/ETH)' > > Cc: nsis@ietf.org > > Betreff: Recommendation on QSpec-1 parameters > >=20 > > Hi Jerry, Cornelia and Attila > >=20 > > I have made an exercise and tried to apply and use the > > QPSEC-1 (mandatory) and QSPEC-2 (optional) parameters into the=20 > > RMD-QOSM. Please note that in my opinion one might get the same=20 > > conclusions if another edge-to-edge QOSM will be used, e.g., the=20 > > future PCN QOSM. > >=20 > >=20 > > My conclusions are as follows: > >=20 > > 1) and parameters should be QSPEC-1=20 > > paramteres, > > but then=20 > > a QNI MUST include both. A QNE that receives both these=20 > > parameters must: > >=20 > > * either strictly interpret at least one of the=20 > > parameters. In this case > > the "R"=20 > > flag and "Q" flags MUST not be set. > >=20 > > * or remap one of the parameters into another parameter=20 > > (e.g. > Bucket> into > > In this case the remapped parameter (e.g., > > has to set the flag. The flag should also be set. > >=20 > >=20 > >=20 > > 2) The parameter influences the way of how the=20 > > data packets should be treated within an edge-to-edge domain. > > In this way the solutions that can be provided by RMD-QOSM in=20 > > situations of=20 > > e.g., severe congestion are limited. Note that this also will=20 > > influence a > > solution=20 > > such as PCN in case of solving the preemption issue. > > My recommendation is to ignore this parameter when it has to=20 > > be used in > > such edge-to-edge domains. This means that this parameter should be=20 > > * either a QSPEC-2 parameter=20 > > * or a QSPEC-1 parameter that is able to be ignored=20 > > in edge-to-edge domains, without that the flags "R" and=20 > > "Q" flags are > > set.=20 > > In the last case the QOSM description should emphasize that > > this parameter is ignored.=20 > >=20 > >=20 > > 3) : as already mentioned in the last version of the QSPEC > > template draft > > such a parameter cannot be mandatory, because in several countries > > preemption of > > sessions in favour of others is not allowed. Thus this=20 > > parameter, should > > either be=20 > > a QSPEC-2 parameter or a QSPEC-1 that could be in some=20 > > cases ignored. > > Further, I would again recommend that all the =20 > > parameters, MUST > > be included=20 > > by a QNI, then a QNE that receives these parameters could: > > * either strictly interpret at least one of the=20 > > parameters. In this case > > the "R"=20 > > flag and "Q" flags MUST not be set. > >=20 > > * or remap one of the parameters into another parameter=20 > > In this case the remapped parameter > > has to set the flag. The flag should also be set. > > =20 > > 4) : this parameter can be a QSPEC-1 parameter,=20 > > but a QNI MUST > > include=20 > > all parameters, i.e., , > Type> and=20 > > . Then a QNE that receives these=20 > > parameters could: > > * either strictly interpret at least one of the=20 > > parameters. In this case > > the "R"=20 > > flag and "Q" flags MUST not be set. > >=20 > > * or remap one of the parameters into another parameter,=20 > > e.g., "DSCP" =3D> > > "PHB ID code" > > In this case the remapped parameter, e.g., > > has to set the flag. The flag should also be set. > >=20 > > Best Regards, > > Georgios > >=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 Tue Sep 26 11:33:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSEuh-0008Ec-19; Tue, 26 Sep 2006 11:32:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSEuf-0008EP-Ch for nsis@ietf.org; Tue, 26 Sep 2006 11:32:01 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSEue-0001Xx-KZ for nsis@ietf.org; Tue, 26 Sep 2006 11:32: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 k8QFUgP5024530; Tue, 26 Sep 2006 17:30:49 +0200 (MEST) From: "Georgios Karagiannis" To: "'Kappler, Cornelia'" , "'Ash, Gerald R \(Jerry\), ALABS'" , "=?iso-8859-1?Q?'Attila_B=E1der_=28IJ/ETH=29'?=" Subject: RE: [NSIS] AW: Recommendation on QSpec-1 parameters Date: Tue, 26 Sep 2006 17:30:39 +0200 Message-ID: <002701c6e180$bbbee070$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: Aca/6wl1mien3kJ5R0u2kXlkJtiCmAIP4e+wAAWS8CAAAoy9AAOH1HuAACvc7DAAAM4ZkAAAThngAA7rUXAAHft90AAEopLQAABi+9AAAL3FQAAAyKRQAAATFzAANAFP4ACdR8LQACcVEaAAAinnwACTWb4AAJ0ZMbAABsNIEAAsBDoQAAHp99A= In-Reply-To: X-Spam-Score: -5.599 () ALL_TRUSTED,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, 26 Sep 2006 17:30:53 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4cbeb0f20efb229aa93fae1468d20275 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 see in line! =20 -----Original Message----- From: Kappler, Cornelia [mailto:cornelia.kappler@siemens.com]=20 Sent: dinsdag 26 september 2006 14:10 To: Georgios Karagiannis; Ash, Gerald R (Jerry), ALABS; Attila B=E1der (IJ/ETH) Cc: nsis@ietf.org Subject: AW: [NSIS] AW: Recommendation on QSpec-1 parameters Hi Georgios > Re (1): "cause collapse in network performance": I assume this is something=20 > you think might happen rather than the result of a measurement?=20 > For sure the inclusion of every mandatory parameter is a=20 > trade off between performance and interoperabilty. And my=20 > impression is "rough consensus" in the WG is including=20 > Excess Treatment (since we dont have any measurements)=20 > [reading your more detailed email attached my impression=20 > is you worry particularly about a QNE being forced to remark rather = than drop.=20 > So may be this is a problem with this particular value of Excess Treatment?] Georgios: Please note that the main problem with this relates to the = parameter. The problem does impact not only the network performance, but also = the operation of the network. If a node strictly follows the mandated requirement, then in case of e.g., a severe congestion, then the network might completely collapse, i.e., a total network failure could occur. Regarding the Excess Treatment value, the current specification = mentions that=20 the QNI will specify the value! > Re (2): a) As you know, the QNI does NOT need to include every=20 > parameter (ceterum censeo...!?!?!?!) (Nor a QNI must=20 > be able to fill all three priority parameters.=20 > A QNI only fills those parameters it cares about) Georgios: regarding a)=20 Yes, I know that the current version specifies that the QNI does NOT = need to include every parameter. And that is exactly what creates the problems mentioned by me. If the = QNI will be required to include these parameters, then most of the remapping problems within the network are solved. This is because the QNI will actually do the remapping by itself and it = will have a better knowledge=20 on accepting or rejecting a requested reservation.=20 For example, if we look to the QoS Class parameters,=20 each of the QoS class parameters are usefull in some setting and impossible in other settings. In order to make the parameter always possible we can do that by requiring that the QNI must include all three QoS class parameters, then a QNE can choose=20 the one that it needs. Note that if a QNI is interested only in one of = them, say , then the QNI Could set this parameter as QSPEC-1 parameter. However, in this case the = QNI MUST also fill in the other two parameters, i.e., and , which can be set as QSPEC-2 parameters. In this way it will be possible for any QNE to remap the value of the QSPEC-1 parameter, e.g.,=20 into either or . = Furthermore, the QNI will have all the knowledge=20 On which method has been used for the remapping of the parameter. > b) Doubtlessly there is no perfect mapping between=20 > the individual parameters. But then the goal of=20 > QoS NSLP is interoperability. And this is only=20 > possible when allowing an (imperfect) mapping. Georgios: regarding b)=20 I am not talking about imperfect mapping, but I am referring to an impossible mapping. Could you please provide me with two examples: 1) Please provide an example of remapping of=20 the parameter into parameter 2) Please provide an example of remapping of=20 the parameter into parameter Many thanks in adavance! Best Regards, Georgios > -----Urspr=FCngliche Nachricht----- > Von: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > Gesendet: Montag, 25. September 2006 17:22 > An: Kappler, Cornelia; 'Ash, Gerald R (Jerry), ALABS'; 'Attila B=E1der = > (IJ/ETH)' > Cc: nsis@ietf.org > Betreff: RE: [NSIS] AW: Recommendation on QSpec-1 parameters >=20 > Hi Cornelia >=20 > The problems that I have found with these parameters are: >=20 > 1) Not all QSPEC-1 parameters are necessary to provide the=20 > interoperability. > For example, the QNE must support each parameter even if that=20 > parameter causes a collapse in > the network performance, e.g., .=20 >=20 > 2) There are 4 sets of QSPEC-1 parameters: , ,=20 > Treatment> > . Each of these sets includes more than one parameter,=20 > e.g., > includes the , and =20 > parameters. However, > in the current version of QSpec template, a QNI must include at=20 > least one >=20 > of the parameters. Thus, for example, consider that a QNI includes=20 > either a > a or a . Based on the current=20 > QSpec template specification > a diffserv based QNE must be able to interpret a =20 > and a > =20 > even if it cannot do that! Please note that I do not think that it=20 > is possible > to remap a or a parameter into = > a PHB class parameter. >=20 >=20 > Below you can find a copy of the e-mail that I have sent this morning=20 > that describes these issues in a more detailed way: >=20 > --------------------- >=20 >=20 > * Regarding the , the RMD QNEs should be able to=20 > choose the most efficient way for excess treatment in order to for=20 > example, solve severe congestion situations. > If this parameter is mandatory, this will mean that the end QNI will=20 > dictate what kind of excess treatment should be used by each QNE in=20 > the RMD domain. > This will limit the way of how the severe congestion is solved. >=20 > Note that in a severe congestion situation, typically most packets=20 > will be dropped! However, if the is mandatory and=20 > the end QNI dictates that the packets should be remarked and not=20 > dropped, then all the nodes that are under severe congestion will keep = > the congestion and the network will very quickly collapse. >=20 >=20 > * Regarding and , if both are included in=20 > the desired> or then a QNE can choose the one of the two > parameters. >=20 > A problem may arise from the fact that the QNI will not know which of=20 > the one is used by the QNEs. > One solution of this problem can be solved in the following way: > If a QNI is willing to use the parameter as mandatory,=20 > then the QNI must include the parameter as QSPEC-1=20 > parameter and it must also inlcude the parameter as=20 > QSPEC-2 parameter. > If a QNE cannot use the , then it will use the optional=20 > parameter and will set the "R" and "Q" flags associated=20 > with the parameter. > When is chosen as QSPEC-1 parameter, then Bucket> is > chosen as > QSPEC-2 parameter. A similar method of remapping as described above=20 > can be followed. > Note that in this case the way of how the remapping of one > QSPEC-1 parameter > value into another value is specified by the QNI.=20 >=20 >=20 > * Regarding , the mentioned solution regarding the=20 > remapping from > high to normal by appling a degradation of high priority to=20 > normal priority, > maybe can help, but the main problem that I have is the fact=20 > that all four > parameters are mandatory and for a QOSM that uses=20 > one of the four > parameters, it is difficult to remap one of the > parameters into another one. >=20 > If a QNI includes all 4 parameters, then a QNE can=20 > choose the one > that it needs! Note that a QNI should be able to fill all 4 QSPEC-1 > parameters. This is the same situation as the=20 > situation that a > QNE should be able to process all QSPEC-1 parameters. > A problem may arise from the fact that the QNI will not know=20 > which of the > one is used by the QNEs. > One solution of this problem can be solved in the following way: > Make only one of the four parameters QSPEC-1 parameter.=20 > The QNI must include all the other three parameters as > QSPEC-2 parameters. > The way of how the remapping is done is similar to the=20 > explanation that I > give above regarding and parameters. >=20 >=20 > * The problem with the QoS class parameters is that it is=20 > very difficult to > remap One of the QoS class parameters into another parameter.=20 > In my previous > e-mails I emphasized that each of the QoS class parameters=20 > are usefull in > some setting and useless in other settings. In order to make=20 > the > parameter always usefull We can do that by requiring that the QNI must > include all three QoS class parameters, then a QNE can choose=20 > the one that > it needs. Note that a QNI should be able to fill all 3=20 > QSPEC-1 > parameters. This is the same situation as the situation that=20 > a QNE should be > able to process all QSPEC-1 parameters. >=20 > ---------------------------------- >=20 > Best Regards, > Georgios >=20 > -----Original Message----- > From: Kappler, Cornelia [mailto:cornelia.kappler@siemens.com]=20 > Sent: maandag 25 september 2006 13:53 > To: Georgios Karagiannis; Ash, Gerald R (Jerry), ALABS; Attila B=E1der > (IJ/ETH) > Cc: nsis@ietf.org > Subject: [NSIS] AW: Recommendation on QSpec-1 parameters >=20 > Hi Georgios,=20 >=20 > essentially you would include always all parameters into the=20 > QSPEC. The goal > of the QSPEC exercise was however right the contrary: gain=20 > interoperability > by allowing (may be unprecise) "x-interpretation" of=20 > parameters. So I think > your proposal is - while entirely possible - not in the=20 > spirit of the draft. > There are other possibilities if you make slight compromises=20 > (regarding (i) > the exact interpretation of QNI parameters and (ii) what a=20 > QNE must be able > to do (note in the RMD case these are just the stateful edge QNEs!))=20 >=20 > Cornelia=20 >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > Gesendet: Freitag, 22. September 2006 11:25 > > An: 'Ash, Gerald R (Jerry), ALABS'; Kappler, Cornelia;=20 > 'Attila B=E1der=20 > > (IJ/ETH)' > > Cc: nsis@ietf.org > > Betreff: Recommendation on QSpec-1 parameters > >=20 > > Hi Jerry, Cornelia and Attila > >=20 > > I have made an exercise and tried to apply and use the > > QPSEC-1 (mandatory) and QSPEC-2 (optional) parameters into the=20 > > RMD-QOSM. Please note that in my opinion one might get the same=20 > > conclusions if another edge-to-edge QOSM will be used, e.g., the=20 > > future PCN QOSM. > >=20 > >=20 > > My conclusions are as follows: > >=20 > > 1) and parameters should be QSPEC-1=20 > > paramteres, > > but then=20 > > a QNI MUST include both. A QNE that receives both these=20 > > parameters must: > >=20 > > * either strictly interpret at least one of the=20 > > parameters. In this case > > the "R"=20 > > flag and "Q" flags MUST not be set. > >=20 > > * or remap one of the parameters into another parameter=20 > > (e.g. > Bucket> into > > In this case the remapped parameter (e.g., > > has to set the flag. The flag should also be set. > >=20 > >=20 > >=20 > > 2) The parameter influences the way of how the=20 > > data packets should be treated within an edge-to-edge domain. > > In this way the solutions that can be provided by RMD-QOSM in=20 > > situations of=20 > > e.g., severe congestion are limited. Note that this also will=20 > > influence a > > solution=20 > > such as PCN in case of solving the preemption issue. > > My recommendation is to ignore this parameter when it has to=20 > > be used in > > such edge-to-edge domains. This means that this parameter should be=20 > > * either a QSPEC-2 parameter=20 > > * or a QSPEC-1 parameter that is able to be ignored=20 > > in edge-to-edge domains, without that the flags "R" and=20 > > "Q" flags are > > set.=20 > > In the last case the QOSM description should emphasize that > > this parameter is ignored.=20 > >=20 > >=20 > > 3) : as already mentioned in the last version of the QSPEC > > template draft > > such a parameter cannot be mandatory, because in several countries > > preemption of > > sessions in favour of others is not allowed. Thus this=20 > > parameter, should > > either be=20 > > a QSPEC-2 parameter or a QSPEC-1 that could be in some=20 > > cases ignored. > > Further, I would again recommend that all the =20 > > parameters, MUST > > be included=20 > > by a QNI, then a QNE that receives these parameters could: > > * either strictly interpret at least one of the=20 > > parameters. In this case > > the "R"=20 > > flag and "Q" flags MUST not be set. > >=20 > > * or remap one of the parameters into another parameter=20 > > In this case the remapped parameter > > has to set the flag. The flag should also be set. > > =20 > > 4) : this parameter can be a QSPEC-1 parameter,=20 > > but a QNI MUST > > include=20 > > all parameters, i.e., , > Type> and=20 > > . Then a QNE that receives these=20 > > parameters could: > > * either strictly interpret at least one of the=20 > > parameters. In this case > > the "R"=20 > > flag and "Q" flags MUST not be set. > >=20 > > * or remap one of the parameters into another parameter,=20 > > e.g., "DSCP" =3D> > > "PHB ID code" > > In this case the remapped parameter, e.g., > > has to set the flag. The flag should also be set. > >=20 > > Best Regards, > > Georgios > >=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 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Sep 26 11:55:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSFHD-0003u4-8Q; Tue, 26 Sep 2006 11:55:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSFHC-0003td-C8 for nsis@ietf.org; Tue, 26 Sep 2006 11:55:18 -0400 Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSFHB-0007N5-4D for nsis@ietf.org; Tue, 26 Sep 2006 11:55:18 -0400 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx.mail.saic.com; Tue, 26 Sep 2006 11:55:00 -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 M2006092611545700888 ; Tue, 26 Sep 2006 11:54:59 -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, 26 Sep 2006 11:54: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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] AW: Recommendation on QSpec-1 parameters Date: Tue, 26 Sep 2006 11:54:52 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426230EB0@0591-ITS-EXMP02.us.saic.com> In-Reply-To: <002701c6e180$bbbee070$4c0d5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] AW: Recommendation on QSpec-1 parameters Thread-Index: Aca/6wl1mien3kJ5R0u2kXlkJtiCmAIP4e+wAAWS8CAAAoy9AAOH1HuAACvc7DAAAM4ZkAAAThngAA7rUXAAHft90AAEopLQAABi+9AAAL3FQAAAyKRQAAATFzAANAFP4ACdR8LQACcVEaAAAinnwACTWb4AAJ0ZMbAABsNIEAAsBDoQAAHp99AABeK/gA== From: "Roy, Radhika R." To: "Georgios Karagiannis" X-OriginalArrivalTime: 26 Sep 2006 15:54:52.0726 (UTC) FILETIME=[1ABE7560:01C6E184] 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 Georgios and all: Is it not wise to drop the QOS classes like Y.1541 and DSTE from the QSPEC draft in the first place as we mentioned over the years? Can anyone make any sense when they want to "map" between Y.1541 and DSTE QOS classes?=20 Moreover, are those "values" not chosen those independent from one another to sever different purposes decoupling "arbitrarily" from the needs of the upper layer applications just to have the network-centric view? Even from the network-centric view, will anyone be able to "map" between Y.1541 and DSTE QOS classes that make technical sense to sever the purpose of the network QOS, if not application QOS? Best regards, Radhika > b) Doubtlessly there is no perfect mapping between=20 > the individual parameters. But then the goal of=20 > QoS NSLP is interoperability. And this is only=20 > possible when allowing an (imperfect) mapping. Georgios: regarding b)=20 I am not talking about imperfect mapping, but I am referring to an impossible mapping. Could you please provide me with two examples: 1) Please provide an example of remapping of=20 the parameter into parameter 2) Please provide an example of remapping of=20 the parameter into parameter Many thanks in adavance! Best Regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Sep 26 11:58:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSFJq-0004bj-5v; Tue, 26 Sep 2006 11:58:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSFJo-0004Ny-OH for nsis@ietf.org; Tue, 26 Sep 2006 11:58:00 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GSFJi-0007oq-Bx for nsis@ietf.org; Tue, 26 Sep 2006 11:58:00 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-5.tower-120.messagelabs.com!1159286271!9832530!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 6965 invoked from network); 26 Sep 2006 15:57:51 -0000 Received: from unknown (HELO attrh9i.attrh.att.com) (134.24.146.4) by server-5.tower-120.messagelabs.com with SMTP; 26 Sep 2006 15:57:51 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh9i.attrh.att.com (8.13.7/8.13.7) with ESMTP id k8QFq2eZ015895; Tue, 26 Sep 2006 11:52:04 -0400 (EDT) Received: from OCCLUST04EVS1.ugd.att.com (ocst07.ugd.att.com [135.38.164.12]) by attrh9i.attrh.att.com (8.13.7/8.13.7) with ESMTP id k8QFptej015812; Tue, 26 Sep 2006 11:51:56 -0400 (EDT) Received: from kcclust06evs1.ugd.att.com ([135.38.164.89]) by OCCLUST04EVS1.ugd.att.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 26 Sep 2006 10:57:41 -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 Date: Tue, 26 Sep 2006 10:57:40 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7D98@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <000001c6de29$09feb270$4c0d5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Recommendation on QSpec-1 parameters thread-index: Aca/6wl1mien3kJ5R0u2kXlkJtiCmAIP4e+wAAWS8CAAAoy9AAOH1HuAACvc7DAAAM4ZkAAAThngAA7rUXAAHft90AAEopLQAABi+9AAAL3FQAAAyKRQAAATFzAANAFP4ACdR8LQACcVEaAAAinnwACTWb4AANeTFUA= From: "Ash, Gerald R \(Jerry\), ALABS" To: "Georgios Karagiannis" X-OriginalArrivalTime: 26 Sep 2006 15:57:41.0620 (UTC) FILETIME=[7F69A340:01C6E184] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: "Ash, Gerald R \(Jerry\), ALABS" , nsis@ietf.org Subject: [NSIS] RE: Recommendation on QSpec-1 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 Georgios, In the spirit of John's post http://www1.ietf.org/mail-archive/web/nsis/current/msg06726.html can we please hear from other people on this topic, and not have so many repetitions of RMD-QOSM specific concerns. E.g., we have seen many times: > The parameter influences the way of how the=20 > data packets should be treated within an edge-to-edge domain. > In this way the solutions that can be provided by RMD-QOSM in > situations of e.g., severe congestion are limited. Note that > this also will influence a solution such as PCN in case of > solving the preemption issue. A QNE supporting a different Local QOSM than the Initiator QOSM has 3 options 1. strictly interpret QSPEC-1 parameters populated in the Initiator QSPEC 2. remap QSPEC-1 parameters populated in the Initiator QSPEC (as specified in the Local-QOSM specification document) 3. reject the reservation In the instance you cite, #3 may be the appropriate response. Even if a QSPEC-1 parameter could be ignored the QNI would probably reject the reservation anyway. Thanks, Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Sep 26 12:02:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSFNW-0003jU-Hu; Tue, 26 Sep 2006 12:01:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSFNV-0003dc-6o for nsis@ietf.org; Tue, 26 Sep 2006 12:01:49 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSFNT-0000at-QZ for nsis@ietf.org; Tue, 26 Sep 2006 12:01:49 -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 k8QG1DoX027635; Tue, 26 Sep 2006 18:01:17 +0200 (MEST) From: "Georgios Karagiannis" To: "'Ash, Gerald R \(Jerry\), ALABS'" Date: Tue, 26 Sep 2006 18:01:10 +0200 Message-ID: <002d01c6e184$ff07ed00$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: Aca/6wl1mien3kJ5R0u2kXlkJtiCmAIP4e+wAAWS8CAAAoy9AAOH1HuAACvc7DAAAM4ZkAAAThngAA7rUXAAHft90AAEopLQAABi+9AAAL3FQAAAyKRQAAATFzAANAFP4ACdR8LQACcVEaAAAinnwACTWb4AANeTFUAAAKeXAA== In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC7D98@KCCLUST06EVS1.ugd.att.com> X-Spam-Score: -5.599 () ALL_TRUSTED,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, 26 Sep 2006 18:01:17 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: nsis@ietf.org Subject: [NSIS] RE: Recommendation on QSpec-1 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 Hi Jerry I think that you are right, we should hear the opinion of other people on the topic! Best Regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Sep 26 13:24:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSGf5-0006mL-Jn; Tue, 26 Sep 2006 13:24:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSGf4-0006mB-4a for nsis@ietf.org; Tue, 26 Sep 2006 13:24:02 -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 1GSGf2-0007Lj-Qu for nsis@ietf.org; Tue, 26 Sep 2006 13:24:02 -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, 26 Sep 2006 20:23:54 +0300 id 000AFD37.4519622A.00003457 Date: Tue, 26 Sep 2006 20:23:54 +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: 9466e0365fc95844abaf7c3f15a05c7d Subject: [NSIS] A question to people about QoS NSLP Tear operation X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.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, 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 From nsis-bounces@ietf.org Tue Sep 26 13:55:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSH94-0004Dh-5z; Tue, 26 Sep 2006 13:55:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSH91-00044G-TX for nsis@ietf.org; Tue, 26 Sep 2006 13:54:59 -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 1GSH8y-0004HC-Lq for nsis@ietf.org; Tue, 26 Sep 2006 13:54:59 -0400 Received: from [10.3.1.136] (din-cisuc136.dei.uc.pt [10.3.1.136]) (authenticated bits=0) by smtp2.dei.uc.pt (8.13.6/8.13.6) with ESMTP id k8QHsdxo031639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Sep 2006 18:54:39 +0100 Message-ID: <4519694E.4080005@student.dei.uc.pt> Date: Tue, 26 Sep 2006 18:54:22 +0100 From: David Palma User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) 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=ISO-8859-1; format=flowed 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: 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 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 From nsis-bounces@ietf.org Tue Sep 26 14:01:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSHEH-000057-Av; Tue, 26 Sep 2006 14:00:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSHEF-0008Ri-LZ for nsis@ietf.org; Tue, 26 Sep 2006 14:00: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 1GSHED-0004qT-5d for nsis@ietf.org; Tue, 26 Sep 2006 14:00: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; Tue, 26 Sep 2006 21:00:18 +0300 id 000AFD32.45196AB2.00004DDF Date: Tue, 26 Sep 2006 21:00:17 +0300 (EEST) From: Jukka MJ Manner To: David Palma Subject: Re: [NSIS] A question to people about QoS NSLP Tear operation In-Reply-To: <4519694E.4080005@student.dei.uc.pt> Message-ID: References: <4519694E.4080005@student.dei.uc.pt> 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: 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 message. That would be the simple solution, true, but I wonder if people are comfortable with just that. I'd like to hear people's views on wherther we should go for A) no RESPONSE messages to errors, no signaling of errors with tearing RESERVEs (just rely on the soft state). B) Provide something more (as presented in my email). Regards, Jukka On Tue, 26 Sep 2006, 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 From nsis-bounces@ietf.org Wed Sep 27 02:46:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSTAu-0006uI-T0; Wed, 27 Sep 2006 02:45:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSTAu-0006uD-Gp for nsis@ietf.org; Wed, 27 Sep 2006 02:45:44 -0400 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSTAt-0003UJ-2d for nsis@ietf.org; Wed, 27 Sep 2006 02:45:44 -0400 Received: from S4DE8PSAAGT.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Wed, 27 Sep 2006 08:45:42 +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, 27 Sep 2006 08:45:42 +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] RE: Recommendation on QSpec-1 parameters Date: Wed, 27 Sep 2006 08:45:41 +0200 Message-Id: <6439282641581441A36F7F6F83ED2ED2CBF88C@S4DE8PSAAFQ.mitte.t-com.de> in-reply-to: <9473683187ADC049A855ED2DA739ABCA0DDC7D98@KCCLUST06EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Recommendation on QSpec-1 parameters Thread-Index: AcbhhJ1CWCBxX0SOTkyPkMPP5gyDowAedsHw From: "Geib, Ruediger" To: X-OriginalArrivalTime: 27 Sep 2006 06:45:42.0040 (UTC) FILETIME=[8D048980:01C6E200] 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 Jerry, didn't read the draft in detail. As far as I understood,=20 it provides a toolbox supporting mappings between=20 different QoS definitions. A set of parameters has=20 been defined for mandatory support. The=20 discussion going on here seems to be, whether=20 that's a perfect set or not. If that describes the situation, my suggestion=20 would be to add a statement saying=20 that due to a lack of sufficient deployment the=20 contents of the document are a kind of best guess,=20 which should be reviewed once operational=20 experience requires or allows such a review.=20 Regards, Rudiger |-----Original Message----- |From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] |Sent: Tuesday, September 26, 2006 5:58 PM |To: Georgios Karagiannis |Cc: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org |Subject: [NSIS] RE: Recommendation on QSpec-1 parameters | | |Georgios, | |In the spirit of John's post |http://www1.ietf.org/mail-archive/web/nsis/current/msg06726.html can we |please hear from other people on this topic, and not have so many |repetitions of RMD-QOSM specific concerns. | |E.g., we have seen many times: | |> The parameter influences the way of how the=20 |> data packets should be treated within an edge-to-edge domain. |> In this way the solutions that can be provided by RMD-QOSM in |> situations of e.g., severe congestion are limited. Note that |> this also will influence a solution such as PCN in case of |> solving the preemption issue. | |A QNE supporting a different Local QOSM than the Initiator QOSM has 3 |options |1. strictly interpret QSPEC-1 parameters populated in the Initiator |QSPEC |2. remap QSPEC-1 parameters populated in the Initiator QSPEC (as |specified in the Local-QOSM specification document) |3. reject the reservation | |In the instance you cite, #3 may be the appropriate response. =20 |Even if a |QSPEC-1 parameter could be ignored the QNI would probably reject the |reservation anyway. | |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 Sep 27 11:31:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSbNH-0000Wi-PX; Wed, 27 Sep 2006 11:31:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSbNG-0000Vn-94 for nsis@ietf.org; Wed, 27 Sep 2006 11:31:02 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSbNC-0001Ku-KN for nsis@ietf.org; Wed, 27 Sep 2006 11:31:02 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 28EB61BAC4D; Wed, 27 Sep 2006 17:30:58 +0200 (CEST) In-Reply-To: <44D9FE47.4060104@tm.uka.de> References: <20060712163212.GA8050@mafr.de> <778F8072-E72D-461D-80B0-74ED876772C0@netlab.nec.de> <44D9FE47.4060104@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: Martin Stiemerling Subject: Re: [NSIS] NATFW: LE-MRM and NATFW_DTINFO_IPv4/IPv6 Date: Wed, 27 Sep 2006 17:30:56 +0200 To: Roland Bless X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac 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 and all, Sorry for the delay in answering. I have been away on holidays and some business trips. More inline. Martin Am 09.08.2006 um 17:24 schrieb Roland Bless: > Hi Martin, > > Martin Stiemerling wrote: >> The LE-MRM has been just defined for the NAT usage and is not >> intended >> for pure firewall usage. The main difference between LE-MRM and the >> PC-MRM in the NAT case is: The message can probably not be forwarded >> when the receiver is behind a NAT and it is using the PC-MRM with a >> wildcarded sender IP address. When there are multiple NATs in >> parallel >> to the Internet, GIST may have the issue of not knowing which >> route to >> take. In this case GIST would return an error message. By using the > > Sorry, but I absolutely don't get it. Why doesn't the GIST node know > which route to take? So a route lookup for the prefix N doesn't > succeed > in this case (no route) or returns more than one entry (should not > happen), or what? I can only imagine the "MRI too wild case", > i.e., specifying a /7 when you only have /8s or so. A node cannot know all possible inbound routes from the Internet. If there is just a single inbound route, it is not an issue at all, i.e., take this single route. However, if there are multiple inbound routes, i.e., a firewall/NAT with multiple IP interfaces, it is probably impossible to determine through which route the IP packets will arrive at your box. > > So what I understand from the draft and you mail is that: > - DS is currently unknown and somewhere outside your (DRs) NATed > domain. > - DR wants to do a REA first which also includes a route pinning, i.e. > no matter which NAT your REA hits, the incoming stream from DS > will then hit that particular NAT. > - DR sends a REA message "upstream" towards some external node > with IP address LS (and maybe LS!=DS) behind the NAT. > So the SDA is LS which is also used in the LE-MRM as destination. Yes, that's right. > > Why, then can't we use the very same address in a PC-MRM, so > ip.src=R, ip.dst=LS, > pc-mrm.src= LS, pc-mrm.dst= R, pc-mrm.direction=upstream > pc-mrm.prefixlength=32? > So it's not a wildcarded PC-MRM. In this case I don't see > any routing problem for GIST. Or, what is the reason that we must > use a wildcarded PC-MRM? What you describe was how we did it until the LE-MRM was "invented". This was considered as a "dirty hack". There is no public trace about this discussion, because it was on a sidetrack offline. Do you know about this old draft, initially explaining the reasoning for LE-MRM? http://www.watersprings.org/pub/id/draft-stiemerling-nsis-natfw- mrm-02.txt There is a semantical difference between the PC-MRM usage you have described and the LE-MRM usage. The described PC-MRM usage creates NTLP state at all NATFW NSLP nodes with this MRI pc-mrm.src= LS, pc-mrm.dst= R, pc-mrm.direction=upstream, pc-mrm.prefixlength=32. The PC-MRM creates the corresponding state for the flow described with above MRI excerpt, i.e., flow source is LS, etc. This state is never used again in the future and does not correspond to any inbound flow, because LS is not the real flow source. So this is to some degree ugly, because there is a state without relationship to real life. This "signaling somewhere to get out here" (i.e., the LE-MRM) is actually not describing a flow, compared to the PC-MRM. This is original reason to split them. Another reason is the multiple inbound routes case. With LE-MRM GIST is taking care about multiple inbound routes, because the flow source is the signaling destination address (SDA) actually not representing a flow. With PC-MRM the flow source may case GIST to stop forwarding if there are multiple inbound routes. Plus GIST cannot know whether the whole network is NAT'ed or not. > >> LE-MRM, GIST is always able to route the message upstream to "a" >> NAT. In >> the first place it is not necessary to hit the best NAT, i.e., >> closest >> to the data sender but to get a public reachable IP address. By >> choosing >> different SDAs, one may get a better or worse located NAT. > > I understand and this is also clear. If you vary LS, your NAT may > differ, but this doesn't matter (except for suboptimal routing) > because you pin down the route by hitting the NAT. > >> It is not that easy, because LE-MRM gives more power to hosts behind >> NATs. LE-MRM will definitely find an edge-NAT while PC-MRM can easily >> fail if there are multiple NATs in parallel. > > Sorry, but it's not clear to me why the LE-MRM gives more power > to hosts. If we use a PC-MRM like in the scenario above, there > will be no problem, or, can you explain once again, giving a concrete > example, why it would fail? Processing PC-MRM and LE-MRM is fundamentally different when it comes to multiple inbound routes. PC-MRM will probably fail, because GIST cannot determine which route is being taken. LE-MRM will keep working in any case. > >> However, it is time to rework the section(s) on the LE-MRM/PC-MRM >> usage >> (plus DTINFO) for getting it all clear. I see the issue of having the >> information about the MRM usage spread too much over the document and >> lack of some good introductory text. There will be an updated >> text in >> the next version clarifying this. > > Actually the "magic" or "special power" behind the LE-MRM is > currently not getting clear. Maybe there are some implicit > assumptions that are not written down yet. I assume that the reasoning for all of it is not clear I you haven't followed two years of discussions. Obviously, this is impossible. I have it on my list for the upcoming revision, to clarify on the LE-MRM usage and benefits. Thanks! Martin _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Sep 27 15:41:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSfHQ-0004jv-2x; Wed, 27 Sep 2006 15:41:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSfHP-0004h5-5z for nsis@ietf.org; Wed, 27 Sep 2006 15:41:15 -0400 Received: from natreg.rzone.de ([81.169.145.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSfHN-0005mv-Ns for nsis@ietf.org; Wed, 27 Sep 2006 15:41:15 -0400 Received: from [10.129.203.242] (gprs-pool-1-022.eplus-online.de [212.23.126.22]) (authenticated bits=0) by post.webmailer.de (8.13.6/8.13.6) with ESMTP id k8RJf4rE005750; Wed, 27 Sep 2006 21:41:06 +0200 (MEST) Message-ID: <451AD3CA.3020407@cs.uni-goettingen.de> Date: Wed, 27 Sep 2006 21:40:58 +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: <4519694E.4080005@student.dei.uc.pt> In-Reply-To: <4519694E.4080005@student.dei.uc.pt> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) 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 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 From nsis-bounces@ietf.org Thu Sep 28 02:51:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSpji-0002cZ-Jn; Thu, 28 Sep 2006 02:51:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSpjf-0002QM-FH for nsis@ietf.org; Thu, 28 Sep 2006 02:51:07 -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 1GSpcN-00076g-5A for nsis@ietf.org; Thu, 28 Sep 2006 02:43:36 -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; Thu, 28 Sep 2006 09:43:32 +0300 id 000AFD2E.451B6F14.00007950 Date: Thu, 28 Sep 2006 09:43:31 +0300 (EEST) From: Jukka MJ Manner To: Bernd Schloer Subject: Re: [NSIS] A question to people about QoS NSLP Tear operation In-Reply-To: <451AD3CA.3020407@cs.uni-goettingen.de> Message-ID: References: <4519694E.4080005@student.dei.uc.pt> <451AD3CA.3020407@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: 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 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 From nsis-bounces@ietf.org Thu Sep 28 03:52:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSqgT-0004OK-QM; Thu, 28 Sep 2006 03:51:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSqgR-0004Cq-Na for nsis@ietf.org; Thu, 28 Sep 2006 03:51:51 -0400 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSqgK-000337-4B for nsis@ietf.org; Thu, 28 Sep 2006 03:51:47 -0400 Received: from mail3.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id k8S7pfZ2012441; Thu, 28 Sep 2006 09:51:41 +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 k8S7pfYa005997; Thu, 28 Sep 2006 09:51:41 +0200 Received: from blns00fa.ww002.siemens.net ([147.54.45.102]) by mchp771a.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Sep 2006 09:51:40 +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] RE: Recommendation on QSpec-1 parameters Date: Thu, 28 Sep 2006 09:51:39 +0200 Message-ID: In-Reply-To: <6439282641581441A36F7F6F83ED2ED2CBF88C@S4DE8PSAAFQ.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] RE: Recommendation on QSpec-1 parameters Thread-Index: AcbhhJ1CWCBxX0SOTkyPkMPP5gyDowAedsHwADUbYEA= From: "Kappler, Cornelia" To: "Geib, Ruediger" , X-OriginalArrivalTime: 28 Sep 2006 07:51:40.0912 (UTC) FILETIME=[EF1A3700:01C6E2D2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 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 Ruediger,=20 I think this is an excellent idea.=20 Cornelia=20 > -----Urspr=FCngliche Nachricht----- > Von: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]=20 > Gesendet: Mittwoch, 27. September 2006 08:46 > An: gash@att.com > Cc: nsis@ietf.org > Betreff: RE: [NSIS] RE: Recommendation on QSpec-1 parameters >=20 > Jerry, >=20 > didn't read the draft in detail. As far as I understood,=20 > it provides a toolbox supporting mappings between=20 > different QoS definitions. A set of parameters has=20 > been defined for mandatory support. The=20 > discussion going on here seems to be, whether=20 > that's a perfect set or not. >=20 > If that describes the situation, my suggestion=20 > would be to add a statement saying=20 > that due to a lack of sufficient deployment the=20 > contents of the document are a kind of best guess,=20 > which should be reviewed once operational=20 > experience requires or allows such a review.=20 >=20 > Regards, >=20 > Rudiger >=20 > |-----Original Message----- > |From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] > |Sent: Tuesday, September 26, 2006 5:58 PM > |To: Georgios Karagiannis > |Cc: Ash, Gerald R (Jerry), ALABS; nsis@ietf.org > |Subject: [NSIS] RE: Recommendation on QSpec-1 parameters > | > | > |Georgios, > | > |In the spirit of John's post > |http://www1.ietf.org/mail-archive/web/nsis/current/msg06726.h > tml can we > |please hear from other people on this topic, and not have so many > |repetitions of RMD-QOSM specific concerns. > | > |E.g., we have seen many times: > | > |> The parameter influences the way of how the=20 > |> data packets should be treated within an edge-to-edge domain. > |> In this way the solutions that can be provided by RMD-QOSM in > |> situations of e.g., severe congestion are limited. Note that > |> this also will influence a solution such as PCN in case of > |> solving the preemption issue. > | > |A QNE supporting a different Local QOSM than the Initiator QOSM has 3 > |options > |1. strictly interpret QSPEC-1 parameters populated in the Initiator > |QSPEC > |2. remap QSPEC-1 parameters populated in the Initiator QSPEC (as > |specified in the Local-QOSM specification document) > |3. reject the reservation > | > |In the instance you cite, #3 may be the appropriate response. =20 > |Even if a > |QSPEC-1 parameter could be ignored the QNI would probably reject the > |reservation anyway. > | > |Thanks, > |Jerry > | > |_______________________________________________ > |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 Thu Sep 28 04:39:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSrPu-00051C-Qi; Thu, 28 Sep 2006 04:38:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSrPt-000517-4a for nsis@ietf.org; Thu, 28 Sep 2006 04:38:49 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSrPq-000083-N8 for nsis@ietf.org; Thu, 28 Sep 2006 04:38:49 -0400 Received: from [127.0.0.1] (kobe.netlab.nec.de [195.37.70.60]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 8FF951BACA1; Thu, 28 Sep 2006 10:38:45 +0200 (CEST) In-Reply-To: <951128250608220220o656558a8n7c58c7baefb289bf@mail.gmail.com> References: <951128250608220220o656558a8n7c58c7baefb289bf@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <974B7D15-0B38-4E5A-9861-75AD6BB67BF6@netlab.nec.de> Content-Transfer-Encoding: quoted-printable From: Martin Stiemerling Subject: Re: [NSIS] Session Lifetime processing question [Section 3.4] Date: Thu, 28 Sep 2006 09:26:31 +0200 To: =?ISO-8859-1?Q?Rui_Vil=E3o?= X-Mailer: Apple Mail (2.752.2) 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 Rui, Am 22.08.2006 um 11:20 schrieb Rui Vil=E3o: > I'm from University of Coimbra and I'm currently implementing NATFW =20= > version 12. > > When processing the session lifetime object in a NF upstream node, =20 > after a successful response from the NR, as described in section =20 > 3.4 , one of three things can happen: > > - everything is OK, the response message continues to be forward; > - session lifetime is greater than the stored value, generates an =20 > error response message; > - session lifetime is smaller than the acceptable value for the =20 > node, generates an error response message. > > What to do when generating such an error response message? > > Is the default action of the response message to continue upstream =20 > with the proper error code? In this case what happens to the =20 > entities already signalled? Is the request deleted due to the soft-=20 > states or should we send a specific notify message towards the NR? You are right. There is some error processing missing here. I just =20 came across the same issue when doing the last round of proof reading. The error code will be propagated from the NF detecting the lifetime =20 issue (upstream **) to the NI. There is currently no notification of =20 this error condition towards the NR, leaving all NFs and the NR =20 already having seen the response in an undesired state. I.e., storing =20= NSLP signaling sessions that are basically not valid/needed. My proposal: NFs running in such an error condition must additionally =20= send a NOTIFY towards the NR. This NOTIFY can information the NFs on =20 the way to NR and the NR about the error condition. The NOTIFY =20 semantics would need to be adapted to this, because currently NOTIFY =20 messages are only allowed to be sent towards the NI. ** Trying to avoid upstream/downstream terminology for the NSLP level =20= starting NOW! ;-) Martin= _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Sep 28 04:39:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSrPu-00051C-Qi; Thu, 28 Sep 2006 04:38:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSrPt-000517-4a for nsis@ietf.org; Thu, 28 Sep 2006 04:38:49 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSrPq-000083-N8 for nsis@ietf.org; Thu, 28 Sep 2006 04:38:49 -0400 Received: from [127.0.0.1] (kobe.netlab.nec.de [195.37.70.60]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 8FF951BACA1; Thu, 28 Sep 2006 10:38:45 +0200 (CEST) In-Reply-To: <951128250608220220o656558a8n7c58c7baefb289bf@mail.gmail.com> References: <951128250608220220o656558a8n7c58c7baefb289bf@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <974B7D15-0B38-4E5A-9861-75AD6BB67BF6@netlab.nec.de> Content-Transfer-Encoding: quoted-printable From: Martin Stiemerling Subject: Re: [NSIS] Session Lifetime processing question [Section 3.4] Date: Thu, 28 Sep 2006 09:26:31 +0200 To: =?ISO-8859-1?Q?Rui_Vil=E3o?= X-Mailer: Apple Mail (2.752.2) 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 Rui, Am 22.08.2006 um 11:20 schrieb Rui Vil=E3o: > I'm from University of Coimbra and I'm currently implementing NATFW =20= > version 12. > > When processing the session lifetime object in a NF upstream node, =20 > after a successful response from the NR, as described in section =20 > 3.4 , one of three things can happen: > > - everything is OK, the response message continues to be forward; > - session lifetime is greater than the stored value, generates an =20 > error response message; > - session lifetime is smaller than the acceptable value for the =20 > node, generates an error response message. > > What to do when generating such an error response message? > > Is the default action of the response message to continue upstream =20 > with the proper error code? In this case what happens to the =20 > entities already signalled? Is the request deleted due to the soft-=20 > states or should we send a specific notify message towards the NR? You are right. There is some error processing missing here. I just =20 came across the same issue when doing the last round of proof reading. The error code will be propagated from the NF detecting the lifetime =20 issue (upstream **) to the NI. There is currently no notification of =20 this error condition towards the NR, leaving all NFs and the NR =20 already having seen the response in an undesired state. I.e., storing =20= NSLP signaling sessions that are basically not valid/needed. My proposal: NFs running in such an error condition must additionally =20= send a NOTIFY towards the NR. This NOTIFY can information the NFs on =20 the way to NR and the NR about the error condition. The NOTIFY =20 semantics would need to be adapted to this, because currently NOTIFY =20 messages are only allowed to be sent towards the NI. ** Trying to avoid upstream/downstream terminology for the NSLP level =20= starting NOW! ;-) Martin= _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Sep 28 04:39:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSrPx-00053t-2Q; Thu, 28 Sep 2006 04:38:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSrPv-00051U-Gw for nsis@ietf.org; Thu, 28 Sep 2006 04:38:51 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSrPt-00008A-3T for nsis@ietf.org; Thu, 28 Sep 2006 04:38:51 -0400 Received: from [127.0.0.1] (kobe.netlab.nec.de [195.37.70.60]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 72C651BACA3; Thu, 28 Sep 2006 10:38:46 +0200 (CEST) In-Reply-To: <20060812085050.GA8057@mafr.de> References: <20060812085050.GA8057@mafr.de> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6D8B4A87-7CE8-4EAF-8835-567973576728@netlab.nec.de> Content-Transfer-Encoding: 7bit From: Martin Stiemerling Date: Thu, 28 Sep 2006 10:25:12 +0200 To: Matthias Friedrich X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: nsis@ietf.org Subject: [NSIS] Re: NATFW Proxy Mode X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.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, Am 12.08.2006 um 10:50 schrieb Matthias Friedrich: > Hi, > > I've got a question about the NATFW Proxy Mode (Section 3.7.7.1, > "Proxying for a Data Sender"). It looks like case b) is incomplete: > > According to the spec, the NI+ may decide to "teardown the REA-PROXY > sessions", but there is noting said how it should be done. I think the It is described how to teardown REA-PROXY sessions, but in a hidden way. The REA-PROXY section mentions that processing of REA-PROXY and the CREATE message works in the same way as their non-proxy counterparts REA and CREATE. Therefore, the process of tearing down a REA-PROXY session is setting the session lifetime to zero. This will also terminate the corresponding CREATE sent by the edge-device. I have to admit that the text about this is somewhat short and can be easily misunderstood. I have added it to my issue list and I will add it to the issue tracker. > NI+ can't tear down the REA session because it would loose the > reserved > external address. Starting a new non-proxy REA session afterwards > doesn't help because a different external address would be reserved. You are right about loosing the external address if you teardown a REA or REA-PROXY session. However, the external address is still in use if there is already a CREATE message coming from outside, i.e., a non-proxy CREATE. > > I'd suggest to add to the spec that the NI+ should keep the old REA > session alive, but set the proxy bit in the REA messages to zero. The > NF then tears down the CREATE session in the usual way, by sending > CREATE(lifetime==0). What remains are two sessions: The old REA > session > and the CREATE session initiated by the DS. Interesting point of switching between proxy and non-proxy mode within a single NSLP signaling session. I have to go back and think about it and the implications. Martin _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Sep 28 04:39:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSrPx-00053t-2Q; Thu, 28 Sep 2006 04:38:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSrPv-00051U-Gw for nsis@ietf.org; Thu, 28 Sep 2006 04:38:51 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSrPt-00008A-3T for nsis@ietf.org; Thu, 28 Sep 2006 04:38:51 -0400 Received: from [127.0.0.1] (kobe.netlab.nec.de [195.37.70.60]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 72C651BACA3; Thu, 28 Sep 2006 10:38:46 +0200 (CEST) In-Reply-To: <20060812085050.GA8057@mafr.de> References: <20060812085050.GA8057@mafr.de> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6D8B4A87-7CE8-4EAF-8835-567973576728@netlab.nec.de> Content-Transfer-Encoding: 7bit From: Martin Stiemerling Date: Thu, 28 Sep 2006 10:25:12 +0200 To: Matthias Friedrich X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: nsis@ietf.org Subject: [NSIS] Re: NATFW Proxy Mode X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.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, Am 12.08.2006 um 10:50 schrieb Matthias Friedrich: > Hi, > > I've got a question about the NATFW Proxy Mode (Section 3.7.7.1, > "Proxying for a Data Sender"). It looks like case b) is incomplete: > > According to the spec, the NI+ may decide to "teardown the REA-PROXY > sessions", but there is noting said how it should be done. I think the It is described how to teardown REA-PROXY sessions, but in a hidden way. The REA-PROXY section mentions that processing of REA-PROXY and the CREATE message works in the same way as their non-proxy counterparts REA and CREATE. Therefore, the process of tearing down a REA-PROXY session is setting the session lifetime to zero. This will also terminate the corresponding CREATE sent by the edge-device. I have to admit that the text about this is somewhat short and can be easily misunderstood. I have added it to my issue list and I will add it to the issue tracker. > NI+ can't tear down the REA session because it would loose the > reserved > external address. Starting a new non-proxy REA session afterwards > doesn't help because a different external address would be reserved. You are right about loosing the external address if you teardown a REA or REA-PROXY session. However, the external address is still in use if there is already a CREATE message coming from outside, i.e., a non-proxy CREATE. > > I'd suggest to add to the spec that the NI+ should keep the old REA > session alive, but set the proxy bit in the REA messages to zero. The > NF then tears down the CREATE session in the usual way, by sending > CREATE(lifetime==0). What remains are two sessions: The old REA > session > and the CREATE session initiated by the DS. Interesting point of switching between proxy and non-proxy mode within a single NSLP signaling session. I have to go back and think about it and the implications. Martin _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Sep 28 06:43:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GStMO-0000bp-8E; Thu, 28 Sep 2006 06:43:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GStMN-0000Yf-IZ for nsis@ietf.org; Thu, 28 Sep 2006 06:43:19 -0400 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GStMK-0005Tm-KB for nsis@ietf.org; Thu, 28 Sep 2006 06:43:19 -0400 Received: from mail1.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id k8SAh68e004165; Thu, 28 Sep 2006 12:43:06 +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 k8SAh5gR031541; Thu, 28 Sep 2006 12:43:05 +0200 Received: from blns00fa.ww002.siemens.net ([147.54.45.102]) by mchp7wta.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Sep 2006 12:43:04 +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] AW: Recommendation on QSpec-1 parameters Date: Thu, 28 Sep 2006 12:43:03 +0200 Message-ID: In-Reply-To: <002701c6e180$bbbee070$4c0d5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] AW: Recommendation on QSpec-1 parameters Thread-Index: Aca/6wl1mien3kJ5R0u2kXlkJtiCmAIP4e+wAAWS8CAAAoy9AAOH1HuAACvc7DAAAM4ZkAAAThngAA7rUXAAHft90AAEopLQAABi+9AAAL3FQAAAyKRQAAATFzAANAFP4ACdR8LQACcVEaAAAinnwACTWb4AAJ0ZMbAABsNIEAAsBDoQAAHp99AAX6osYA== From: "Kappler, Cornelia" To: "Georgios Karagiannis" , "Ash, Gerald R \(Jerry\), ALABS" , =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= X-OriginalArrivalTime: 28 Sep 2006 10:43:04.0933 (UTC) FILETIME=[E0DB4950:01C6E2EA] X-Spam-Score: 0.0 (/) X-Scan-Signature: e3ebaaff3b3539efaf29ef65eea2aded 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 I think it is very hard to determine what is the right set of parameters = without any actual deployment.=20 A QNI can always include values for all QSPEC-1 parameters if it thinks = this is useful. But I see no point in mandating this.=20 If Excess Treatment is set to remark, but a particular QOSM only has one = queue, then the remarking may just mean "drop". So I dont see a problem = here, either.=20 I havent thought about mappings between different QoS Classes, and may = be it is difficult to do. But why would the QNI be in a better position = to map (because it would essentially do that when including values for = all parameters) than a QNE? And if the QNI thinks it knows better then = it can include the values. Cornelia > -----Urspr=FCngliche Nachricht----- > Von: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 > Gesendet: Dienstag, 26. September 2006 17:31 > An: Kappler, Cornelia; 'Ash, Gerald R (Jerry), ALABS';=20 > 'Attila B=E1der (IJ/ETH)' > Cc: nsis@ietf.org > Betreff: RE: [NSIS] AW: Recommendation on QSpec-1 parameters >=20 > Hi Cornelia >=20 > Please see in line! > =20 >=20 > -----Original Message----- > From: Kappler, Cornelia [mailto:cornelia.kappler@siemens.com]=20 > Sent: dinsdag 26 september 2006 14:10 > To: Georgios Karagiannis; Ash, Gerald R (Jerry), ALABS; Attila B=E1der > (IJ/ETH) > Cc: nsis@ietf.org > Subject: AW: [NSIS] AW: Recommendation on QSpec-1 parameters >=20 > Hi Georgios >=20 > > Re (1): > "cause collapse in network performance": I assume this is something=20 > > you think might happen rather than the result of a measurement?=20 > > For sure the inclusion of every mandatory parameter is a=20 > > trade off between performance and interoperabilty. And my=20 > > impression is "rough consensus" in the WG is including=20 > > Excess Treatment (since we dont have any measurements)=20 > > [reading your more detailed email attached my impression=20 > > is you worry particularly about a QNE being forced to=20 > remark rather than > drop.=20 > > So may be this is a problem with this particular value of Excess > Treatment?] >=20 > Georgios: Please note that the main problem with this relates=20 > to the Treatment> parameter. > The problem does impact not only the network performance,=20 > but also the > operation of the network. > If a node strictly follows the mandated requirement, then=20 > in case of > e.g., a severe congestion, then > the network might completely collapse, i.e., a total=20 > network failure > could occur. > Regarding the Excess Treatment value, the current=20 > specification mentions > that=20 > the QNI will specify the value! >=20 > > Re (2): > a) As you know, the QNI does NOT need to include every=20 > > parameter (ceterum censeo...!?!?!?!) (Nor a QNI must=20 > > be able to fill all three priority parameters.=20 > > A QNI only fills those parameters it cares about) >=20 > Georgios: regarding a)=20 > Yes, I know that the current version specifies that the QNI=20 > does NOT need to > include every parameter. > And that is exactly what creates the problems mentioned by=20 > me. If the QNI > will be required to > include these parameters, then most of the remapping problems=20 > within the > network are solved. > This is because the QNI will actually do the remapping by=20 > itself and it will > have a better knowledge=20 > on accepting or rejecting a requested reservation.=20 > For example, if we look to the QoS Class parameters,=20 > each of the QoS class parameters are usefull in > some setting and impossible in other settings. In order to=20 > make the class> > parameter always possible we can do that by requiring that=20 > the QNI must > include all three QoS class parameters, then a QNE can choose=20 > the one that it needs. Note that if a QNI is interested only=20 > in one of them, > say , then the QNI > Could set this parameter as QSPEC-1 parameter. However, in=20 > this case the QNI > MUST also fill in the other two parameters, i.e., =20 > and class type>, which can be set as QSPEC-2 parameters. > In this way it will be possible for any QNE to remap the value of the > QSPEC-1 parameter, e.g.,=20 > into either or .=20 > Furthermore, > the QNI will have all the knowledge=20 > On which method has been used for the remapping of the > parameter. >=20 > > b) Doubtlessly there is no perfect mapping between=20 > > the individual parameters. But then the goal of=20 > > QoS NSLP is interoperability. And this is only=20 > > possible when allowing an (imperfect) mapping. >=20 > Georgios: regarding b)=20 > I am not talking about imperfect mapping, but I am referring to an > impossible mapping. > Could you please provide me with two examples: > 1) Please provide an example of remapping of=20 > the parameter into parameter > 2) Please provide an example of remapping of=20 > the parameter into parameter >=20 >=20 > Many thanks in adavance! > Best Regards, > Georgios >=20 >=20 >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > Gesendet: Montag, 25. September 2006 17:22 > > An: Kappler, Cornelia; 'Ash, Gerald R (Jerry), ALABS';=20 > 'Attila B=E1der=20 > > (IJ/ETH)' > > Cc: nsis@ietf.org > > Betreff: RE: [NSIS] AW: Recommendation on QSpec-1 parameters > >=20 > > Hi Cornelia > >=20 > > The problems that I have found with these parameters are: > >=20 > > 1) Not all QSPEC-1 parameters are necessary to provide the=20 > > interoperability. > > For example, the QNE must support each parameter even if that=20 > > parameter causes a collapse in > > the network performance, e.g., .=20 > >=20 > > 2) There are 4 sets of QSPEC-1 parameters: , ,=20 > > > Treatment> > > . Each of these sets includes more than one parameter,=20 > > e.g., > > includes the , and QoS class>=20 > > parameters. However, > > in the current version of QSpec template, a QNI must include at=20 > > least one > >=20 > > of the parameters. Thus, for example, consider that a=20 > QNI includes=20 > > either a > > a or a . Based on=20 > the current=20 > > QSpec template specification > > a diffserv based QNE must be able to interpret a class type>=20 > > and a > > =20 > > even if it cannot do that! Please note that I do not=20 > think that it=20 > > is possible > > to remap a or a =20 > parameter into=20 > > a PHB class parameter. > >=20 > >=20 > > Below you can find a copy of the e-mail that I have sent=20 > this morning=20 > > that describes these issues in a more detailed way: > >=20 > > --------------------- > >=20 > >=20 > > * Regarding the , the RMD QNEs should be able to=20 > > choose the most efficient way for excess treatment in order to for=20 > > example, solve severe congestion situations. > > If this parameter is mandatory, this will mean that the end=20 > QNI will=20 > > dictate what kind of excess treatment should be used by each QNE in=20 > > the RMD domain. > > This will limit the way of how the severe congestion is solved. > >=20 > > Note that in a severe congestion situation, typically most packets=20 > > will be dropped! However, if the is=20 > mandatory and=20 > > the end QNI dictates that the packets should be remarked and not=20 > > dropped, then all the nodes that are under severe=20 > congestion will keep=20 > > the congestion and the network will very quickly collapse. > >=20 > >=20 > > * Regarding and , if both are included in=20 > > the > desired> or then a QNE can choose the one of the two > > parameters. > >=20 > > A problem may arise from the fact that the QNI will not=20 > know which of=20 > > the one is used by the QNEs. > > One solution of this problem can be solved in the following way: > > If a QNI is willing to use the parameter as=20 > mandatory,=20 > > then the QNI must include the parameter as QSPEC-1=20 > > parameter and it must also inlcude the parameter as=20 > > QSPEC-2 parameter. > > If a QNE cannot use the , then it will use=20 > the optional=20 > > parameter and will set the "R" and "Q" flags associated=20 > > with the parameter. > > When is chosen as QSPEC-1 parameter, then > Bucket> is > > chosen as > > QSPEC-2 parameter. A similar method of remapping as described above=20 > > can be followed. > > Note that in this case the way of how the remapping of one > > QSPEC-1 parameter > > value into another value is specified by the QNI.=20 > >=20 > >=20 > > * Regarding , the mentioned solution regarding the=20 > > remapping from > > high to normal by appling a degradation of high priority to=20 > > normal priority, > > maybe can help, but the main problem that I have is the fact=20 > > that all four > > parameters are mandatory and for a QOSM that uses=20 > > one of the four > > parameters, it is difficult to remap one of the=20 > > > parameters into another one. > >=20 > > If a QNI includes all 4 parameters, then a QNE can=20 > > choose the one > > that it needs! Note that a QNI should be able to fill all 4 QSPEC-1 > > parameters. This is the same situation as the=20 > > situation that a > > QNE should be able to process all QSPEC-1 parameters. > > A problem may arise from the fact that the QNI will not know=20 > > which of the > > one is used by the QNEs. > > One solution of this problem can be solved in the following way: > > Make only one of the four parameters QSPEC-1 parameter.=20 > > The QNI must include all the other three parameters as > > QSPEC-2 parameters. > > The way of how the remapping is done is similar to the=20 > > explanation that I > > give above regarding and parameters. > >=20 > >=20 > > * The problem with the QoS class parameters is that it is=20 > > very difficult to > > remap One of the QoS class parameters into another parameter.=20 > > In my previous > > e-mails I emphasized that each of the QoS class parameters=20 > > are usefull in > > some setting and useless in other settings. In order to make=20 > > the > > parameter always usefull We can do that by requiring that=20 > the QNI must > > include all three QoS class parameters, then a QNE can choose=20 > > the one that > > it needs. Note that a QNI should be able to fill all 3=20 > > QSPEC-1 > > parameters. This is the same situation as the situation that=20 > > a QNE should be > > able to process all QSPEC-1 parameters. > >=20 > > ---------------------------------- > >=20 > > Best Regards, > > Georgios > >=20 > > -----Original Message----- > > From: Kappler, Cornelia [mailto:cornelia.kappler@siemens.com]=20 > > Sent: maandag 25 september 2006 13:53 > > To: Georgios Karagiannis; Ash, Gerald R (Jerry), ALABS; Attila = B=E1der > > (IJ/ETH) > > Cc: nsis@ietf.org > > Subject: [NSIS] AW: Recommendation on QSpec-1 parameters > >=20 > > Hi Georgios,=20 > >=20 > > essentially you would include always all parameters into the=20 > > QSPEC. The goal > > of the QSPEC exercise was however right the contrary: gain=20 > > interoperability > > by allowing (may be unprecise) "x-interpretation" of=20 > > parameters. So I think > > your proposal is - while entirely possible - not in the=20 > > spirit of the draft. > > There are other possibilities if you make slight compromises=20 > > (regarding (i) > > the exact interpretation of QNI parameters and (ii) what a=20 > > QNE must be able > > to do (note in the RMD case these are just the stateful=20 > edge QNEs!))=20 > >=20 > > Cornelia=20 > >=20 > > > -----Urspr=FCngliche Nachricht----- > > > Von: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > Gesendet: Freitag, 22. September 2006 11:25 > > > An: 'Ash, Gerald R (Jerry), ALABS'; Kappler, Cornelia;=20 > > 'Attila B=E1der=20 > > > (IJ/ETH)' > > > Cc: nsis@ietf.org > > > Betreff: Recommendation on QSpec-1 parameters > > >=20 > > > Hi Jerry, Cornelia and Attila > > >=20 > > > I have made an exercise and tried to apply and use the > > > QPSEC-1 (mandatory) and QSPEC-2 (optional) parameters into the=20 > > > RMD-QOSM. Please note that in my opinion one might get the same=20 > > > conclusions if another edge-to-edge QOSM will be used, e.g., the=20 > > > future PCN QOSM. > > >=20 > > >=20 > > > My conclusions are as follows: > > >=20 > > > 1) and parameters should be QSPEC-1=20 > > > paramteres, > > > but then=20 > > > a QNI MUST include both. A QNE that receives both these=20 > > > parameters must: > > >=20 > > > * either strictly interpret at least one of the=20 > > > parameters. In this case > > > the "R"=20 > > > flag and "Q" flags MUST not be set. > > >=20 > > > * or remap one of the parameters into another parameter=20 > > > (e.g. > > Bucket> into > > > In this case the remapped parameter (e.g., > > > has to set the flag. The flag should also be set. > > >=20 > > >=20 > > >=20 > > > 2) The parameter influences the way of how the=20 > > > data packets should be treated within an edge-to-edge domain. > > > In this way the solutions that can be provided by RMD-QOSM in=20 > > > situations of=20 > > > e.g., severe congestion are limited. Note that this also will=20 > > > influence a > > > solution=20 > > > such as PCN in case of solving the preemption issue. > > > My recommendation is to ignore this parameter when it has to=20 > > > be used in > > > such edge-to-edge domains. This means that this parameter=20 > should be=20 > > > * either a QSPEC-2 parameter=20 > > > * or a QSPEC-1 parameter that is able to be ignored=20 > > > in edge-to-edge domains, without that the flags "R" and=20 > > > "Q" flags are > > > set.=20 > > > In the last case the QOSM description should emphasize that > > > this parameter is ignored.=20 > > >=20 > > >=20 > > > 3) : as already mentioned in the last version=20 > of the QSPEC > > > template draft > > > such a parameter cannot be mandatory, because in=20 > several countries > > > preemption of > > > sessions in favour of others is not allowed. Thus this=20 > > > parameter, should > > > either be=20 > > > a QSPEC-2 parameter or a QSPEC-1 that could be in some=20 > > > cases ignored. > > > Further, I would again recommend that all the =20 > > > parameters, MUST > > > be included=20 > > > by a QNI, then a QNE that receives these parameters could: > > > * either strictly interpret at least one of the=20 > > > parameters. In this case > > > the "R"=20 > > > flag and "Q" flags MUST not be set. > > >=20 > > > * or remap one of the parameters into another parameter=20 > > > In this case the remapped parameter > > > has to set the flag. The flag should also be set. > > > =20 > > > 4) : this parameter can be a QSPEC-1 parameter,=20 > > > but a QNI MUST > > > include=20 > > > all parameters, i.e., , > > Type> and=20 > > > . Then a QNE that receives these=20 > > > parameters could: > > > * either strictly interpret at least one of the=20 > > > parameters. In this case > > > the "R"=20 > > > flag and "Q" flags MUST not be set. > > >=20 > > > * or remap one of the parameters into another parameter,=20 > > > e.g., "DSCP" =3D> > > > "PHB ID code" > > > In this case the remapped parameter, e.g., > > > has to set the flag. The flag should also be set. > > >=20 > > > Best Regards, > > > Georgios > > >=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 >=20 >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Sep 28 07:27:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSu2o-00082r-LR; Thu, 28 Sep 2006 07:27:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSu2o-00082m-8W for nsis@ietf.org; Thu, 28 Sep 2006 07:27:10 -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 1GSu2j-0004cy-Iy for nsis@ietf.org; Thu, 28 Sep 2006 07:27:10 -0400 Received: from win2003.dickmann2003.home (p548A51A3.dip.t-dialin.net [84.138.81.163]) by www.difra-computer.de (Postfix) with ESMTP id A21B33E4083 for ; Thu, 28 Sep 2006 13:26:10 +0200 (CEST) MIME-Version: 1.0 Date: Thu, 28 Sep 2006 13:14:43 +0200 Content-class: urn:content-classes:message Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NSIS for end users - It's reality Thread-Index: Acbi8LoxXMKAMt3cQHaZTwSNFzJ2Cw== From: "Christian Dickmann" To: , X-Spam-Score: 0.1 (/) X-Scan-Signature: 2d133cc328f58695161c98bb4f4dc213 Cc: nsis_imp@informatik.uni-goettingen.de Subject: [NSIS] NSIS for end users - It's reality X-BeenThere: nsis@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="===============0384234064==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0384234064== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6E2EF.4C727190" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C6E2EF.4C727190 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 the NSIS team of the University of Goettingen is proud to announce the release of a new development version of our NSIS package, which offers a lot of new features. We now support Traffic Control (tc) on Linux to really reserve resources and allow the integration of NSIS/QoS into applications by offering a QoS NSLP API. This development version also comes with a lot of bugfixes and updates to new draft versions of GIST and QoS NSLP.=20 =20 However, the most exciting new feature is the support for Windows XP and OpenWRT[1]! =20 The Windows XP version is a demonstration prototype, which is able to detect the UDP port used by Skype[2] and trigger the local QoS NSLP daemon to request resources for phone calls. In addition, we support OpenWRT, which is a Linux distribution for embedded devices, i.e. broadband Wireless LAN / DSL routers. On a lot of such routers, like the Linksys WRT54G (see the OpenWRT homepage[1] for a list of supported hardware), OpenWRT can be installed as an alternative firmware. =20 All new features combined, NSIS usage in SOHO networks becomes reality!=20 The Windows machine triggers the request and the DSL router reserves the resources by the use of the Traffic Control tool. =20 You can find the development versions for all platforms of the NSIS package on our beta version page. The ChangeLog which lists all changes is also available on that page. Please see the individual README files on how to use the packages. =20 http://user.informatik.uni-goettingen.de/~nsis/beta.html =20 We encourage anyone to try this development version and appreciate feedback of any kind, such as installation/setup experience, bug reports, feature requests, etc. =20 Christian Dickmann On behalf of University of Goettingen NSIS team =20 [1] OpenWRT: http://www.openwrt.org [2] Skype: http://www.skype.com =20 ------_=_NextPart_001_01C6E2EF.4C727190 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

the NSIS team of the University of Goettingen is proud to announce the release of a new development version of our = NSIS package, which offers a lot of new features. We now support Traffic = Control (tc) on Linux to really reserve resources and allow the integration of = NSIS/QoS into applications by offering a QoS NSLP API. This development version = also comes with a lot of bugfixes and updates to new draft versions of GIST = and QoS NSLP.

 

However, the most exciting new feature is the = support for Windows XP and OpenWRT[1]!

 

The Windows XP version is a demonstration = prototype, which is able to detect the UDP port used by Skype[2] and trigger the = local QoS NSLP daemon to request resources for phone = calls.

In addition, we support OpenWRT, which is a = Linux distribution for embedded devices, i.e. broadband Wireless LAN / DSL = routers. On a lot of such routers, like the Linksys WRT54G (see the OpenWRT = homepage[1] for a list of supported hardware), OpenWRT can be installed as an = alternative firmware.

 

All new features combined, NSIS usage in = SOHO networks becomes reality! =

The Windows machine triggers the request and = the DSL router reserves the resources by the use of the Traffic Control = tool.

 

You can find the development versions for all platforms of the NSIS package on our beta version page. The ChangeLog = which lists all changes is also available on that page. Please see the = individual README files on how to use the packages.

 

http://user.informatik.uni-goettingen.de/~nsis= /beta.html

 

We encourage anyone to try this development = version and appreciate feedback of any kind, such as installation/setup = experience, bug reports, feature requests, etc.

 

Christian = Dickmann

On behalf of University of Goettingen NSIS team

 

[1] OpenWRT: http://www.openwrt.org

[2] Skype: http://www.skype.com

 

------_=_NextPart_001_01C6E2EF.4C727190-- --===============0384234064== 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 --===============0384234064==-- From nsis-bounces@ietf.org Thu Sep 28 13:28:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSzfW-0000sF-R4; Thu, 28 Sep 2006 13:27:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSzfV-0000p2-MV for nsis@ietf.org; Thu, 28 Sep 2006 13:27:29 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSzfU-0000T9-As for nsis@ietf.org; Thu, 28 Sep 2006 13:27:29 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A2FA38E0001 for ; Thu, 28 Sep 2006 19:27:27 +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, 28 Sep 2006 19:27:27 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Sep 2006 19:27:27 +0200 Message-ID: <451C05FF.3000509@ericsson.com> Date: Thu, 28 Sep 2006 19:27:27 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Magnus Westerlund Subject: Re: [NSIS] Volunteers to be IANA expert reviewer for GIST References: <45017369.9030502@ericsson.com> In-Reply-To: <45017369.9030502@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Sep 2006 17:27:27.0210 (UTC) FILETIME=[5E4CF4A0:01C6E323] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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, The IESG has appointed Robert Hancock (robert.hancock@roke.co.uk) as designated IANA expert for GIST (draft-ietf-nsis-ntlp) effective with the approval of that protocol specification. Cheers Magnus Magnus Westerlund skrev: > Hi, > > GIST (draft-ietf-nsis-ntlp) specifies some IANA managed registries where > the policy is expert review. The expert will review any registration > requests in those registries (and value ranges) that are under this > policy to ensure that requests are following the rules for these > registries and are sensible. It important that the expert reviewer can > perform these requests in a timely manner. For more information on the > role of IANA designated experts, see RFC 2434. > > So if you have the necessary skills for this role and are interested in > volunteering please send me an email before the 25th of September. > > Best Regards > > Magnus Westerlund > TSV AD > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > -- 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 Sep 28 14:28:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT0bc-00048k-Jw; Thu, 28 Sep 2006 14:27:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT0ba-00048X-L9 for nsis@ietf.org; Thu, 28 Sep 2006 14:27:30 -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 1GT0bY-0008Ki-F1 for nsis@ietf.org; Thu, 28 Sep 2006 14:27:30 -0400 Received: from Bea (87-196-126-179.net.novis.pt [87.196.126.179]) by smtp.dei.uc.pt (8.13.6/8.13.6) with ESMTP id k8SIQUDS010281; Thu, 28 Sep 2006 19:26:30 +0100 From: "Marilia Curado" To: Date: Thu, 28 Sep 2006 19:26:23 +0100 Organization: University of Coimbra Message-ID: <025701c6e32b$9d5414f0$6402a8c0@Bea> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcbjK5kGGyxN/8mVQz+5DUC0t+3RdA== 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=-0.552, required 3, BAYES_00 -2.60, HTML_MESSAGE 0.00, RCVD_IN_SORBS_DUL 2.05) X-FCTUC-DEI-SIC-MailScanner-From: marilia@dei.uc.pt X-Spam-Status: No X-Spam-Score: 0.1 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Cc: =?iso-8859-1?Q?'Lu=EDs_Cordeiro'?= Subject: [NSIS] Coimbra NSIS interop event X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: marilia@dei.uc.pt List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0471697264==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0471697264== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0258_01C6E333.FF187CF0" This is a multi-part message in MIME format. ------=_NextPart_000_0258_01C6E333.FF187CF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, =20 The NSIS interop will take place in the University of Coimbra on October 12th and 13th. The event will be supported by the EuQoS and Eurolabs IST projects. =20 At the moment we have the confirmation of 4 different implementations. =20 I=92m renewing our invitation to come to Coimbra. If you are not able to = come and are willing to make remote tests on these dates, please inform us, = and we will include your implementation in the test planning. =20 Looking forward to hear from you. =20 Mar=EDlia Curado ------=_NextPart_000_0258_01C6E333.FF187CF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear all,

 

The NSIS interop will take place in the = University of = Coimbra on October 12th and = 13th. The event will be supported by the EuQoS and Eurolabs IST = projects.

 

At the moment we have the confirmation of 4 = different implementations.

 

I’m renewing our invitation to come to = Coimbra. If = you are not able to come and are willing to make remote tests on these dates, please = inform us, and we will include your implementation in the test = planning.

 

Looking forward to hear from = you.

 

Mar=EDlia Curado

------=_NextPart_000_0258_01C6E333.FF187CF0-- --===============0471697264== 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 --===============0471697264==-- From nsis-bounces@ietf.org Thu Sep 28 15:08:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT1Ef-0004vm-W8; Thu, 28 Sep 2006 15:07:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT1Ee-0004ve-R1 for nsis@ietf.org; Thu, 28 Sep 2006 15:07:52 -0400 Received: from natlemon.rzone.de ([81.169.145.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GT1Ec-000158-Bd for nsis@ietf.org; Thu, 28 Sep 2006 15:07:52 -0400 Received: from [192.168.178.200] (p5484B886.dip0.t-ipconnect.de [84.132.184.134]) (authenticated bits=0) by post.webmailer.de (8.13.6/8.13.6) with ESMTP id k8SJ7k3c018571; Thu, 28 Sep 2006 21:07:47 +0200 (MEST) Message-ID: <451C1D80.3000006@cs.uni-goettingen.de> Date: Thu, 28 Sep 2006 21:07:44 +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: <4519694E.4080005@student.dei.uc.pt> <451AD3CA.3020407@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: 7fa173a723009a6ca8ce575a65a5d813 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 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 From nsis-bounces@ietf.org Fri Sep 29 05:01:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTEEj-0003kb-HJ; Fri, 29 Sep 2006 05:00:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTEEi-0003k1-D9 for nsis@ietf.org; Fri, 29 Sep 2006 05:00:48 -0400 Received: from smtp.mei.co.jp ([133.183.129.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTEEf-00009z-Kb for nsis@ietf.org; Fri, 29 Sep 2006 05:00:48 -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 k8T90SNE020085; Fri, 29 Sep 2006 18:00:28 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id k8T90TC29032; Fri, 29 Sep 2006 18:00:29 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/dodgers) with ESMTP id k8T90Sd21459; Fri, 29 Sep 2006 18:00:28 +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: Fri, 29 Sep 2006 16:59:27 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD012F2131@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: AcbjMZ9ZYS2M7EzDSx6KIW+UIk86ewAavUJA From: "Cheng Hong" To: "Bernd Schloer" , "Jukka MJ Manner" X-Spam-Score: 0.1 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 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 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.=20 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. =20 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=20 > -----Original Message----- > From: Bernd Schloer [mailto:bschloer@cs.uni-goettingen.de]=20 > 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 >=20 > Hi, >=20 > if a teardown is not possible due to some errors and the QNI=20 > gets informed about them, then the errors might be fixed and=20 > a clean teardown gets possible. >=20 > I prefer the signaling of errors rather than soft state removal. >=20 > Bernd >=20 >=20 > Jukka MJ Manner wrote: > > Hi, > >=20 > > If you look at the QoS NSLP error situations (codes), all sorts of=20 > > things could go wrong, e.g.: > >=20 > > - 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=20 > > failure) > >=20 > > Thus, would it be important to signal those errors to the=20 > QNI when a=20 > > resource removal failed? > >=20 > > Jukka > >=20 > > On Wed, 27 Sep 2006, Bernd Schloer wrote: > >=20 > >=20 > >>Hi Jukka and all, > >> > >>I agree with David that the soft state removes a session if=20 > it isn't=20 > >>refreshed any more. On the other hand it can be of interest=20 > for a QNI=20 > >>to know immediately about the success of a state removal.=20 > It can take=20 > >>quite a long time till the soft state expires. This could=20 > be a waste=20 > >>of resources. > >> > >>What error conditions do you have in mind? Do you thing the=20 > existing=20 > >>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 with the=20 > >>>TEAR flag, like missing QSPEC (if necessary) or if a=20 > reservation does=20 > >>>not exist (this message might also be silently dropped),=20 > this is not necessary. > >>> > >>>Even if the RESERVE with the TEAR flag is not accepted,=20 > after a while=20 > >>>the soft-state will take care of the process of removing=20 > this session=20 > >>>since it isn't refreshed anymore. > >>> > >>>For the same reason I believe that RII is not necessary=20 > since the QNI=20 > >>>doesn't need to be concerned with reservations that 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 too open. > >>>> > >>>>1. Can a Tear-operation cause an error situation, and=20 > 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 further? > >>>> > >>>>2. Can the QNI request a confirmation of state removal, that the=20 > >>>>operation was successful, e.g, by including an RII into=20 > 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=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.=20 > Now, if this QNE later gets > >>>>back an error message, or a RESPONSE, for a session it no=20 > longer knows, > >>>>what does the QNE do? Re-set up routing state towards the=20 > QNI using > >>>>GIST, and send the message forward? > >>>> > >>>>RSVP RFC2209 says basically that unknown messages are=20 > silently dropped. > >>>>Still, in this case, an error message, or a RESPONSE, can be=20 > >>>>considered to be similar to an RSVP CONFIRM (RACK)=20 > message, which is=20 > >>>>just forwarded without much processing. > >>>> > >>>> > >>>>Regards, > >>>>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 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Sep 29 06:10:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTFJS-0004Et-7h; Fri, 29 Sep 2006 06:09:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTFJQ-0004Eo-Li for nsis@ietf.org; Fri, 29 Sep 2006 06:09:44 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTFJO-0000dw-Ru for nsis@ietf.org; Fri, 29 Sep 2006 06:09:44 -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 k8TA9KVb000771; Fri, 29 Sep 2006 12:09:33 +0200 (MEST) From: "Georgios Karagiannis" To: "'Kappler, Cornelia'" , "'Ash, Gerald R \(Jerry\), ALABS'" , "=?iso-8859-1?Q?'Attila_B=E1der_=28IJ/ETH=29'?=" Subject: RE: [NSIS] AW: Recommendation on QSpec-1 parameters Date: Fri, 29 Sep 2006 12:09:17 +0200 Message-ID: <000101c6e3af$5ae09f10$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: Aca/6wl1mien3kJ5R0u2kXlkJtiCmAIP4e+wAAWS8CAAAoy9AAOH1HuAACvc7DAAAM4ZkAAAThngAA7rUXAAHft90AAEopLQAABi+9AAAL3FQAAAyKRQAAATFzAANAFP4ACdR8LQACcVEaAAAinnwACTWb4AAJ0ZMbAABsNIEAAsBDoQAAHp99AAX6osYAAxYz3w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: -5.54 () 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]); Fri, 29 Sep 2006 12:09:37 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 32604d42645517c44d778f1d111b40a6 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 But the main problem I have is that due to some QSPEC-1 constraints,=20 the edge-to-edge concept of NSIS will not be able to be deployed at all. = Therefore, it is important to solve these problems now! Best regards, Georgios=20 -----Original Message----- From: Kappler, Cornelia [mailto:cornelia.kappler@siemens.com]=20 Sent: donderdag 28 september 2006 12:43 To: Georgios Karagiannis; Ash, Gerald R (Jerry), ALABS; Attila B=E1der (IJ/ETH) Cc: nsis@ietf.org Subject: AW: [NSIS] AW: Recommendation on QSpec-1 parameters Hi Georgios,=20 I think it is very hard to determine what is the right set of parameters without any actual deployment.=20 A QNI can always include values for all QSPEC-1 parameters if it thinks = this is useful. But I see no point in mandating this.=20 If Excess Treatment is set to remark, but a particular QOSM only has one queue, then the remarking may just mean "drop". So I dont see a problem here, either.=20 I havent thought about mappings between different QoS Classes, and may = be it is difficult to do. But why would the QNI be in a better position to map (because it would essentially do that when including values for all parameters) than a QNE? And if the QNI thinks it knows better then it = can include the values. Cornelia > -----Urspr=FCngliche Nachricht----- > Von: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > Gesendet: Dienstag, 26. September 2006 17:31 > An: Kappler, Cornelia; 'Ash, Gerald R (Jerry), ALABS'; 'Attila B=E1der = > (IJ/ETH)' > Cc: nsis@ietf.org > Betreff: RE: [NSIS] AW: Recommendation on QSpec-1 parameters >=20 > Hi Cornelia >=20 > Please see in line! > =20 >=20 > -----Original Message----- > From: Kappler, Cornelia [mailto:cornelia.kappler@siemens.com] > Sent: dinsdag 26 september 2006 14:10 > To: Georgios Karagiannis; Ash, Gerald R (Jerry), ALABS; Attila B=E1der > (IJ/ETH) > Cc: nsis@ietf.org > Subject: AW: [NSIS] AW: Recommendation on QSpec-1 parameters >=20 > Hi Georgios >=20 > > Re (1): > "cause collapse in network performance": I assume this is something > > you think might happen rather than the result of a measurement?=20 > > For sure the inclusion of every mandatory parameter is a trade off=20 > > between performance and interoperabilty. And my impression is "rough = > > consensus" in the WG is including Excess Treatment (since we dont=20 > > have any measurements) [reading your more detailed email attached my = > > impression is you worry particularly about a QNE being forced to > remark rather than > drop.=20 > > So may be this is a problem with this particular value of Excess > Treatment?] >=20 > Georgios: Please note that the main problem with this relates to the=20 > Treatment> parameter. > The problem does impact not only the network performance, but also=20 > the operation of the network. > If a node strictly follows the mandated requirement, then in case=20 > of e.g., a severe congestion, then > the network might completely collapse, i.e., a total network=20 > failure could occur. > Regarding the Excess Treatment value, the current specification=20 > mentions that > the QNI will specify the value! >=20 > > Re (2): > a) As you know, the QNI does NOT need to include every > > parameter (ceterum censeo...!?!?!?!) (Nor a QNI must be able to fill = > > all three priority parameters. > > A QNI only fills those parameters it cares about) >=20 > Georgios: regarding a) > Yes, I know that the current version specifies that the QNI does NOT=20 > need to include every parameter. > And that is exactly what creates the problems mentioned by me. If the=20 > QNI will be required to include these parameters, then most of the=20 > remapping problems within the network are solved. > This is because the QNI will actually do the remapping by itself and=20 > it will have a better knowledge on accepting or rejecting a requested=20 > reservation. > For example, if we look to the QoS Class parameters, each of the QoS=20 > class parameters are usefull in some setting and impossible in other=20 > settings. In order to make the class> > parameter always possible we can do that by requiring that the QNI=20 > must include all three QoS class parameters, then a QNE can choose the = > one that it needs. Note that if a QNI is interested only in one of=20 > them, say , then the QNI Could set this parameter as = > QSPEC-1 parameter. However, in this case the QNI MUST also fill in the = > other two parameters, i.e., and , which=20 > can be set as QSPEC-2 parameters. > In this way it will be possible for any QNE to remap the value of the > QSPEC-1 parameter, e.g., > into either or .=20 > Furthermore, > the QNI will have all the knowledge > On which method has been used for the remapping of the =20 > parameter. >=20 > > b) Doubtlessly there is no perfect mapping between the individual=20 > > parameters. But then the goal of QoS NSLP is interoperability. And=20 > > this is only possible when allowing an (imperfect) mapping. >=20 > Georgios: regarding b) > I am not talking about imperfect mapping, but I am referring to an=20 > impossible mapping. > Could you please provide me with two examples: > 1) Please provide an example of remapping of the =20 > parameter into parameter > 2) Please provide an example of remapping of the =20 > parameter into parameter >=20 >=20 > Many thanks in adavance! > Best Regards, > Georgios >=20 >=20 >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > Gesendet: Montag, 25. September 2006 17:22 > > An: Kappler, Cornelia; 'Ash, Gerald R (Jerry), ALABS'; > 'Attila B=E1der > > (IJ/ETH)' > > Cc: nsis@ietf.org > > Betreff: RE: [NSIS] AW: Recommendation on QSpec-1 parameters > >=20 > > Hi Cornelia > >=20 > > The problems that I have found with these parameters are: > >=20 > > 1) Not all QSPEC-1 parameters are necessary to provide the=20 > > interoperability. > > For example, the QNE must support each parameter even if that=20 > > parameter causes a collapse in > > the network performance, e.g., .=20 > >=20 > > 2) There are 4 sets of QSPEC-1 parameters: , ,=20 > > > Treatment> > > . Each of these sets includes more than one parameter,=20 > > e.g., > > includes the , and QoS class> > > parameters. However, > > in the current version of QSpec template, a QNI must include at=20 > > least one > >=20 > > of the parameters. Thus, for example, consider that a > QNI includes > > either a > > a or a . Based on > the current > > QSpec template specification > > a diffserv based QNE must be able to interpret a class type> > > and a > > =20 > > even if it cannot do that! Please note that I do not > think that it > > is possible > > to remap a or a > parameter into > > a PHB class parameter. > >=20 > >=20 > > Below you can find a copy of the e-mail that I have sent > this morning > > that describes these issues in a more detailed way: > >=20 > > --------------------- > >=20 > >=20 > > * Regarding the , the RMD QNEs should be able to=20 > > choose the most efficient way for excess treatment in order to for=20 > > example, solve severe congestion situations. > > If this parameter is mandatory, this will mean that the end > QNI will > > dictate what kind of excess treatment should be used by each QNE in=20 > > the RMD domain. > > This will limit the way of how the severe congestion is solved. > >=20 > > Note that in a severe congestion situation, typically most packets=20 > > will be dropped! However, if the is > mandatory and > > the end QNI dictates that the packets should be remarked and not=20 > > dropped, then all the nodes that are under severe > congestion will keep > > the congestion and the network will very quickly collapse. > >=20 > >=20 > > * Regarding and , if both are included in=20 > > the > desired> or then a QNE can choose the one of the two > > parameters. > >=20 > > A problem may arise from the fact that the QNI will not > know which of > > the one is used by the QNEs. > > One solution of this problem can be solved in the following way: > > If a QNI is willing to use the parameter as > mandatory, > > then the QNI must include the parameter as QSPEC-1=20 > > parameter and it must also inlcude the parameter as > > QSPEC-2 parameter. > > If a QNE cannot use the , then it will use > the optional > > parameter and will set the "R" and "Q" flags associated=20 > > with the parameter. > > When is chosen as QSPEC-1 parameter, then > Bucket> is > > chosen as > > QSPEC-2 parameter. A similar method of remapping as described above=20 > > can be followed. > > Note that in this case the way of how the remapping of one > > QSPEC-1 parameter > > value into another value is specified by the QNI.=20 > >=20 > >=20 > > * Regarding , the mentioned solution regarding the=20 > > remapping from high to normal by appling a degradation of high=20 > > priority to normal priority, maybe can help, but the main problem=20 > > that I have is the fact that all four parameters are=20 > > mandatory and for a QOSM that uses one of the four =20 > > parameters, it is difficult to remap one of the > > > parameters into another one. > >=20 > > If a QNI includes all 4 parameters, then a QNE can choose = > > the one that it needs! Note that a QNI should be able to fill all 4=20 > > QSPEC-1 parameters. This is the same situation as the=20 > > situation that a QNE should be able to process all QSPEC-1=20 > > parameters. > > A problem may arise from the fact that the QNI will not know which=20 > > of the one is used by the QNEs. > > One solution of this problem can be solved in the following way: > > Make only one of the four parameters QSPEC-1 parameter.=20 > > The QNI must include all the other three parameters as > > QSPEC-2 parameters. > > The way of how the remapping is done is similar to the explanation=20 > > that I give above regarding and =20 > > parameters. > >=20 > >=20 > > * The problem with the QoS class parameters is that it is=20 > > very difficult to > > remap One of the QoS class parameters into another parameter.=20 > > In my previous > > e-mails I emphasized that each of the QoS class parameters=20 > > are usefull in > > some setting and useless in other settings. In order to make=20 > > the > > parameter always usefull We can do that by requiring that=20 > the QNI must > > include all three QoS class parameters, then a QNE can choose=20 > > the one that > > it needs. Note that a QNI should be able to fill all 3=20 > > QSPEC-1 > > parameters. This is the same situation as the situation that=20 > > a QNE should be > > able to process all QSPEC-1 parameters. > >=20 > > ---------------------------------- > >=20 > > Best Regards, > > Georgios > >=20 > > -----Original Message----- > > From: Kappler, Cornelia [mailto:cornelia.kappler@siemens.com]=20 > > Sent: maandag 25 september 2006 13:53 > > To: Georgios Karagiannis; Ash, Gerald R (Jerry), ALABS; Attila = B=E1der > > (IJ/ETH) > > Cc: nsis@ietf.org > > Subject: [NSIS] AW: Recommendation on QSpec-1 parameters > >=20 > > Hi Georgios,=20 > >=20 > > essentially you would include always all parameters into the=20 > > QSPEC. The goal > > of the QSPEC exercise was however right the contrary: gain=20 > > interoperability > > by allowing (may be unprecise) "x-interpretation" of=20 > > parameters. So I think > > your proposal is - while entirely possible - not in the=20 > > spirit of the draft. > > There are other possibilities if you make slight compromises=20 > > (regarding (i) > > the exact interpretation of QNI parameters and (ii) what a=20 > > QNE must be able > > to do (note in the RMD case these are just the stateful=20 > edge QNEs!))=20 > >=20 > > Cornelia=20 > >=20 > > > -----Urspr=FCngliche Nachricht----- > > > Von: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > Gesendet: Freitag, 22. September 2006 11:25 > > > An: 'Ash, Gerald R (Jerry), ALABS'; Kappler, Cornelia;=20 > > 'Attila B=E1der=20 > > > (IJ/ETH)' > > > Cc: nsis@ietf.org > > > Betreff: Recommendation on QSpec-1 parameters > > >=20 > > > Hi Jerry, Cornelia and Attila > > >=20 > > > I have made an exercise and tried to apply and use the > > > QPSEC-1 (mandatory) and QSPEC-2 (optional) parameters into the=20 > > > RMD-QOSM. Please note that in my opinion one might get the same=20 > > > conclusions if another edge-to-edge QOSM will be used, e.g., the=20 > > > future PCN QOSM. > > >=20 > > >=20 > > > My conclusions are as follows: > > >=20 > > > 1) and parameters should be QSPEC-1=20 > > > paramteres, > > > but then=20 > > > a QNI MUST include both. A QNE that receives both these=20 > > > parameters must: > > >=20 > > > * either strictly interpret at least one of the=20 > > > parameters. In this case > > > the "R"=20 > > > flag and "Q" flags MUST not be set. > > >=20 > > > * or remap one of the parameters into another parameter=20 > > > (e.g. > > Bucket> into > > > In this case the remapped parameter (e.g., > > > has to set the flag. The flag should also be set. > > >=20 > > >=20 > > >=20 > > > 2) The parameter influences the way of how the=20 > > > data packets should be treated within an edge-to-edge domain. > > > In this way the solutions that can be provided by RMD-QOSM in=20 > > > situations of=20 > > > e.g., severe congestion are limited. Note that this also will=20 > > > influence a > > > solution=20 > > > such as PCN in case of solving the preemption issue. > > > My recommendation is to ignore this parameter when it has to=20 > > > be used in > > > such edge-to-edge domains. This means that this parameter=20 > should be=20 > > > * either a QSPEC-2 parameter=20 > > > * or a QSPEC-1 parameter that is able to be ignored=20 > > > in edge-to-edge domains, without that the flags "R" and=20 > > > "Q" flags are > > > set.=20 > > > In the last case the QOSM description should emphasize that > > > this parameter is ignored.=20 > > >=20 > > >=20 > > > 3) : as already mentioned in the last version=20 > of the QSPEC > > > template draft > > > such a parameter cannot be mandatory, because in=20 > several countries > > > preemption of > > > sessions in favour of others is not allowed. Thus this=20 > > > parameter, should > > > either be=20 > > > a QSPEC-2 parameter or a QSPEC-1 that could be in some=20 > > > cases ignored. > > > Further, I would again recommend that all the =20 > > > parameters, MUST > > > be included=20 > > > by a QNI, then a QNE that receives these parameters could: > > > * either strictly interpret at least one of the=20 > > > parameters. In this case > > > the "R"=20 > > > flag and "Q" flags MUST not be set. > > >=20 > > > * or remap one of the parameters into another parameter=20 > > > In this case the remapped parameter > > > has to set the flag. The flag should also be set. > > > =20 > > > 4) : this parameter can be a QSPEC-1 parameter,=20 > > > but a QNI MUST > > > include=20 > > > all parameters, i.e., , > > Type> and=20 > > > . Then a QNE that receives these=20 > > > parameters could: > > > * either strictly interpret at least one of the=20 > > > parameters. In this case > > > the "R"=20 > > > flag and "Q" flags MUST not be set. > > >=20 > > > * or remap one of the parameters into another parameter,=20 > > > e.g., "DSCP" =3D> > > > "PHB ID code" > > > In this case the remapped parameter, e.g., > > > has to set the flag. The flag should also be set. > > >=20 > > > Best Regards, > > > Georgios > > >=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 >=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 Fri Sep 29 06:15:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTFOS-0007Hv-6y; Fri, 29 Sep 2006 06:14:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTFOQ-0007Hp-O0 for nsis@ietf.org; Fri, 29 Sep 2006 06:14:54 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTFOP-0001JN-8V for nsis@ietf.org; Fri, 29 Sep 2006 06:14:54 -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 k8TAER7K001623; Fri, 29 Sep 2006 12:14:31 +0200 (MEST) From: "Georgios Karagiannis" To: "'Jukka MJ Manner'" , "'Bernd Schloer'" Subject: RE: [NSIS] A question to people about QoS NSLP Tear operation Date: Fri, 29 Sep 2006 12:14:23 +0200 Message-ID: <000201c6e3b0$0c933100$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: AcbiywxYLClNvxPdS3yLSXu0VqgFuQA5J8wA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 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]); Fri, 29 Sep 2006 12:14:33 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 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 agree with David that the QNI doesn't need to be concerned with reservations that might have not been torn down because they will be torn down when the soft state expires. This holds also for the error codes you listed in your previous e-mail. Best Regards, Georgios -----Original Message----- From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI] Sent: donderdag 28 september 2006 8:44 To: Bernd Schloer Cc: nsis@ietf.org Subject: Re: [NSIS] A question to people about QoS NSLP Tear operation 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 From nsis-bounces@ietf.org Fri Sep 29 15:31:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTO3y-0002uH-W9; Fri, 29 Sep 2006 15:30:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTO3x-0002tj-2X for nsis@ietf.org; Fri, 29 Sep 2006 15:30:21 -0400 Received: from natlemon.rzone.de ([81.169.145.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTO3v-0006AA-HO for nsis@ietf.org; Fri, 29 Sep 2006 15:30:21 -0400 Received: from [192.168.178.200] (p5484C11A.dip0.t-ipconnect.de [84.132.193.26]) (authenticated bits=0) by post.webmailer.de (8.13.6/8.13.6) with ESMTP id k8TJUG0t014655; Fri, 29 Sep 2006 21:30:17 +0200 (MEST) Message-ID: <451D7441.7070300@cs.uni-goettingen.de> Date: Fri, 29 Sep 2006 21:30: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: Cheng Hong Subject: Re: [NSIS] A question to people about QoS NSLP Tear operation References: <5F09D220B62F79418461A978CA0921BD012F2131@pslexc01.psl.local> In-Reply-To: <5F09D220B62F79418461A978CA0921BD012F2131@pslexc01.psl.local> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 325b777e1a3a618c889460b612a65510 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 Dear Hong and all, the normal case should be that the teardown is understood, where possible an error situation should be recovered and where no recovery is possible the reservation state can be torn down by the soft state expiration. An unrecoverable error could be the wrong SID or the QNI fails because on an empty battery. I think a confirmation of state removal improves network scalability. Bernd soft state expiry. 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 From nsis-bounces@ietf.org Sat Sep 30 04:56:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTadl-0002Z8-NI; Sat, 30 Sep 2006 04:56:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTadj-0002Wq-Sa for nsis@ietf.org; Sat, 30 Sep 2006 04:56:07 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTadh-000336-Pk for nsis@ietf.org; Sat, 30 Sep 2006 04:56:07 -0400 Received: from [192.168.178.22] (pD9E3497B.dip0.t-ipconnect.de [217.227.73.123]) by kyoto.netlab.nec.de (Postfix) with ESMTP id CE1731BAC99; Sat, 30 Sep 2006 10:56:01 +0200 (CEST) In-Reply-To: <951128250608281037w7d34ffc9p4d460f75827814d@mail.gmail.com> References: <951128250608281037w7d34ffc9p4d460f75827814d@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Martin Stiemerling Subject: Re: [NSIS] Responses to TRACE messages Date: Fri, 29 Sep 2006 18:24:56 +0200 To: =?ISO-8859-1?Q?Rui_Vil=E3o?= X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 Rui, The cited text "RESPONSE messages are responses to CREATE and REA =20 messages." has not been adapted to fit also the TRACE response case. =20 It must read "RESPONSE messages are responses to CREATE, REA, and TRACE messages." As Hannes has said, we are going to update the section in the new =20 revision of the draft. Thanks Martin Am 28.08.2006 um 19:37 schrieb Rui Vil=E3o: > Hi all, > > I'm having doubts when generating a RESPONSE to TRACE messages. In =20 > section 3.7.6 we can find several times that we have to send a =20 > RESPONSE message, but when we read section 4.3.3, we can find =20 > "RESPONSE messages are responses to CREATE and REA messages.". So =20 > what to do when processing a TRACE message? > > Best regards, > > Rui Vil=E3o > > _______________________________________________ > 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 Sep 30 04:56:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTadp-0002hX-3I; Sat, 30 Sep 2006 04:56:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTado-0002gz-3x for nsis@ietf.org; Sat, 30 Sep 2006 04:56:12 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTadh-000334-Pk for nsis@ietf.org; Sat, 30 Sep 2006 04:56:12 -0400 Received: from [192.168.178.22] (pD9E3497B.dip0.t-ipconnect.de [217.227.73.123]) by kyoto.netlab.nec.de (Postfix) with ESMTP id AE5081BAC4D; Sat, 30 Sep 2006 10:56:00 +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: <75EC7E7A-8BD8-4156-9962-E0F56AA72557@netlab.nec.de> Content-Transfer-Encoding: 7bit From: Martin Stiemerling DFrom nsis-bounces@ietf.org Sat Sep 30 04:56:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTadl-0002Z8-NI; Sat, 30 Sep 2006 04:56:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTadj-0002Wq-Sa for nsis@ietf.org; Sat, 30 Sep 2006 04:56:07 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTadh-000336-Pk for nsis@ietf.org; Sat, 30 Sep 2006 04:56:07 -0400 Received: from [192.168.178.22] (pD9E3497B.dip0.t-ipconnect.de [217.227.73.123]) by kyoto.netlab.nec.de (Postfix) with ESMTP id CE1731BAC99; Sat, 30 Sep 2006 10:56:01 +0200 (CEST) In-Reply-To: <951128250608281037w7d34ffc9p4d460f75827814d@mail.gmail.com> References: <951128250608281037w7d34ffc9p4d460f75827814d@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Martin Stiemerling Subject: Re: [NSIS] Responses to TRACE messages Date: Fri, 29 Sep 2006 18:24:56 +0200 To: =?ISO-8859-1?Q?Rui_Vil=E3o?= X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 Rui, The cited text "RESPONSE messages are responses to CREATE and REA =20 messages." has not been adapted to fit also the TRACE response case. =20 It must read "RESPONSE messages are responses to CREATE, REA, and TRACE messages." As Hannes has said, we are going to update the section in the new =20 revision of the draft. Thanks Martin Am 28.08.2006 um 19:37 schrieb Rui Vil=E3o: > Hi all, > > I'm having doubts when generating a RESPONSE to TRACE messages. In =20 > section 3.7.6 we can find several times that we have to send a =20 > RESPONSE message, but when we read section 4.3.3, we can find =20 > "RESPONSE messages are responses to CREATE and REA messages.". So =20 > what to do when processing a TRACE message? > > Best regards, > > Rui Vil=E3o > > _______________________________________________ > 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 Sep 30 04:56:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTadp-0002hX-3I; Sat, 30 Sep 2006 04:56:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTado-0002gz-3x for nsis@ietf.org; Sat, 30 Sep 2006 04:56:12 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTadh-000334-Pk for nsis@ietf.org; Sat, 30 Sep 2006 04:56:12 -0400 Received: from [192.168.178.22] (pD9E3497B.dip0.t-ipconnect.de [217.227.73.123]) by kyoto.netlab.nec.de (Postfix) with ESMTP id AE5081BAC4D; Sat, 30 Sep 2006 10:56:00 +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: <75EC7E7A-8BD8-4156-9962-E0F56AA72557@netlab.nec.de> Content-Transfer-Encoding: 7bit From: Martin Stiemerling Date: Fri, 29 Sep 2006 18:22:08 +0200 To: Christian Dickmann X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: nsis_imp@informatik.uni-goettingen.de, nsis-imp@lists.ietf.org, nsis@ietf.org Subject: [NSIS] Re: [Nsis_imp] NSIS for end users - It's reality X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org All NSIS-team@Goettingen, Congrats for the good work! Martin Am 28.09.2006 um 13:14 schrieb Christian Dickmann: > Hi, > > > > the NSIS team of the University of Goettingen is proud to announce > the release of a new development version of our NSIS package, which > offers a lot of new features. We now support Traffic Control (tc) > on Linux to really reserve resources and allow the integration of > NSIS/QoS into applications by offering a QoS NSLP API. This > development version also comes with a lot of bugfixes and updates > to new draft versions of GIST and QoS NSLP. > > > > However, the most exciting new feature is the support for Windows > XP and OpenWRT[1]! > > > > The Windows XP version is a demonstration prototype, which is able > to detect the UDP port used by Skype[2] and trigger the local QoS > NSLP daemon to request resources for phone calls. > > In addition, we support OpenWRT, which is a Linux distribution for > embedded devices, i.e. broadband Wireless LAN / DSL routers. On a > lot of such routers, like the Linksys WRT54G (see the OpenWRT > homepage[1] for a list of supported hardware), OpenWRT can be > installed as an alternative firmware. > > > > All new features combined, NSIS usage in SOHO networks becomes > reality! > > The Windows machine triggers the request and the DSL router > reserves the resources by the use of the Traffic Control tool. > > > > You can find the development versions for all platforms of the NSIS > package on our beta version page. The ChangeLog which lists all > changes is also available on that page. Please see the individual > README files on how to use the packages. > > > > http://user.informatik.uni-goettingen.de/~nsis/beta.html > > > > We encourage anyone to try this development version and appreciate > feedback of any kind, such as installation/setup experience, bug > reports, feature requests, etc. > > > > Christian Dickmann > > On behalf of University of Goettingen NSIS team > > > > [1] OpenWRT: http://www.openwrt.org > > [2] Skype: http://www.skype.com > > > > _______________________________________________ > Nsis_Imp mailing list > Nsis_Imp@informatik.uni-goettingen.de > https://user.informatik.uni-goettingen.de/mailman/listinfo/nsis_imp _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis ate: Fri, 29 Sep 2006 18:22:08 +0200 To: Christian Dickmann X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: nsis_imp@informatik.uni-goettingen.de, nsis-imp@lists.ietf.org, nsis@ietf.org Subject: [NSIS] Re: [Nsis_imp] NSIS for end users - It's reality X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org All NSIS-team@Goettingen, Congrats for the good work! Martin Am 28.09.2006 um 13:14 schrieb Christian Dickmann: > Hi, > > > > the NSIS team of the University of Goettingen is proud to announce > the release of a new development version of our NSIS package, which > offers a lot of new features. We now support Traffic Control (tc) > on Linux to really reserve resources and allow the integration of > NSIS/QoS into applications by offering a QoS NSLP API. This > development version also comes with a lot of bugfixes and updates > to new draft versions of GIST and QoS NSLP. > > > > However, the most exciting new feature is the support for Windows > XP and OpenWRT[1]! > > > > The Windows XP version is a demonstration prototype, which is able > to detect the UDP port used by Skype[2] and trigger the local QoS > NSLP daemon to request resources for phone calls. > > In addition, we support OpenWRT, which is a Linux distribution for > embedded devices, i.e. broadband Wireless LAN / DSL routers. On a > lot of such routers, like the Linksys WRT54G (see the OpenWRT > homepage[1] for a list of supported hardware), OpenWRT can be > installed as an alternative firmware. > > > > All new features combined, NSIS usage in SOHO networks becomes > reality! > > The Windows machine triggers the request and the DSL router > reserves the resources by the use of the Traffic Control tool. > > > > You can find the development versions for all platforms of the NSIS > package on our beta version page. The ChangeLog which lists all > changes is also available on that page. Please see the individual > README files on how to use the packages. > > > > http://user.informatik.uni-goettingen.de/~nsis/beta.html > > > > We encourage anyone to try this development version and appreciate > feedback of any kind, such as installation/setup experience, bug > reports, feature requests, etc. > > > > Christian Dickmann > > On behalf of University of Goettingen NSIS team > > > > [1] OpenWRT: http://www.openwrt.org > > [2] Skype: http://www.skype.com > > > > _______________________________________________ > Nsis_Imp mailing list > Nsis_Imp@informatik.uni-goettingen.de > https://user.informatik.uni-goettingen.de/mailman/listinfo/nsis_imp _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sat Sep 30 07:02:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTcbE-0007ga-6j; Sat, 30 Sep 2006 07:01:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTcbD-0007gV-Ef for nsis@ietf.org; Sat, 30 Sep 2006 07:01:39 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTcb9-0005JF-Nq for nsis@ietf.org; Sat, 30 Sep 2006 07:01: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 k8UB1Mcu021685; Sat, 30 Sep 2006 13:01:22 +0200 (MEST) Received: from janus.cs.utwente.nl (janus [130.89.10.26]) by zeus.cs.utwente.nl (8.12.10/8.12.10) with ESMTP id k8UB1J1h018686; Sat, 30 Sep 2006 13:01:22 +0200 (MEST) Received: (from nobody@localhost) by janus.cs.utwente.nl (8.11.7p1+Sun/8.10.2) id k8UB1Bb17094; Sat, 30 Sep 2006 13:01:11 +0200 (MEST) Date: Sat, 30 Sep 2006 13:01:11 +0200 (MEST) X-Authentication-Warning: janus.cs.utwente.nl: nobody set sender to karagian@cs.utwente.nl using -f To: bschloer@cs.uni-goettingen.de, Hong.Cheng@sg.panasonic.com 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; Sat, 30 Sep 2006 11:01:10 +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: <3ZtaKfQT.1159614070.0836420.karagian@ewi.utwente.nl> In-Reply-To: <451D7441.7070300@cs.uni-goettingen.de> 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.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]); Sat, 30 Sep 2006 13:01:25 +0200 (MEST) X-Spam-Score: 0.1 (/) X-Scan-Signature: 515708a075ffdf0a79d1c83b601e2afd 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 I think that there might be a misunderstanding in the meaning of this thread. I think that all of us agree that an explicit tear (release) procedure must be used. Thus a RESERVE with a Tear (T) flag set will be used when an explicit tear (release) procedure is required. The open issue is related to weather it should be possible for the QNI (QNE) to include an RII object in the tear RESERVE in order to subsequently receive a RESPONSE from the QNR. In this way the QNI (QNE) will know that the tear down procedure was sucessful. Best Regards, Georgios On 9/29/2006, "Bernd Schloer" wrote: >Dear Hong and all, > >the normal case should be that the teardown is understood, >where possible an error situation should be recovered and >where no recovery is possible the reservation state can be >torn down by the soft state expiration. > >An unrecoverable error could be the wrong SID or the QNI >fails because on an empty battery. I think a confirmation >of state removal improves network scalability. > >Bernd > > >soft state expiry. > >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 Sat Sep 30 08:39:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTe74-00016c-3o; Sat, 30 Sep 2006 08:38:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTe72-00016T-Ge for nsis@ietf.org; Sat, 30 Sep 2006 08:38:36 -0400 Received: from natklopstock.rzone.de ([81.169.145.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTe71-0000ed-Ue for nsis@ietf.org; Sat, 30 Sep 2006 08:38:36 -0400 Received: from [192.168.178.200] (p5484AF54.dip0.t-ipconnect.de [84.132.175.84]) (authenticated bits=0) by post.webmailer.de (8.13.6/8.13.6) with ESMTP id k8UCc72t019651; Sat, 30 Sep 2006 14:38:07 +0200 (MEST) Message-ID: <451E6527.9040903@cs.uni-goettingen.de> Date: Sat, 30 Sep 2006 14:37:59 +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: Georgios Karagiannis Subject: Re: [NSIS] A question to people about QoS NSLP Tear operation References: <3ZtaKfQT.1159614070.0836420.karagian@ewi.utwente.nl> In-Reply-To: <3ZtaKfQT.1159614070.0836420.karagian@ewi.utwente.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 918f4bd8440e8de4700bcf6d658bc801 Cc: Hong.Cheng@sg.panasonic.com, "nsis@ietf.org" , Jukka MJ Manner X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.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, one question was whether it should be possible to include a RII object in the teardown msg to get a confirmation of state removal. Another question was whether a teardown can cause an error situation and how this error situation is handled. When the Reserve with set T-Flag is not accepted, an error message could be sent back or the message could be ignored which causes state removal by soft-state expiration. My idea then was that the error situation could potentially be fixed when the QNI gets informed and that for network scalability reasons this should be preferred. I can't see a misunderstanding so far. Please see also http://www1.ietf.org/mail-archive/web/nsis/current/msg06745.html Best Regards, Bernd Georgios Karagiannis wrote: > Hi all > > I think that there might be a misunderstanding in the meaning of this > thread. > I think that all of us agree that an explicit tear (release) procedure > must be used. Thus a RESERVE with a Tear (T) flag set will be used when > an explicit tear (release) procedure is required. > > The open issue is related to weather it should be possible for the QNI > (QNE) to include an RII object in the tear RESERVE in order to > subsequently receive a RESPONSE from the QNR. In this way the QNI (QNE) > will know that the tear down procedure was sucessful. > > Best Regards, > Georgios > > > > On 9/29/2006, "Bernd Schloer" wrote: > > >>Dear Hong and all, >> >>the normal case should be that the teardown is understood, >>where possible an error situation should be recovered and >>where no recovery is possible the reservation state can be >>torn down by the soft state expiration. >> >>An unrecoverable error could be the wrong SID or the QNI >>fails because on an empty battery. I think a confirmation >>of state removal improves network scalability. >> >>Bernd >> >> >>soft state expiry. >> >>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/nsi > > s _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sat Sep 30 11:59:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GThEb-0002ZM-W9; Sat, 30 Sep 2006 11:58:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GThEa-0002ZG-Eq for nsis@ietf.org; Sat, 30 Sep 2006 11:58:36 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GThEV-0006NZ-HD for nsis@ietf.org; Sat, 30 Sep 2006 11:58:36 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-5.tower-120.messagelabs.com!1159631908!10002911!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 23045 invoked from network); 30 Sep 2006 15:58:29 -0000 Received: from unknown (HELO attrh9i.attrh.att.com) (134.24.146.4) by server-5.tower-120.messagelabs.com with SMTP; 30 Sep 2006 15:58:29 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh9i.attrh.att.com (8.13.7/8.13.7) with ESMTP id k8UFqbcn029796; Sat, 30 Sep 2006 11:52:38 -0400 (EDT) Received: from kcclust06evs1.ugd.att.com (kcst12.ugd.att.com [135.38.164.89]) by attrh9i.attrh.att.com (8.13.7/8.13.7) with ESMTP id k8UFqOYb029749; Sat, 30 Sep 2006 11:52:25 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: Question on QSPEC Implementation (was RE: [NSIS] NSIS for end users - It's reality) Date: Sat, 30 Sep 2006 10:58:14 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7DD7@KCCLUST06EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question on QSPEC Implementation (was RE: [NSIS] NSIS for end users - It's reality) thread-index: Acbi8LoxXMKAMt3cQHaZTwSNFzJ2CwBtcGHA From: "Ash, Gerald R \(Jerry\), ALABS" To: "Christian Dickmann" , , X-Spam-Score: 0.1 (/) X-Scan-Signature: 32604d42645517c44d778f1d111b40a6 Cc: "Ash, Gerald R \(Jerry\), ALABS" , =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= , nsis_imp@informatik.uni-goettingen.de, "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: , Content-Type: multipart/mixed; boundary="===============1869182757==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============1869182757== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6E4A9.3CBBBE25" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6E4A9.3CBBBE25 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Christian, All, =20 Congratulations on this significant accomplishment! =20 We have a question regarding QSPEC implementation. In Section 4.3.3.1 = (Reservation Failure & Error E-Flag) of the QSPEC draft = http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-11.txt = we = describe the dual use of the E-flag. =20 We'd like your opinion and others' opinion on the NSIS implementation = list RE a possible issue with the 'overloading' of the E-Flag. As = described in Section 4.3.3.1 the E-flag has a dual purpose and can mean = either 'QSPEC parameter not met' or 'QSPEC parameter error'. As = described, if the E flag is set for erroneous parameters, it MUST NOT be = set for parameters not met, and visa versa. I.e., the use of the E flag = is completely disjoint for the two cases. =20 =20 However, what if a QSPEC contains n parameters. The RMF parses the = parameters sequentially, and the first parameter is not met and its = E-Flag is raised. The parsing continues, everything is fine. But the = nth parameter is erroneous. Its E-Flag is raised. What we currently = require is the RMF goes back to the first parameter and unsets the = E-Flag. =20 Is this an implementation problem big enough that it would warrant an = additional flag to distinguish the 2 cases? We would prefer not to = introduce another flag unless this is seen as a significant problem. =20 Your opinion on this would be helpful since you have already developed a = prototype QSPEC implementation. =20 Thanks, Jerry, Cornelia, Attila =20 ________________________________ From: Christian Dickmann [mailto:mail@christian-dickmann.de]=20 Sent: Thursday, September 28, 2006 7:15 AM To: nsis-imp@lists.ietf.org; nsis@ietf.org Cc: nsis_imp@informatik.uni-goettingen.de Subject: [NSIS] NSIS for end users - It's reality Hi, =20 the NSIS team of the University of Goettingen is proud to announce the = release of a new development version of our NSIS package, which offers a = lot of new features. We now support Traffic Control (tc) on Linux to = really reserve resources and allow the integration of NSIS/QoS into = applications by offering a QoS NSLP API. This development version also = comes with a lot of bugfixes and updates to new draft versions of GIST = and QoS NSLP.=20 =20 However, the most exciting new feature is the support for Windows XP and = OpenWRT[1]! =20 The Windows XP version is a demonstration prototype, which is able to = detect the UDP port used by Skype[2] and trigger the local QoS NSLP = daemon to request resources for phone calls. In addition, we support OpenWRT, which is a Linux distribution for = embedded devices, i.e. broadband Wireless LAN / DSL routers. On a lot of = such routers, like the Linksys WRT54G (see the OpenWRT homepage[1] for a = list of supported hardware), OpenWRT can be installed as an alternative = firmware. =20 All new features combined, NSIS usage in SOHO networks becomes reality!=20 The Windows machine triggers the request and the DSL router reserves the = resources by the use of the Traffic Control tool. =20 You can find the development versions for all platforms of the NSIS = package on our beta version page. The ChangeLog which lists all changes = is also available on that page. Please see the individual README files = on how to use the packages. =20 http://user.informatik.uni-goettingen.de/~nsis/beta.html =20 We encourage anyone to try this development version and appreciate = feedback of any kind, such as installation/setup experience, bug = reports, feature requests, etc. =20 Christian Dickmann On behalf of University of Goettingen NSIS team =20 [1] OpenWRT: http://www.openwrt.org [2] Skype: http://www.skype.com =20 ------_=_NextPart_001_01C6E4A9.3CBBBE25 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Christian, All,
 
Congratulations on this significant=20 accomplishment!
 
We have a question regarding QSPEC = implementation.  In=20 Section 4.3.3.1=20 (Reservation Failure & Error E-Flag) of the QSPEC draft http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-11.txt we describe the dual use of = the=20 E-flag. 

We'd like your opinion = and others'=20 opinion on the NSIS implementation list RE a possible issue=20 with the 'overloading' of the E-Flag.  As described in Section = 4.3.3.1 the E-flag=20 has a dual purpose and can mean either 'QSPEC parameter not = met' or 'QSPEC parameter error'.  As = described,=20 if the E flag is set for erroneous parameters, it MUST NOT be set for = parameters=20 not met, and visa versa.  I.e., the=20 use of the E flag is completely disjoint for the two cases. 

 

However,=20 what if a QSPEC contains n parameters. The RMF parses the = parameters=20 sequentially, and the first parameter is not=20 met and its E-Flag is raised. =20 The parsing continues, everything is fine.  But the nth parameter is erroneous. = Its E-Flag=20 is raised.  What we = currently require=20 is the RMF goes back to the first parameter and unsets the E-Flag.

 

Is this an implementation problem big enough = that it=20 would warrant an additional flag to distinguish the 2 cases?  We = would=20 prefer not to introduce another flag unless this is seen as a = significant=20 problem.

 

Your opinion on this would be helpful since = you have=20 already developed a prototype QSPEC=20 implementation.

 

Thanks,

Jerry, Cornelia,=20 Attila

=
 
From: = Christian Dickmann=20 [mailto:mail@christian-dickmann.de]
Sent: Thursday, September = 28,=20 2006 7:15 AM
To: nsis-imp@lists.ietf.org; = nsis@ietf.org
Cc:=20 nsis_imp@informatik.uni-goettingen.de
Subject: [NSIS] NSIS for = end=20 users - It's reality

Hi,

 

the NSIS team of the University of Goettingen is proud to announce = the=20 release of a new development version of our NSIS package, which offers a = lot of=20 new features. We now support Traffic Control (tc) on Linux to really = reserve=20 resources and allow the integration of NSIS/QoS into applications by = offering a=20 QoS NSLP API. This development version also comes with a lot of bugfixes = and=20 updates to new draft versions of GIST and QoS NSLP.=20

 

However, the most exciting new feature is the = support=20 for Windows XP and OpenWRT[1]!

 

The Windows XP version is a demonstration = prototype,=20 which is able to detect the UDP port used by Skype[2] and trigger the = local QoS=20 NSLP daemon to request resources for phone = calls.

In addition, we support OpenWRT, which is a = Linux=20 distribution for embedded devices, i.e. broadband Wireless LAN / DSL = routers. On=20 a lot of such routers, like the Linksys WRT54G (see the OpenWRT = homepage[1] for=20 a list of supported hardware), OpenWRT can be installed as an = alternative=20 firmware.

 

All new features combined, NSIS usage in = SOHO networks becomes reality!=20

The Windows machine triggers the request and = the DSL=20 router reserves the resources by the use of the Traffic Control=20 tool.

 

You can find the development versions for all = platforms=20 of the NSIS package on our beta version page. The ChangeLog which lists = all=20 changes is also available on that page. Please see the individual README = files=20 on how to use the packages.

 

http://user.informatik.uni-goettingen.de/~nsis/beta.html=

 

We encourage anyone to try this development = version and=20 appreciate feedback of any kind, such as installation/setup experience, = bug=20 reports, feature requests, etc.

 

Christian=20 Dickmann

On behalf of University of Goettingen=20 NSIS team

 

[1] OpenWRT:=20 http://www.openwrt.org

[2] Skype:=20 http://www.skype.com

 

------_=_NextPart_001_01C6E4A9.3CBBBE25-- --===============1869182757== 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 --===============1869182757==-- From nsis-bounces@ietf.org Sat Sep 30 12:33:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GThln-00011G-6B; Sat, 30 Sep 2006 12:32:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GThlm-00011B-7V for nsis@ietf.org; Sat, 30 Sep 2006 12:32:54 -0400 Received: from natreg.rzone.de ([81.169.145.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GThll-0007jb-MB for nsis@ietf.org; Sat, 30 Sep 2006 12:32:54 -0400 Received: from [192.168.178.200] (p5484AF54.dip0.t-ipconnect.de [84.132.175.84]) (authenticated bits=0) by post.webmailer.de (8.13.6/8.13.6) with ESMTP id k8UGWnb7024304; Sat, 30 Sep 2006 18:32:49 +0200 (MEST) Message-ID: <451E9C27.80603@cs.uni-goettingen.de> Date: Sat, 30 Sep 2006 18:32:39 +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: Cheng Hong Subject: Re: [NSIS] A question to people about QoS NSLP Tear operation References: <5F09D220B62F79418461A978CA0921BD012F2131@pslexc01.psl.local> In-Reply-To: <5F09D220B62F79418461A978CA0921BD012F2131@pslexc01.psl.local> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 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, 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 From nsis-bounces@ietf.org Sat Sep 30 13:06:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTiHI-0005h3-C1; Sat, 30 Sep 2006 13:05:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTiHH-0005gx-6J for nsis@ietf.org; Sat, 30 Sep 2006 13:05:27 -0400 Received: from natblert.rzone.de ([81.169.145.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTiHD-0007Wj-IX for nsis@ietf.org; Sat, 30 Sep 2006 13:05:27 -0400 Received: from [192.168.178.200] (p5484AF54.dip0.t-ipconnect.de [84.132.175.84]) (authenticated bits=0) by post.webmailer.de (8.13.6/8.13.6) with ESMTP id k8UH5AwD008225; Sat, 30 Sep 2006 19:05:11 +0200 (MEST) Message-ID: <451EA3BD.4000306@schloer.net> Date: Sat, 30 Sep 2006 19:05:01 +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: "Ash, Gerald R \(Jerry\), ALABS" Subject: Re: Question on QSPEC Implementation (was RE: [NSIS] NSIS for end users - It's reality) References: <9473683187ADC049A855ED2DA739ABCA0DDC7DD7@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC7DD7@KCCLUST06EVS1.ugd.att.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: nsis_imp@informatik.uni-goettingen.de, nsis@ietf.org, nsis-imp@lists.ietf.org, =?ISO-8859-1?Q?der_=28IJ/ETH=29=22?= , =?ISO-8859-1?Q?=22Attila_B=E1?=, "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 Jerry and all, :-) I believe that this is not a big problem. Even if the RMF parses the parameters sequentially, the whole object can be accessed any time. You can do the manipulation on the object level or you can consider the QSPEC as a (char-)array and the manipulation can be done on the byte- or bit-level. And it is passed as an entire object back to the NSLP. Bernd Ash, Gerald R (Jerry), ALABS wrote: > Christian, All, > > Congratulations on this significant accomplishment! > > We have a question regarding QSPEC implementation. In Section 4.3.3.1 (Reservation Failure & Error E-Flag) of the QSPEC draft http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-11.txt we describe the dual use of the E-flag. > > We'd like your opinion and others' opinion on the NSIS implementation list RE a possible issue with the 'overloading' of the E-Flag. As described in Section 4.3.3.1 the E-flag has a dual purpose and can mean either 'QSPEC parameter not met' or 'QSPEC parameter error'. As described, if the E flag is set for erroneous parameters, it MUST NOT be set for parameters not met, and visa versa. I.e., the use of the E flag is completely disjoint for the two cases. > > > > However, what if a QSPEC contains n parameters. The RMF parses the parameters sequentially, and the first parameter is not met and its E-Flag is raised. The parsing continues, everything is fine. But the nth parameter is erroneous. Its E-Flag is raised. What we currently require is the RMF goes back to the first parameter and unsets the E-Flag. > > > > Is this an implementation problem big enough that it would warrant an additional flag to distinguish the 2 cases? We would prefer not to introduce another flag unless this is seen as a significant problem. > > > > Your opinion on this would be helpful since you have already developed a prototype QSPEC implementation. > > > > Thanks, > > Jerry, Cornelia, Attila > > > ________________________________ > > From: Christian Dickmann [mailto:mail@christian-dickmann.de] > Sent: Thursday, September 28, 2006 7:15 AM > To: nsis-imp@lists.ietf.org; nsis@ietf.org > Cc: nsis_imp@informatik.uni-goettingen.de > Subject: [NSIS] NSIS for end users - It's reality > > > > Hi, > > > > the NSIS team of the University of Goettingen is proud to announce the release of a new development version of our NSIS package, which offers a lot of new features. We now support Traffic Control (tc) on Linux to really reserve resources and allow the integration of NSIS/QoS into applications by offering a QoS NSLP API. This development version also comes with a lot of bugfixes and updates to new draft versions of GIST and QoS NSLP. > > > > However, the most exciting new feature is the support for Windows XP and OpenWRT[1]! > > > > The Windows XP version is a demonstration prototype, which is able to detect the UDP port used by Skype[2] and trigger the local QoS NSLP daemon to request resources for phone calls. > > In addition, we support OpenWRT, which is a Linux distribution for embedded devices, i.e. broadband Wireless LAN / DSL routers. On a lot of such routers, like the Linksys WRT54G (see the OpenWRT homepage[1] for a list of supported hardware), OpenWRT can be installed as an alternative firmware. > > > > All new features combined, NSIS usage in SOHO networks becomes reality! > > The Windows machine triggers the request and the DSL router reserves the resources by the use of the Traffic Control tool. > > > > You can find the development versions for all platforms of the NSIS package on our beta version page. The ChangeLog which lists all changes is also available on that page. Please see the individual README files on how to use the packages. > > > > http://user.informatik.uni-goettingen.de/~nsis/beta.html > > > > We encourage anyone to try this development version and appreciate feedback of any kind, such as installation/setup experience, bug reports, feature requests, etc. > > > > Christian Dickmann > > On behalf of University of Goettingen NSIS team > > > > [1] OpenWRT: http://www.openwrt.org > > [2] Skype: http://www.skype.com > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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